Re: sweet-expressions instead of s-expressions?
- From: JShrager@xxxxxxxxx
- Date: 24 Sep 2006 11:44:22 -0700
Not to throw cold water on this impressive series of demos, these
aren't excellent but somewhat tangential to what I had in mind. Mark my
words: "Remember in thinking through this: Don't fight the syntax! If
you try to have both python dicts AND python syntax, you'll lose, and
you'll lose macros and you might as well go back to Python."
What you (both) have demonstrated is the power or reader macros in
defining new syntax, but I don't think that new syntax (in the sense of
reader macros) is either necessary nor particularly appropriate in the
context of the present discussion. I had mind mind something at the
same time hack-wise simpler, yet coneptually more complex: Not just
letter one type: {for bar baz frob} -- forget the braces etc. Rather,
what I had in mind (Neil puzzling through himself) was what the central
concept(s) is(are) of dictionaries and how, using standard Lisp macros,
one could get the >concepts<, not just the baces and brackets. Of
course, the concepts are almost already there (as I pointed out) in
Lisp (in the guise of hash tables, mostly), and I don't think that he
wants -- or shouldn't want -- what you have offered, which is the
syntax. Rather, he wants (or should want) hash-tables to be as
convenient as dictionaries. The only things really limiting this in
Lisp are the need to declare them, and the ability to use
comprehensions (i.e., slicing expressions aka comprehensions aka
generators) as the targets of setting operations. (Some would say that
generators are themselves a conceptual advantage of Python, but these
are trivally obtainable using, or if you like, macofying in of Lisp
generators, and there are already lisp packages that do this!)
Neither of these is a huge stumbling block (although the former:
declaration) may cause efficiency problems -- which may be why Lisp
requires this; I'm not sure). And the examples hereabove by Ari and
Pascal contain part of the story, but in reading their code, I would
say to ignore their syntactic offerings and focus on their semantic
offerings, and expand from there. Adding syntax is usually simple (as
demonstrated) but generally a bad idea (as I have previously argued)
because it breaks the model of code as data and v.v.
.
- References:
- sweet-expressions instead of s-expressions?
- From: Neil Toronto
- Re: sweet-expressions instead of s-expressions?
- From: JShrager
- Re: sweet-expressions instead of s-expressions?
- From: Pascal Bourguignon
- Re: sweet-expressions instead of s-expressions?
- From: Ari Johnson
- sweet-expressions instead of s-expressions?
- Prev by Date: Re: sweet-expressions instead of s-expressions?
- Next by Date: Re: Handling Complexity Using Lisp
- Previous by thread: Re: sweet-expressions instead of s-expressions?
- Next by thread: Re: sweet-expressions instead of s-expressions?
- Index(es):
Relevant Pages
|
