I'm wondering why the ANSI CL standard makes the following
implementation dependent:
CL-USER(2): (read)
`,foo
`,FOO
CL-USER(3): (car *)
EXCL::BACKQUOTE
CL-USER(4): (cadr **)
(EXCL::BQ-COMMA FOO)
Seems like `,foo should have a standard mapping to a list structure
just as `foo does.
--
actual email
(apply #'concatenate 'string (reverse '("com" "." "kantz" ·@"
"jason-list")))
From: Kent M Pitman
Subject: Re: reading backquote expressions
Date:
Message-ID: <u8y2ublsx.fsf@nhplace.com>
"Jason" <··········@gmail.com> writes:
> I'm wondering why the ANSI CL standard makes the following
> implementation dependent:
>
> CL-USER(2): (read)
> `,foo
> `,FOO
> CL-USER(3): (car *)
> EXCL::BACKQUOTE
> CL-USER(4): (cadr **)
> (EXCL::BQ-COMMA FOO)
>
> Seems like `,foo should have a standard mapping to a list structure
> just as `foo does.
Implementations are allowed to optimize this stuff differently.
You aren't supposed to write programs that care. What program
are you wishing you could write?
Kent M Pitman wrote:
> Implementations are allowed to optimize this stuff differently.
> You aren't supposed to write programs that care. What program
> are you wishing you could write?
I'm exploring a column-based list syntax that translates to CL syntax.
The translation hit some hurdles with backquote. What I'm finding is
that translating backquote expressions into a list representation
would require temporarily substituting the #\` reader macro and doing
my own string parsing.
If anyone wants to try out the tanslator, the code is here:
http://kantz.com/jason/programs/ergono
An example of the syntax:
defun denom, (kinds)
cond -> (= kinds 1), 1
-> (= kinds 2), 5
-> (= kinds 3), 10
-> (= kinds 4), 25
-> (= kinds 5), 50
defun count-change, (amount)
labels -> cc (amount kinds)
cond -> (= amount 0), 1
-> (or (< amount 0) (= kinds 0)), 0
t + cc amount, 1- kinds
cc (- amount (denom kinds)), kinds
cc amount, 5
Kent M Pitman <······@nhplace.com> writes:
> "Jason" <··········@gmail.com> writes:
>
>> I'm wondering why the ANSI CL standard makes the following
>> implementation dependent:
>>
>> CL-USER(2): (read)
>> `,foo
>> `,FOO
>> CL-USER(3): (car *)
>> EXCL::BACKQUOTE
>> CL-USER(4): (cadr **)
>> (EXCL::BQ-COMMA FOO)
>>
>> Seems like `,foo should have a standard mapping to a list structure
>> just as `foo does.
>
> Implementations are allowed to optimize this stuff differently.
> You aren't supposed to write programs that care. What program
> are you wishing you could write?
I'm not the OP but I once went down the path, while writing a matched
pair of interpreter/compiler for a domain specific language, of
wishing that I could define code-templates using backquote
syntax and then analyze the resulting s-exprs to generate slightly
different code in the interpreter and compiler. But because you can't
do that I found a completely different way to slice up my problem so I
don't know if there would have been some other problem with that
approach. But it seemed if `(foo ,bar ,@baz) was just sugar for
something like Scheme's (quasiquote (foo (unquote bar)
(unquote-splicing baz))) I could have done what I wanted pretty
easily.
-Peter
--
Peter Seibel ·····@gigamonkeys.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel <·····@gigamonkeys.com> wrote:
+---------------
| Kent M Pitman <······@nhplace.com> writes:
| > "Jason" <··········@gmail.com> writes:
| >> Seems like `,foo should have a standard mapping to a list structure
| >> just as `foo does.
| >
| > Implementations are allowed to optimize this stuff differently.
| > You aren't supposed to write programs that care. What program
| > are you wishing you could write?
|
| I'm not the OP but I once went down the path, while writing a matched
| pair of interpreter/compiler for a domain specific language, of
| wishing that I could define code-templates using backquote
| syntax and then analyze the resulting s-exprs to generate slightly
| different code in the interpreter and compiler. But because you can't
| do that I found a completely different way to slice up my problem so I
| don't know if there would have been some other problem with that
| approach. But it seemed if `(foo ,bar ,@baz) was just sugar for
| something like Scheme's (quasiquote (foo (unquote bar)
| (unquote-splicing baz))) I could have done what I wanted pretty easily.
+---------------
I once ran into the same thing while trying to port a pidgin version
of Olin Shiver's "Scsh" notation into CL. The problem is that much of
Scsh internally depends on Scheme's standard reader parsing of backquote
as QUASIQUOTE, comma as UNQUOTE, and comma-at as UNQUOTE-SPLICING,
even if not properly nested. That is, statements in Scsh are (usually)
"implicitly backquoted", and thus the following might be the "natural"
way to write a common function in CLsh [if the latter existed]:
(loop for i in (directory "foo")
do (clsh (ls -l ,i)))
As it is, most CL readers complain vociferously about "excess" commas
or comma-at's, so one would have to write it this way:
(loop for i in (directory "foo")
do (clsh `(ls -l ,i)))
Not a *big* difference you might say, but in practice it's fairly
annoying if you're trying to use Scsh/CLsh as your top-level shell.
Plus, sometimes the reader so "optimizes" the backquoted expression
for you before you get your hands on it that you can't uniquely recover
what the user typed to produce the S-expr result READ gave you.
Finally, a (hypothetical) CLsh has to have to have a massive set of
feature tests to conditionalize the post-READ (un)parsing of Scsh-like
forms, variantions that might change radically between releases of
each supported CL implementation.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
From: Kent M Pitman
Subject: Re: reading backquote expressions
Date:
Message-ID: <u64xwhmmg.fsf@nhplace.com>
Peter Seibel <·····@gigamonkeys.com> writes:
> I'm not the OP but I once went down the path, while writing a matched
> pair of interpreter/compiler for a domain specific language, of
> wishing that I could define code-templates using backquote
> syntax and then analyze the resulting s-exprs to generate slightly
> different code in the interpreter and compiler. But because you can't
> do that I found a completely different way to slice up my problem so I
> don't know if there would have been some other problem with that
> approach. But it seemed if `(foo ,bar ,@baz) was just sugar for
> something like Scheme's (quasiquote (foo (unquote bar)
> (unquote-splicing baz))) I could have done what I wanted pretty
> easily.
I actually don't know a strong argument against doing what Scheme did,
but I recall it seemed to upset some of the vendors, who seemed to
want to optimize these structures at read-time and apparently felt this
would work against that.
This is a place where I don't understand why users don't go to each
vendor and pressure them one by one to make the change so they can see
if the vendor has a reason not to. The hope would be that either some
vendor will tell you a reason or eventually all vendors will do the
right thing.
But I'm confused by your use of "But because you can't do that" here.
Such a defeatist tone. I recall reading in a post here that some
recent writer, I forget his name, said that one reason that Lisp excels
over Java is that if you don't like Java, you have to wait for vendors
to change, while Lisp provides you tools to rewrite the language's
syntax and so to overcome what you perceive as weaknesses. Maybe you
should buy that guy's book. ;)
Kent M Pitman <······@nhplace.com> writes:
> Peter Seibel <·····@gigamonkeys.com> writes:
>
>> I'm not the OP but I once went down the path, while writing a matched
>> pair of interpreter/compiler for a domain specific language, of
>> wishing that I could define code-templates using backquote
>> syntax and then analyze the resulting s-exprs to generate slightly
>> different code in the interpreter and compiler. But because you can't
>> do that I found a completely different way to slice up my problem so I
>> don't know if there would have been some other problem with that
>> approach. But it seemed if `(foo ,bar ,@baz) was just sugar for
>> something like Scheme's (quasiquote (foo (unquote bar)
>> (unquote-splicing baz))) I could have done what I wanted pretty
>> easily.
>
> I actually don't know a strong argument against doing what Scheme did,
> but I recall it seemed to upset some of the vendors, who seemed to
> want to optimize these structures at read-time and apparently felt this
> would work against that.
>
> This is a place where I don't understand why users don't go to each
> vendor and pressure them one by one to make the change so they can see
> if the vendor has a reason not to. The hope would be that either some
> vendor will tell you a reason or eventually all vendors will do the
> right thing.
>
> But I'm confused by your use of "But because you can't do that" here.
> Such a defeatist tone.
Hey, I didn't give up--I just found another (possibly better) way to
slice up the problem. Though not before going pretty far down the path
of implementing my own backquote facility before realizing that that
was what I was doing and that that was way overkill for what I was
actually trying to do.
> I recall reading in a post here that some recent writer, I forget
> his name, said that one reason that Lisp excels over Java is that if
> you don't like Java, you have to wait for vendors to change, while
> Lisp provides you tools to rewrite the language's syntax and so to
> overcome what you perceive as weaknesses. Maybe you should buy that
> guy's book. ;)
Yeah, but he's crazy. If everyone just makes up their own syntax and
control constructs who knows what'll happen.
-Peter
--
Peter Seibel ·····@gigamonkeys.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Jason wrote:
> Seems like `,foo should have a standard mapping to a list structure
> just as `foo does.
Neither of these notations maps to any standard object representation.
All we know is that `,foo is translated into some expression which
under evaluation behaves like FOO, and `foo is translated into
something that under evaluation behaves like (QUOTE FOO).
In fact, these very translations can be applied at read-time, an
implementation choice which comes with the loss of being able to
recover the original backquote notation.
ANSI CL doesn't even require the result of backquote read syntax to be
printable back as the original backquote read syntax. Not only isn't
there a standard representation, but there doesn't have to be a
representation at all, so to speak. :)
Kaz Kylheku wrote:
> ANSI CL doesn't even require the result of backquote read syntax to be
> printable back as the original backquote read syntax. Not only isn't
> there a standard representation, but there doesn't have to be a
> representation at all, so to speak. :)
I agree that this is the correct argument. While the ANS does not
_require_ that the reader amcros for backquote etc. return forms
that allow the pretty printer to reproduce the original backquote
expression, it also does not prohibit it. Many implementors (myself
included) consider this to be a valuable feature in an implementation.
IMO there is no particular need for this representation to be
standardized.
If you need a particular predictable representation for backquote
syntax, there is a reasonable complete backquote implementation in
CLtL2 which you could appropriate and customize, binding *readtable*
to your own readtable copy with your own backquote reader macro family.
From: Kent M Pitman
Subject: Re: reading backquote expressions
Date:
Message-ID: <u64xt1y57.fsf@nhplace.com>
"Steven M. Haflich" <···@alum.mit.edu> writes:
> Kaz Kylheku wrote:
>
> > ANSI CL doesn't even require the result of backquote read syntax to be
> > printable back as the original backquote read syntax. Not only isn't
> > there a standard representation, but there doesn't have to be a
> > representation at all, so to speak. :)
>
> I agree that this is the correct argument. While the ANS does not
> _require_ that the reader amcros for backquote etc. return forms
> that allow the pretty printer to reproduce the original backquote
> expression, it also does not prohibit it. Many implementors (myself
> included) consider this to be a valuable feature in an implementation.
> IMO there is no particular need for this representation to be
> standardized.
>
> If you need a particular predictable representation for backquote
> syntax, there is a reasonable complete backquote implementation in
> CLtL2 which you could appropriate and customize, binding *readtable*
> to your own readtable copy with your own backquote reader macro family.
I was thinking more on this, and the following recollection came to
mind: Way back in the Maclisp days, just before CL(TL) standardization
began, around 1979-1980, there were multiple competing packages with
varying syntaxes and functionalities. Alan Bawden's is the one that
won, if I recall. But various others were flying about.
At the time, I think read-time error checking was one of the key
design criteria that people liked. That meant getting an error for a
comma out of place, and for double-comma inside a single comma, etc.
In hindsight, there are certainly a lot of places where people make
these kinds of errors and it's been good to catch them early.
In the original Maclisp backquote, actually, backquote gave you all new
structure. It was later modified (after I'd rewritten huge amounts of
code (or what passed for huge amounts back then) to assume that `(,a b c)
was like (list a 'b 'c) to try to share as much structure as possible,
then breaking all my nice newly rewritten code. The issue of sharing was
paramount for most people, and so someone, probably JonL White, changed
it to share structure, and made `(,a b c) mean (cons a '(b c)). And at
that point, there became places where people wnated `(foo `(bar ,',x))
to turn cleanly into
'(foo (bar xval))
not
`(foo (bar ,'xval))
so I guess there was a desire for implementation-flexibility to support
such magic and produce sharing wherever possible.
I also remember a special concern, too, about someone re-introducing a
comma into a backquoted expression by accident and confusing things.
In hindsight, I don't know how worrisome an issue this really is.
Scheme has had the ability to do this for a while, and its people
could probably say it runs into trouble much. I've not heard of any
irritation about it.
And certainly I think we undervalued the need to be able to deal with
a backquoted expression as a template that user might walk without
evaluating as a kind of user-expressed template (e.g., for a pattern
matcher).
So I'm personally softening some on this, even though I think we did
originally make the decisions we did for sound reasons.
And regardless of my preference, I hope these memories help put some of it
into perspective.
Kent M Pitman writes:
> And regardless of my preference, I hope these memories help put some
> of it into perspective.
The perspective is much appreciated. It sounds like there wasn't an
informal standard, so the choice was to leave the formal standard
flexible. Which is fine, b/c a preferred behavior of #\` isn't
impossibly difficult to implement in common lisp and pass around to
others.
I wonder in general how much of cl was taken from other lisps where the
features had a history of use and acceptance, and how much was new
design.