loading Emacs-Lisp into CL
Kent M Pitman
> while trying to implement an EL/CL compatibility package (a preliminary
> version is available in elisp.lsp in
> <http://www.goems.com/~sds/data/cllib.zip>), I encountered a problem:
> apparently, the following (calendar.el in Emacs distribution):
>
> (defmacro calendar-for-loop (var from init to final do &rest body)
> "Execute a for loop."
> (` (let (( (, var) (1- (, init)) ))
> (while (>= (, final) (setq (, var) (1+ (, var))))
> (,@ body)))))
>
> is correct in EL (but not in CL). obviously I have to redefine
> backquote in the emacs-lisp package, but I don't know how to do this
> easily (I am not particularly eager to re-invent the wheel).
>
> Any suggestions?
>
> [the obvious solution - load backquote.el - fails because the file
> defines `backquote-unquote-symbol' to be ', and the reader chokes on
> this]
>
> Thanks.
In the olden days (maclisp), pre-backquote, we used to do:
(sublis (list (cons 'var var) (cons 'init init) (cons 'final final)
(cons 'bodyform (cons 'progn body)))
'(let ((var (1- init)))
(while (>= final (setq var (1+ var))) bodyform)))
Don't know if that helps, but it's worth noticing that sometimes when
technology runs awry, the underlying thing they're buying you sometimes
isn't worth the fuss.
Erik Naggum
| (defmacro calendar-for-loop (var from init to final do &rest body)
| "Execute a for loop."
| (` (let (( (, var) (1- (, init)) ))
| (while (>= (, final) (setq (, var) (1+ (, var))))
| (,@ body)))))
|
| is correct in EL (but not in CL). obviously I have to redefine backquote
| in the emacs-lisp package, but I don't know how to do this easily (I am
| not particularly eager to re-invent the wheel).
|
| Any suggestions?
yes. don't bother. many things in Emacs Lisp should not be replicated.
instead, fix the Emacs sources and submit them as patches.
#:Erik
Hrvoje Niksic
> yes. don't bother. many things in Emacs Lisp should not be
> replicated. instead, fix the Emacs sources and submit them as
> patches.
A large amount of legacy Emacs code (both in the distribution and
elsewhere on the net) uses "old-style" backquotes. If Sam's goal is
to run such code unchanged, he will probably have to implement the
backquote junk, somehow.
Erik Naggum
| Note that it only works with Allegro CL with Erik's readtable fix, which
| he did not post but sent me by private e-mail. I would appreciate if he
| did post it for public consumption.
um, I'm not sure this is a good idea, but here goes:
excl: ;; compile and load this, do _not_ evaluate interpreted
(loop ;; make the #\ reader fully ANSI CL compliant, ignore CLtL1.
with readtables = (get-objects 11)
for i from 1 to (aref readtables 0)
for readtable = (aref readtables i) do
(when (readtable-dispatch-tables readtable)
(set-dispatch-macro-character #\# #\\
(named-function sharp-backslash
(lambda (stream backslash font)
(declare (ignore font))
(stream-unread-char backslash stream)
(let* ((charstring (read-extended-token stream)))
(unless *read-suppress*
(or (if (= (length charstring) 1)
(char charstring 0)
(name-char charstring))
(internal-reader-error
stream "Meaningless character name ~A"
(string-upcase charstring)))))))
readtable)))
this is deliberately Allegro CL-specific and hopefully won't work
anywhere else. unsupported, copyrighted, no warranties kind of stuff,
based on my understanding of source code licensed to supported customers,
but not derived from which, etc, legal blah blah blah, sue Bill Gates if
you have problems, and indemnify everybody else, OK? cancel? <click>
#:Erik
Kent M Pitman
> This does not work with CLISP because (probe-file "/etc/") signals an
> error (file is not a directory). (a workaround is being worked on).
Incidentally, I see no reason for (probe-file "/etc/") to return
anything useful in any conforming implementation. Directories are not
required to be files. In some operating systems, they aren't files.
That's not to say an implementation can't usefully define this behavior;
I just wanted to be clear it's not something you should expect because
of the standard... at least, not for any reason I can recall.
Mike McDonald
Wouldn't it be easier to implement the byte code interpreter and just run
the .elc files instead?
Mike McDonald
mik...@mikemac.com
Erik Naggum
| Wouldn't it be easier to implement the byte code interpreter and just run
| the .elc files instead?
for this particular case, it would, but the byte code interpreter calls
out to functions all the time, and you would need to implement almost
everything anyway. the byte code is also more incompatible between the
various versions of Emacs than the source is. not that it isn't a good
idea, but it would probably cause a lot more work than you think to get
it right everywhere.
#:Erik
Howard R. Stearns
what is meant by "old style backquote".
How are elisp macros and/or backquote different than CL?
Aaron Crane
"Howard R. Stearns" <how...@elwood.com> writes:
> Could someone sumarize what the issue was with backquote. I don't know
> what is meant by "old style backquote".
In older Emacs Lisp dialects, backquote, comma and comma-at are macros,
rather than being handled by the reader. This means that instead of
(defmacro forever (&rest body)
`(do () (nil) ,@body))
you have to write
(defmacro forever (&rest body) ; old-style Emacs Lisp
(` (do () (nil) (,@ body)))
Clearly, this rapidly becomes incomprehensible as the complexity of the
backquoted form rises.
Modern Emacs Lisp readers have horrific kluges to recognise old-style
backquoting; this also means that certain (admittedly obscure) usages of
backquote will fail.
--
Aaron Crane <aaron...@pobox.com> <URL:http://pobox.com/~aaronc/>
Howard R. Stearns
If I recall correctly, the ANSI CL spec suggests (but does not require)
that implementations of the backquote reader try to be compatible with
Scheme and other dialects, which provide macros (as opposed to reader
macros) for doing some of the same things as CL backquote does.
For example, there should be macros named QUASIQUOTE, UNQUOTE and
UNQUOTE-SPLICING. (If one wanted to provide similar utilities for other
CL backquoting features that are not part of Scheme, one would also
define something like "unquote-splicing!" and "quasivector".)
I don't know how many CL implementations do this, but if they support
anything like this (even with different names,) then it should be pretty
easy to support elisp quasiquoting macros within CL.
It is not clear to me whether one could then get away with either of:
1. globally replacing "(` " (with space) to "(quasiquote ",
"(,@ " => "(unquote-splicing ", etc.
2. Hacking the ` reader to return the symbol QUASIQUOTE if the next
character is
a space, and similarly for , and ,@. This would allows .el files to
be used
directly, without modification. However, it might screw up .lisp
files, so
arrangements would have to made such that the modified readtable
would be used
only on .el files.
Both of these depend on the assumption that "old style elisp
backquoting" relied on whitespace to terminate the symbols named "`",
"," and ",@".
If this concept is sound, I can donate some untested code to the cause.
I have code for the next version of Eclipse that implements QUASIQUOTE,
etc., macros, and coordinates them with the backquote reader macros.
The code is about 4 screen fulls and is loosely based on appendix C in
CLtL2. Contact me if you want it. Here's an overview:
;;; We process quasiquote forms at macroexpansion time, and backquote
;;; forms at read time. In either case, processing involves
;;; simplifiying the forms and transforming them to bq-xxx forms. The
;;; bq-xxx macros expand into xxx, but are recognized by the
;;; pretty-printer so that they can be printed using backquote
;;; characters. They also keep the simplifier from mistakenly
;;; simplifying user code.
Kelly Murray
for improvement in CL...
The syntax of Backquote is about as ugly as one can imagine.
Unfortunately, backquote is almost always used when
defining macros. And with the macro being one of the key
strengths of lisp, we have the situation where a key strength
of lisp uses one of the most bizarre and ugly syntactic constructs
in the language. At least parenthesis have a form of beauty
and functionality, but backquote is just plain ugly and bizzare.
So how about some suggestions on something different,
something better. How about a straw man:
Use [] to replace , and {} to replace ,@
i.e. `(zap ,foo ,@bar) ==> `(zap [foo] {bar})
Mike McDonald
Kelly Murray <k...@IntelliMarket.Com> writes:
> Another area where there exist major room
> for improvement in CL...
>
> The syntax of Backquote is about as ugly as one can imagine.
> Unfortunately, backquote is almost always used when
> defining macros. And with the macro being one of the key
> strengths of lisp, we have the situation where a key strength
> of lisp uses one of the most bizarre and ugly syntactic constructs
> in the language. At least parenthesis have a form of beauty
> and functionality, but backquote is just plain ugly and bizzare.
>
> So how about some suggestions on something different,
> something better. How about a straw man:
> Use [] to replace , and {} to replace ,@
> i.e. `(zap ,foo ,@bar) ==> `(zap [foo] {bar})
Looks about as ugly and bizzare to me as the current syntax.
Mike McDonald
mik...@mikemac.com
Dave Pearson
> [SNIP backquote is ugly]
>
> i.e. `(zap ,foo ,@bar) ==> `(zap [foo] {bar})
[Coming from a lisp "dabbler"] I'd always thought ("always" is the last year
that I've been toying with lisp) that the backquote syntax had a certain
beauty to it. It's hard to describe but I felt that "," and ",@" painted the
actual action into my editor. "," "nicked and opened" what followed and ",@"
"nicked and unrolled" what followed.
Assuming your suggestion was serious (I've got this funny feeling I may have
missed the joke in your post), why do you think the current syntax is ugly?
--
Take a look in Hagbard's World: | w3ng - The WWW Norton Guide reader.
http://www.acemake.com/hagbard/ | eg - Norton Guide reader for Linux.
http://www.hagbard.demon.co.uk/ | weg - Norton Guide reader for Windows.
Free software, including........| dgscan - DGROUP scanner for Clipper.
Johan Kullstam
> On Wed, 24 Feb 1999 11:22:26 -0800, Kelly Murray <k...@IntelliMarket.Com> wrote:
>
> > [SNIP backquote is ugly]
> >
> > i.e. `(zap ,foo ,@bar) ==> `(zap [foo] {bar})
>
> [Coming from a lisp "dabbler"] I'd always thought ("always" is the last year
> that I've been toying with lisp) that the backquote syntax had a certain
> beauty to it. It's hard to describe but I felt that "," and ",@" painted the
> actual action into my editor. "," "nicked and opened" what followed and ",@"
> "nicked and unrolled" what followed.
>
> Assuming your suggestion was serious (I've got this funny feeling I may have
> missed the joke in your post), why do you think the current syntax
> is ugly?
it certainly looks weird.
where else do you find the comma attached to the *front* of anything?
i suppose you get used to it, but it is rather jarring to have your
normal sense of where to put commas completely turned on its head.
--
J o h a n K u l l s t a m
[kull...@ne.mediaone.net]
Don't Fear the Penguin!
Bulent Murtezaoglu
[...]
JK> where else do you find the comma attached to the *front* of
JK> anything?
JK> i suppose you get used to it, but it is rather jarring to have
JK> your normal sense of where to put commas completely turned on
JK> its head.
How is this different than '+' in prefix?
You get used to it in about a few hours, in my experience.
I may be biased though, I already had decided that I loved lisp
when I started using backquote and comma.
BM
Mike McDonald
Johan Kullstam <kull...@ne.mediaone.net> writes:
> where else do you find the comma attached to the *front* of anything?
>
> i suppose you get used to it, but it is rather jarring to have your
> normal sense of where to put commas completely turned on its head.
>
I think that's a good thing! It draws your attention to it that something
unusual is going on.
Mike McDonald
mik...@mikemac.com
Johan Kullstam
i am not trying to say it's good or bad here. it is just unique and
takes some getting used to.
Martti Halminen
> The syntax of Backquote is about as ugly as one can imagine.
> Unfortunately, backquote is almost always used when
> defining macros. And with the macro being one of the key
> strengths of lisp, we have the situation where a key strength
> of lisp uses one of the most bizarre and ugly syntactic constructs
> in the language. At least parenthesis have a form of beauty
> and functionality, but backquote is just plain ugly and bizzare.
>
> So how about some suggestions on something different,
> something better. How about a straw man:
> Use [] to replace , and {} to replace ,@
> i.e. `(zap ,foo ,@bar) ==> `(zap [foo] {bar})
First of all, you have a readability problem with this particular
suggestion: I read your `(zap [foo] {bar}) first as `(zap [foo] (bar)),
in other words, for anybody with less than perfect eyesight, () and {}
are uncomfortably similar in some fonts.
The other problem I have with this is that this would add more
parentheses to the program; as the most often heard complaint from
newcomers is that all the parens make the language unreadable, adding
more of them would be unlikely to help.
I find that I actually prefer Lisp's style of using no explicit end
delimiter in quote etc.: saves me from all the problems with missing or
misplaced end delimiters, the whitespace or parens ending the form are
quite sufficient for my taste as end indicators.
I prefer the current backquote to your suggestion, I'd rather save the
[]{} for the user for any extension languages etc.
--
________________________________________________________________
^. Martti Halminen
/ \`. Design Power Europe Oy
/ \ `. Tekniikantie 12, FIN-02150 Espoo, Finland
/\`. \ | Tel:+358 9 4354 2306, Fax:+358 9 455 8575
/__\|___\| Mailto:Martti....@dpe.fi http://www.dpe.fi
Erik Naggum
| Modern Emacs Lisp readers have horrific kluges to recognise old-style
| backquoting; this also means that certain (admittedly obscure) usages of
| backquote will fail.
this isn't quite true. the new-style backquoting is returned as
old-style function calls with funny function names.
(car (read-from-string "`(a ,b ,@c)")) => (\` (a (\, b) (\,@ c)))
(the two values are returned as a cons.) moreover, ` is a macro:
(symbol-function '\`) => (macro . #<lambda (arg)>)
this macro is not very well-written and frequently gets seriously
confused.
#:Erik, who has tried and given up fixing it
Erik Naggum
| where else do you find the comma attached to the *front* of anything?
what do you mean "comma"? don't you see it's a low quote?
#:Erik :)
Erik Naggum
| What is the license?
basically "use it, don't change it, don't redistribute it."
it's much better for all of us that this is fixed in the actual sources.
#:Erik
Dave Seaman
Since the ordinary quote (') is sometimes called an "inverted comma,"
what could be more natural than un-inverting the comma in order to
reverse the effect? This seems especially appropriate in constructs like
',item, where the item needs to be evaluated and then quoted.
--
Dave Seaman dse...@purdue.edu
Pennsylvania Supreme Court Denies Fair Trial for Mumia Abu-Jamal
<http://mojo.calyx.net/~refuse/altindex.html>
Tim Bradshaw
> where else do you find the comma attached to the *front* of anything?
It's not a comma, it's a quote in the wrong place. (I bet this isn't
really why it's done like that, but...)
(and what about colons on the front of keywords...)
--tim
Barry Margolin
>Johan Kullstam <kull...@ne.mediaone.net> writes:
>
>> where else do you find the comma attached to the *front* of anything?
>
>It's not a comma, it's a quote in the wrong place. (I bet this isn't
>really why it's done like that, but...)
The idea is that the comma is the *opposite* of the backquote.
>(and what about colons on the front of keywords...)
Colons were already being used as package separators, so it was natural to
adopt them as a keyword indicator as well. Putting them at the beginning
was done by analogy with the way options are often specified to OS commands
(e.g. -<keyword> on Multics, -<letter> on Unix, /<keyword> on ITS and most
DEC OS's).
--
Barry Margolin, bar...@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Erik Naggum
| Another area where there exist major room for improvement in CL...
it doesn't appear that you want to use Common Lisp at all, but it also
doesn't appear that you have any gripes more fundamental than syntactic
aesthetics. what gives? this is a part of the language you can change
at will, but there simply is no need to do this in Common Lisp.
speaking of which, I explained to the British guy sitting next to me on a
recent transatlantic flight that I worked with Common Lisp. he in turn
talked about his great hobby: ornithology, where "common" is a synonym
for "garden", as in "garden variety". he thought it would have better
acceptance if it was called "Garden Lisp". feel free to use it, Kelly.
#:Erik
Kelly Murray
>
> Kelly Murray wrote:
>
> > The syntax of Backquote is about as ugly as one can imagine.
> > Unfortunately, backquote is almost always used when
> > defining macros. And with the macro being one of the key
> > strengths of lisp, we have the situation where a key strength
> > of lisp uses one of the most bizarre and ugly syntactic constructs
> > in the language. At least parenthesis have a form of beauty
> > and functionality, but backquote is just plain ugly and bizzare.
> >
> > So how about some suggestions on something different,
> > something better. How about a straw man:
> > Use [] to replace , and {} to replace ,@
> > i.e. `(zap ,foo ,@bar) ==> `(zap [foo] {bar})
>
> First of all, you have a readability problem with this particular
> suggestion: I read your `(zap [foo] {bar}) first as `(zap [foo] (bar)),
> in other words, for anybody with less than perfect eyesight, () and {}
> are uncomfortably similar in some fonts.
Well, I asked for suggestions, so far there is only criticism.
I find it fascinating that such an ugly thing can be defended.
If you can't offer something better, then let me ask that
you propose something that is even uglier.
Not something more confusing, but uglier.
-kelly
Barry Margolin
Kelly Murray <k...@IntelliMarket.Com> wrote:
>Well, I asked for suggestions, so far there is only criticism.
>I find it fascinating that such an ugly thing can be defended.
>If you can't offer something better, then let me ask that
>you propose something that is even uglier.
>Not something more confusing, but uglier.
How about:
(quasiquote zap (unquote foo) (unquote-splicing bar))
This is what Scheme specifies `(zap ,foo ,@bar) should expand into. But no
one in their right mind would enter this explicitly into a macro
definition.
Virtually anything is going to be somewhat cryptic, since the goal of
backquote is to be terse so that the general structure of the template
isn't obscured. The same reasoning applies to FORMAT's control strings
(for a giant leap the otherway, and IMHO backward, take a look at C++'s I/O
operators << and >>).
As a general style convention, paired characters like [] and {} should be
saved for things that do grouping (analogous to the use of () and #() for
lists and arrays). Macro characters that just modify a single s-expression
should prefix characters; no terminating character is needed, since Lisp's
syntax already makes that apparent. That's why Lisp uses 'foo rather than
'foo', and why ,foo and ,@foo are more appropriate than [foo] and {foo}.
Christopher C Stacy
(defun find-drink (&optional (occupation "astronaut"))
(sql:select [favorite_drink] :from [people] :where [= [occupation] ?occupation]))
Kalle Olavi Niemitalo
> (quasiquote zap (unquote foo) (unquote-splicing bar))
>
> This is what Scheme specifies `(zap ,foo ,@bar) should expand into.
You missed one level of parentheses:
(quasiquote (zap (unquote foo) (unquote-splicing bar)))
Erik Naggum
| Well, I asked for suggestions, so far there is only criticism.
complaining about syntax is not constructive to begin with.
| I find it fascinating that such an ugly thing can be defended.
I find it fascinating that you are so concerned with minor things.
| If you can't offer something better, then let me ask that you propose
| something that is even uglier.
well, you just did that. coming up with something uglier still would
take away time from doing constructive work.
your constant whining about how ugly Common Lisp is probably furthers
_some_ goal of yours, but it is destructive and disruptive to others.
#:Erik
Mike McDonald
Kelly Murray <k...@IntelliMarket.Com> writes:
> Well, I asked for suggestions, so far there is only criticism.
> I find it fascinating that such an ugly thing can be defended.
Beauty is in the eye of the beholder.
I personally don't agree with your sense of asthetics.
Mike McDonald
mik...@mikemac.com
Barry Margolin
But I'm guessing it follows the "grouping" convention I mentioned, e.g.
(sql:select [field1 field2 ...] :from [table1 table2 ...] ...)
Kelly Murray
Be that as it may, I still haven't seen you or anyone else
suggest something they consider better.
Do you mean to imply a leading , is the best looking syntax
for doing in-place pattern substitution?
I believe a $ is used by some applications,
`(foo $bar $@zap)
I will acknowledge that embeddings using ,', the comma
makes it clear the levels. But then I'd also say at this
point the backquote expressions are REALLY ugly, and perhaps
more important, become very hard to understand.
What did the Dylan folks come up with macros?
-kelly
Dorai Sitaram
Kelly Murray <k...@IntelliMarket.Com> wrote:
>Mike McDonald wrote:
>>
>> Beauty is in the eye of the beholder.
>>
>> I personally don't agree with your sense of asthetics.
>
>Be that as it may, I still haven't seen you or anyone else
>suggest something they consider better.
>Do you mean to imply a leading , is the best looking syntax
>for doing in-place pattern substitution?
>
>I believe a $ is used by some applications,
>`(foo $bar $@zap)
>
>I will acknowledge that embeddings using ,', the comma
>makes it clear the levels. But then I'd also say at this
>point the backquote expressions are REALLY ugly, and perhaps
>more important, become very hard to understand.
A hard-to-understand backquote/comma expression is
going to remain hard to understand even if you change
the notation. The difficulty is related to the
complexity of the expression itself, and not blamable
on syntax.
To answer your question: I don't think there can be a
strictly better syntax.
--d
Mike McDonald
Kelly Murray <k...@IntelliMarket.Com> writes:
> Mike McDonald wrote:
>>
>> In article <36D5BFE7...@intellimarket.com>,
>> Kelly Murray <k...@IntelliMarket.Com> writes:
>>
>> > Well, I asked for suggestions, so far there is only criticism.
>> > I find it fascinating that such an ugly thing can be defended.
>>
>>
>> I personally don't agree with your sense of asthetics.
>>
>
> Be that as it may, I still haven't seen you or anyone else
> suggest something they consider better.
> Do you mean to imply a leading , is the best looking syntax
> for doing in-place pattern substitution?
No, it means we're not unhappy enough with the current syntax to waste our
time designing another one.
Mike McDonald
mik...@mikemac.com
Paul Meurer
<bar...@bbnplanet.com> wrote:
>In article <x8lvhgp...@world.std.com>,
>Christopher C Stacy <cst...@world.std.com> wrote:
>>The [] delimiters are used in various SQL packages for embedded SQL expressions.
>>
>>(defun find-drink (&optional (occupation "astronaut"))
>> (sql:select [favorite_drink] :from [people] :where [= [occupation]
>
>But I'm guessing it follows the "grouping" convention I mentioned, e.g.
>
>(sql:select [field1 field2 ...] :from [table1 table2 ...] ...)
>
Not exactly. Table or field identifiers can be structured: a table
might be qualified by owner and database, and a "field" might be a SQL
function application. So you would write e.g.
(select [max [field1]] [min [field2]]
:from [owner table @ remote-database])
But I guess your point remains the same.
(And if you ask me, I find the comma-backquote-syntax very elegant. It
is very inintrusive and gives you often a good visual impression of
how the expanded code would look like.)
Paul
Paul Meurer at HIT UiB no
Humanities Information Technologies,
University of Bergen
Allegt. 27
5007 Bergen, Norway
Frank A. Adrian
Kelly Murray wrote in message <36D6FBC2...@IntelliMarket.Com>...
>What did the Dylan folks come up with macros?
Something incredibly ugly and stupid because the idiots at Apple decided
that the C crowd could be placated by getting rid of parentheses. This made
the language ugly and so they had to define an ugly macro system with
bunches of special cases. The current Dylan macro language reference takes
about 25 sections to describe the mess they came up with. If you like this
sort of thing, I heartily reccommend Dylan to you, so you may experience for
yourself the joys of working with crappy syntax...
faa
Barry Margolin
In particular, I think Dylan's macros are more comparable to Scheme's
high-level macros defined with syntax-rules, rather than CL's mechanism of
consing up explicit s-expressions. Neither of them uses (or needs)
anything like backquote, but neither do they have the full flexibility of
CL's macros (you can't execute arbitrary programs to produce arbitrary
code).
Kent M Pitman
> I will acknowledge that embeddings using ,', the comma
> makes it clear the levels. But then I'd also say at this
> point the backquote expressions are REALLY ugly, and perhaps
> more important, become very hard to understand.
How is this statement different than the statement "calculus is ugly"
or "lambda calculus is ugly"? There is nothing a priori hard to
understand about things like ,', if you know the idioms. I have
used these for years and once I figured out what the nesting rules
were, I was completely comfortable with it and it's hard for me to
imagine anything else being more perspicuous [to me]. I sometimes
rewrite these in ways that avoid it because I know others have an
emotional reaction to the nestings, but I consider that an accomodation
to bad preparation for use of the tools, not an admission that
the notation was inelegant.
,', means "this token is substituted from the layer two out"
,',', means "this token is substituted from the layer three out"
,, means "this is an active token both times this expands"
,,, means "this is an active token all three times this expands"
Things like ,,', are harder to say verbally because you have to think
about a more complex interaction, but if the complex interaction is
what you need, it's hard to think of a more concise way to express it.
(I'm not saying that concise is a uniquely determined synonym for
elegance, but it's one possible measure and it does not automatically
obscure meeting.)
Incidentally, although the meaning of c...r in CL is well-understood,
I suspect people only "understand" and certainly I only recommend
as good style the use of car, cdr, caar, and the set denoted by
the regular expression cad*r. In particular, it is 99% of the time
an abstraction violation (in the sense that it almost always coalesces
two unrelated data structure accesses in the same operation if you
use two a's in a c...r name unless you're using caar (and it only
works in that case because the two unrelated accesses -- the first
of a list and the first of a pair -- have been defined to have meaning
as "the first of an alist").
But I guess my point is that ,',', is not much more complicated to
understand thatn cdddr. And ,,', is not a lot more complicated
to understand than cdaar. It's not the notation that's making it hard
but the actual request to perform this operation in the first place.
At the time backquote was added to Maclisp, there were a zillion people
who had done the equivalent thing in different ways using these or
similar characters. Everyone knew something like this was needed.
But one of several things that helped the backquote we know to
win over some others, as I recall, was that after an extended discussion
of nesting we decided it nested correctly and intuitively. There were
one or more others proposed that did NOT nest correctly and could not
be freely substituted into others without destroying their meaning
(because they counted from the outside in, and insertion into another
expression changed the count downward and hence the actual meaning
of the commas). So it's odd since it was chosen for its intuitiveness
(and since I believe that choice was made correctly) to hear people
always say how unintuitive it was. Smart people. I honestly think
they have never tried and have mostly given in to the hype suggesting
it's so.
JMO.
Kent M Pitman
> > Be that as it may, I still haven't seen you or anyone else
> > suggest something they consider better.
> > Do you mean to imply a leading , is the best looking syntax
> > for doing in-place pattern substitution?
>
> No, it means we're not unhappy enough with the current syntax to waste our
> time designing another one.
People who weren't there at the time should understand that when backquote
was introduced, comma had a meaning in Maclisp: it was a synonym for space.
I think I was one of the only people who complained and mainly because
I was using it in data files as a pretty notation for coordinates:
(1,2)
meant the same as
(1 2)
I grumbled that this "useful" meaning would go away. But in retrospect
I think that since there was no value to the redundancy and since a special
purpose coordinate pair reader is so easy to write, the value of having
chosen a character which was wholly redundant and which virtually no one
used for anything real was very high, and had another character like
"$" been taken, it would have been much worse because lots of programs
used the others as alphabetics.
The grabbing of @ was much more controversial and many program bugs
were discovered in printers that printed things like '`(foo , @bar)
incorrectly. Nowadays I think all printers mostly anticipate this
one. But the competitors were mostly things like [foo ! bar] and
<foo .bar baz> and other baroque things like that which didn't "look"
like what they were making and ultimately I think would have done much
worse.
Also, if you think about the "Lisp philosophy" you'll see it's all about
the idea that notations are introduced by a lead-in thing. Only a few
things aren't that way (such as package prefixes, which are infix) and
almost without exception they are massively problematic. It is hard to
write a good parser for "potential numbers" that figures out when something
is a number and when it's not. It is not rocket science to write something
that figures out how to parse foo:bar, but it's painful enough that it's
annoying. By contrast, things like quote and the sharpsign readmacro and the
backquote and comma parsers are very easy to write because you immediately
know from the get-go what you're parsing and can plan ahead for it.
Anyway, I think the choice of a prefix character was the right thing.
And, as I've argued above, the choice of comma as that prefix character
was pretty good. It's relatively unobtrusive (which I think was one of
the issues--I think only dot really competed and had another meaning for
consing so was probably good to stay clear of). I think backquote
was a much less good choice because people can't tell ` and ' apart
visually. And most people don't complain about the ` -- they focus all
their anger on the , .... puzzles me.
I guess I'm rambling. But presumably this is mostly trivia you wouldn't
know if you weren't there to see.
Kelly Murray
Yes, there could be confusion between {body} *var* and {body}* var,
but in my world, we rarely use global variables.
As existing CL'ers don't seem to care, it doesn't matter
what I pick, it won't be liked. The old syntax should still
work, just like the old IF syntax still works in NiCLOS.
If I asked about more substantial changes to CL, such
as multiprocessing, datatbase, locking, or object system changes
on this newsgroup, one simply can't have an informed opinion
unless they spend time studying the issue.
For example, NiCLOS eliminates EQL specializers on methods.
If you can tell me how much they cost in terms of complexity
of the object system implementation, then any discussion of
their value might be worthwhile, otherwise it's not worth much.
Not true for syntax, everyone can have a valid opinion,
as it's all subjective.
-Kelly Murray k...@niclos.com
(macro atomically (name &rest body)
(if name
then
`(with-lock ({name}) {body}*)
else
`(excl:without-interrupts {body}*)
))
(macro atomically (name &rest body)
(if name
then
`(with-lock (,name) ,@body)
else
`(excl:without-interrupts ,@body)
))
Johan Kullstam
> I think I've settled on using {} for , and {}* for ,@.
> Yes, there could be confusion between {body} *var* and {body}* var,
> but in my world, we rarely use global variables.
????
> As existing CL'ers don't seem to care, it doesn't matter
> what I pick, it won't be liked. The old syntax should still
> work, just like the old IF syntax still works in NiCLOS.
>
> If I asked about more substantial changes to CL, such
> as multiprocessing, datatbase, locking, or object system changes
> on this newsgroup, one simply can't have an informed opinion
> unless they spend time studying the issue.
> For example, NiCLOS eliminates EQL specializers on methods.
> If you can tell me how much they cost in terms of complexity
> of the object system implementation, then any discussion of
> their value might be worthwhile, otherwise it's not worth much.
> Not true for syntax, everyone can have a valid opinion,
> as it's all subjective.
not true. i think syntax is what makes lisp as powerful as it is.
lisp has a very consistent syntax based on the list as denoted by
parens. since (almost) everything is infix, it is easy to write a
parser.
what does this buy us? ease of making a lisp parser is nice, but not
directly important. what it does give is the power of *macros*.
since programs have a regular structure, we can easily apply programs
to code itself. and since macros look much like programs, we can make
macro generating macros which make code. imho this is most of the
secret of lisp.
sure, other methods of quoting are possible. just as (quote x) is 'x,
so could (quasiquote x) be `x &c. this is in keeping with the style
of lisp. however, if you break the style, you could be breaking that
which makes lisp strong!
do not destroy what makes lisp powerful.
apart from appealing to your sense of what is pretty, how does {} and
{}* fare as programming fodder? are they as easy to use in a program?
can they be mechanically layered by the macro structure? if they are
just as useful, why go out of your way to invent a gratutious syntax
variant? if they are *better*, please explain how and persuade us to
your side.
you need to think all these things through.
> -Kelly Murray k...@niclos.com
>
> (macro atomically (name &rest body)
> (if name
> then
> `(with-lock ({name}) {body}*)
> else
> `(excl:without-interrupts {body}*)
> ))
>
> (macro atomically (name &rest body)
> (if name
> `(with-lock (,name) ,@body)
> `(excl:without-interrupts ,@body)))
Kelly Murray
>
> apart from appealing to your sense of what is pretty, how does {} and
> {}* fare as programming fodder? are they as easy to use in a program?
One more, my coffee break is over, then back to work..
I am not destroying a key aspect of what makes lisp powerful,
as Dylan did when it went full-boogy PASCALish.
That is the beauty of it in my mind, all the power, but
with a sense of C/Java/Basic structure. Keep in mind
that 99.9% of programmers don't use Lisp. Should one
cater to the .1% that does if it turns off the other 99.9%.
If it turns them off too, then I still lose nothing I didn't
already have. In any case, y'all tell me the syntax doesn't
matter, people will learn whatever twisted notation they
need to if the value in return is compelling, so indulge me.
In any case,
The syntax of `(foo ,bar ,@more) does not have a
defined representation in Common Lisp. Do a (READ)
and type in the above, and you get some implementation dependent
junk. It doesn't need to be defined, as 'foo is (quote foo),
because macros don't manipulate backquote expression, they manipulate
non-backquotes using backquote.
The syntax of `(foo {bar} {more}*) will be processed just
like backquote, you'd get something like
`(excl::backquote foo (excl::bq-comma bar) (excl::bg-comma-atsign more))
-Kelly
Lieven Marchand
> I think I've settled on using {} for , and {}* for ,@.
> Yes, there could be confusion between {body} *var* and {body}* var,
> but in my world, we rarely use global variables.
>
> As existing CL'ers don't seem to care, it doesn't matter
> what I pick, it won't be liked. The old syntax should still
> work, just like the old IF syntax still works in NiCLOS.
Speaking for myself, I don't have any problems with the existing
backquote syntax, but I could also easily get used to yours. I don't
understand what you find so important about it. You can even change it
to your style with some reader magic in existing CL implementations
without writing one yourself.
> If I asked about more substantial changes to CL, such
> as multiprocessing, datatbase, locking, or object system changes
> on this newsgroup, one simply can't have an informed opinion
> unless they spend time studying the issue.
I'd be interested in seeing some documentation about your system.
> For example, NiCLOS eliminates EQL specializers on methods.
> If you can tell me how much they cost in terms of complexity
> of the object system implementation, then any discussion of
> their value might be worthwhile, otherwise it's not worth much.
I'm not a CLOS guru but I haven't seen many compelling examples of
their usefullness. They can inhibit inlining of dispatching based on
inferred types. And special cases can be treated, be it more clumsily,
in the generic function specialized on their type. I don't have any
large CLOS programs at hand right now, but I wonder how often their
used in real programs.
--
Lieven Marchand <m...@bewoner.dma.be>
------------------------------------------------------------------------------
It was six months of C++ that made me determined to find something else to do
with my life. #:Erik Naggum
Christopher R. Barry
> In any case, y'all tell me the syntax doesn't matter
Actually, it seems everyone who has commented on it doesn't like
it. Count in my vote against it as well. If you're only making NiCLOS
for your own use, then to each his own. Else, you may want to do
better than just having the existing Common Lisp macro syntax
"probably still work", or whatever it was you said to that effect.
A lot of people like to extend the language to use their own
bastardized if-else constructs and procedural-language idioms. I
believe a design goal of the language was to allow this sort of
thing. As a matter of fact, using `{' and `}' which are supposed to be
"user reserved macro characters" will probably tick a few people off
that like to use them for the same kind of stuff you do.
Just a few points to consider,
Christopher
Barry Margolin
Lieven Marchand <m...@bewoner.dma.be> wrote:
>Speaking for myself, I don't have any problems with the existing
>backquote syntax, but I could also easily get used to yours. I don't
>understand what you find so important about it. You can even change it
>to your style with some reader magic in existing CL implementations
>without writing one yourself.
I think I understand what he likes about his syntax. It looks kind of like
BNF, or the notation used in things like RFC 822 to describe syntax.
Fernando D. Mato Mira
Kelly Murray wrote:
> I think I've settled on using {} for , and {}* for ,@.
> Yes, there could be confusion between {body} *var* and {body}* var,
> but in my world, we rarely use global variables.
Thanks for posting this. I'm not sure if you'll be selling NiCLOS,
but at least I won't need to find out, as it has just ruled itself
out for the next time I have to choose a Lisp system to integrate
in an application. I don't want the language to gratuitously steal
characters
I might use in high-level representations. Also, having been burned
several times already,
I don't use any non-portable syntactic features (including things
like `foo:'), so I can move quite freely from one dialect to another:
ACL (no C++ FFI)
Lispworks (broken C++ FFI)
ILOG Talk (unusable GC w/Performer, no multithreading support, death)
"(defliteral :foo foo:) .."
MzScheme (still no native compilation, integration w/Java uncertain)
"(define :foo ':foo) (define t #t) (define else t) .."