Re: pretty-lambdas

[Sundar Narasimhan <address@hidden>]

   At 9:46 AM -0500 12/4/02, Sundar Narasimhan wrote:
   >      ^ (x y) (+ x y)
   >So now I wonder idly.. how many other languages can do something like
   >this (given this discussion started out re. macros after all :) --
   >i.e. modify the base syntax for introducing something so basic.
   >
   >Python, Perl, Ruby, Smalltalk? Perhaps?
   >

   I don't know how many languages let you modify the syntax
   at the level of the lexer.

   I'm not convinced that this is actually a good idea, as it
   happens, but it is undeniably useful to be able to define
   a special "read table" for reading custom data files.  One
   could reasonably argue that this is properly the domain of
   lexing and parsing libraries, without having to argue as well
   that macros are a poor idea.

   Common Lisp also has these things called "symbol macros"
   where a random symbol in any old position can be magically
   macro-expanded.  I'm pretty sure this is a bad idea.  The
   problem with both of these things is that they can cause
   the "deep" syntax of the language to silently change with
   no cue to the reader that something magic is happening.
   This is not quite as true of ordinary Lisp macros.  (I
   say "not quite" because ordinary macros quite often change
   evaluation semantics.)

Actually -- I tend to shy away from "good" vs. "bad" judgements when
such facilities are concerned since these, in my mind at least, are  
in the gray area of "trade-offs". 

Just because programmers design languages does NOT mean that the
syntax should necessarily be governed by them. I'll illustrate what I
mean with a slight digression.

If you look at the entire "business rules" segment -- look at Ilog
JRules for a popular example, you will see that it's key successes
have been because of the fact it lets you attach "pseudo-english" like
descriptions to a business-object model, that end up controlling a
rete-engine written in Java underneath. It uses reflections heavily --
but makes a completely different argument about separation of levels
than people have made on this group about using reflection
facilities. I could say the same about Matlab/Mathematica, AutoCad and
other niche products.

I'll give you another example -- whenever I attempt to teach
programming to kids or novices -- I find I have a *huge* conceptual
hurdle to jump. They just don't understand why one has to "bother"
with all this extra (, {, $, # stuff. I've tried Logo and other so
called "educational" languages, but after a few years bashing my head
against my average student (note I don't worry about the stars here
:), I'm more than convinced that it is the "fixed structure" that
machines expect (that is sometimes oh so drastically different from
what kids are taught in their other subjects and walks of life) that
is at the root of the problem. Making things more "flexible", so that
different syntaxes can be supported .. could potentially impact
this.. because I can see how perhaps I can write programs that start
with "minimal structure to do simple things", and then gradually ramp
up to more complicated things. Right now we have a situation where
.. because it's an "all or nothing" game, we tend to lose 70% of the
class right at the beginning (of course they all then go on to become
the pointy headed bosses of the others that do master the
syntax/structure :)

So.. I think there *are* benefits to putting in facilities at the
language level to allow such drastic redefinitions of syntax. i.e. the
reader really doesn't want to see the machine-level, or progamming
language level semantics sometimes.

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 :)