[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: data structure in LL
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.
>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.
>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.
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
email@example.com have teddy bears and even
teddy bears get drunk