[Openmcl-devel] Using readtables for only one library

[Dan Weinreb]

Ron,

Well, they're not always a bad thing.  However, when you use
them you have to be aware of possible drawbacks:

They can be confusing to people reading the code, particularly
if they are overused or unclear.  This is true of regular
macros, as you all know; I think it's even more true of reader
macros.  It's very important to be restrained and use good
taste, which is a hard thing to quantify and teach.

They can be confusing to program development tools.
For example, Emacs indentation can be confused by
lexical syntax that it doesn't know about.  We can
extend Emacs indentation for more macros, in Slime,
pretty easily, but for reader macros it's far harder.

There's no namespace for them, so if you load two
libraries that both redefine the same syntax (use
the same character, or the same character following
#, or whatever), you can be in trouble.  The tools
mentioned in this thread look like they might
be able to mitigate this.

Alexander's idea of
having reader macros that check to see what
package you're in, and only take effect based on
that, is a good idea; that, plus a way to "chain"
reader macros (i.e. each one can either do its
thing or pass on work to the next) might possibly
be a good thing but that's just off the top of my
head.

By the way, one of the things I was thinking of
doing was making this Ruby-ism work:

"There were ${n} words in the file."

It's lexical shorthand for a subset of "format",
to put it in Common Lisp terms.  It doesn't
break Slime's indentation.

>From my point
of view, Ruby is drenched in syntactic sugar.
I am more accepting of such sweeteners as I get older,
when it's used in its place, i.e. depending on
context.

-- Dan



----- "Ron Garret" <ron at flownet.com> wrote:

> On May 8, 2010, at 4:41 PM, Ben Hyde wrote:
> 
> > I've argued against read tables in all the systems I've built
> 
> On what basis?  (Don't mean to start a flame war here.  I'm honestly
> curious.)
> 
> rg
> 
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel