Re: pretty-lambdas

[Sundar Narasimhan <address@hidden>]

   I think that what you are looking for is not necessarily addressed
   by instruments such as macros, but I've thought about this for
   all of 3 minutes.

Scott: Agreed. (It's just that macros come closer to helping me in
this regard, than some other facilities -- and yes, I'm very aware of
the dangers -- and in fact, do tend to discourage multi-page macros
around here unless there's a very good reason for them).

   "Good" = "benefit to risk ratio is high"
   "Bad"  = "benefit to risk ratio is low"

   In my experience, reader macros are a close call, but if I were
   implementing a new Lisp, I would leave them in.  Symbol macros
   have a very low benefit to risk ratio, in my experience, so I
   would leave them out.

Understood.

   Just from watching the problems of doing a good macro system in
   Dylan, I would have to say that the practical problems of allowing
   "drastic definitions" of syntax in the language are pretty daunting.

   Or in a Japanese-like postfix syntax, "Problems the macro system
   good Dylan in watching regarding, problems practical syntax's
   'redefinitions drastic' of language in regarding pretty daunting are."

LOL.. see.. that's part of the problem w/ macros I think. We don't
understand them well enough, and w/ experiences like this one the cost
appears prohibitively high. Perhaps we have a lot more 'unlearning' to
do before we get this right. Sometimes the starting point constrains
where one can aim for. And unfortunately, we all can't start from
scratch all the time.
 
   I would be interested to see a parser that can be extended, on the
   fly, from handling the first syntax to additionally handling the
   second one.  (That's not meant to be sarcastic -- I really would
   be interested in seeing how drastic a change in syntax can be.)

Very good question/thoughts to ponder.
 
   >I think we programmers automatically make the leap from that -- "if
   >you can't see what the program counter might do here, how the heck am
   >I going to debug it".. Exactly the right question to ask - and tease
   >apart where the tool support, language facility, abstraction
   >boundaries between runtime/execution/use lie. Doesn't mean it's bad
   >.. it just 'appears' bad because some people don't quite know how to
   >deal w/ that perhaps :)