Re: data structure in LL

[Dan Sugalski <address@hidden>]

At 04:50 PM 12/11/2001 -0500, Shriram Krishnamurthi wrote:
>Dan Sugalski wrote:
>
> > I think we've already got them. Lists can't be in lists, but we fake it
> > pretty well with arrays. The s-exp
> >
> >     ("foo" "bar" (1 2 3))
> >
> > turns into
> >
> >    ["foo", "bar", [1, 2, 3]]
> >
> > in perl. Rather than a list with an embedded list, it's an array with an
> > embedded array. Output from subs could be embedded there, but I don't know
> > enough Lisp/Scheme to do it properly.
>
>The list/array distinction isn't important.  The point about
>s-expressions is not that they offer a nice syntax for lists.  So do
>lots of languages.  Their key property is that Lisp/Scheme provides a
>primitive named READ, which converts external Scheme data -- including
>*program text* -- into s-expressions.

Well, so what? Perl has Data::Dumper, python has its pickling, and lots of 
other languages do similar things. This isn't anything particularly unique 
to Lisp-family languages.

Lisp's treatment of code and data as more or less the same thing's not as 
common in procedural languages, but procedural languages treat code and 
data as fundamentally different things.

>You say Perl has eval.

No, I didn't, though it does.

>What does eval in Perl consume?

I'm tempted to say "A code reference, of course," though that would be 
missing your point. Yes, string eval consumes a string.

>Scheme's EVAL
>doesn't consume a *string*: it consumes a list (which you can generate
>through any means, including writing it as an s-expression).

Which would tend to imply they were two different (though in this case 
similar) functions with the same name. When thawing code from storage you'd 
probably use eval if you weren't interested in anything more sophisticated. 
For thawing data you'd use Data::Dumper, which is our data equivalent to 
READ and as difficult to use.

If you're building s-expressions at runtime from within a running program, 
you just do. There's nothing fancy needed, though you could go so far as to 
create a closure if you wanted.

If your argument is that text strings are generally a lousy data storage 
format, I won't disagree. I thought it was a bad idea the first time I laid 
eyes on /etc/passwd over a decade ago. If you like, we can get together and 
rant about it for ages, and take some shots at the XML folks while we're at 
it. If your argument is that text strings are a lousy way to store program 
text, I think you're on shakier ground. If your argument is that text and 
data should be universally interchangeable, I think I'll take a miss on the 
argument, since I think you're off into the philosophy of programming 
language design, and I don't go there.

>In
>particular, then, you can READ a program and EVAL it.  You can do that
>just as easily in a string-based EVAL.  But you can also throw your
>entire suite of list-processing functions at this list between READ
>and EVAL to manipulate your program (eg, implementing a macro system).
>Which is a lot nicer than trying to pull it apart and put it back
>together with regexps.

That's generally why we keep program code and data separate. (You can take 
that particular design decision up with Grace Hopper, I think) Might as 
well take shots at python, ruby, C, COBOL, Fortran, APL, PL/I, and Pascal 
while you're at it.

FWIW, I think you underestimate the power of perl's preprocessing and 
source filter system. I'll point you, then, at the modules Acme::Bleach and 
Lingua::Romana::Perligata as examples.

The first is a persistent source filter (it alters the program source 
on-disk when the program's run) and an amusing toy. (It's companion, 
Acme::DWIM, goes so far as to change all the operators in a perl program to 
be ..., so $foo = 2+2 becomes $foo = 2...2. And still runs)

The second makes perl a much less positionally-dependent language, as well 
as removing the need for the sigils perl uses to mark a variable as a hash, 
array, or scalar.

					Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
dan@sidhe.org                         have teddy bears and even
                                      teddy bears get drunk