Re: [Python-ideas] Ruby-style Blocks in Python Idea
FW: Sorry, forgot to change the subject line for the sake of threaded mail readers and archives.... ---------- Forwarded message ---------- From: "Stephen J. Turnbull" <stephen@xemacs.org> Terry Reedy writes:
I'm glad you're bringing out the cognitive aspect of this, because to me, though it may seem "gratuitously mystical or mystifying" , there is an essential epistemological component to this issue related to the [bidirectional] cognitive mapping of and between mathematical <-- and --> psychological identity and the confusion stems from the inability to frame the issue around a single linear "classical" construct as generally imposed by typed text (did you follow that?). Even writing this sentence confounds my multidimensional meaning which I'm trying to compress into standard language constructs. Normally, I'd use hand gestures and inflection to split out the two different orthogonal aspects of what I'm trying to convey which simply cannot occupy the same space at the same time, but (obviously) that luxury is unavailable here. So in the end, unless there's sufficient purchase in the listener, I have to be somewhat content sounding like a moron spouting gibberish. What Tav's proposal, in my mind, is aiming to do is provide greater syntactic support within Python so as to minimize cognitive gibberish when the code is reified in the mind of the viewer. Of course, it doesn't help that were culturally trained into VonNeuman architecture-thinking were such conflation of dimensionality is built into the hardware itself. Really, like Stephan is pointing out, "re-ification" *IS* the best analogy to help elucidate of this issue (better in German: Verdinglichung). See wikipedia's "Reification (Marxism)" (--though be prepared that, depending on your state of mind, it will either make sense or sound like its logic is [perfectly] backward, like some flipped bit because it borders that special interplay between subject-object.) These kind of [Anonymous] functions/code blocks explicitly tell the user that "This is NOT part of my program", yet (due to the classical, flat nature of standard computer programming) I must "include" (in a constrained way since I'm not able to include the context or externalized identity in which this code will be run) it here [in my editor window text] even though its logical geometry is orthogonal to my program. It's like a vortex out of flatland--an interface into a different dimension, hence it's difficulty in explaining it to the natives of flatlandia. To put a name on it puts an identity label upon something pointing in the wrong direction (i.e. to the surrounding code) which isn't *meant* to be an an independent block of usable code or be part of the social context of its surroundings. It's like seeing your own body's innards mapped inside-out into a computer program and calling it "marcos" while I continue to function normally in some other dimensionality in some mysterious way to magically maintain my normal cognition elsewhere. Better to see those innards as anonymous data (that for whatever reason I'm needing to interface to) even though they are perfectly functioning blocks with an identity elsewhere (i.e.: me). So, yes, "anonymity" can be a virtue from a given perspective. ...Seems to be a parallel to meta-programming but on the other side of the scale--instead of abstracting "upwards" into greater levels of abstraction, it abstracts sideways and downwards into levels of concreteness. Naming in both cases is problematic if you want to avoid the categorical errors easily made by the flatland of the typed text. gibberish? marcos
On Wed, 11 Mar 2009 11:01:41 am average wrote:
These kind of [Anonymous] functions/code blocks explicitly tell the user that "This is NOT part of my program"
I'm a user, and they don't tell me any such thing. By the way, that word, "explicitly" -- I think you are using "explicitly" as if it actually meant "implicitly". If the function were to explicitly tell the user, it would look something like this: caller( function_that_is_not_part_of_the_program x: x+1 ) which of course is ridiculously verbose. What you say might be true if lambda had that extended meaning, but it doesn't. In Python, lambda merely means "create a nameless function object from a single expression". It's also nonsense, because there the function is, inside the program as clear as day. Arguing that a function that appears inside your program is not part of your program is rather like saying that your stomach is not part of your body. Perhaps what you are getting at is that anonymous functions blur the difference between code and data, and that if you consider them as data, then they are outside the program in some sense? That's not entirely unreasonable: it's common to distinguish between code and data, even though fundamentally they're all just bits and, really, the distinction is all in our mind. (That doesn't mean the distinction isn't important.) But even accepting that an anonymous function used as data is outside of the program in some sense, anonymity is strictly irrelevant. If you consider the lambda function here: caller(lambda x: x+1) to be data, then so is the named function foo here: def foo(x): return x+1 caller(foo) [...]
gibberish?
I'm trying to give you the benefit of the doubt. -- Steven D'Aprano
On Wed, 11 Mar 2009 11:01:41 am average wrote:
These kind of [Anonymous] functions/code blocks explicitly tell the user that "This is NOT part of my program"
I'm a user, and they don't tell me any such thing. By the way, that word, "explicitly" -- I think you are using "explicitly" as if it actually meant "implicitly". If the function were to explicitly tell the user, it would look something like this: caller( function_that_is_not_part_of_the_program x: x+1 ) which of course is ridiculously verbose. What you say might be true if lambda had that extended meaning, but it doesn't. In Python, lambda merely means "create a nameless function object from a single expression". It's also nonsense, because there the function is, inside the program as clear as day. Arguing that a function that appears inside your program is not part of your program is rather like saying that your stomach is not part of your body. Perhaps what you are getting at is that anonymous functions blur the difference between code and data, and that if you consider them as data, then they are outside the program in some sense? That's not entirely unreasonable: it's common to distinguish between code and data, even though fundamentally they're all just bits and, really, the distinction is all in our mind. (That doesn't mean the distinction isn't important.) But even accepting that an anonymous function used as data is outside of the program in some sense, anonymity is strictly irrelevant. If you consider the lambda function here: caller(lambda x: x+1) to be data, then so is the named function foo here: def foo(x): return x+1 caller(foo) [...]
gibberish?
I'm trying to give you the benefit of the doubt. -- Steven D'Aprano
participants (2)
-
average -
Steven D'Aprano