UserLinux chooses Python as "interpretive language" of choice

[Bengt Richter]

On Sun, 21 Dec 2003 17:37:10 -0500, "John Roth" <newsgroups at jhrothjr.com> wrote:
[...]
>
>> >It's a non-starter for Python, though.
>
>> Seems so. OTTOMH I guess you could have the tokenizer generate two kinds
>of names,
>> names_as_now, and bare_names (tagged so with lookahead determining no
>trailers).
>> Then you could dynamically check if a bare_name was referring to a
>callable, and
>> call it with no params if so, and for all other name usage do as now.
>Except that as
>> you point out, you'd need a way to inhibit the effect. But since this
>thing would be
>> unusual (and would cause major breakage), maybe it could be enabled only
>for references
>> to objects with an __autocall__ alias to their __call__ attribute. And
>then, since the
>> auto-call would only happen for bare names, you could pass it as a
>function by using
>> name.__call__ instead of name. Or use vars()['name'].
>
>I think that's getting a bit baroque. In fact, after my previous post,
>I realized that I had an unnecessary complexity: it's simpler to just
>auto-execute "all" functions, and let the ones that require parameters
>and don't have them fail like they do today, rather than try to make
>a distinction.
I sounds like you are suggesting the effect of adding () to every epression
not already ending in (). I don't think you can tell what a name is referring
to until you look it up. Any LOAD_NAME or LOAD_FAST etc. can put a function
reference on the stack (so could the evaluation of any kind of expression!).

It would be unacceptable overhead to test for function magic every time you
got something onto the stack. AFAIK the only thing that now tells the compiler
to generate code to call the unknown thing that has wound up on the stack
is encountering a (...) trailer, empty or not. (Property magic is a little different).

My bare_name distinction limits testing of the stacked item to expressions ending in
plain names, but that's still terrible overhead, unless you generate different
code for when a static analysis can show that the name refers to a function.
Then you could add an implicit () trailer effect for auto-execution. If you could
also require statically determining that it was an "auto-excecute" function, it
could pretty much eliminate run-time overhead, IWT. BTW, I said tokenizer before,
but that's not the place to look ahead for a trailer. Parser/compiler better.

>
>It puts the VM through quite a few less hoops: all that really has to
>be done is duplicate the various opcodes that can fetch a function
>object, so that one of each pair autoexecutes and the other doesn't.
See above. Any expression can potentially "fetch a function". ISTM the only
kind that you were originally concerned with was ones ending in bare names.

>Then the parser can decide which to generate based on whether there
>is a parameter list following, and also on whether the "magic" syntax for
>retreiving the function object without auto-executing it is present.
(quote func) ? ;-)

>
>I suspect it's also easier to explain: funtions and methods are what
>are declared with def and lambda, and if it's not that, then it's not
>going to autoexecute regardless of whether it has a __call__ method.
>Adding classes to the list might be useful as well, but anything more
>would lead, I suspect, to too much confusion.
>
>It's still a non-starter, though
Well, maybe all this is useful in driving home that point ;-)

Regards,
Bengt Richter