Re: Lisp at sexp's length

From: Rahul Jain (rjain_at_nyct.net)
Date: 12/19/03 

Date: Thu, 18 Dec 2003 19:18:19 -0500

tar@sevak.isi.edu (Thomas A. Russ) writes:

> heliosc@mindspring.com (Rayiner Hashem) writes:
>
>>
>> Rahul Jain <rjain@nyct.net> wrote in message news:<87llpdo337.fsf@nyct.net>...
>> > heliosc@mindspring.com (Rayiner Hashem) writes:
>> >
>> > > Although, keyword arguments don't strike me as very prefix-y. "key:
>> > > value" definately seems like infix syntax to me.
>> >
>> > It's :key value, tho.
>> You are, of course, correct. But the significance ":" still strikes me
>> as adding syntax. Kinda like &rest and #.

":" isn't any additional syntax, as Thomas points out. It has no meaning
in the context of the data structure that is being built for the
arglist. In fact, it is prefix syntax because the description comes
before the value. It's not "value (key)", which would be a reasonable
syntax with an appropriate usage (or lack thereof) of parens elsewhere.

The truth is that this has nothing to do with prefix or infix at the
level of the language; it has to do with namespacing. &rest is there
because you need to do SOMETHING to indicate that the next variable will
be bound to the remainder of the arglist. Why not have a uniform look to
the symbols that are used as markers in the lambda-lists so that it's
easier for humans to spot them? # is there because there are all kinds
of funky data types you might want to enter as a literal using special
formatting conventions.

The character-level syntax is really a different thing than what we're
talking about here, and this is what the OP doesn't get. You don't need
to change the low-level parser in order to add a new operator to the
language, because precedence and associativity aren't an issue.

> Not anymore than is already present for reading symbols. Nowhere does
> Common Lisp require that keyword argument markers be keyword SYMBOLS.
> You are allowed to use any symbols at all for the keywords.
>
> Now, most programmers tend to use keywords as the markers for keyword
> arguments, and that is the default, but it isn't mandated. There are,
> in fact, some advocates of NOT using keywords.

I think this is mostly in the case of initargs, as you could have
multiple superclasses with the same symbol-name for their slots, but
different packages. If the initargs are the same symbol, then you get a
strange partial namespace conflict. 

-- 
Rahul Jain
rjain@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist

Relevant Pages

  • Re: A __getattr__ for class methods?
    ... or am I trying to mirror a functionality that Python simply does ... I'm not sure that the way you tackled this is the good approach: while it's quite flexible as far as the search criteria go, it'll require less than obvious code to match keywords and values, will lead to somewhat verbose syntax, and the syntax itself is unforgiving, brittle and not really pythonic. ... As you probably know, Python has a good support for keyword args, allowing you to fill your arguments out of order. ... But **kwargs goes beyond the regular explicit keyword arguments: when specified, **kwargs is a dict populated with the implicit keyword arguments, the ones you haven't specified in the argument tuple of your method. ...
    (comp.lang.python)
  • Re: Working on new language
    ... I really do like self documenting syntax like this, the only thing is it can ... to select specific options that the compiler enforces. ... So apart from the "so" keyword mentioned below I require ... Keyword: 10 pow: 2 ...
    (comp.lang.misc)
  • Re: C# Vs VB.NET
    ... because it was written in one language and then simply syntax-translated to ... Translation can usually be done line by line, keyword by ... Legacy functions are an extension you don't have to use. ... Different syntax, exact same thing. ...
    (microsoft.public.dotnet.framework.clr)
  • Re: The problem with "as" [was "Re: PEP 318"]
    ... Because the keyword keeps it unambiguous, ... The problem with using different keywords for each phrase is - after ... to modify an existing syntax, ... I'm not seriously proposing decorators on parameters at this point.) ...
    (comp.lang.python)
  • Re: Why cons *pairs*?
    ... So why are lists used as the basis of program representation, ... a legal data structure isomorphic to the parse tree of the program, ... structures are most naturally expressed by that syntax?" ... CONS-based lists support these fairly well. ...
    (comp.lang.scheme)