UserLinux chooses Python as "interpretive language" of choice

[John Roth]

"Bengt Richter" <bokr at oz.net> wrote in message
news:bs541e$8l2$0 at 216.39.172.122...
> On Sun, 21 Dec 2003 07:41:40 -0500, "John Roth" <newsgroups at jhrothjr.com>
wrote:
>
> >
> >"Bengt Richter" <bokr at oz.net> wrote in message
> >news:bs2j3b$fc5$0 at 216.39.172.122...
> >> On Sat, 20 Dec 2003 06:38:20 -0500, "John Roth"
<newsgroups at jhrothjr.com>
> >wrote:
> >> What would be the syntax you would like to use, with what effect?
> >
> >Well, the basic idea was simply to make the () optional for functions
> >with no parameters. No particular syntax there but it would require some
> >major jump through hoops gyrations from the virtual machine, and there
> >would have to be some way of getting the function object when you
> >wanted it, and I suspect the difference between a function object and
> >a more general 'callable' would totally confuse most people. And of
> >course, does a function/method with only keywords count as a function
> >with no parameters?
> >
> >Ruby can get away with it because, as far as I know, functions are not
> >first class objects. They certainly aren't in Perl which was Ruby's
> >inspiration.
>
> Really? Perl was Ruby's inspiration??

One of them. There's a bit of this and that, but overall
it seems a bit more Perlish than Pythonish. I've never
gotten a satisfactory answer about how it's "more
object-oriented" than Python, unless they mean that
it uses methods instead of built-in functions.

> >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.

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.
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.

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

John Roth

> Not that I am proposing this ;-)
>
> Regards,
> Bengt Richter