Advertisement

Did "1984" have the wrong bad guy?

Started by December 09, 2009 01:51 AM
76 comments, last by superpig 14 years, 10 months ago
Quote: Original post by LessBread
As an aside, a similar thing that happened to Rachel Porcaro happened to one of my cousins, except it wasn't the IRS but the state. My cousin served in the Air Force and was trained as a nurse. After his discharge he got a nursing license and went to work. During his last years in the service he began to suffer epileptic seizures that continued after his discharge. The seizures were determined to be service related and eventually he was given a 100% disability rating by the VA. He could no longer work but kept up his nursing license in the hope that maybe someday he could return to work. In the meantime he receives payments from the government on which he pays no income taxes. The state tax board noted that he had not paid taxes but he had a nursing license, so they sent him a letter claiming that he owed taxes based on the average salary of a nurse at his level of skill. Fortunately for him he was able to clear up the discrepancy with a phone call.


This problem would've been solved by either less inference or more information. I think one of the problems with lack of privacy is that it's usually incomplete. Complete information would lead to fewer false positives.

The other problem is that it's usually one-sided. If everyone knew everything about everyone, there wouldn't be as much of an issue. It'd be something like mutually assured destruction.

Quote: Original post by WazzatMan
You can't logically cast, or convert, a function to an integer


What about Church Encoding?
Quote: What about Church Encoding?


I'm not familiar with that concept, but what I mean is the following does not make sense:

- + *

I cannot add the process of subtracting two numbers with the process of multiplying two numbers. A process is not data, a description of that process is data. When I do the following in scheme:

(let
((times-two (lambda (x) (* x 2))))
(map times-two (list 4 5 6 7))
)

I am giving the map function a description of the process of multiplying a number by two. It cannot do anything more significant with that description than use it to perform the process, or pass it on to another function.

If I write the following:

(let
((times-two (lambda (x) (* x 5))))
(map times-two (list 4 5 6 7))
)


I have not suddenly changed the process of multiplying by two, I have simply changed the description to a description which is incorrect.

Similarly the following does not make sense:

3 1 4

What does one-ing three and four mean? Nothing, because 1 does not describe a process, it describes a quantity.

There is a clear distinction between what an operation is and what an operand is, from the highest to the lowest levels. I cannot simply say they are interchangable. The distinction exists precisely to avoid error.

[Edited by - WazzatMan on December 11, 2009 1:02:23 PM]
Advertisement
Quote: Original post by Oberon_Command
Quote: Original post by Momoko_Fan
I don't care about my privacy, and I don't see why anyone else should.

Really? So you wouldn't care if I installed a camera in your bathroom and made a music video out of the footage it captures of you peeing?

I would like to recommend to both of you "The Eternal Value of Privacy" by Bruce Schneier.

(Incidentally, I agree with Momoko_Fan on one point: I really do not care about his/her privacy. I tend to believe that people who don't care about their privacy don't deserve it ;P)
Widelands - laid back, free software strategy
Quote: Original post by Way Walker
Quote: Original post by LessBread
As an aside, a similar thing that happened to Rachel Porcaro happened to one of my cousins, except it wasn't the IRS but the state. My cousin served in the Air Force and was trained as a nurse. After his discharge he got a nursing license and went to work. During his last years in the service he began to suffer epileptic seizures that continued after his discharge. The seizures were determined to be service related and eventually he was given a 100% disability rating by the VA. He could no longer work but kept up his nursing license in the hope that maybe someday he could return to work. In the meantime he receives payments from the government on which he pays no income taxes. The state tax board noted that he had not paid taxes but he had a nursing license, so they sent him a letter claiming that he owed taxes based on the average salary of a nurse at his level of skill. Fortunately for him he was able to clear up the discrepancy with a phone call.


This problem would've been solved by either less inference or more information. I think one of the problems with lack of privacy is that it's usually incomplete. Complete information would lead to fewer false positives.


I think it was more an indication of the desperation of a deeply indebted State of California to come up with tax revenue. The state had enough information to go fishing, so it went fishing but didn't catch anything.

Quote: Original post by Way Walker
The other problem is that it's usually one-sided. If everyone knew everything about everyone, there wouldn't be as much of an issue. It'd be something like mutually assured destruction.


I'm reminded of the sci-fi trope of humanoid species that can read each others minds.

"I thought what I'd do was, I'd pretend I was one of those deaf-mutes." - the Laughing Man
Quote: Original post by WazzatMan
Quote: What about Church Encoding?


I'm not familiar with that concept, but what I mean is the following does not make sense:

- + *

I cannot add the process of subtracting two numbers with the process of multiplying two numbers.

...

Similarly the following does not make sense:

3 1 4

What does one-ing three and four mean? Nothing, because 1 does not describe a process, it describes a quantity.

There is a clear distinction between what an operation is and what an operand is, from the highest to the lowest levels. I cannot simply say they are interchangable. The distinction exists precisely to avoid error.


Making a distinction between operands and operations doesn't avoid the error since you can still . Mathematically, the following don't make sense, either:

1 / 0
00

Even if the Lisp equivalents make sense (perhaps returning infinity and 1, respectively), that doesn't mean all operations apply to all operands. I don't know Lisp very well (took an intro course that used Scheme nearly a decade ago), but I think the following are nonsense:

(car '())
(cdr '())

even though you're applying a list operation to an operand that's a list. Also, if I stretch my limited understanding likely beyond the breaking point, the only difference between

'(car '(1 2))

and

(car '(1 2))

is that the latter is executed by default, right? So the former is a list containing a function and a list (which may be executed at any time) while the latter executes the same list by applying its first element (which is luckily a function) to the rest of the list (which is luckily a list, the expected data type for the function).

Further, Church Encoding allows you to express integers as processes (n is represented as the process of composing a function with itself n times).
Quote: Original post by Way Walker

(car '())
(cdr '())

even though you're applying a list operation to an operand that's a list. Also, if I stretch my limited understanding likely beyond the breaking point, the only difference between


Not quite. '() is the empty list, which evaluates to NIL, which is not a list. Since car evaluates its parameter before operating on it, meaning that (car '()) actually evaluates (car nil), you're actually applying car to something that is not a list.

Quote:
'(car '(1 2))

and

(car '(1 2))

is that the latter is executed by default, right? So the former is a list containing a function and a list (which may be executed at any time) while the latter executes the same list by applying its first element (which is luckily a function) to the rest of the list (which is luckily a list, the expected data type for the function).


Again, not quite. The first one is just a list. It does not contain a function. It contains the NAME of a function, but it does not contain the function itself. In other words, it's simply a less-verbose equivalent to saying: (list 'car '(1 2)). If you wanted to be REALLY verbose, you could replicate the behavior of your second version (the un-quoted one) by going:

; The code you provided:(car '(1 2)); Verbose, data-driven version; This stores the above expression in a list, then stores that list in; a variable, then applies "funcall" to the variable. Note that nowhere; in the list is the actual function itself - only the name.;; Just as a side note, "funcall" is a Common Lisp function. ; It might be slightly different in Scheme (which I've never used).;(let ((f (cons 'car (cons 1 (cons 2 nil)))))  (funcall (car f) (cdr f))); output:1


edit: whoops, left off some parentheses

[Edited by - Oberon_Command on December 11, 2009 5:29:06 PM]
Advertisement
Quote: Original post by Oberon_Command
Not quite. '() is the empty list, which evaluates to NIL, which is not a list. Since car evaluates its parameter before operating on it, meaning that (car '()) actually evaluates (car nil), you're actually applying car to something that is not a list.


Is it car that evaluates its parameter before operating on it, or does the implementation do that before sending it to car?

Quote:
Quote:
'(car '(1 2))

and

(car '(1 2))

is that the latter is executed by default, right? So the former is a list containing a function and a list (which may be executed at any time) while the latter executes the same list by applying its first element (which is luckily a function) to the rest of the list (which is luckily a list, the expected data type for the function).


Again, not quite. The first one is just a list. It does not contain a function. It contains the NAME of a function, but it does not contain the function itself. In other words, it's simply a less-verbose equivalent to saying: (list 'car (list 1 2)), or even (cons 'car (cons (cons 1 (cons 2 nil)) nil)). You could even replicate the behavior of your second one by going:


(let ((f (cons 'car (cons (cons 1 (cons 2 nil)) nil)))  (funcall (car f) (cdr f)))


What distinction are you making by calling the first one "just a list" as opposed to my "a list containing..."? Is it un-Lisp-like to say that a list contains certain elements?

And the name of a function is a symbol? A string? Can it be manipulated? At what point does it replace the name with the function?

And does any of this affect my point? If it does, could you spell out the difference it makes to what I was saying? It's been a while since I've worked with Scheme so I could very easily be missing the implications of what you're saying. The snippet you put at the end looks, to my eye, to be demonstrating what I was saying. (And there should only be one open parenthesis right after "let", right?)

EDIT: Stop editing your post! I'm not changing mine again. :p
Quote: Original post by Way Walker
Quote: Original post by Oberon_Command
Not quite. '() is the empty list, which evaluates to NIL, which is not a list. Since car evaluates its parameter before operating on it, meaning that (car '()) actually evaluates (car nil), you're actually applying car to something that is not a list.


Is it car that evaluates its parameter before operating on it, or does the implementation do that before sending it to car?


I'm not sure if it makes a difference, since there's nothing else that '() could be (it's NOT actually a list, semantically-speaking, we just treat it as one), but I believe it is the former. [edit:] That seems to be how quote and other special forms work. Functions "proper" might be different.

Quote:
What distinction are you making by calling the first one "just a list" as opposed to my "a list containing..."? Is it un-Lisp-like to say that a list contains certain elements?


You can say that a list contains certain elements, but you can't say that a list containing certain elements makes it in any way NOT a list. The distinction is that there IS no distinction - an unevaluated statement in Lisp is just a list. The code is represented in the same way data is, so the only difference between code and data is that one has meaningful results when it is treated as code.

Quote: And the name of a function is a symbol? A string? Can it be manipulated? At what point does it replace the name with the function?


It is a symbol. It doesn't have any meaning until it is evaluated in some context. If that were not the case, you could not use quoted symbols that aren't actually bound to a variable, function, or macro. That is what the quote operator is actually for; preventing symbols from being evaluated. For instance:

; this statement...(let ((x 5) (y 2))  (cons (+ x y) (list 'x 'y 'z))) ; note that there is no such variable "z", yet we can still use it as a symbol(7 X Y Z) ; ... produces this list; likewise, this one...(list 'cons 'X 'Y)(CONS X Y) ; produces this; and this...(set 'x 1)(set 'y 2)(eval (list 'CONS 'x 'y))(1 . 2)  ; produces this, at least in the Steel Bank Common Lisp implementation


Quote: And does any of this affect my point? If it does, could you spell out the difference it makes to what I was saying? It's been a while since I've worked with Scheme so I could very easily be missing the implications of what you're saying. The snippet you put at the end looks, to my eye, to be demonstrating what I was saying.


I'm not actually disagreeing with your main point. I was just trying to enhance and clarify it by quibbling over details before somebody else who didn't agree with you did.

Quote: (And there should only be one open parenthesis right after "let", right?)


No, there should be two. The first parameter to let is a list of variable associations, which are themselves lists. That confused me at first, too. [grin]

Quote: Having first-class functions doesn't mean you don't see any difference between data and code.


The code/data relationship in Lisp isn't because of the fact that it has first-class functions. That's merely a consequence of the way it treats code in general. In Lisp, code is data. Not all data is code, but all code in Lisp is data and is represented in exactly the same way. The only distinction arises when that data is evaluated by the runtime environment and either fails or produces meaningful results.

edit: Fixed parentheses [grin]

[Edited by - Oberon_Command on December 11, 2009 5:51:44 PM]
Quote: Original post by Oberon_Command
Quote: Original post by Way Walker
What distinction are you making by calling the first one "just a list" as opposed to my "a list containing..."? Is it un-Lisp-like to say that a list contains certain elements?


You can say that a list contains certain elements, but you can't say that a list containing certain elements makes it in any way NOT a list. The distinction is that there IS no distinction - an unevaluated statement in Lisp is just a list. The code is represented in the same way data is, so the only difference between code and data is that one has meaningful results when it is treated as code.


Not to go too far into the Lisp lesson, but my memory was that the quote made it evaluate to the list or symbol itself instead of evaluating it to get a return value. So if x and y were set to 1 and 2, then '(x y) would evaluate to (1 2) and you'd have to write '('x 'y) to get the symbols in the list.
Quote: Original post by Way Walker
Not to go too far into the Lisp lesson, but my memory was that the quote made it evaluate to the list or symbol itself instead of evaluating it to get a return value. So if x and y were set to 1 and 2, then '(x y) would evaluate to (1 2) and you'd have to write '('x 'y) to get the symbols in the list.


No. In Common Lisp, '(x y) evaluates to (X Y) and '('x 'y) evaluates to ('X 'Y). Again, it might be different in Scheme.

edit: Corrected output to upper-case. I need to be more careful when transcribing program outputs, apparently. [grin]

[Edited by - Oberon_Command on December 11, 2009 10:43:57 PM]

This topic is closed to new replies.

Advertisement