Egil Möller:
> I am a little bit wary about the number of different types of braces and
> parens in
> modern expressions, and how their usage compares to other languages.
> In Python, () are used for function calls and tuples (read-only lists),
> [] are used for lists and {} are used for mappings (assoc-lists).
It's much more complicated than that in Python.
In fact, modern-expressions are (unsurprisingly) similar to Python.
In Python:
Unprefixed (..) are used for precedence-overriding, as in 3*(4+5)
Prefixed (..) are used for function calls, as in f(x).
Unprefixed [...] is a list constructor, as in a=[1,2,3].
Prefixed [...] is a list accessor, as in a[1]
Unprefixed {...} is a hashtable constructor, as in a={5:"hi",6:"bye"}
Prefixed {} is unassigned, to my knowledge; x{} is an error.
In Python "prefixed" vs. "unprefixed" is distinguished by whether or not an
expression is complete, but this requires a fixed syntax that Lisps
(understandably)
don't have.
Both Python and modern-expressions have _different_ semantics for
(), [], and {}, depending on whether or not they are prefixed. Thus,
I argue that while this is new to Lisps, it's what a lot of people are ALREADY
used to. We just need to tell them that whitespace is a parameter separator,
and thus "a()" and "a ()" have different meanings. Given that
whitespace is a parameter separator, this is unsurprising :-).
> A very different approach to infix notation could be to not use special
> parenthesis, but a macro and a special symbol. The macro would enable
>infix for the expression and for all sub-expressions, except ones
>prefixed with the special symbol.
Several people (including Gloria) have developed infix macros, and I think
they definitely have their place.
The problem with infix macros is that any OTHER macro that is invoked BEFORE
the infix macro will necessarily see the WRONG operators. So, for example, a
macro that looks for (* ... (+ ....) ....) and replaces it with something else
will NOT
see the "+" if it's invoked in a context before the substitutions occur. This
means that just when you start depending on the macro, it "breaks".
This is why I'm pursuing a reader-based approach. Once the S-expression is
read in,
ALL macros work in EXACTLY the way it "says on the tin" - even if they deep-dive
recursively into their arguments (as some macros do).
Even an ordinary macro name doesn't look bad with term-prefixing, e.g.:
nfx(3 + 4 * 5)
The nice thing is that reader-based and macro-based approaches aren't exclusive
to each other. In fact, I think you can argue that they complement each other
nicely.
> It would also be interresting to implement the Pythonic list features,
>e.g. slices and slice assignment. Extra points for implementing both a
>destructive and a non-destructive version. E.g.
That was the idea of "bracketaccess", but that means that someone
has to figure out those semantics.
let
group
a b[1:5]
c d[0:3,x,5:7,9:]
Hmm, that doesn't look very Lispish - that has lots of
unnecessary punctuation to bite you later when you start manipulating lists.
How about something simpler:
a[x] - access to single element x.
a[x y] - access to x...y. Does it include y? To be determined!
I don't see the need for the "append" versions; it'd be easier to have
append operations. Python, for example, doesn't even try to do that,
and it has a rich syntax compared to most. Python _does_ have a
"step" function, and you could permit:
a[x y step] - access to x...y with step 'step'.
You could also permit >1 dimension, putting each in a list:
a[(x) (y)] - access to 2D array, element (x y)
a[(x1 y1) (x2 y2)] - access to the rectangle (x1,y1)...(x2, y2)
--- David A. Wheeler
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss
