I read the recent thread:
"Why some people think that Scheme is not a Lisp":
http://groups.google.com/groups?dq=&hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=sfwk786uzh0.fsf%40shell01.TheWorld.com&prev=/groups%3Fq%3Dcomp.lang.lisp%26ie%3DUTF-8%26oe%3DUTF-8%26hl%3Den%26btnG%3DGoogle%2BSearch
I understand that Lisp semantics are based on lists and Scheme
semantics are based on Strings. Now can you give me a short concise
example where this difference shows in practical terms?
Eran Gatt gave the following example:
<quote>
Yes. The canonical example is:
(defun foo () '(1 2 3))
(eq (foo) (foo))
Common Lisp requires this to return T, but the Scheme equivalent is
not
required to return #T (and indeed there are Scheme implementations
that do
not return #T).
</quote> <!-- sidenote: you see one advantage of XML over S-expr here.
Unlike a parenthesis you immediately know what this closing tag refers
to -->
The example is good, but it doesn't SEEM to be practically relevant.
I'm not saying it isn't.
Can anyone give a simple example where you do some computational task
with Lisp that would be much harder to do with Scheme so that the
advantage of Lisp becomes more apparent?
Thank you very much...
In article <····························@posting.google.com>,
·········@gmx.net (thelifter) wrote:
> Can anyone give a simple example where you do some computational task
> with Lisp that would be much harder to do with Scheme so that the
> advantage of Lisp becomes more apparent?
(defmacro compile-time-factorial (n)
(if (numberp n)
(if (and (integerp n) (> n 0))
(factorial n)
(error "Can't take the factorial of ~S" n))
(if (or (symbolp n) (listp n))
`(factorial ,n)
(error "Can't take the factorial of ~S" n))))
E.
···@jpl.nasa.gov (Erann Gat) writes:
> In article <····························@posting.google.com>,
> ·········@gmx.net (thelifter) wrote:
>
>> Can anyone give a simple example where you do some computational task
>> with Lisp that would be much harder to do with Scheme so that the
>> advantage of Lisp becomes more apparent?
>
> (defmacro compile-time-factorial (n)
> (if (numberp n)
> (if (and (integerp n) (> n 0))
> (factorial n)
> (error "Can't take the factorial of ~S" n))
> (if (or (symbolp n) (listp n))
> `(factorial ,n)
> (error "Can't take the factorial of ~S" n))))
>
> E.
(require (lib "defmacro.ss"))
(defmacro compile-time-factorial (n)
(define (factorial x)
(if (zero? x)
1
(* x (factorial (sub1 x)))))
(if (number? n)
(if (and (integer? n) (> n 0))
(factorial n)
(error "Can't take the factorial of " n))
(if (or (symbol? n) (list? n))
`(factorial ,n)
(error "Can't take the factorial of " n))))
Joe Marshall <···@ccs.neu.edu> writes:
> ···@jpl.nasa.gov (Erann Gat) writes:
>
> > In article <····························@posting.google.com>,
> > ·········@gmx.net (thelifter) wrote:
> >
> >> Can anyone give a simple example where you do some computational task
> >> with Lisp that would be much harder to do with Scheme so that the
> >> advantage of Lisp becomes more apparent?
> >
> > (defmacro compile-time-factorial (n)
> > (if (numberp n)
> > (if (and (integerp n) (> n 0))
> > (factorial n)
> > (error "Can't take the factorial of ~S" n))
> > (if (or (symbolp n) (listp n))
> > `(factorial ,n)
> > (error "Can't take the factorial of ~S" n))))
> >
> > E.
>
> (require (lib "defmacro.ss"))
>
> (defmacro compile-time-factorial (n)
>
> (define (factorial x)
> (if (zero? x)
> 1
> (* x (factorial (sub1 x)))))
>
> (if (number? n)
> (if (and (integer? n) (> n 0))
> (factorial n)
> (error "Can't take the factorial of " n))
> (if (or (symbol? n) (list? n))
> `(factorial ,n)
> (error "Can't take the factorial of " n))))
Wouldn't it be more fun to write just plain old factorial and
then a compiler-macro for it? Scheme doesn't have compiler
macros and the facility is hard to simulate.
Not that this is itself a "deep" problem with Scheme. The deep
problem, I think, is better expressed as "Scheme's lack of
consideration for the many different `times' that decisions
are made." That is, the collective absence of #., eval-when,
load-time-value, define-compiler-macro, etc. are more of a
collective concern and more of an indication of overall
differences in politics/philosophy than any given one of those.
The fact that they have "other ways" of addressing one or more
of them isn't really a "fix" for this claim, since the issue
isn't "what can be computed" but "how". We already know from
Turing that "what can be computed" is not in question; the only
difference is ever "how" and whether two dialects/languages/language
families are either "mostly alike" or "hardly alike". So unless
the answer is "you missed eval-when. it's on page 47." then the
answer is "you're right, they're different on these important
points"... unless you think these points are unimportant. and
then we disagree as well...
I'm speaking to the generic "you" here, not necessarily to Joe.
Kent M Pitman <······@world.std.com> writes:
> Wouldn't it be more fun to write just plain old factorial and
> then a compiler-macro for it? Scheme doesn't have compiler
> macros and the facility is hard to simulate.
>
> Not that this is itself a "deep" problem with Scheme. The deep
> problem, I think, is better expressed as "Scheme's lack of
> consideration for the many different `times' that decisions
> are made."
I think it isn't really a lack of consideration, but a lack of
agreement amongst the various scheme implementors.
> I'm speaking to the generic "you" here, not necessarily to Joe.
This is a generic reply, not necessarily from me.
Joe Marshall <···@ccs.neu.edu> writes:
> (require (lib "defmacro.ss"))
>
> (defmacro compile-time-factorial (n)
Oh my, how /unhygienic/!!
You are cheating and you know it.
> (define (factorial x)
> (if (zero? x)
> 1
> (* x (factorial (sub1 x)))))
Intresting. Do you have a reference for this one?
> (if (number? n)
> (if (and (integer? n) (> n 0))
> (factorial n)
> (error "Can't take the factorial of " n))
> (if (or (symbol? n) (list? n))
> `(factorial ,n)
> (error "Can't take the factorial of " n))))
I am flabbergasted. You must be a GENIUS!!
Mario S. Mommer wrote:
> Joe Marshall <···@ccs.neu.edu> writes:
>
>>(require (lib "defmacro.ss"))
>>
>>(defmacro compile-time-factorial (n)
>
>
> Oh my, how /unhygienic/!!
Where? The factorial is local to
the compile-time-factorial function.
--
Jens Axel S�gaard
Jens Axel S�gaard <······@jasoegaard.dk> writes:
> Mario S. Mommer wrote:
> > Joe Marshall <···@ccs.neu.edu> writes:
> >
> >>(require (lib "defmacro.ss"))
> >>
> >>(defmacro compile-time-factorial (n)
> > Oh my, how /unhygienic/!!
>
> Where? The factorial is local to
> the compile-time-factorial function.
Splitting hairs, eh? :-)
Wasn't the party line over at c.l.s that cl's defmacro is broken
because it is not "hygienic"?
Besides, you just have spotted a bug in his code.
Mario S. Mommer <········@yahoo.com> writes:
> Jens Axel S�gaard <······@jasoegaard.dk> writes:
>> Mario S. Mommer wrote:
>> > Joe Marshall <···@ccs.neu.edu> writes:
>> >
>> >>(require (lib "defmacro.ss"))
>> >>
>> >>(defmacro compile-time-factorial (n)
>> > Oh my, how /unhygienic/!!
>>
>> Where? The factorial is local to
>> the compile-time-factorial function.
>
> Splitting hairs, eh? :-)
>
> Wasn't the party line over at c.l.s that cl's defmacro is broken
> because it is not "hygienic"?
I wouldn't say characterize that as the `c.l.s party line'.
A CL defmacro clearly isn't broken in the context of CL.
A CL-type macro in a Scheme context, however, cannot be guaranteed to
not inadvertantly capture bindings. If you want or need that kind of
a guarantee, then you'll need some sort of variable renaming that CL
macros cannot do.
Non-hygienic Scheme macros have been around for longer than Common
Lisp has, but since a canonical implementation couldn't be agreed
upon, the report never included them.
Mario S. Mommer wrote:
> Joe Marshall <···@ccs.neu.edu> writes:
> > (require (lib "defmacro.ss"))
> >
> > (defmacro compile-time-factorial (n)
>
> Oh my, how /unhygienic/!!
>
> You are cheating and you know it.
Why? The original question asked for a demonstration of how the claim that
"Lisp semantics are based on lists" has practical relevance. The provided
answer didn't address that issue at all, and Joe Marshall's Scheme version
of the same macro demonstrates this. Note that defmacro can be implemented
in terms of syntax-case, a portable Scheme macro system.
Anton
In article <····················@newsread2.news.atl.earthlink.net>, "Anton
van Straaten" <·····@appsolutions.com> wrote:
> Mario S. Mommer wrote:
> > Joe Marshall <···@ccs.neu.edu> writes:
> > > (require (lib "defmacro.ss"))
> > >
> > > (defmacro compile-time-factorial (n)
> >
> > Oh my, how /unhygienic/!!
> >
> > You are cheating and you know it.
>
> Why? The original question asked for a demonstration of how the claim that
> "Lisp semantics are based on lists" has practical relevance. The provided
> answer didn't address that issue at all, and Joe Marshall's Scheme version
> of the same macro demonstrates this. Note that defmacro can be implemented
> in terms of syntax-case, a portable Scheme macro system.
Note that the OP asked for an example that was made easier by Lisp's
treatment of programs as lists, not an example that was made possible by
it. If you actually go and write the code for compile-time-factorial
using syntax-case it will become quite clear that my example is in fact on
point.
(define-macro is not a part of the Scheme standard. It is provided by
many Scheme implementations because, of course, Scheme does not *prohibit*
programs from being represented as lists, but neither does it require them
to be so, and so you cannot count on having define-macro at your
disposal.)
E.
Erann Gat wrote:
> Note that the OP asked for an example that was made easier by Lisp's
> treatment of programs as lists, not an example that was made possible by
> it. If you actually go and write the code for compile-time-factorial
> using syntax-case it will become quite clear that my example is in fact on
> point.
>
> (define-macro is not a part of the Scheme standard. It is provided by
> many Scheme implementations because, of course, Scheme does not *prohibit*
> programs from being represented as lists, but neither does it require them
> to be so, and so you cannot count on having define-macro at your
> disposal.)
An implementation of defmacro in terms of syntax-case seems quite
straightforward, as such things go. The production-quality implementation
of define-macro in PLT Scheme is 139 lines.
Your example seems to depend on the presence or absence of defmacro, which
you claim depends on this property of programs being represented as lists.
However, PLT Scheme represents programs internally as abstract syntax
objects, and easily supports defmacro, so the causal connection you claim
isn't apparent to me. The issue is not simply whether programs are treated
as lists.
To try to avoid going around again on the specific minutiae of this issue,
I'm curious to know whether you think the idea of specifying program
semantics using an abstract syntax definition, i.e. not necessarily Lisp
lists, somehow makes it impossible to achieve what Common Lisp achieves.
If you agree that it's possible to achieve the same semantics via an
abstract syntax, then your real point is essentially just that Scheme
doesn't have the particular semantics you want. This has little to do with
the specific way in which program representation is defined.
Anton
In article <·····················@newsread2.news.atl.earthlink.net>,
"Anton van Straaten" <·····@appsolutions.com> wrote:
> To try to avoid going around again on the specific minutiae of this issue,
> I'm curious to know whether you think the idea of specifying program
> semantics using an abstract syntax definition, i.e. not necessarily Lisp
> lists, somehow makes it impossible to achieve what Common Lisp achieves.
No, of course I don't believe that. Why would you even raise such a
ridiculous notion? This discussion was never about what is and is not
possible, it's about what is easy and what is hard. When it comes to what
is possible Greenspun's tenth always applies.
E.
Erann Gat wrote:
> In article <·····················@newsread2.news.atl.earthlink.net>,
> "Anton van Straaten" <·····@appsolutions.com> wrote:
>
> > To try to avoid going around again on the specific minutiae of this
issue,
> > I'm curious to know whether you think the idea of specifying program
> > semantics using an abstract syntax definition, i.e. not necessarily Lisp
> > lists, somehow makes it impossible to achieve what Common Lisp achieves.
>
> No, of course I don't believe that. Why would you even raise such a
> ridiculous notion? This discussion was never about what is and is not
> possible, it's about what is easy and what is hard. When it comes to what
> is possible Greenspun's tenth always applies.
You're right, sorry, but only in that "impossible" was the wrong choice of
words. "Harder" would work just as well. Lists are simply an abstraction
(and in Lisp, a particular implementation too). What the Scheme spec allows
for is for some other abstraction to be used to represent program code, in
particularly, abstractions which are better suited to storing all sorts of
other useful information related to source code. My question is, do you
think that this choice necessarily makes things harder for the sorts of
applications of lists you're thinking of?
But your answer is probably that you consider Scheme's semantics to be
defined on strings, so my question doesn't apply. However, I think that's a
misunderstanding of the spec, and various Scheme implementations back that
up.
Anton
In article <·····················@newsread2.news.atl.earthlink.net>,
"Anton van Straaten" <·····@appsolutions.com> wrote:
> Erann Gat wrote:
> > In article <·····················@newsread2.news.atl.earthlink.net>,
> > "Anton van Straaten" <·····@appsolutions.com> wrote:
> >
> > > To try to avoid going around again on the specific minutiae of this
> issue,
> > > I'm curious to know whether you think the idea of specifying program
> > > semantics using an abstract syntax definition, i.e. not necessarily Lisp
> > > lists, somehow makes it impossible to achieve what Common Lisp achieves.
> >
> > No, of course I don't believe that. Why would you even raise such a
> > ridiculous notion? This discussion was never about what is and is not
> > possible, it's about what is easy and what is hard. When it comes to what
> > is possible Greenspun's tenth always applies.
>
> You're right, sorry, but only in that "impossible" was the wrong choice of
> words. "Harder" would work just as well. Lists are simply an abstraction
> (and in Lisp, a particular implementation too). What the Scheme spec allows
> for is for some other abstraction to be used to represent program code, in
> particularly, abstractions which are better suited to storing all sorts of
> other useful information related to source code. My question is, do you
> think that this choice necessarily makes things harder for the sorts of
> applications of lists you're thinking of?
IMO what makes (some) things harder is that Scheme does not require that
this abstraction be made available as a first-class construct available
for manipulation by the user. Common Lisp does. (So does Python,
incidentally, and to my knowledge these are the only two languages that
do. Python's API is much more awkward than Lisp's:
http://www.python.org/doc/current/lib/module-parser.html)
> But your answer is probably that you consider Scheme's semantics to be
> defined on strings, so my question doesn't apply.
Sure it does. It doesn't really matter whether or not it is strictly true
that Scheme semantics are defined on strings or not, what matters is that
they are *not* defined on lists (or any other Scheme data structure).
They are defined on some abstract thing that is not accessible to the user
that happens to be isomorphic to lists, but which are not (necessarily)
lists. That's not my opinion, that is what I have been told by Scheme
people.
> However, I think that's a
> misunderstanding of the spec, and various Scheme implementations back that
> up.
What implementations provide says nothing about what the standard
requires. The Scheme standard defines a pretty impoverished language, so
it is no surprise that most implementations offer extensions of one sort
or another.
E.
Erann Gat wrote:
> In article <·····················@newsread2.news.atl.earthlink.net>,
> "Anton van Straaten" <·····@appsolutions.com> wrote:
> > Lists are simply an abstraction
> > (and in Lisp, a particular implementation too). What the Scheme spec
> > allows for is for some other abstraction to be used to represent program
> > code, in particular, abstractions which are better suited to storing all
sorts
> > of other useful information related to source code. My question is, do
you
> > think that this choice necessarily makes things harder for the sorts of
> > applications of lists you're thinking of?
>
> IMO what makes (some) things harder is that Scheme does not require that
> this abstraction be made available as a first-class construct available
> for manipulation by the user. Common Lisp does. (So does Python,
> incidentally, and to my knowledge these are the only two languages that
> do. Python's API is much more awkward than Lisp's:
> http://www.python.org/doc/current/lib/module-parser.html)
In practice, the capabilities of actual Scheme implementations in this area
are much, much closer to Common Lisp than Python's are. I would have
thought practice is what counts, but more below.
> It doesn't really matter whether or not it is strictly true
> that Scheme semantics are defined on strings or not, what matters is that
> they are *not* defined on lists (or any other Scheme data structure).
> They are defined on some abstract thing that is not accessible to the user
> that happens to be isomorphic to lists, but which are not (necessarily)
> lists. That's not my opinion, that is what I have been told by Scheme
> people.
I agree with that assessment of what the standard says, but it can't simply
be ignored that these abstract syntax things are often made available to the
user. A prominent example of this is the syntax-case macro system, which is
very portable across Schemes and provided natively in multiple
implementations.
I realize that you dislike the lack of a guarantee in the standard, but I'm
wondering whether this is based on actual experience of portability
problems, or simply comparing "marketing bullet points". I don't find it a
problem that syntax-case doesn't run on the LispMe Scheme implementation on
my Palm Pilot; but it does run on PLT, SISC, Gambit, and many other Schemes.
> > However, I think that's a
> > misunderstanding of the spec, and various Scheme implementations back
that
> > up.
>
> What implementations provide says nothing about what the standard
> requires. The Scheme standard defines a pretty impoverished language, so
> it is no surprise that most implementations offer extensions of one sort
> or another.
But that's the whole *point*!!! The Scheme spec is not supposed to be like
the Common Lisp spec. It was deliberately designed to allow a variety of
implementations which share a common set of core semantics. This feature in
particular wasn't left out of the spec - rather, it was left deliberately
open.
The problem is, there is no separate standard for "Core Common Lisp", and
there is no standard for "Big-Ass Scheme", and so these discussions
continually compare apples to apple seeds. The objection you're making
about "Scheme" doesn't seem to apply with any major implementation of
Scheme, afaict, and that's because those Schemes have done exactly what the
standard intended, which is to explore ways of doing things which have not
been cast in stone in a standard. In addition, high-level facilities like
defmacro are available in these major implementations, typically built on
top of whatever underlying facility is available, such as syntax-case - so
there's still significant commonality at the high level, even when
underlying implementations differ.
The benefit of this is that in the better implementations, the features of
the available syntax objects go beyond what a direct list representation of
source code can provide. So you're objecting to the very aspect of the
Scheme spec that has allowed Scheme implementations to improve on the
feature you're actually interested in.
Anton
In article <·····················@newsread2.news.atl.earthlink.net>,
"Anton van Straaten" <·····@appsolutions.com> wrote:
> Erann Gat wrote:
> > In article <·····················@newsread2.news.atl.earthlink.net>,
> > "Anton van Straaten" <·····@appsolutions.com> wrote:
> > > Lists are simply an abstraction
> > > (and in Lisp, a particular implementation too). What the Scheme spec
> > > allows for is for some other abstraction to be used to represent program
> > > code, in particular, abstractions which are better suited to storing all
> sorts
> > > of other useful information related to source code. My question is, do
> you
> > > think that this choice necessarily makes things harder for the sorts of
> > > applications of lists you're thinking of?
> >
> > IMO what makes (some) things harder is that Scheme does not require that
> > this abstraction be made available as a first-class construct available
> > for manipulation by the user. Common Lisp does. (So does Python,
> > incidentally, and to my knowledge these are the only two languages that
> > do. Python's API is much more awkward than Lisp's:
> > http://www.python.org/doc/current/lib/module-parser.html)
>
> In practice, the capabilities of actual Scheme implementations in this area
> are much, much closer to Common Lisp than Python's are. I would have
> thought practice is what counts, but more below.
It all depends on what your goals are. If you care about writing code
that is reliably portable across implementations then what's in the
standard matters. If you don't then it doesn't.
> I realize that you dislike the lack of a guarantee in the standard
No, you do not realize this, you imagine it (this seems to be a common
afliction on c.l.l. these days). I have expressed no opinion about it one
way or the other. I have merely pointed it out.
> > What implementations provide says nothing about what the standard
> > requires. The Scheme standard defines a pretty impoverished language, so
> > it is no surprise that most implementations offer extensions of one sort
> > or another.
>
> But that's the whole *point*!!! The Scheme spec is not supposed to be like
> the Common Lisp spec. It was deliberately designed to allow a variety of
> implementations which share a common set of core semantics. This feature in
> particular wasn't left out of the spec - rather, it was left deliberately
> open.
And how is that different from what I've said?
> The problem is, there is no separate standard for "Core Common Lisp", and
> there is no standard for "Big-Ass Scheme", and so these discussions
> continually compare apples to apple seeds. The objection you're making
> about "Scheme"
I am not making any objection, I am merely pointing out a fact (one which
you have just said you agree with).
It is fascinating how much passion can be evoked at the mere statement of
objective facts.
E.
··························@jpl.nasa.gov (Erann Gat) writes:
> In article <·····················@newsread2.news.atl.earthlink.net>,
> "Anton van Straaten" <·····@appsolutions.com> wrote:
>>
>> In practice, the capabilities of actual Scheme implementations in this area
>> are much, much closer to Common Lisp than Python's are. I would have
>> thought practice is what counts, but more below.
>
> It all depends on what your goals are. If you care about writing code
> that is reliably portable across implementations then what's in the
> standard matters. If you don't then it doesn't.
It even depends on fine distinctions. There are *many* Scheme
implementations that claim adherence to the absolute minimum standard
that are little more than toys. If you want to be reliably portable
to *each and every one* of them, then you need to be very strict about
following R5RS.
On the other hand, there are only a handful of `major
implementations', and there is a much broader set of common features
that are `de facto' standard if not `de jure' standards.
The same situation exists to some extent in Common Lisp: there is no
standard network package, no standard multithreading package, no
standard FFI, no standard `makefile', etc. But all the `major
implementations' have some mechanism for most of these features, and
in some cases they are very similar.
> I am not making any objection, I am merely pointing out a fact (one which
> you have just said you agree with).
>
> It is fascinating how much passion can be evoked at the mere statement of
> objective facts.
Objective facts get people into trouble all the time: it is a fact
that in the United States that skin color is a strong predictor of
certain job skills, but try bringing that one up in casual conversation.
~jrm
----
BTW: I mean `predictor' in a statistically correlated sense. I cannot
image that there is a physical causality involved.
In article <············@ccs.neu.edu>, Joe Marshall <···@ccs.neu.edu> wrote:
> On the other hand, there are only a handful of `major
> implementations', and there is a much broader set of common features
> that are `de facto' standard if not `de jure' standards.
That's today. What about tomorrow?
> The same situation exists to some extent in Common Lisp
That's certainly true, which is one of the reasons I think CL would
benefit from some updating.
> > It is fascinating how much passion can be evoked at the mere statement of
> > objective facts.
>
> Objective facts get people into trouble all the time
That's true too. I find it fascinating nonetheless.
> it is a fact that in the United States that skin color
> is a strong predictor of certain job skills
An excellent example. This one is so touchy that you felt compelled to add:
> BTW: I mean `predictor' in a statistically correlated sense. I cannot
> image that there is a physical causality involved.
Actually, I think it's very likely that there is physical causality involved.
(Stop and think about your reaction to that statement for a moment before
you go on to the next one.)
For example, someone who is skilled at work that is performed out of doors
(a construction worker, for example) is more likely to have dark skin than
someone who is skilled at work that is performed indoors (e.g. a factory
worker) because the former tend to spend more time in the sun.
E.
P.S.:
(let ()
(declare (tangent))
"I also believe that there is another causal chain at work which is the
elephant in the living room that no one wants to talk about. It goes
something like this: someone with dark skin in the U.S. is much more
likely to experience bigotry and prejudice than someone with light skin.
Experiencing bigotry and prejudice is an obstacle to achievement. Thus,
people with dark skin tend to achieve less relative to their potential not
through any fault of their own but because they have an additional
obstacle to overcome that people with light skin do not have. Then on top
of that, people with dark skin have to deal with the *expectation* that
they will achieve less coming from bleeding heart liberals who accept that
chain of reasoning, which then presents an additional obstacle to
achievement, which then makes the expectation of lower achievement become
a self-fulfilling prophecy in a truly vicious cycle. Fortunately, many
people with dark skin are attaining high achievement despite all the crap
that they have to deal with, so maybe we'll be able to get past all this
some day.
I also believe that there is a similar (though nowhere near as pernicious)
phenomenon among people who like to program in Lisp.")
··························@jpl.nasa.gov (Erann Gat) writes:
> In article <············@ccs.neu.edu>, Joe Marshall <···@ccs.neu.edu> wrote:
>
>> it is a fact that in the United States that skin color
>> is a strong predictor of certain job skills
>
> An excellent example. This one is so touchy that you felt compelled to add:
>
>> BTW: I mean `predictor' in a statistically correlated sense. I cannot
>> image that there is a physical causality involved.
>
> Actually, I think it's very likely that there is physical causality involved.
>
> (Stop and think about your reaction to that statement for a moment before
> you go on to the next one.)
My immediate reaction is that I probably didn't state that in the
unambiguous way I meant:
A person's apparent albedo is not a direct factor of job skills.
This can be readily seen by measuring a person's performance before
and after dipping them in a dark paint. (As a control, you should compare
it with dipping someone in a pastel paint.)
> For example, someone who is skilled at work that is performed out of doors
> (a construction worker, for example) is more likely to have dark skin than
> someone who is skilled at work that is performed indoors (e.g. a factory
> worker) because the former tend to spend more time in the sun.
An someone just back from Aruba may be more relaxed and energized....
Erann Gat wrote:
> > > IMO what makes (some) things harder is that Scheme does not require
that
> > > this abstraction be made available as a first-class construct
available
> > > for manipulation by the user. Common Lisp does. (So does Python,
> > > incidentally, and to my knowledge these are the only two languages
that
> > > do. Python's API is much more awkward than Lisp's:
> > > http://www.python.org/doc/current/lib/module-parser.html)
> >
> > In practice, the capabilities of actual Scheme implementations in this
area
> > are much, much closer to Common Lisp than Python's are. I would have
> > thought practice is what counts, but more below.
>
> It all depends on what your goals are. If you care about writing code
> that is reliably portable across implementations then what's in the
> standard matters. If you don't then it doesn't.
I'm saying that because of the nature of the Scheme standard, reliable
portability is dependent on other things in addition to what's in the
standard. Syntax-case is an example: not mentioned in the standard at all,
but quite reliably portable due to most implementations of it having derived
from the same source, even the same source code. There can be variations in
some details, but not more than the kinds of minor differences that exist
between different versions of other language implementations, including
between different CLs.
I've "ported" programs between Scheme implementations, and the sorts of
issues we're talking about here do not typically require much attention at
all. For all practical purposes, these things are portable. Focusing on
the standard and claiming that portability is a problem because the standard
doesn't mention some of these heavier-weight features, IMO, arises from
trying to treat the Scheme standard as though it were the CL standard -
treating them as having comparable purposes because they are both referred
to as "standards".
> > I realize that you dislike the lack of a guarantee in the standard
>
> No, you do not realize this, you imagine it (this seems to be a common
> afliction on c.l.l. these days). I have expressed no opinion about it one
> way or the other. I have merely pointed it out.
Part of what I'm disagreeing with is your interpretation of the respective
roles of the standards, which involves either an opinion or an assumption
which I don't agree with; but there's also the language in which you've
pointed some of these things out, which seem to go beyond a neutral pointing
out of facts. See below.
> > > What implementations provide says nothing about what the standard
> > > requires. The Scheme standard defines a pretty impoverished language,
so
> > > it is no surprise that most implementations offer extensions of one
sort
> > > or another.
> >
> > But that's the whole *point*!!! The Scheme spec is not supposed to be
like
> > the Common Lisp spec. It was deliberately designed to allow a variety
of
> > implementations which share a common set of core semantics. This
feature in
> > particular wasn't left out of the spec - rather, it was left
deliberately
> > open.
>
> And how is that different from what I've said?
Choice of words. "Impoverish[ed]: to make poor; to deprive of strength,
richness, or fertility by depleting or draining of something essential"
(from m-w.com). Talking about the Scheme standard being "impoverished"
doesn't make sense in the context of a specification for a core language.
It only seems impoverished when compared to something that's not a
specification for a common set of core semantics, as though the intent of
the standard were not that real implementations would extend significantly
beyond the standard.
Such extensions imply divergence in some areas - module systems being a case
in point - but in other areas, standards exist either formally as SRFIs, or
else as de facto standards, such as those relating to macros, which is
directly relevant to this discussion.
Re word choice, I was previously asked to avoid the word "proper" here in
the context of tail recursion. In the current context, an antonym for
impoverished might be "bloated", which I suspect might provoke a response
here if used to describe the CL standard. But I wouldn't say that (other
than in quotes) because I recognize that the CL standard has different
goals, and ones which I support in the appropriate context. In any case, if
the CL standard is bloated, then some of my favorite Schemes would also have
to be called bloated.
> > The problem is, there is no separate standard for "Core Common Lisp",
and
> > there is no standard for "Big-Ass Scheme", and so these discussions
> > continually compare apples to apple seeds. The objection you're making
> > about "Scheme"
>
> I am not making any objection, I am merely pointing out a fact (one which
> you have just said you agree with).
>
> It is fascinating how much passion can be evoked at the mere statement of
> objective facts.
The fact I agreed with was that the Scheme standard defines semantics *not*
on strings, as you originally asserted, but on what you described as "some
abstract thing that is not [necessarily] accessible to the user". This was
one of the points I was originally trying to make, so I'm glad we have some
agreement on it. Perhaps it repeats some of what transpired in the earlier
thread, but of course the issue was raised anew in the current thread by the
original poster.
But you have gone on to describe, as I've understood you, practical
consequences of this agreed-on difference, such as the portability of
certain kinds of code, which I don't agree with. These assumed consequences
seem to be based on opinions related to the respective roles of the
published standards, while at the same time ignoring practical realities
such as de facto standards. The result doesn't seem to be to be "mere
statement of objective facts", which is why I've been responding.
Actually, I think *I'm* the one who's merely been stating objective facts.
;)
Anton
In article <·····················@newsread1.news.atl.earthlink.net>,
"Anton van Straaten" <·····@appsolutions.com> wrote:
> Erann Gat wrote:
> > > > IMO what makes (some) things harder is that Scheme does not require
> that
> > > > this abstraction be made available as a first-class construct
> available
> > > > for manipulation by the user. Common Lisp does. (So does Python,
> > > > incidentally, and to my knowledge these are the only two languages
> that
> > > > do. Python's API is much more awkward than Lisp's:
> > > > http://www.python.org/doc/current/lib/module-parser.html)
> > >
> > > In practice, the capabilities of actual Scheme implementations in this
> area
> > > are much, much closer to Common Lisp than Python's are. I would have
> > > thought practice is what counts, but more below.
> >
> > It all depends on what your goals are. If you care about writing code
> > that is reliably portable across implementations then what's in the
> > standard matters. If you don't then it doesn't.
>
> I'm saying that because of the nature of the Scheme standard, reliable
> portability is dependent on other things in addition to what's in the
> standard.
Yes. We seem to be in violent agreement on this point.
> > > I realize that you dislike the lack of a guarantee in the standard
> >
> > No, you do not realize this, you imagine it (this seems to be a common
> > afliction on c.l.l. these days). I have expressed no opinion about it one
> > way or the other. I have merely pointed it out.
>
> Part of what I'm disagreeing with is your interpretation of the respective
> roles of the standards, which involves either an opinion or an assumption
> which I don't agree with; but there's also the language in which you've
> pointed some of these things out, which seem to go beyond a neutral pointing
> out of facts. See below.
You are mixing apples and oranges. I have expressed an (implicit) opinion
about the Scheme standard as a whole by calling it "impoverished", a
characterization which is shared by many people and which I stand by. I
have expressed no opinion about the objective fact [1] that Scheme's
semantics are defined on strings.
E.
[1] R5RS section 7.1.
Erann Gat wrote:
> I have expressed no opinion about the objective fact [1] that
> Scheme's semantics are defined on strings.
...
> [1] R5RS section 7.1.
In the sense of R5RS section 7.1, Common Lisp's semantics are defined on
strings in the exact same sense as Scheme's - e.g. both languages have the
ability to READ program code from sources such as a text file. Section 7.1
deals with the syntax of these external representations.
If your claim that Scheme's semantics are defined on strings refers to the
above point, then there is no difference between it and Common Lisp in that
respect, and the entire basis for your position disappears.
Objective facts require consistent denotations...
Anton
In article <·················@newsread1.news.atl.earthlink.net>, "Anton
van Straaten" <·····@appsolutions.com> wrote:
> Erann Gat wrote:
> > I have expressed no opinion about the objective fact [1] that
> > Scheme's semantics are defined on strings.
> ...
> > [1] R5RS section 7.1.
>
> In the sense of R5RS section 7.1, Common Lisp's semantics are defined on
> strings in the exact same sense as Scheme's
No. The Common Lisp spec specifically introduces the intermediate concept
of a *form*. The Scheme spec does not.
> - e.g. both languages have the
> ability to READ program code from sources such as a text file. Section 7.1
> deals with the syntax of these external representations.
This is just a reflection of the fact that the syntax for Scheme code is a
subset of the syntax for Scheme data.
> If your claim that Scheme's semantics are defined on strings refers to the
> above point, then there is no difference between it and Common Lisp in that
> respect, and the entire basis for your position disappears.
No. As I said, Common Lisp semantics are defined on forms. The fact that
CL also defines a mapping from strings to forms does not change the fact
that CL semantics are defined on forms, not strings. Forms do not have to
be constructed by passing a string through READ.
E.
Erann Gat wrote:
> In article <·················@newsread1.news.atl.earthlink.net>, "Anton
> van Straaten" <·····@appsolutions.com> wrote:
>
> > Erann Gat wrote:
> > > I have expressed no opinion about the objective fact [1] that
> > > Scheme's semantics are defined on strings.
> > ...
> > > [1] R5RS section 7.1.
> >
> > In the sense of R5RS section 7.1, Common Lisp's semantics are defined on
> > strings in the exact same sense as Scheme's
>
> No. The Common Lisp spec specifically introduces the intermediate concept
> of a *form*. The Scheme spec does not.
As I've previously pointed out, Scheme's semantics are defined on
"expressions, definitions, and syntax definitions". The strings you're
referring to are presumably the "sequence of characters" from which
syntactic tokens are formed, but that's at the lexical level, below the
level at which the semantics are defined, so it's still not true that
"Scheme's semantics are defined on strings", any more than CL's are, as I
said.
Lisp "forms" are data objects, equivalent to programs or expressions
"expressed as data" described in R5RS. However, as we've discussed, R5RS
doesn't *require* that code be expressed as data objects, other than as e.g.
input to EVAL. The fact that code is not required to be expressed as data
objects doesn't automatically mean Scheme's semantics are defined on
strings. In fact, it doesn't affect the definition of the semantics, which
are still on expressions and definitions.
The only thing affected, afaict, is whether one can rely on the availability
of code as data objects at runtime. For various kinds of compiled and
embedded applications, this may not be necessary, and the Scheme spec
doesn't require it.
> No. As I said, Common Lisp semantics are defined on forms. The fact that
> CL also defines a mapping from strings to forms does not change the fact
> that CL semantics are defined on forms, not strings.
Saying "defined on forms, not strings" mixes two entirely different levels
of operation. It would be more correct to say something like "defined on
forms [i.e. data objects], not abstract expressions and definitions".
> Forms do not have to be constructed by passing a string through READ.
Scheme is also agnostic on this issue: code doesn't have to be passed
through READ - especially given that it doesn't have to ever exist as a data
object - and nor does it have to be evaluated with EVAL. However, code
expressed as data objects *can* nevertheless be evaluated with EVAL, whether
or not it has been created by passing a string through READ. I'm not sure
what your point here is.
Anton
In article <···················@newsread1.news.atl.earthlink.net>, "Anton
van Straaten" <·····@appsolutions.com> wrote:
> I'm not sure what your point here is.
My point is that Lisp defines an API for program objects that can be
operated on by the language itself (lists) and Scheme doesn't.
E.
Erann Gat wrote:
>
> In article <···················@newsread1.news.atl.earthlink.net>, "Anton
> van Straaten" <·····@appsolutions.com> wrote:
>
> > I'm not sure what your point here is.
>
> My point is that Lisp defines an API for program objects that can be
> operated on by the language itself (lists) and Scheme doesn't.
I do not understand what you mean in that case.
I routinely build lists using cons and car and cdr, and
then pass them to "eval" to get functions.
Eval does not destroy these lists: I can keep them around
for introspection purposes if I like.
Scheme macros work on list structures at compile time, and
frequently use quote, unquote, quasiquote, and unquote-splicing
to build ferociously complex list structures, invoking the
interpreter to handle language expressions as necessary - which
are then compiled into scheme code in place.
This seems like an API to me. What is missing?
Bear
In article <·················@sonic.net>, Ray Dillinger <····@sonic.net> wrote:
> Erann Gat wrote:
> >
> > In article <···················@newsread1.news.atl.earthlink.net>, "Anton
> > van Straaten" <·····@appsolutions.com> wrote:
> >
> > > I'm not sure what your point here is.
> >
> > My point is that Lisp defines an API for program objects that can be
> > operated on by the language itself (lists) and Scheme doesn't.
>
> I do not understand what you mean in that case.
>
> I routinely build lists using cons and car and cdr, and
> then pass them to "eval" to get functions.
>
> Eval does not destroy these lists: I can keep them around
> for introspection purposes if I like.
>
> Scheme macros work on list structures at compile time, and
> frequently use quote, unquote, quasiquote, and unquote-splicing
> to build ferociously complex list structures, invoking the
> interpreter to handle language expressions as necessary - which
> are then compiled into scheme code in place.
>
> This seems like an API to me. What is missing?
Standardization. R5RS does not include define-macro. This is an
intentional omission because you can't write reliable macros in a Lisp1
using define-macro, which is precisely the reason that define-syntax was
invented.
Also, EVAL was an afterthought, being included only in the latest revision
of the standard, and it specified only that it evaluates Scheme code
represented "as data". It does not specify the format of this data
(though I concede that the use of lists is ubiquitous) and thus there are
many ambiguities about what is and is not allowed. For example, what is
the result of the following?
(let ( (x "foo") ) (eval (list 'eq? x x)))
One could make plausible arguments for #T, #F, and generating an error
because the list is not legal Scheme code because it has no textual
representation.
E.
Erann Gat wrote:
> Also, EVAL was an afterthought, being included only in the latest revision
> of the standard, and it specified only that it evaluates Scheme code
> represented "as data". It does not specify the format of this data
> (though I concede that the use of lists is ubiquitous) and thus there are
> many ambiguities about what is and is not allowed. For example, what is
> the result of the following?
>
> (let ( (x "foo") ) (eval (list 'eq? x x)))
>
> One could make plausible arguments for #T, #F, and generating an error
> because the list is not legal Scheme code because it has no textual
> representation.
Did you mean to write:
(let ( (x "foo") ) (eval (list eq? x x)))
i.e. passing the eq? procedure rather than a symbol. Otherwise, the
external representation of the above list is simply (eq? "foo" "foo"), the
result of which is unspecified in R5RS.
Anton
In article <····················@newsread1.news.atl.earthlink.net>, "Anton
van Straaten" <·····@appsolutions.com> wrote:
> Erann Gat wrote:
> > Also, EVAL was an afterthought, being included only in the latest revision
> > of the standard, and it specified only that it evaluates Scheme code
> > represented "as data". It does not specify the format of this data
> > (though I concede that the use of lists is ubiquitous) and thus there are
> > many ambiguities about what is and is not allowed. For example, what is
> > the result of the following?
> >
> > (let ( (x "foo") ) (eval (list 'eq? x x)))
> >
> > One could make plausible arguments for #T, #F, and generating an error
> > because the list is not legal Scheme code because it has no textual
> > representation.
>
> Did you mean to write:
>
> (let ( (x "foo") ) (eval (list eq? x x)))
No.
> i.e. passing the eq? procedure rather than a symbol. Otherwise, the
> external representation of the above list is simply (eq? "foo" "foo"), the
> result of which is unspecified in R5RS.
No, it isn't. The list constructed in my example has no external
representation in Scheme. In Common Lisp you could write it as:
(eq? #1="foo" #1#)
But that's not the same as (eq? "foo" "foo").
E.
Erann Gat wrote:
> In article <····················@newsread1.news.atl.earthlink.net>, "Anton
> van Straaten" <·····@appsolutions.com> wrote:
>
> > Erann Gat wrote:
> > > Also, EVAL was an afterthought, being included only in the latest
revision
> > > of the standard, and it specified only that it evaluates Scheme code
> > > represented "as data". It does not specify the format of this data
> > > (though I concede that the use of lists is ubiquitous) and thus there
are
> > > many ambiguities about what is and is not allowed. For example, what
is
> > > the result of the following?
> > >
> > > (let ( (x "foo") ) (eval (list 'eq? x x)))
> > >
> > > One could make plausible arguments for #T, #F, and generating an error
> > > because the list is not legal Scheme code because it has no textual
> > > representation.
> >
> > Did you mean to write:
> >
> > (let ( (x "foo") ) (eval (list eq? x x)))
>
> No.
>
> > i.e. passing the eq? procedure rather than a symbol. Otherwise, the
> > external representation of the above list is simply (eq? "foo" "foo"),
the
> > result of which is unspecified in R5RS.
>
> No, it isn't. The list constructed in my example has no external
> representation in Scheme. In Common Lisp you could write it as:
>
> (eq? #1="foo" #1#)
>
> But that's not the same as (eq? "foo" "foo").
Ah! Thanks. But all this means is that the data defined to be accepted by
EVAL, or that produces defined results, is a subset of valid Scheme data -
but we already know that, from Sec. 1.2., "the grammar of Scheme generates a
sublanguage of the language used for data", and the various discussion of
external representations.
Now that I understand what you were getting at, I can address a more
important point:
> [R5RS] does not specify the format of this data
> (though I concede that the use of lists is ubiquitous)
R5RS certainly specifies a minimum format of this data. To summarize, any
value which was converted from an external representation via READ, or any
value which *could* have been produced this way, qualifies as a program
expressed as data. Further, this representation is very much like a Common
Lisp "form" - it can be a list, but it can also be an individual value like
a string, a number, etc. There's no doubt that lists are required to be
accepted by EVAL in Scheme.
As such, R5RS Scheme *does* in fact define an API for dealing with program
code, contrary to your earlier claim, and I'll illustrate the consequences
of this in another post.
Anton
In article <····················@newsread1.news.atl.earthlink.net>, "Anton
van Straaten" <·····@appsolutions.com> wrote:
> R5RS certainly specifies a minimum format of this data.
Really? Where?
> To summarize, any
> value which was converted from an external representation via READ, or any
> value which *could* have been produced this way, qualifies as a program
> expressed as data.
That's what you say. That's not what R5RS says.
> Further, this representation is very much like a Common
> Lisp "form" - it can be a list, but it can also be an individual value like
> a string, a number, etc. There's no doubt that lists are required to be
> accepted by EVAL in Scheme.
That may be so, but if it is it's because of common practice in the Scheme
community, not because R5RS actually says so.
> As such, R5RS Scheme *does* in fact define an API
No, it doesn't. (And if you want to dispute that please do so by citing
the section(s) of R5RS where this alleged definition can be found.)
E.
··························@jpl.nasa.gov (Erann Gat) writes:
> In article <····················@newsread1.news.atl.earthlink.net>, "Anton
> van Straaten" <·····@appsolutions.com> wrote:
>
>> Further, this representation is very much like a Common
>> Lisp "form" - it can be a list, but it can also be an individual value like
>> a string, a number, etc. There's no doubt that lists are required to be
>> accepted by EVAL in Scheme.
>
> That may be so, but if it is it's because of common practice in the Scheme
> community, not because R5RS actually says so.
``the grammar of Scheme generates a sublanguage of the language used
for data.'' Therefore, all programs have a data equivalent.
``the eval procedure evaluates a Scheme program expressed as data.''
Section 7.1.3 gives the subgrammar for scheme programs expressed as
data. That subgrammar includes lists and symbols (which map into
function calls, macro uses, binding expressions, variables, etc.)
(eval expression environment-specifier) procedure
Evaluates expression in the specified environment and returns
its value. Expression must be a valid Scheme expression
represented as data, and environment-specifier must
be a value returned by one of the three procedures described
below.
In article <············@ccs.neu.edu>, Joe Marshall <···@ccs.neu.edu> wrote:
> ··························@jpl.nasa.gov (Erann Gat) writes:
>
> > In article <····················@newsread1.news.atl.earthlink.net>, "Anton
> > van Straaten" <·····@appsolutions.com> wrote:
> >
> >> Further, this representation is very much like a Common
> >> Lisp "form" - it can be a list, but it can also be an individual value like
> >> a string, a number, etc. There's no doubt that lists are required to be
> >> accepted by EVAL in Scheme.
> >
> > That may be so, but if it is it's because of common practice in the Scheme
> > community, not because R5RS actually says so.
>
> ``the grammar of Scheme generates a sublanguage of the language used
> for data.'' Therefore, all programs have a data equivalent.
Actually, all programs have at least two data equivalents.
The program:
(define (foo) 1)
has a data equivalent which is a list of three elements, and a second data
equivalent which is a string with sixteen characters.
> ``the eval procedure evaluates a Scheme program expressed as data.''
>
> Section 7.1.3 gives the subgrammar for scheme programs expressed as
> data. That subgrammar includes lists and symbols (which map into
> function calls, macro uses, binding expressions, variables, etc.)
Actually, that sub-grammar includes strings which produce lists and
symbols when processed by the READ function.
(Note that the terminals of the grammar are all characters. Lists,
symbols, etc. are non-terminals.)
E.
··························@jpl.nasa.gov (Erann Gat) writes:
> In article <············@ccs.neu.edu>, Joe Marshall <···@ccs.neu.edu> wrote:
>
>> ··························@jpl.nasa.gov (Erann Gat) writes:
>>
>> > In article <····················@newsread1.news.atl.earthlink.net>, "Anton
>> > van Straaten" <·····@appsolutions.com> wrote:
>> >
>> >> Further, this representation is very much like a Common
>> >> Lisp "form" - it can be a list, but it can also be an individual value like
>> >> a string, a number, etc. There's no doubt that lists are required to be
>> >> accepted by EVAL in Scheme.
>> >
>> > That may be so, but if it is it's because of common practice in the Scheme
>> > community, not because R5RS actually says so.
>>
>> ``the grammar of Scheme generates a sublanguage of the language used
>> for data.'' Therefore, all programs have a data equivalent.
>
> Actually, all programs have at least two data equivalents.
>
> The program:
>
> (define (foo) 1)
>
> has a data equivalent which is a list of three elements, and a second data
> equivalent which is a string with sixteen characters.
And a third which is a string with 22 characters...
and a fourth which is a string with 30 characters....
And you could Godelize the strings into integers...
But all of these *except* the equivalent as a list of three elements
require the use of the lexical grammar defined in Section 7.1.1
>> ``the eval procedure evaluates a Scheme program expressed as data.''
>>
>> Section 7.1.3 gives the subgrammar for scheme programs expressed as
>> data. That subgrammar includes lists and symbols (which map into
>> function calls, macro uses, binding expressions, variables, etc.)
>
> Actually, that sub-grammar includes strings which produce lists and
> symbols when processed by the READ function.
>
> (Note that the terminals of the grammar are all characters. Lists,
> symbols, etc. are non-terminals.)
The terminals of the various grammars differ! It is an unfortunate
problem that you cannot put a list on a page, you can only put
splotches of ink. Therefore, to indicate that something is a list,
the report uses the printed representation of such. This shouldn't
be construed as meaning that something surrounded in parenthesis
is to be taken as a sequence of characters beginning with the ascii
character 48 (except, of course in the context where the printed
represention is being defined). Attempting to treat the terminals
in section 7.1.3 as characters quickly leads to a contradiction
because <string> -> <self-evaluating>
Erann Gat wrote:
> In article <····················@newsread1.news.atl.earthlink.net>, "Anton
> van Straaten" <·····@appsolutions.com> wrote:
>
> > R5RS certainly specifies a minimum format of this data.
>
> Really? Where?
>
> > To summarize, any
> > value which was converted from an external representation via READ, or
any
> > value which *could* have been produced this way, qualifies as a program
> > expressed as data.
>
> That's what you say. That's not what R5RS says.
>
> > Further, this representation is very much like a Common
> > Lisp "form" - it can be a list, but it can also be an individual value
like
> > a string, a number, etc. There's no doubt that lists are required to be
> > accepted by EVAL in Scheme.
>
> That may be so, but if it is it's because of common practice in the Scheme
> community, not because R5RS actually says so.
>
> > As such, R5RS Scheme *does* in fact define an API
>
> No, it doesn't. (And if you want to dispute that please do so by citing
> the section(s) of R5RS where this alleged definition can be found.)
The most direct answer to this question would be to cite the examples given
for EVAL in section 6.5, which show two examples of quoted lists being
provided to EVAL for evaluation. I'm not really sure what your
interpretation is: are you saying that although the examples show lists
being accepted, that R5RS does not require that lists be accepted, and that
the examples merely show what one possible implementation of Scheme might
do?
To put this in a concrete context, are you saying that the macro I posted
earlier is somehow not standard R5RS, and an R5RS-compliant Scheme could
legally fail to evaluate it correctly?
I'll write up a more detailed response showing how R5RS defines that EVAL
accepts lists, but if you could clarify your take on the above in the
meantime, that might help me address the point better.
Anton
In article <····················@newsread1.news.atl.earthlink.net>, "Anton
van Straaten" <·····@appsolutions.com> wrote:
> Erann Gat wrote:
> > In article <····················@newsread1.news.atl.earthlink.net>, "Anton
> > van Straaten" <·····@appsolutions.com> wrote:
> >
> > > R5RS certainly specifies a minimum format of this data.
> >
> > Really? Where?
> >
> > > To summarize, any
> > > value which was converted from an external representation via READ, or
> any
> > > value which *could* have been produced this way, qualifies as a program
> > > expressed as data.
> >
> > That's what you say. That's not what R5RS says.
> >
> > > Further, this representation is very much like a Common
> > > Lisp "form" - it can be a list, but it can also be an individual value
> like
> > > a string, a number, etc. There's no doubt that lists are required to be
> > > accepted by EVAL in Scheme.
> >
> > That may be so, but if it is it's because of common practice in the Scheme
> > community, not because R5RS actually says so.
> >
> > > As such, R5RS Scheme *does* in fact define an API
> >
> > No, it doesn't. (And if you want to dispute that please do so by citing
> > the section(s) of R5RS where this alleged definition can be found.)
>
> The most direct answer to this question would be to cite the examples given
> for EVAL in section 6.5, which show two examples of quoted lists being
> provided to EVAL for evaluation. I'm not really sure what your
> interpretation is: are you saying that although the examples show lists
> being accepted, that R5RS does not require that lists be accepted, and that
> the examples merely show what one possible implementation of Scheme might
> do?
Exactly.
> To put this in a concrete context, are you saying that the macro I posted
> earlier is somehow not standard R5RS, and an R5RS-compliant Scheme could
> legally fail to evaluate it correctly?
No. I'm saying that in the context of your question the word "correctly"
is not well defined.
In particular, the behavior of your code (which is to say, the behavior of
EVAL) in the face of lists with no printed representation is ambiguous.
E.
Erann Gat wrote:
> In article <····················@newsread1.news.atl.earthlink.net>, "Anton
> van Straaten" <·····@appsolutions.com> wrote:
>
> > Erann Gat wrote:
> > > In article <····················@newsread1.news.atl.earthlink.net>,
"Anton
> > > van Straaten" <·····@appsolutions.com> wrote:
> > >
> > > > R5RS certainly specifies a minimum format of this data.
> > >
> > > Really? Where?
> > >
> > > > To summarize, any
> > > > value which was converted from an external representation via READ,
or
> > any
> > > > value which *could* have been produced this way, qualifies as a
program
> > > > expressed as data.
> > >
> > > That's what you say. That's not what R5RS says.
> > >
> > > > Further, this representation is very much like a Common
> > > > Lisp "form" - it can be a list, but it can also be an individual
value
> > like
> > > > a string, a number, etc. There's no doubt that lists are required
to be
> > > > accepted by EVAL in Scheme.
> > >
> > > That may be so, but if it is it's because of common practice in the
Scheme
> > > community, not because R5RS actually says so.
> > >
> > > > As such, R5RS Scheme *does* in fact define an API
> > >
> > > No, it doesn't. (And if you want to dispute that please do so by
citing
> > > the section(s) of R5RS where this alleged definition can be found.)
> >
> > The most direct answer to this question would be to cite the examples
given
> > for EVAL in section 6.5, which show two examples of quoted lists being
> > provided to EVAL for evaluation. I'm not really sure what your
> > interpretation is: are you saying that although the examples show lists
> > being accepted, that R5RS does not require that lists be accepted, and
that
> > the examples merely show what one possible implementation of Scheme
might
> > do?
>
> Exactly.
Other posts by Joe Marshall and me address this. R5RS makes it quite clear
that EVAL accepts lists as a representation of Scheme expressions, and the
examples it gives illustrate that defined behavior. If you interpret the
examples as demonstrating merely one possible implementation, I believe
you've misinterpreted R5RS.
> > To put this in a concrete context, are you saying that the macro I
posted
> > earlier is somehow not standard R5RS, and an R5RS-compliant Scheme
could
> > legally fail to evaluate it correctly?
>
> No. I'm saying that in the context of your question the word "correctly"
> is not well defined.
It's perfectly well-defined for "valid Scheme expressions represented as
data", as detailed in another post. That is a separate issue from this:
> In particular, the behavior of your code (which is to say, the behavior of
> EVAL) in the face of lists with no printed representation is ambiguous.
I agree, the behavior w.r.t. lists with no external representation is
unspecified. I do now understand the purpose of your earlier example of
(eval (list 'eq? x x)).
However, the behavior regarding lists that do have an external
representation *is* specified: EVAL can evaluate them if their external
representation is a valid Scheme expression - or more conservatively, if
they could have been produced by READ. So when it comes to the main point
under discussion, it turns out that standard Scheme does have an API for
operating on programs represented as data objects, in which non-atomic
expressions must specifically be represented as lists, for the purposes of
evaluation by EVAL. So even if "the semantics of Scheme are not defined on
lists", the semantics of Scheme programs represented as lists are, in fact,
defined by R5RS. It's just that the definition doesn't cover certain edge
cases, such as lists with shared structure.
Anton
In article <··················@newsread1.news.atl.earthlink.net>, "Anton
van Straaten" <·····@appsolutions.com> wrote:
> I believe you've misinterpreted R5RS.
With all due respect, I do not accept the authority of your opinion on
this matter.
> ... certain edge cases, such as lists with shared structure.
One man's edge case is another man's essential functionality. I'll just
point out that because (as you've conceded) Scheme's EVAL is constrained
to operate on lists that have printed representations, there is an
isomorphism between such lists and strings. It is therefore irrelevant
whether or not EVAL is actually constrained to operate only on strings
because (as you've conceded) it *is* constrained to operate on a data
structure (lists with printed representations under Scheme's grammar) that
is isomorphic to strings (which isomorphism is actually implemented in
Scheme by the READ function).
E.
P.S. Any macro defined with your define-makro macro cannot access any
user-defined functions.
Erann Gat wrote:
> In article <··················@newsread1.news.atl.earthlink.net>, "Anton
> van Straaten" <·····@appsolutions.com> wrote:
>
> > I believe you've misinterpreted R5RS.
>
> With all due respect, I do not accept the authority of your opinion on
> this matter.
>
> > ... certain edge cases, such as lists with shared structure.
>
> One man's edge case is another man's essential functionality.
That may be so, but part of what I've been trying to do here is nail down
exactly what it is you're trying to say, which seems to me to have been
shifting - not necessarily because what you *mean* has been shifting, but
because of the way you've been expressing it.
Neither "semantics defined on lists" vs. strings, nor the idea that Scheme
has no "API for program objects" completely communicates your point(s),
afaict. I think that you *think* that "semantics defined on lists" should
communicate those points, but in fact this could have other consequences
than the semantics you seem to prefer, and it could also be duplicated by
some other specification - quite possibly, some superset of the Scheme
specification.
> I'll just point out that because (as you've conceded) Scheme's EVAL
> is constrained to operate on lists that have printed representations,
> there is an isomorphism between such lists and strings. It is therefore
> irrelevant whether or not EVAL is actually constrained to operate only
> on strings because (as you've conceded) it *is* constrained to operate
> on a data structure (lists with printed representations under Scheme's
> grammar) that is isomorphic to strings (which isomorphism is actually
> implemented in Scheme by the READ function).
I consider it progress in the discussion if we can agree that EVAL is
specified to operate on lists, regardless of whether they're minimally
required to be isomorphic to strings. However, I don't agree that this
isomorphism is a "constraint": rather, it's the minimal required
functionality, which implementations can and do exceed: for example, by
supporting lists with shared structure, or procedures as self-evaluating
objects.
> P.S. Any macro defined with your define-makro macro cannot access any
> user-defined functions.
Yes, because R5RS leaves open the degree to which an implementation provides
access to environments. However, this has no bearing on the point that was
being addressed, which is whether R5RS defines an API for access to program
objects. The discussion has since shifted to discussing the specific nature
of that API.
Anton
In article <····················@newsread1.news.atl.earthlink.net>, "Anton
van Straaten" <·····@appsolutions.com> wrote:
> Erann Gat wrote:
> > In article <··················@newsread1.news.atl.earthlink.net>, "Anton
> > van Straaten" <·····@appsolutions.com> wrote:
> >
> > > I believe you've misinterpreted R5RS.
> >
> > With all due respect, I do not accept the authority of your opinion on
> > this matter.
> >
> > > ... certain edge cases, such as lists with shared structure.
> >
> > One man's edge case is another man's essential functionality.
>
> That may be so, but part of what I've been trying to do here is nail down
> exactly what it is you're trying to say, which seems to me to have been
> shifting - not necessarily because what you *mean* has been shifting, but
> because of the way you've been expressing it.
No, it's because what I'm trying to say isn't a crisp idea. It's not a
mathematical statement, it's a psychological (or sociological) one. It's
about mindset. At one level all programming languages are the same. But
clearly there are differences that matter to people. Those differences
have to do with how well the language resonates with people's though
processes. See my response to Pascal Costanza for more detail.
> Neither "semantics defined on lists" vs. strings, nor the idea that Scheme
> has no "API for program objects" completely communicates your point(s),
> afaict. I think that you *think* that "semantics defined on lists" should
> communicate those points, but in fact this could have other consequences
> than the semantics you seem to prefer, and it could also be duplicated by
> some other specification - quite possibly, some superset of the Scheme
> specification.
Perhaps. But I doubt it, and the burden of proof is on the person making
such a claim.
E.
Anton van Straaten wrote:
> However, the behavior regarding lists that do have an external
> representation *is* specified: EVAL can evaluate them if their external
> representation is a valid Scheme expression - or more conservatively, if
> they could have been produced by READ. So when it comes to the main point
> under discussion, it turns out that standard Scheme does have an API for
> operating on programs represented as data objects, in which non-atomic
> expressions must specifically be represented as lists, for the purposes of
> evaluation by EVAL. So even if "the semantics of Scheme are not defined on
> lists", the semantics of Scheme programs represented as lists are, in fact,
> defined by R5RS. It's just that the definition doesn't cover certain edge
> cases, such as lists with shared structure.
...but these edge cases are at the heart of the whole discussion AFAICT.
They allow you to solve issues of macro hygiene in a straightforward
way, just by relying on object identity for generated symbols. At this
point of the discussion it seems to me that R5RS doesn't provide any
reliable means to deal with macro hygiene within a "simulated" low-level
macro feature.
Or can you implement MAKE-SYMBOL in Scheme such that (make-symbol
"TEST") results in a symbol with the print name TEST and (eq?
(make-symbol "TEST") (make-symbol "TEST")) evaluates to #F at the same time?
Pascal
Pascal Costanza wrote:
> Anton van Straaten wrote:
>
> > However, the behavior regarding lists that do have an external
> > representation *is* specified: EVAL can evaluate them if their external
> > representation is a valid Scheme expression - or more conservatively, if
> > they could have been produced by READ. So when it comes to the main
point
> > under discussion, it turns out that standard Scheme does have an API for
> > operating on programs represented as data objects, in which non-atomic
> > expressions must specifically be represented as lists, for the purposes
of
> > evaluation by EVAL. So even if "the semantics of Scheme are not defined
on
> > lists", the semantics of Scheme programs represented as lists are, in
fact,
> > defined by R5RS. It's just that the definition doesn't cover certain
edge
> > cases, such as lists with shared structure.
>
> ...but these edge cases are at the heart of the whole discussion AFAICT.
> They allow you to solve issues of macro hygiene in a straightforward
> way, just by relying on object identity for generated symbols.
I've been responding to broader claims, which I consider overly broad. If
we narrow it back down to specific issues like the one you mention, I don't
really have any argument with that. In the standard, Scheme chose to go in
a different direction in that area, for some specific reasons.
One of the original examples related to object identity - (eq? (foo)
(foo)) - did not have to do with macros & symbols, and my point there was
that semantics defined on lists are not required for the desired
functionality, nor does that semantic basis guarantee such functionality.
Re macros and symbol identity, this is not a particular issue in terms of
the internal consistency of R5RS, since it provides a hygienic macro system.
More below:
> At this point of the discussion it seems to me that R5RS doesn't provide
> any reliable means to deal with macro hygiene within a "simulated"
low-level
> macro feature.
I don't know whether typical low-level macro implementations do anything
along these lines, and if they do, it quite likely relies on extensions.
I'd have to research it.
However, the portable syntax-case macro system
(http://www.scheme.com/syntax-case/) handles this by using an "identifier"
abstraction which has both a symbolic name - the name the programmer uses
and sees - and a binding name. The latter is chosen to ensure uniqueness
during macro expansion. This is essentially equivalent to having two
symbols with the same name, but different object identities - except that
the uniqueness property of names for values of the symbol type is preserved,
so it's less of a hack. :oP
> Or can you implement MAKE-SYMBOL in Scheme such that (make-symbol
> "TEST") results in a symbol with the print name TEST and (eq?
> (make-symbol "TEST") (make-symbol "TEST")) evaluates to #F at the same
time?
The standard STRING->SYMBOL function is required to produce symbols for
which EQ? will return #T in that situation, so no.
Anton
Anton van Straaten wrote:
> Pascal Costanza wrote:
>>...but these edge cases are at the heart of the whole discussion AFAICT.
>>They allow you to solve issues of macro hygiene in a straightforward
>>way, just by relying on object identity for generated symbols.
>
>
> I've been responding to broader claims, which I consider overly broad. If
> we narrow it back down to specific issues like the one you mention, I don't
> really have any argument with that. In the standard, Scheme chose to go in
> a different direction in that area, for some specific reasons.
OK. So for what reasons?
> One of the original examples related to object identity - (eq? (foo)
> (foo)) - did not have to do with macros & symbols, and my point there was
> that semantics defined on lists are not required for the desired
> functionality, nor does that semantic basis guarantee such functionality.
[The following is just a try at wording things differently. I am not
sure whether this hits the nail on the head. However, I think Erann has
a point, but maybe it's better to rephrase his centreal statement that
Scheme is defined on strings whereas Lisp is defined on lists.]
The difference between Common Lisp and Scheme that Erann seems to have
in mind might be stated like this: Common Lisp is defined on a
potentially confluent data structure (lists) whereas R5RS is defined
only for strictly non-confluent structures ("strings").
The fact that CL is defined on potentially confluent structures gives
(flet ((foo () (quote <something>)) (eq (foo) (foo))) straightforward
semantics, whereas it is much harder to give non-ambiguous semantics for
an equivalent program in Scheme if you want to stick to non-confluency.
(Erann, does this capture the essence of your statement?)
> Re macros and symbol identity, this is not a particular issue in terms of
> the internal consistency of R5RS, since it provides a hygienic macro system.
> More below:
>
>
>>At this point of the discussion it seems to me that R5RS doesn't provide
>>any reliable means to deal with macro hygiene within a "simulated" low-level
>>macro feature.
>
>
> I don't know whether typical low-level macro implementations do anything
> along these lines, and if they do, it quite likely relies on extensions.
> I'd have to research it.
>
> However, the portable syntax-case macro system
> (http://www.scheme.com/syntax-case/) handles this by using an "identifier"
> abstraction which has both a symbolic name - the name the programmer uses
> and sees - and a binding name. The latter is chosen to ensure uniqueness
> during macro expansion. This is essentially equivalent to having two
> symbols with the same name, but different object identities - except that
> the uniqueness property of names for values of the symbol type is preserved,
> so it's less of a hack. :oP
Well, I think the solution you describe is the hack. What one needs is
object identity for symbols, so Common Lisp gives you the
straightforward solution. ;-P
Seriously, you probably know that it is very hard to ensure unique
strings...
>>Or can you implement MAKE-SYMBOL in Scheme such that (make-symbol
>>"TEST") results in a symbol with the print name TEST and (eq?
>>(make-symbol "TEST") (make-symbol "TEST")) evaluates to #F at the same time?
>
> The standard STRING->SYMBOL function is required to produce symbols for
> which EQ? will return #T in that situation, so no.
Taking another step back, the whole discussion has it roots in a thread
about why some people think that Scheme is not a Lisp. If I needed to
mention a single reason why I would not regard Scheme (or at least R5RS)
to be a Lisp, it would indeed be the fact that I cannot implement
MAKE-SYMBOL in Scheme.
Pascal
In article <················@web.de>, Pascal Costanza <········@web.de> wrote:
> > One of the original examples related to object identity - (eq? (foo)
> > (foo)) - did not have to do with macros & symbols, and my point there was
> > that semantics defined on lists are not required for the desired
> > functionality, nor does that semantic basis guarantee such functionality.
>
> [The following is just a try at wording things differently. I am not
> sure whether this hits the nail on the head. However, I think Erann has
> a point, but maybe it's better to rephrase his centreal statement that
> Scheme is defined on strings whereas Lisp is defined on lists.]
>
> The difference between Common Lisp and Scheme that Erann seems to have
> in mind might be stated like this: Common Lisp is defined on a
> potentially confluent data structure (lists) whereas R5RS is defined
> only for strictly non-confluent structures ("strings").
>
> The fact that CL is defined on potentially confluent structures gives
> (flet ((foo () (quote <something>)) (eq (foo) (foo))) straightforward
> semantics, whereas it is much harder to give non-ambiguous semantics for
> an equivalent program in Scheme if you want to stick to non-confluency.
>
> (Erann, does this capture the essence of your statement?)
Mostly. I think there's more to it than that though. It's a difference
in mindset that I think transcends the technical details. The point I've
been trying to make is not that one mindset is better than the other, but
merely that the difference exists, and it's bigger than most people think
(certainly bigger than the impression one gets from a superficial
inspection of the two languages).
For example, we've spent a lot of time talking about the interaction of EQ
and QUOTE. But EQness/confluence only matters if you're mutating things,
so if you happen to be a fan of functional programming this entire issue
is moot. So we argue about (eq (foo) (foo)), but the sub-text of this
argument is about whether this issue matters at all. But that of course
can't be resolved because whether it matters is subjective and a matter of
taste, so instead we look for the keys where the light is and argue about
formal semantics and whatnot. But what we're really disagreeing about is
aesthetics.
Likewise for the whole "Scheme semantics are defined on strings"
argument. What this is really about is that Scheme is defined in terms of
a BNF grammar and denotational semantics, while Common Lisp is defined in
terms of a collection of algorithms (an operational semantics). This
leads to arguments of the form,
"I can do compile-time computation using Common Lisp macros."
"Well, yeah, but why would you want to?"
This argument is exactly of the same form as, "I can know what (eq (foo)
(foo)) returns." "Well, yeah, but why do you care?"
There are examples that start from the Scheme side too. "I have a
mathematical description of the semantics of my language." "Well, yeah,
but why would you want that?"
It's hard to describe this difference in a pithy way. The claim that
"Scheme semantics are defined on strings" was an attempt to distill the
essence of the aesthetic difference between Scheme and CL into a short,
punchy sentence that would highlight that difference over the
all-too-apparent similarities. (Kent Pitman has made similar attempts in
terms of concepts like "political parties" and "respect for object
identity".) I could have made the claim more technically precise by
saying something like, "Scheme's semantics are defined on an abstract data
type that is isomorphic to lists that have a printed representation under
the BNF grammar that defines Scheme's syntax." That might have been more
"correct", but it would have completely missed the point, which is that
whatever Scheme's semantics are defined on it's more like a string than it
is like a list (or perhaps it's better to say that it is just as much like
a string as it is like a list, since it's isomorphic to both).
E.
From: ·············@comcast.net
Subject: Re: Lisp vs. Scheme
Date:
Message-ID: <k77s5zyv.fsf@comcast.net>
··························@jpl.nasa.gov (Erann Gat) writes:
> For example, we've spent a lot of time talking about the interaction of EQ
> and QUOTE.
And in thinking about it, I've decided that
(let ((thunk (lambda () '(a))))
(eq? (thunk) (thunk)))
must return #t. Here is why:
(let ((thunk (lambda () '(a)))) (eq? thunk thunk)) => #t
is required by R5RS, section 6.1
·············@comcast.net writes:
> And in thinking about it, I've decided that
>
> (let ((thunk (lambda () '(a))))
> (eq? (thunk) (thunk)))
>
> must return #t. Here is why:
>
> (let ((thunk (lambda () '(a)))) (eq? thunk thunk)) => #t
>
> is required by R5RS, section 6.1
But could QUOTE possibly be like a constructor in this situation? THUNK could
conceivably be creating a new list every time.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
········@STRIPCAPStelus.net The Rhythm has my soul.
Ray Blaak <········@STRIPCAPStelus.net> writes:
> ·············@comcast.net writes:
>> And in thinking about it, I've decided that
>>
>> (let ((thunk (lambda () '(a))))
>> (eq? (thunk) (thunk)))
>>
>> must return #t. Here is why:
>>
>> (let ((thunk (lambda () '(a)))) (eq? thunk thunk)) => #t
>>
>> is required by R5RS, section 6.1
>
> But could QUOTE possibly be like a constructor in this situation? THUNK could
> conceivably be creating a new list every time.
Section 4.1.2 states that (QUOTE <datum>) evaluates to <datum>.
Section 7.2.3 shows that expressions in K (which includes quoted
objects as per 7.2.1) are passed directly to the expression
continuation.
In article <············@ccs.neu.edu>, Joe Marshall <···@ccs.neu.edu> wrote:
> Ray Blaak <········@STRIPCAPStelus.net> writes:
>
> > ·············@comcast.net writes:
> >> And in thinking about it, I've decided that
> >>
> >> (let ((thunk (lambda () '(a))))
> >> (eq? (thunk) (thunk)))
> >>
> >> must return #t. Here is why:
> >>
> >> (let ((thunk (lambda () '(a)))) (eq? thunk thunk)) => #t
> >>
> >> is required by R5RS, section 6.1
> >
> > But could QUOTE possibly be like a constructor in this situation?
THUNK could
> > conceivably be creating a new list every time.
>
> Section 4.1.2 states that (QUOTE <datum>) evaluates to <datum>.
>
> Section 7.2.3 shows that expressions in K (which includes quoted
> objects as per 7.2.1) are passed directly to the expression
> continuation.
This was discussed at nauseating length in this thread:
http://groups.google.com/groups?dq=&hl=en&lr=&ie=UTF-8&threadm=bbnlm2%24b1s19%241%40ID-60390.news.dfncis.de&rnum=1&prev=/groups%3Fq%3Dg:thl1132347985d%26dq%3D%26hl%3Den%26lr%3D%26ie%3DUTF-8%26selm%3Dbbnlm2%2524b1s19%25241%2540ID-60390.news.dfncis.de
(In case that URL is a too unwieldly, the thread starts with message iD
<··············@ID-60390.news.dfncis.de>)
E.
··························@jpl.nasa.gov (Erann Gat) writes:
> In article <············@ccs.neu.edu>, Joe Marshall <···@ccs.neu.edu> wrote:
>
>> Ray Blaak <········@STRIPCAPStelus.net> writes:
>>
>> > ·············@comcast.net writes:
>> >> And in thinking about it, I've decided that
>> >>
>> >> (let ((thunk (lambda () '(a))))
>> >> (eq? (thunk) (thunk)))
>> >>
>> >> must return #t. Here is why:
>> >>
>> >> (let ((thunk (lambda () '(a)))) (eq? thunk thunk)) => #t
>> >>
>> >> is required by R5RS, section 6.1
>> >
>> > But could QUOTE possibly be like a constructor in this situation?
> THUNK could
>> > conceivably be creating a new list every time.
>>
>> Section 4.1.2 states that (QUOTE <datum>) evaluates to <datum>.
>>
>> Section 7.2.3 shows that expressions in K (which includes quoted
>> objects as per 7.2.1) are passed directly to the expression
>> continuation.
>
> This was discussed at nauseating length in this thread:
I don't think we touched upon the equations in 7.2.3 in that thread.
I have also come to the conclusion that Jeffrey Mark Siskind's Stalin
is non-compliant on this particular point.
In article <············@ccs.neu.edu>, Joe Marshall <···@ccs.neu.edu> wrote:
> ··························@jpl.nasa.gov (Erann Gat) writes:
>
> > In article <············@ccs.neu.edu>, Joe Marshall <···@ccs.neu.edu> wrote:
> >
> >> Ray Blaak <········@STRIPCAPStelus.net> writes:
> >>
> >> > ·············@comcast.net writes:
> >> >> And in thinking about it, I've decided that
> >> >>
> >> >> (let ((thunk (lambda () '(a))))
> >> >> (eq? (thunk) (thunk)))
> >> >>
> >> >> must return #t. Here is why:
> >> >>
> >> >> (let ((thunk (lambda () '(a)))) (eq? thunk thunk)) => #t
> >> >>
> >> >> is required by R5RS, section 6.1
> >> >
> >> > But could QUOTE possibly be like a constructor in this situation?
> > THUNK could
> >> > conceivably be creating a new list every time.
> >>
> >> Section 4.1.2 states that (QUOTE <datum>) evaluates to <datum>.
> >>
> >> Section 7.2.3 shows that expressions in K (which includes quoted
> >> objects as per 7.2.1) are passed directly to the expression
> >> continuation.
> >
> > This was discussed at nauseating length in this thread:
>
> I don't think we touched upon the equations in 7.2.3 in that thread.
>
> I have also come to the conclusion that Jeffrey Mark Siskind's Stalin
> is non-compliant on this particular point.
I think if you want to start beating on this particular dead horse again
you should do it over in comp.lang.scheme.
E.
From: ·············@comcast.net
Subject: Re: Lisp vs. Scheme
Date:
Message-ID: <65ja42qs.fsf@comcast.net>
··························@jpl.nasa.gov (Erann Gat) writes:
> I think if you want to start beating on this particular dead horse again
> you should do it over in comp.lang.scheme.
I thought I saw it twitch. My mistake.
Pascal Costanza wrote:
> Anton van Straaten wrote:
>
> > Pascal Costanza wrote:
>
> >>...but these edge cases are at the heart of the whole discussion AFAICT.
> >>They allow you to solve issues of macro hygiene in a straightforward
> >>way, just by relying on object identity for generated symbols.
> >
> >
> > I've been responding to broader claims, which I consider overly broad.
> > If we narrow it back down to specific issues like the one you mention, I
> > don't really have any argument with that. In the standard, Scheme chose
> > to go in a different direction in that area, for some specific reasons.
>
> OK. So for what reasons?
Lots of interrelated reasons. The people who originally tackled hygienic
macros - Kohlbecker et al., mostly at Indiana - wanted not just to work
around variable capture issues, as "object identity for generated symbols"
does, but to solve the problem more thoroughly. Not only the capture
problem, but also the issue of how macro transformation is specified, i.e.
consing, quasiquoting, and making sure you escape the right variables wasn't
seen as ideal. Both of these goals were both ultimately achieved, and in
the Scheme community, the result was seen as advantageous.
That wasn't because defmacro in Scheme doesn't work (despite common CL
propaganda to the contrary) - almost every Scheme offers defmacro, and
plenty of real Scheme code uses it. Rather, I think it's because defmacro
seems to be counter to some of the goals of Scheme - it reintroduces the
*potential* for lexical confusion in a language that was built from the
beginning on the notion of unambiguous lexical scoping. Even if it's
possible to work around that potential confusion, this kind of thing is
clearly out of place when compared to the rest of the Scheme standard.
In fact, you can go back further than the relatively recent history of
hygienic macros, to the original ideas put forth by Sussman & Steele: that
evaluation could be performed by substitution, as in the lambda calculus,
and that referential transparency was therefore important (also originally
pursued by McCarthy). This basic perspective has influenced the directions
in which Scheme has developed. In particular, this whole issue of
"semantics on lists vs. strings" (which I still think is a misleading
characterization, explained further below), comes in part from the natural
directions in which the idea of evaluation by substitution tends to lead.
For example, substituting into (eq? (foo) (foo)) a definition for 'foo' of
(lambda () '(1 2 3)) ultimately gives (eq? '(1 2 3) '(1 2 3)), which is
allowed to be false even in CL. If you want a notion of object identity in
this environment, you would need to define it very carefully, to avoid
losing some desirable capabilities. But from this more functional
perspective, the entire notion of object identity is called into question.
If you want to give an object some unique identity, you can do so explicitly
by adding the appropriate properties to that object. There's no need to
have the language automatically assign an identity - even to objects which
don't need it - based on ultimately arbitrary considerations. In light of
these kinds of considerations, the RnRS approach to object identity is to
underspecify it, which allows an implementations to decide some of these
issues in a context-appropriate way.
Finally, I think that there are two relevant principles that are evident in
R5RS: operations are defined with a minimum of machinery; and a minimum of
constraints are placed on implementations. In both cases, "minimum" is
defined as "the least necessary to achieve the desired semantics".
Explicitly defining the language's semantics on "data objects", if the goal
is merely to achieve a way to work around variable capture, would violate
both of these principles. Of course, the CL position is likely to be that
this design choice creates a whole set of benefits. However, *if* those
same benefits can be achieved some other way (and I believe they can), then
defining semantics on data objects is still likely to impose an undue
constraint on implementations.
The real benefit I see of doing it the CL way is simply that it's easy to
define and communicate the desired semantics, informally anyway, if they are
defined on data objects. It may present some difficulty for more formal
specification, though, which highlights another relevant core difference
between CL and Scheme: that Scheme has tended to aim for semantic
simplicity, originally deriving from its connection to lambda calculus, and
later expressed by the formal semantics in R5RS. Defining semantics on data
objects might be ruled out on these grounds alone.
However, this doesn't necessarily mean that similar ends can't be achieved,
by some simple extensions to R5RS - and some Schemes do this, e.g. by
supporting syntax for defining lists with shared structure, or by
implementing a proper defmacro, still without requiring semantics defined on
data objects. Although as I've said, the semantics of data objects
representing programs are in fact defined, by extension from the underlying
semantics.
> > One of the original examples related to object identity - (eq? (foo)
> > (foo)) - did not have to do with macros & symbols, and my point there
was
> > that semantics defined on lists are not required for the desired
> > functionality, nor does that semantic basis guarantee such
functionality.
>
> [The following is just a try at wording things differently. I am not
> sure whether this hits the nail on the head. However, I think Erann has
> a point, but maybe it's better to rephrase his centreal statement that
> Scheme is defined on strings whereas Lisp is defined on lists.]
>
> The difference between Common Lisp and Scheme that Erann seems
> to have in mind might be stated like this: Common Lisp is defined on a
> potentially confluent data structure (lists) whereas R5RS is defined
> only for strictly non-confluent structures ("strings").
But strings can represent confluent lists - as they do in CL - and a number
of Scheme implementations do exactly this. Semantics can still be defined
on those "strings". This ends up seeming to be a difference that is no
difference, or to put it another way, semantics defined on lists seems to be
a red herring which is hiding the real differences.
I believe those real differences can be expressed in terms of a common
semantic framework, and that it's neither necessary nor productive to talk
in terms of semantics defined on lists vs. strings to understand or explain
these differences - quite the opposite, it confuses the issue. The CL
standard offers a way of thinking about its semantics, which may be a useful
way for understanding CL internally, but it's not useful for comparison
outside of CL.
Put it this way: I'm sure that the informal part of R5RS could be rewritten
to define its semantics on lists in the same way that CL does, but still
retain the same end result as the original semantics. Or, do the opposite
and rewrite the CL standard (might take a little longer). At that point, we
could compare the two and look at the actual differences. However, I don't
think that rewriting effort is really necessary: we can do that comparison
easily enough without it, as long as we can see past certain distractions.
> The fact that CL is defined on potentially confluent structures gives
> (flet ((foo () (quote <something>)) (eq (foo) (foo))) straightforward
> semantics, whereas it is much harder to give non-ambiguous semantics for
> an equivalent program in Scheme if you want to stick to non-confluency.
I don't agree about "much harder" - we're talking about:
(let* ((x (quote <something>)) (foo (lambda () x))) (eq? (foo) (foo)))
...which is guaranteed to return true.
> > However, the portable syntax-case macro system
> > (http://www.scheme.com/syntax-case/) handles this by using an
"identifier"
> > abstraction which has both a symbolic name - the name the programmer
uses
> > and sees - and a binding name. The latter is chosen to ensure
uniqueness
> > during macro expansion. This is essentially equivalent to having two
> > symbols with the same name, but different object identities - except
that
> > the uniqueness property of names for values of the symbol type is
preserved,
> > so it's less of a hack. :oP
>
> Well, I think the solution you describe is the hack. What one needs is
> object identity for symbols, so Common Lisp gives you the
> straightforward solution. ;-P
Hmm, further discussion of this point will be difficult, and not only
because both our tongues are sticking out...
> Seriously, you probably know that it is very hard to ensure unique
> strings...
The implementation I described need not restrict its binding names to
strings - I don't actually know whether it does.
> >>Or can you implement MAKE-SYMBOL in Scheme such that (make-symbol
> >>"TEST") results in a symbol with the print name TEST and (eq?
> >>(make-symbol "TEST") (make-symbol "TEST")) evaluates to #F at the same
time?
> >
> > The standard STRING->SYMBOL function is required to produce symbols for
> > which EQ? will return #T in that situation, so no.
>
> Taking another step back, the whole discussion has it roots in a thread
> about why some people think that Scheme is not a Lisp. If I needed to
> mention a single reason why I would not regard Scheme (or at least R5RS)
> to be a Lisp, it would indeed be the fact that I cannot implement
> MAKE-SYMBOL in Scheme.
Why? That seems completely arbitrary. You're saying that because standard
Scheme symbols don't have identity distinct from their names - a valid
design choice, not a flaw - that Scheme is not a Lisp? You could create
your own abstraction with the behavior you want. You could even use that
abstraction in defmacros, to avoid variable capture. In fact, Scheme
defmacros can use gensym for that purpose, which amounts to more or less the
same thing - distinguishing a name used in a macro definition, from the name
bound in the expanded code.
Alternatively, you could write an R5RS-standard hygienic macro to wrap your
defmacro bodies, and guarantee no conflicts that way.
BTW, I'd like to propose that we've been looking at this all wrong. In
fact, the question is really whether Common Lisp is a Scheme, and as proof
that it is, I offer Dorai Sitaram's "Scheme Macros for Common Lisp":
http://www.ccs.neu.edu/home/dorai/mbe/mbe-lsp.html
Anton
Anton van Straaten wrote:
> Pascal Costanza wrote:
>
>>Anton van Straaten wrote:
>>
>>
>>>Pascal Costanza wrote:
>>
>>>>...but these edge cases are at the heart of the whole discussion AFAICT.
>>>>They allow you to solve issues of macro hygiene in a straightforward
>>>>way, just by relying on object identity for generated symbols.
>>>
>>>
>>>I've been responding to broader claims, which I consider overly broad.
>>>If we narrow it back down to specific issues like the one you mention, I
>>>don't really have any argument with that. In the standard, Scheme chose
>>>to go in a different direction in that area, for some specific reasons.
>>
>>OK. So for what reasons?
>
>
> Lots of interrelated reasons. The people who originally tackled hygienic
> macros - Kohlbecker et al., mostly at Indiana - wanted not just to work
> around variable capture issues, as "object identity for generated symbols"
> does, but to solve the problem more thoroughly. Not only the capture
> problem, but also the issue of how macro transformation is specified, i.e.
> consing, quasiquoting, and making sure you escape the right variables wasn't
> seen as ideal. Both of these goals were both ultimately achieved, and in
> the Scheme community, the result was seen as advantageous.
I don't quite understand why the CL way wasn't seen as ideal, but this
doesn't contribute to the current discussion anyway, at least if it's
possible in both languages to implement the approach of the respective
other language.
However, I am not convinced yet that Scheme is indeed able to _support_
CL-like macro programming...
> That wasn't because defmacro in Scheme doesn't work (despite common CL
> propaganda to the contrary) - almost every Scheme offers defmacro, and
> plenty of real Scheme code uses it. Rather, I think it's because defmacro
> seems to be counter to some of the goals of Scheme - it reintroduces the
> *potential* for lexical confusion in a language that was built from the
> beginning on the notion of unambiguous lexical scoping. Even if it's
> possible to work around that potential confusion, this kind of thing is
> clearly out of place when compared to the rest of the Scheme standard.
...because in order to be able to avoid variable capture reliably, you
need to also have GENSYM and/or MAKE-SYMBOL (with the CL semantics that
GENSYM/MAKE-SYMBOL provide symbols with unique identity). So it's not
sufficient to provide DEFMACRO to support CL-like macro programming.
> In fact, you can go back further than the relatively recent history of
> hygienic macros, to the original ideas put forth by Sussman & Steele: that
> evaluation could be performed by substitution, as in the lambda calculus,
> and that referential transparency was therefore important (also originally
> pursued by McCarthy). This basic perspective has influenced the directions
> in which Scheme has developed. In particular, this whole issue of
> "semantics on lists vs. strings" (which I still think is a misleading
> characterization, explained further below), comes in part from the natural
> directions in which the idea of evaluation by substitution tends to lead.
OK.
[...]
>>The difference between Common Lisp and Scheme that Erann seems
>>to have in mind might be stated like this: Common Lisp is defined on a
>>potentially confluent data structure (lists) whereas R5RS is defined
>>only for strictly non-confluent structures ("strings").
>
> But strings can represent confluent lists - as they do in CL - and a number
> of Scheme implementations do exactly this.
I have carefully worded the above sentence to only talk about R5RS, not
about Scheme in general.
[...]
> Put it this way: I'm sure that the informal part of R5RS could be rewritten
> to define its semantics on lists in the same way that CL does, but still
> retain the same end result as the original semantics. Or, do the opposite
> and rewrite the CL standard (might take a little longer). At that point, we
> could compare the two and look at the actual differences. However, I don't
> think that rewriting effort is really necessary: we can do that comparison
> easily enough without it, as long as we can see past certain distractions.
It seems to me that you are now talking about "completeness properties".
Of course, it's perfectly possible to implement object identity on top
of a purely value-based core, for example by providing a function that
generates unique strings and making sure that noone else is able to
generate these strings. (The latter part is actually the hard part.)
Vice versa, it's possible to use only values on top of a identity-based
core.
But in order to get a fruitful result from this discussion, we have to
find an agreement where to draw the line between what is an acceptable
extension and what not. As an extreme case, you wouldn't want to call
Java a Lisp-like language because it is possible to implement a Scheme
interpreter in Java. This is only to say that this discussion is not
about completeness properties.
>>The fact that CL is defined on potentially confluent structures gives
>>(flet ((foo () (quote <something>)) (eq (foo) (foo))) straightforward
>>semantics, whereas it is much harder to give non-ambiguous semantics for
>>an equivalent program in Scheme if you want to stick to non-confluency.
>
>
> I don't agree about "much harder" - we're talking about:
>
> (let* ((x (quote <something>)) (foo (lambda () x))) (eq? (foo) (foo)))
>
> ...which is guaranteed to return true.
OK, but we're _also_ talking about:
(defmacro double (x)
(let ((y (make-symbol "Y")))
`(let ((,y ,x))
(* 2 ,y))))
...which cannot be implemented in R5RS in a straightforward way. (And to
a Common Lisper these two examples illustrate the same issue.)
>>>However, the portable syntax-case macro system
>>>(http://www.scheme.com/syntax-case/) handles this by using an "identifier"
>>>abstraction which has both a symbolic name - the name the programmer uses
>>>and sees - and a binding name. The latter is chosen to ensure uniqueness
>>>during macro expansion. This is essentially equivalent to having two
>>>symbols with the same name, but different object identities - except that
>>>the uniqueness property of names for values of the symbol type is preserved,
>>>so it's less of a hack. :oP
>>
>>Well, I think the solution you describe is the hack. What one needs is
>>object identity for symbols, so Common Lisp gives you the
>>straightforward solution. ;-P
>
>
> Hmm, further discussion of this point will be difficult, and not only
> because both our tongues are sticking out...
...and this might be an indication that we have found a real (objective)
difference between Common Lisp and Scheme.
>>Seriously, you probably know that it is very hard to ensure unique
>>strings...
>
>
> The implementation I described need not restrict its binding names to
> strings - I don't actually know whether it does.
Because of this discussion, I have checked out some Scheme
implementations. I find the conceptual model of CL-style macros so
simple, beautiful and easy to handle, and the various solutions for
macro hygiene issues proposed in the Scheme community so confusing that
I have always tried first to find out whether a particular Scheme
implementation supports decent CL-style macro programming with a decent
GENSYM/MAKE-SYMBOL implementation. One documentation I have found that
seems to be representative to me is the following provided with SISC
(which in turn seems to be a very faithful implementation of R5RS):
"SISC's unique symbols are generated by creating a number of the form
current-time + (random-16-bit-natural*311040000000) +
(counter*155520000000). [...] Only if all of these factors align will
a colliding symbol be generated. This is not as unlikely as
say a Microsoft GUID or Java VMID number, but it should be sufficiently
unlikely. [...]"
[from http://sisc.sourceforge.net/manual/html/apd.html#id2954431 ]
This definitely sounds like a hack to me. Why should I want a 99%
solution when I can have a straightforward 100% one?
(However, I am not 100% sure whether I am missing something...)
What Scheme implementations provide a CL-style MAKE-SYMBOL?
>>>>Or can you implement MAKE-SYMBOL in Scheme such that (make-symbol
>>>>"TEST") results in a symbol with the print name TEST and (eq?
>>>>(make-symbol "TEST") (make-symbol "TEST")) evaluates to #F at the same time?
>
>>>The standard STRING->SYMBOL function is required to produce symbols for
>>>which EQ? will return #T in that situation, so no.
>>
>>Taking another step back, the whole discussion has it roots in a thread
>>about why some people think that Scheme is not a Lisp. If I needed to
>>mention a single reason why I would not regard Scheme (or at least R5RS)
>>to be a Lisp, it would indeed be the fact that I cannot implement
>>MAKE-SYMBOL in Scheme.
>
>
> Why? That seems completely arbitrary. You're saying that because standard
> Scheme symbols don't have identity distinct from their names - a valid
> design choice, not a flaw - that Scheme is not a Lisp? You could create
> your own abstraction with the behavior you want. You could even use that
> abstraction in defmacros, to avoid variable capture. In fact, Scheme
> defmacros can use gensym for that purpose, which amounts to more or less the
> same thing - distinguishing a name used in a macro definition, from the name
> bound in the expanded code.
>
> Alternatively, you could write an R5RS-standard hygienic macro to wrap your
> defmacro bodies, and guarantee no conflicts that way.
I hope you have gotten an idea by now why it doesn't seem to me that
your suggestions provide a satisfying solution. (But I am still open to
see whether I have made a mistake somewhere...)
Nevertheless, I don't think that the MAKE-SYMBOL issue is completely
arbitrary. To the contrary, I think it captures the common line of all
the statements so far extremely well that argue that the gap between
Common Lisp and Scheme is bigger than one might expect.
Here is another try to reformulate the list-vs-string statement:
The semantics of Scheme/R5RS are defined on a data structure with value
semantics whereas the semantics of Common Lisp are defined on a data
structure with reference semantics.
Furthermore, Schemers care about the fact that their language is defined
on a data structure with value semantics whereas Common Lispers care
about the fact that their language is defined on a data structure with
reference semantics.
Is this a wording you could agree to?
> BTW, I'd like to propose that we've been looking at this all wrong. In
> fact, the question is really whether Common Lisp is a Scheme, and as proof
> that it is, I offer Dorai Sitaram's "Scheme Macros for Common Lisp":
> http://www.ccs.neu.edu/home/dorai/mbe/mbe-lsp.html
Not quite. From that page: "The Scheme report requires that the macro
definers be hygienic , i.e., that they automatically avoid these lexical
captures. This Common Lisp implementation does not provide hygiene. [...]"
The solutions suggested on that page essentially mean to go back to the
Common Lisp way of doing things. This is probably as annoying to a
Schemer as it is for a Common Lisper to suggest to use hygienic macros
to solve the lack of MAKE-SYMBOL.
Pascal
Pascal Costanza <········@web.de> writes:
> Anton van Straaten wrote:
>
> > Lots of interrelated reasons. The people who originally tackled hygienic
> > macros - Kohlbecker et al., mostly at Indiana - wanted not just to work
> > around variable capture issues, as "object identity for generated symbols"
> > does, but to solve the problem more thoroughly. Not only the capture
> > problem, but also the issue of how macro transformation is specified, i.e.
> > consing, quasiquoting, and making sure you escape the right variables wasn't
> > seen as ideal. Both of these goals were both ultimately achieved, and in
> > the Scheme community, the result was seen as advantageous.
>
> I don't quite understand why the CL way wasn't seen as ideal, but this
> doesn't contribute to the current discussion anyway, at least if it's
> possible in both languages to implement the approach of the respective
> other language.
As an aside, Pascal, have you read this paper?
"Syntactic Closures" <http://citeseer.nj.nec.com/531541.html>
After seeing Kent Pitman cite it time after time, I finally read it
(I'm glad he keeps bringing it up!). It outlines the problems with
defmacro-style macros in Scheme, and proposes a fairly simple concept
(syntactic closures, duh) that would allow Scheme to incorporate a
Lisp-style macro system.
As for pattern-matching, it seems to me like Scheme was trying to kill
two birds (or maybe a bird and the cat stalking it) with one
inappropriate stone. A pattern-matching facility is valuable in and
of itself, and could be a helpful tool for use by macros. See, for
example, Fare's pattern-matcher:
<http://www.ocf.berkeley.edu/~tfb/no-carrier/fare-relicensed>
> The solutions suggested on that page essentially mean to go back to the
> Common Lisp way of doing things. This is probably as annoying to a
> Schemer as it is for a Common Lisper to suggest to use hygienic macros
> to solve the lack of MAKE-SYMBOL.
You mean Scheme-style macros, not "hygienic macrose", right? Cos it
turns out they're not actually hygienic:
<http://citeseer.nj.nec.com/550415.html>
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Thomas F. Burdick wrote:
> Pascal Costanza <········@web.de> writes:
>
>
>>Anton van Straaten wrote:
>>
>>
>>>Lots of interrelated reasons. The people who originally tackled hygienic
>>>macros - Kohlbecker et al., mostly at Indiana - wanted not just to work
>>>around variable capture issues, as "object identity for generated symbols"
>>>does, but to solve the problem more thoroughly. Not only the capture
>>>problem, but also the issue of how macro transformation is specified, i.e.
>>>consing, quasiquoting, and making sure you escape the right variables wasn't
>>>seen as ideal. Both of these goals were both ultimately achieved, and in
>>>the Scheme community, the result was seen as advantageous.
>>
>>I don't quite understand why the CL way wasn't seen as ideal, but this
>>doesn't contribute to the current discussion anyway, at least if it's
>>possible in both languages to implement the approach of the respective
>>other language.
>
>
> As an aside, Pascal, have you read this paper?
> "Syntactic Closures" <http://citeseer.nj.nec.com/531541.html>
>
> After seeing Kent Pitman cite it time after time, I finally read it
> (I'm glad he keeps bringing it up!). It outlines the problems with
> defmacro-style macros in Scheme, and proposes a fairly simple concept
> (syntactic closures, duh) that would allow Scheme to incorporate a
> Lisp-style macro system.
Thanks a lot for the link. After a first sweep through the paper it
seems to me that this will probably bring up the Lisp-1/-2 issue again.
I will read it more closely soon (and probably avoid commenting on it ;)
> As for pattern-matching, it seems to me like Scheme was trying to kill
> two birds (or maybe a bird and the cat stalking it) with one
> inappropriate stone. A pattern-matching facility is valuable in and
> of itself, and could be a helpful tool for use by macros. See, for
> example, Fare's pattern-matcher:
> <http://www.ocf.berkeley.edu/~tfb/no-carrier/fare-relicensed>
Thanks again.
>>The solutions suggested on that page essentially mean to go back to the
>>Common Lisp way of doing things. This is probably as annoying to a
>>Schemer as it is for a Common Lisper to suggest to use hygienic macros
>>to solve the lack of MAKE-SYMBOL.
>
>
> You mean Scheme-style macros, not "hygienic macrose", right? Cos it
> turns out they're not actually hygienic:
> <http://citeseer.nj.nec.com/550415.html>
Now that's really a good one! :-))
Excellent links!
Pascal
Thomas F. Burdick wrote:
> You mean Scheme-style macros, not "hygienic macrose", right? Cos it
> turns out they're not actually hygienic:
> <http://citeseer.nj.nec.com/550415.html>
But "Seemingly Unhygienic" is not the same as "Non hygienic" ?
--
Jens Axel S�gaard
Jens Axel S�gaard <······@jasoegaard.dk> writes:
> Thomas F. Burdick wrote:
>
> > You mean Scheme-style macros, not "hygienic macrose", right? Cos it
> > turns out they're not actually hygienic:
> > <http://citeseer.nj.nec.com/550415.html>
>
> But "Seemingly Unhygienic" is not the same as "Non hygienic" ?
I only skimmed the paper, but "seemingly unhygienic" appeared to be
used in the sense of, "macros written using this technique seem to be
unhygienic."
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
This is a very late response, but to set the record straight:
On Monday, September 29, 2003 1:01 AM, Thomas F. Burdick wrote:
> Jens Axel S�gaard <······@jasoegaard.dk> writes:
>
> > Thomas F. Burdick wrote:
> >
> > > You mean Scheme-style macros, not "hygienic macrose", right? Cos it
> > > turns out they're not actually hygienic:
> > > <http://citeseer.nj.nec.com/550415.html>
> >
> > But "Seemingly Unhygienic" is not the same as "Non hygienic" ?
>
> I only skimmed the paper, but "seemingly unhygienic" appeared to be
> used in the sense of, "macros written using this technique seem to be
> unhygienic."
I suppose that whether this is true depends on exactly what is meant by
that. However, the paper in question achieves its unhygiene by redefining
native constructs like 'let' and 'lambda', with versions that allow
violation of hygiene. There is no violation of hygiene relative to native
Scheme binding operations, nor is such violation possible.
Anton
Anton van Straaten wrote:
> ... There is no violation of hygiene relative to native
> Scheme binding operations, nor is such violation possible.
Another example of pie-in-the-sky meaningless dictates from the false
god of purity (according to some non-god's definition of purity) cocking
up a perfectly reasonable Feature: variable capture. I'd spell it out,
but I suspect the advantage of Getting Work Done would not compute for
Schemers, so I will save my breath.
Well, just a little: if you do not like variable capture, you do not
really understand the power of macros and never will. Secondly,:
kt
[1] sorry, in fact my heart goes out to Boston fans, truly.
--
http://tilton-technology.com
What?! You are a newbie and you haven't answered my:
http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey
Kenny Tilton wrote:
>
> Another example of pie-in-the-sky meaningless dictates from the false
> god of purity (according to some non-god's definition of purity) cocking
> up a perfectly reasonable Feature: variable capture. I'd spell it out,
> but I suspect the advantage of Getting Work Done would not compute for
> Schemers, so I will save my breath.
>
> Well, just a little: if you do not like variable capture, you do not
> really understand the power of macros and never will.
What I don't like is *inadvertent* variable capture. Common Lisp
provides a way to avoid variable capture (using gensym) but using
gensym for every internal variable you don't want to allow to capture
a context variable is a pain in the butt. I'd really rather see a
way to *allow* explicit variable capture (using some kind of
declaration) and have hygienic renaming be the default.
Hmmm.
Y'know, I bet a macro can be defined to do exactly that....
Bear
Ray Dillinger <····@sonic.net> writes:
> Kenny Tilton wrote:
> > Well, just a little: if you do not like variable capture, you do not
> > really understand the power of macros and never will.
>
> What I don't like is *inadvertent* variable capture. Common Lisp
> provides a way to avoid variable capture (using gensym) but using
> gensym for every internal variable you don't want to allow to capture
> a context variable is a pain in the butt. I'd really rather see a
> way to *allow* explicit variable capture (using some kind of
> declaration) and have hygienic renaming be the default.
The situation should not be an all or nothing thing. Having to manually avoid
variable capture is a way to get errors (as with any approach based on being
disciplined). On the other hand doing contortions with Scheme's syntax-case
system when you really do need variable capture is a major pain in the ass.
The answer is make it easy to do both: have hygiene by default, along with an
easy-to-use "escape" mechanism. Dylan has something like ?=foo if one desires
to capture foo. Why couldn't this be done in Scheme or Lisp as well? It is
easy, and addresses both camps' complaints about each other's macro approaches.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
········@STRIPCAPStelus.net The Rhythm has my soul.
Ray Dillinger wrote:
> Kenny Tilton wrote:
>
>>Another example of pie-in-the-sky meaningless dictates from the false
>>god of purity (according to some non-god's definition of purity) cocking
>>up a perfectly reasonable Feature: variable capture. I'd spell it out,
>>but I suspect the advantage of Getting Work Done would not compute for
>>Schemers, so I will save my breath.
>>
>>Well, just a little: if you do not like variable capture, you do not
>>really understand the power of macros and never will.
>
>
> What I don't like is *inadvertent* variable capture. Common Lisp
> provides a way to avoid variable capture (using gensym) but using
> gensym for every internal variable you don't want to allow to capture
> a context variable is a pain in the butt.
1. Sounds like your style needs to be more functional.
2. (with-gensyms (a b c d)... is a snap. And if one is doing macros at
all, writing with-gensyms is a snap if you don't have On Lisp.
I'd really rather see a
> way to *allow* explicit variable capture (using some kind of
> declaration) and have hygienic renaming be the default.
I think the syntax would be no lighter than a with-gensyms. Besides, if
one is doing inadvertent capture in something that occurs enough to be a
macro, don't you also get compiler warnings on most uses where the
captured variable is not lexically available?
kenny
--
http://tilton-technology.com
What?! You are a newbie and you haven't answered my:
http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey
Ray Dillinger wrote:
> What I don't like is *inadvertent* variable capture. Common Lisp
> provides a way to avoid variable capture (using gensym) but using
> gensym for every internal variable you don't want to allow to capture
> a context variable is a pain in the butt. I'd really rather see a
> way to *allow* explicit variable capture (using some kind of
> declaration) and have hygienic renaming be the default.
>
> Hmmm.
>
> Y'know, I bet a macro can be defined to do exactly that....
Do you know about WITH-UNIQUE-NAMES (aka WITH-GENSYMS) and REBINDING, as
provided for example by LispWorks [1], that make these things nearly a
non-issue?
Pascal
[1] Probably also by other implementations, but MCL and LispWorks are
the ones I know best at the moment, and MCL doesn't provide them. [2]
[2] But I have found them via Google and included them in my init.lisp
for MCL. [3]
[3] It's funny to chain footnotes like this, isn't it? ;)
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
On Fri, 17 Oct 2003 18:40:41 +0200, Pascal Costanza <········@web.de> wrote:
> Do you know about WITH-UNIQUE-NAMES (aka WITH-GENSYMS) and
> REBINDING, as provided for example by LispWorks [1], that make these
> things nearly a non-issue?
>
> Pascal
>
> [1] Probably also by other implementations, but MCL and LispWorks
> are the ones I know best at the moment, and MCL doesn't provide
> them. [2]
>
> [2] But I have found them via Google and included them in my
> init.lisp for MCL.
WITH-UNIQUE-NAMES is part of CLiki's "Common Lisp Utilities" but
REBINDING somehow didn't make it there although it was intended to end
up there, too.
<http://www.cliki.net/with-unique-names>
<http://www.cliki.net/Common%20Lisp%20Utilities>
<http://groups.google.com/groups?selm=cy3wv0fya0p.fsf%40ljosa.com>
Edi.
Kenny Tilton wrote:
>
>
> Anton van Straaten wrote:
>
> > ... There is no violation of hygiene relative to native
> > Scheme binding operations, nor is such violation possible.
>
> Another example of pie-in-the-sky meaningless dictates from the false
> god of purity (according to some non-god's definition of purity) cocking
> up a perfectly reasonable Feature: variable capture. I'd spell it out,
> but I suspect the advantage of Getting Work Done would not compute for
> Schemers, so I will save my breath.
>
> Well, just a little: if you do not like variable capture, you do not
> really understand the power of macros and never will. Secondly,:
>
> kt
>
> [1] sorry, in fact my heart goes out to Boston fans, truly.
Secondly,: ??? Something to do with baseball again?
Anyway, if you want to do variable capture in Scheme, use syntax-case or
defmacro. I use all three macro systems, and find I often reach for
syntax-rules first, because it's a very clean way of defining many kinds of
macro. Objecting to it on the grounds that it's too pure is just as
perverse as objecting to anything else on the grounds that it's too impure.
Neither claim is meaningful without the context of an application; both
systems have useful applications.
Anton
Pascal Costanza wrote:
> Because of this discussion, I have checked out some Scheme
> implementations. I find the conceptual model of CL-style macros so
> simple, beautiful and easy to handle, and the various solutions for
> macro hygiene issues proposed in the Scheme community so confusing that
> I have always tried first to find out whether a particular Scheme
> implementation supports decent CL-style macro programming with a decent
> GENSYM/MAKE-SYMBOL implementation. One documentation I have found that
> seems to be representative to me is the following provided with SISC
> (which in turn seems to be a very faithful implementation of R5RS):
> What Scheme implementations provide a CL-style MAKE-SYMBOL?
PLT-Scheme (DrScheme)
<http://download.plt-scheme.org/doc/mzscheme/mzscheme-Z-H-3.html#node_sec_3.6>
Chez Scheme:
<https://www.cs.indiana.edu/chezscheme/csug/objects.html#g1866>
--
Jens Axel S�gaard
Jens Axel S�gaard wrote:
> Pascal Costanza wrote:
>
>> Because of this discussion, I have checked out some Scheme
>> implementations. I find the conceptual model of CL-style macros so
>> simple, beautiful and easy to handle, and the various solutions for
>> macro hygiene issues proposed in the Scheme community so confusing
>> that I have always tried first to find out whether a particular Scheme
>> implementation supports decent CL-style macro programming with a
>> decent GENSYM/MAKE-SYMBOL implementation. One documentation I have
>> found that seems to be representative to me is the following provided
>> with SISC (which in turn seems to be a very faithful implementation of
>> R5RS):
>
>
>> What Scheme implementations provide a CL-style MAKE-SYMBOL?
>
>
> PLT-Scheme (DrScheme)
> <http://download.plt-scheme.org/doc/mzscheme/mzscheme-Z-H-3.html#node_sec_3.6>
>
>
> Chez Scheme:
> <https://www.cs.indiana.edu/chezscheme/csug/objects.html#g1866>
Thanks for the links. SISC also provides something along these lines:
http://sisc.sourceforge.net/manual/html/ch03.html#Symbols
I have missed this bit.
Pascal
Pascal Costanza wrote:
> OK, but we're _also_ talking about:
>
> (defmacro double (x)
> (let ((y (make-symbol "Y")))
> `(let ((,y ,x))
> (* 2 ,y))))
> ...which cannot be implemented in R5RS in a straightforward way. (And >
to a Common Lisper these two examples illustrate the same issue.)
Wouldn't that simply be:
(define-syntax double
(syntax-rules ()
[(double x) (let ((y x))
(* 2 y))]))
> (let ([y 42]) (double 1))
2
What am I missing?
--
Jens Axel S�gaard
Jens Axel S�gaard wrote:
> Pascal Costanza wrote:
>
>> OK, but we're _also_ talking about:
>>
>> (defmacro double (x)
>> (let ((y (make-symbol "Y")))
>> `(let ((,y ,x))
>> (* 2 ,y))))
>
>
>> ...which cannot be implemented in R5RS in a straightforward way. (And >
>
> to a Common Lisper these two examples illustrate the same issue.)
>
> Wouldn't that simply be:
>
> (define-syntax double
> (syntax-rules ()
> [(double x) (let ((y x))
> (* 2 y))]))
>
>
> > (let ([y 42]) (double 1))
> 2
>
> What am I missing?
...that you're not using a low-level macro?
The appropriate way to define double would be (defun double (x) (* 2 x))
- but the example above is given to show what can be done with "real"
objects in source code, not how to best implement the specific example.
Your implementation doesn't show a use of objects in source code.
To put it differently, both macros (mine and yours) solve a macro
hygiene issue, but the Common Lisp version makes use of the fact that
the language is defined on a data structure with reference semantics
whereas the Scheme version sticks to a data structure with value semantics.
My conjecture is that it is hard to have an implementation in Scheme
that simulates the Common Lisp solution without introducing a notion of
identity for source code elements.
Pascal
Does anyone here have any experience hooking up a lisp server to fastcgi.
I have written a Othello game in lisp.
I wish to hook it up to a applet game board. Communication will be XML-RPC
over a apache server using
fastcgi as a trampoline.
I have written the server in Corman Common Lisp.
The only library for connection to Common Lisp I found was for CMU CL.
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
On Tue, 30 Sep 2003 14:45:31 +0100, John Thingstad <··············@chello.no> wrote:
> Does anyone here have any experience hooking up a lisp server to
> fastcgi. I have written a Othello game in lisp. I wish to hook it
> up to a applet game board. Communication will be XML-RPC over a
> apache server using fastcgi as a trampoline. I have written the
> server in Corman Common Lisp. The only library for connection to
> Common Lisp I found was for CMU CL.
There's another one for CLISP:
<http://www.cliki.net/FastCGI>
Edi.
PS: I think it wasn't a good idea to put this question into the middle
of a monster thread that was probably killfiled by half of c.l.l
long ago. Why didn't you just start a new thread?
> Because of this discussion, I have checked out some Scheme
> implementations. I find the conceptual model of CL-style macros so
> simple, beautiful and easy to handle, and the various solutions for
> macro hygiene issues proposed in the Scheme community so confusing that
> I have always tried first to find out whether a particular Scheme
> implementation supports decent CL-style macro programming with a decent
> GENSYM/MAKE-SYMBOL implementation. One documentation I have found that
> seems to be representative to me is the following provided with SISC
> (which in turn seems to be a very faithful implementation of R5RS):
>
> "SISC's unique symbols are generated by creating a number of the form
> current-time + (random-16-bit-natural*311040000000) +
> (counter*155520000000). [...] Only if all of these factors align will
> a colliding symbol be generated. This is not as unlikely as
> say a Microsoft GUID or Java VMID number, but it should be sufficiently
> unlikely. [...]"
>
I'm quite late to this discussion, but the above is taken *way* out of
context. The symbol generation routine described above has nothing to
do with hygienic macros at all, but rather in generating unique
symbols to prevent module binding
collisions, mostly for anonymous modules. The hygienic macro system
(the syntax-case expander by Dybvig et al) does *not* rely on this
mechanism for hygiene.
The reason for the Scheme above is to strike a balance between a
collision free identifier and an overwhelmingly unreadable symbol.
Scott
Scott Miller wrote:
>>Because of this discussion, I have checked out some Scheme
>>implementations. I find the conceptual model of CL-style macros so
>>simple, beautiful and easy to handle, and the various solutions for
>>macro hygiene issues proposed in the Scheme community so confusing that
>>I have always tried first to find out whether a particular Scheme
>>implementation supports decent CL-style macro programming with a decent
>>GENSYM/MAKE-SYMBOL implementation. One documentation I have found that
>>seems to be representative to me is the following provided with SISC
>>(which in turn seems to be a very faithful implementation of R5RS):
>>
>>"SISC's unique symbols are generated by creating a number of the form
>>current-time + (random-16-bit-natural*311040000000) +
>>(counter*155520000000). [...] Only if all of these factors align will
>> a colliding symbol be generated. This is not as unlikely as
>>say a Microsoft GUID or Java VMID number, but it should be sufficiently
>>unlikely. [...]"
>>
>
> I'm quite late to this discussion, but the above is taken *way* out of
> context. The symbol generation routine described above has nothing to
> do with hygienic macros at all, but rather in generating unique
> symbols to prevent module binding
> collisions, mostly for anonymous modules. The hygienic macro system
> (the syntax-case expander by Dybvig et al) does *not* rely on this
> mechanism for hygiene.
I haven't said that. The approaches taken by Common Lisp and Scheme wrt
to macro hygiene are vastly different. Scheme defines a macro system,
"declares" it to be hygienic and leaves it to the implementor of the
macro system to make this work. (I am oversimplifying things a bit
here.) Common Lisp gives symbols unique identities, provides functions
to create symbols that are unique regardless of their names, and leaves
the rest of the work to the programmers of macros. Both Schemers and
Common Lispniks find their respective approaches to be advantageous.
So yes, the Scheme macro system does not rely on unique symbols for
hygiene. The above paragraph just intended to indicate that I, as one
who prefers Common Lisp-style macro hygiene, find it hard to stick to my
preferred programming style when switching to Scheme.
(I haven't really invested a lot of time to do this, so it might be just
me. However, since Common Lisp already provides what I think is the
perfect solution for solving macro hygiene issues, I don't bother a lot.)
> The reason for the Scheme above is to strike a balance between a
> collision free identifier and an overwhelmingly unreadable symbol.
Yes, I understand that. In Common Lisp, you don't need to strike a
balance here (or only for extremely unlikely cases that may occur only
during debugging).
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
Pascal Costanza <········@web.de> wrote in message news:<············@f1node01.rhrz.uni-bonn.de>...
> Scott Miller wrote:
> I haven't said that. The approaches taken by Common Lisp and Scheme wrt
> to macro hygiene are vastly different. Scheme defines a macro system,
> "declares" it to be hygienic and leaves it to the implementor of the
> macro system to make this work. (I am oversimplifying things a bit
> here.) Common Lisp gives symbols unique identities, provides functions
> to create symbols that are unique regardless of their names, and leaves
> the rest of the work to the programmers of macros. Both Schemers and
> Common Lispniks find their respective approaches to be advantageous.
>
The Scheme standard often does such things. In this case, it says
"The introduced variable is effectively renamed throughout its scope".
Doing
this literally is one possible implementation. I for one prefer that
implementation details be left up to the implementors, as it
encourages
creativity in solutions.
> (I haven't really invested a lot of time to do this, so it might be just
> me. However, since Common Lisp already provides what I think is the
> perfect solution for solving macro hygiene issues, I don't bother a lot.)
>
> > The reason for the Scheme above is to strike a balance between a
> > collision free identifier and an overwhelmingly unreadable symbol.
>
> Yes, I understand that. In Common Lisp, you don't need to strike a
> balance here (or only for extremely unlikely cases that may occur only
> during debugging).
>
Sure, but that burden is shifted to the programmer, as well as the
all the opportunity for error.
I really just came here to point out the irrelevance of your comment
about gensym, especially given the existance of
string->uninterned-symbol.
Thats done, so I will leave everyone in peace before an language
arguments
start smoldering.
Scott
>
> Pascal
Scott Miller wrote:
> Pascal Costanza <········@web.de> wrote in message news:<············@f1node01.rhrz.uni-bonn.de>...
>
>>Scott Miller wrote:
>
>
>>I haven't said that. The approaches taken by Common Lisp and Scheme wrt
>>to macro hygiene are vastly different. Scheme defines a macro system,
>>"declares" it to be hygienic and leaves it to the implementor of the
>>macro system to make this work. (I am oversimplifying things a bit
>>here.) Common Lisp gives symbols unique identities, provides functions
>>to create symbols that are unique regardless of their names, and leaves
>>the rest of the work to the programmers of macros. Both Schemers and
>>Common Lispniks find their respective approaches to be advantageous.
>>
>
> The Scheme standard often does such things. In this case, it says
> "The introduced variable is effectively renamed throughout its scope".
> Doing
> this literally is one possible implementation. I for one prefer that
> implementation details be left up to the implementors, as it
> encourages
> creativity in solutions.
That's a reasonable position.
>>(I haven't really invested a lot of time to do this, so it might be just
>>me. However, since Common Lisp already provides what I think is the
>>perfect solution for solving macro hygiene issues, I don't bother a lot.)
>>
>>
>>>The reason for the Scheme above is to strike a balance between a
>>>collision free identifier and an overwhelmingly unreadable symbol.
>>
>>Yes, I understand that. In Common Lisp, you don't need to strike a
>>balance here (or only for extremely unlikely cases that may occur only
>>during debugging).
>>
>
> Sure, but that burden is shifted to the programmer, as well as the
> all the opportunity for error.
With the same argument you could criticize both languages not having a
static type system. I don't think these problems occur in practice, at
least not in a Lisp-2.
> I really just came here to point out the irrelevance of your comment
> about gensym, especially given the existance of
> string->uninterned-symbol.
string->uninternend-symbol is not part of R5RS.
> Thats done, so I will leave everyone in peace before an language
> arguments
> start smoldering.
I don't think there is a need for a language war here. I think both
positions are reasonable.
Pascal
"Anton van Straaten" <·····@appsolutions.com> writes:
[ I've only been looking here and there since the early days of this
thread, but ... ]
> So even if "the semantics of Scheme are not defined on lists", the
> semantics of Scheme programs represented as lists are, in fact,
> defined by R5RS. It's just that the definition doesn't cover
> certain edge cases, such as lists with shared structure.
Some "just"! That's the whole point, the source is lists, not text.
The semantics are that of a s-exp language, not a textual one.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Thomas F. Burdick wrote:
> "Anton van Straaten" <·····@appsolutions.com> writes:
>
> [ I've only been looking here and there since the early days of this
> thread, but ... ]
>
> > So even if "the semantics of Scheme are not defined on lists", the
> > semantics of Scheme programs represented as lists are, in fact,
> > defined by R5RS. It's just that the definition doesn't cover
> > certain edge cases, such as lists with shared structure.
>
> Some "just"! That's the whole point, the source is lists, not text.
My point is that R5RS is deliberately minimal, and in real implementations,
can and has been extended to support a syntactic representation of lists
with shared structure. Despite R5RS being minimal, the approach it takes to
defining the semantics doesn't preclude such a definition.
> The semantics are that of a s-exp language, not a textual one.
We could start a whole new round in which we discuss whether Scheme has the
semantics of an s-exp language or not, but it's the same issue. I say it
has those semantics, even if the standard defines them minimally.
It's easy to argue that because R5RS is minimal, it doesn't provide feature
X - there are plenty of things it doesn't provide, often deliberately, and
they're easy to determine and check. The more interesting question is what
its semantic approach *allows* an implementation to achieve. Arguments of
the form "Scheme is ..." tend to miss the point if they really mean "R5RS is
...", and aren't willing to look beyond what R5RS *requires*, to what it
allows - because then they're dealing with a fictitious, restricted language
which no-one actually implements.
No-one argues that because the Haskell Core language is missing some or
other feature, that Haskell doesn't have that feature. The difference is
that other than SRFIs and de-facto standards, there's no "Big Scheme"
standard. Essentially, there's no equivalent to the CL standard (whereas,
CL has no equivalent to the Scheme standard). That has an effect on
portability between implementations, certainly, but it's not a technical
issue of language semantics.
That all said, I'm much more willing to accept Erann's argument about
"mindset", than to accept the distinction that's been made as a technical
one. I think the main way in which it's a technical distinction is that the
first thing anyone trying to formalize the semantics of CL would probable
want to do is translate it into something more formally tractable - like a
textual representation with whatever annotations are needed to fully capture
its structure.
Anton
Erann Gat wrote:
> In article <····················@newsread1.news.atl.earthlink.net>, "Anton
> van Straaten" <·····@appsolutions.com> wrote:
>
> > R5RS certainly specifies a minimum format of this data.
>
> Really? Where?
>
> > To summarize, any
> > value which was converted from an external representation via READ, or
any
> > value which *could* have been produced this way, qualifies as a program
> > expressed as data.
>
> That's what you say. That's not what R5RS says.
>
> > Further, this representation is very much like a Common
> > Lisp "form" - it can be a list, but it can also be an individual value
like
> > a string, a number, etc. There's no doubt that lists are required to be
> > accepted by EVAL in Scheme.
>
> That may be so, but if it is it's because of common practice in the Scheme
> community, not because R5RS actually says so.
>
> > As such, R5RS Scheme *does* in fact define an API
>
> No, it doesn't. (And if you want to dispute that please do so by citing
> the section(s) of R5RS where this alleged definition can be found.)
I see Joe Marshall has posted a similar response, but I had already written
this up, so here goes:
R5RS section 1.2, Syntax: "The read procedure parses its input as data
(section 7.1.2), not as program."
Sec 7.1.2, External Representations: "<Datum> is what the read procedure
(section 6.6.2) successfully parses. Note that any string that parses as an
expression will also parse as a datum."
Sec 6.5, Eval: "<Expression> must be a valid Scheme expression represented
as data"
From the above, it's clear that READ can parse an expression as a datum. If
such an expression looks like a list in terms of the syntax for external
representations defined in 7.1.2, then the result of READ will be a list.
Such a list represents "an expression represented as data" - it is something
that "parses as an expression" but that has been read by READ, which
"parses its input as data".
EVAL requires "a valid Scheme expression represented as data". Therefore,
when READ is applied to a valid Scheme expression, returning "an expression
represented as data", that result is a valid value for EVAL, and EVAL will
evaluate it. Since for any non-trivial expression, that result will be a
list, EVAL is required to accept lists as representations of expressions.
It's easy to demonstrate that it is possible to construct lists equivalent
to those produced using READ, but without using READ. Since such lists are
indistinguishable from lists created with read, such lists are also required
to be accepted by EVAL. IOW, this defines the minimum characteristics of
expressions represented as data. An R5RS program can rely on being able to
create lists that are isomorphic to the equivalent expressions read by READ,
and evaluate them with EVAL.
Anton
In article <·····················@newsread1.news.atl.earthlink.net>,
"Anton van Straaten" <·····@appsolutions.com> wrote:
> Erann Gat wrote:
> > In article <····················@newsread1.news.atl.earthlink.net>, "Anton
> > van Straaten" <·····@appsolutions.com> wrote:
> >
> > > R5RS certainly specifies a minimum format of this data.
> >
> > Really? Where?
> >
> > > To summarize, any
> > > value which was converted from an external representation via READ, or
> any
> > > value which *could* have been produced this way, qualifies as a program
> > > expressed as data.
> >
> > That's what you say. That's not what R5RS says.
> >
> > > Further, this representation is very much like a Common
> > > Lisp "form" - it can be a list, but it can also be an individual value
> like
> > > a string, a number, etc. There's no doubt that lists are required to be
> > > accepted by EVAL in Scheme.
> >
> > That may be so, but if it is it's because of common practice in the Scheme
> > community, not because R5RS actually says so.
> >
> > > As such, R5RS Scheme *does* in fact define an API
> >
> > No, it doesn't. (And if you want to dispute that please do so by citing
> > the section(s) of R5RS where this alleged definition can be found.)
>
> I see Joe Marshall has posted a similar response, but I had already written
> this up, so here goes:
>
> R5RS section 1.2, Syntax: "The read procedure parses its input as data
> (section 7.1.2), not as program."
>
> Sec 7.1.2, External Representations: "<Datum> is what the read procedure
> (section 6.6.2) successfully parses. Note that any string that parses as an
> expression will also parse as a datum."
>
> Sec 6.5, Eval: "<Expression> must be a valid Scheme expression represented
> as data"
>
> From the above, it's clear that READ can parse an expression as a datum.
No. It can parse a string that was generated by the expression grammar.
This is not the same thing as parsing an expression. (In fact, parsing an
expression is non-sensical. In Scheme, parsing is something that happens
to character strings, and only to character strings.)
But we're getting off track here, because obviously I'm not arguing that
EVAL *can't* take lists as an argument. Let me try to restate my position
another way and see if that doesn't get is out of this loop:
"Scheme's EVAL could be construed to operate on strings rather than lists
without losing any essential functionality."
What I mean by "essential functionality" is any functionality that cannot
be restored by a trivial amount of code. For example, a READ that took
strings instead of lists could obviously no longer run the examples in
R5RS, but this functionality could be restored with a trivial amount of
code (a call to READ-FROM-STRING or some such thing) and is therefore not
essential functionality.
E.
Erann Gat wrote:
> In article <·····················@newsread1.news.atl.earthlink.net>,
> "Anton van Straaten" <·····@appsolutions.com> wrote:
> > R5RS section 1.2, Syntax: "The read procedure parses its input as data
> > (section 7.1.2), not as program."
> >
> > Sec 7.1.2, External Representations: "<Datum> is what the read procedure
> > (section 6.6.2) successfully parses. Note that any string that parses
as an
> > expression will also parse as a datum."
> >
> > Sec 6.5, Eval: "<Expression> must be a valid Scheme expression
represented
> > as data"
> >
> > From the above, it's clear that READ can parse an expression as a datum.
>
> No. It can parse a string that was generated by the expression grammar.
> This is not the same thing as parsing an expression. (In fact, parsing an
> expression is non-sensical. In Scheme, parsing is something that happens
> to character strings, and only to character strings.)
>
> But we're getting off track here [...]
I don't think that this is so off-track, since you've raised the same issue
in other recent posts. I'll rephrase what I wrote, using language from
R5RS:
7.1.2: "<Datum> is what the read procedure (section 6.6.2) successfully
parses. Note that any string that parses as an
expression will also parse as a datum."
So, if READ is provided with a string that "parses as an expression", then
it will parse it "as a datum". If that expression has list syntax, as
defined in 7.1.2, then the resulting datum will be a list. This datum can
then be provided to EVAL, since it is a "valid Scheme expression represented
as data".
The point here is that there is no doubt whether EVAL accepts strings or
some other data type to represent programs: R5RS specifies that it accepts
lists, and a compliant implementation cannot make up some other data
structure for EVAL to accept, to represent expressions such as procedure
application or macro invocation, because those expressions are defined to
have list syntax, and they will be read as lists.
> But we're getting off track here, because obviously I'm not arguing that
> EVAL *can't* take lists as an argument. Let me try to restate my position
> another way and see if that doesn't get is out of this loop:
>
> "Scheme's EVAL could be construed to operate on strings rather than lists
> without losing any essential functionality."
>
> What I mean by "essential functionality" is any functionality that cannot
> be restored by a trivial amount of code. For example, a READ that took
> strings instead of lists could obviously no longer run the examples in
> R5RS, but this functionality could be restored with a trivial amount of
> code (a call to READ-FROM-STRING or some such thing) and is therefore not
> essential functionality.
That's fine. But it means that we have thrown out the idea that "Lisp
defines an API for program objects that can be
operated on by the language itself (lists) and Scheme doesn't." I'm happy
to be narrowing in on the real point, and look forward to finding out what
it is. ;)
Seriously, other than (eval (list 'eq? x x)) which does not appear to have
any real purpose, the only example discussed which demonstrated the possible
benefits of shared structure in data objects representing programs, was that
of the identity of quoted objects such as lists. However, as previously
discussed, the same semantics could be obtained simply by defining the
identity of quoted objects to relate to their location in a program, even if
that program is only represented textually. Is there any reason that
semantics defined on first-class data objects are actually necessary, that
can't be achieved by a more abstract specification?
Anton
"Anton van Straaten" <·····@appsolutions.com> writes:
> Erann Gat wrote:
> > For example, what is the result of the following?
> >
> > (let ( (x "foo") ) (eval (list 'eq? x x)))
>
> Did you mean to write:
>
> (let ( (x "foo") ) (eval (list eq? x x)))
>
> i.e. passing the eq? procedure rather than a symbol. Otherwise, the
> external representation of the above list is simply (eq? "foo" "foo"), the
> result of which is unspecified in R5RS.
Are you sure? If passing the eq? procedure directly, then there is no need for
eval at all, just invoke it directly.
Eval is only useful if it can do the work of evaluating. 'eq? *must* be able
to be passed in, presumably to be looked up in the current environment.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
········@STRIPCAPStelus.net The Rhythm has my soul.
Ray Blaak wrote:
> "Anton van Straaten" <·····@appsolutions.com> writes:
> > Erann Gat wrote:
> > > For example, what is the result of the following?
> > >
> > > (let ( (x "foo") ) (eval (list 'eq? x x)))
> >
> > Did you mean to write:
> >
> > (let ( (x "foo") ) (eval (list eq? x x)))
> >
> > i.e. passing the eq? procedure rather than a symbol. Otherwise, the
> > external representation of the above list is simply (eq? "foo" "foo"),
the
> > result of which is unspecified in R5RS.
>
> Are you sure? If passing the eq? procedure directly, then there is no need
for
> eval at all, just invoke it directly.
Erann was trying to demonstrate limitations on the specification of EVAL in
Scheme, but the example he gave didn't seem to do that. The change I
proposed intentionally passed a procedure object to EVAL, demonstrating the
point I *think* Erann might have been getting at. The result of EVAL on
something like a procedure object doesn't appear to be defined in R5RS.
> Eval is only useful if it can do the work of evaluating. 'eq? *must* be
able
> to be passed in, presumably to be looked up in the current environment.
Yes, that's why Erann's original example doesn't demonstrate any limitation
of EVAL, and why I questioned it.
Anton
"Anton van Straaten" <·····@appsolutions.com> writes:
> [ (let ((x "foo")) (eval (list 'eq? x x)))
> vs
> (let ((x "foo")) (eval (list eq? x x))) ]
>
> Erann was trying to demonstrate limitations on the specification of EVAL in
> Scheme, but the example he gave didn't seem to do that. The change I
> proposed intentionally passed a procedure object to EVAL, demonstrating the
> point I *think* Erann might have been getting at. The result of EVAL on
> something like a procedure object doesn't appear to be defined in R5RS.
I'm not sure, but I think possibly Erann meant what he wrote.
The point about the first form is that the CADR and the CADDR of the
list you're passing to EVAL are the same object; while this has an
external representation in CL, namely '(eq? #1="foo" #1#), I believe
it doesn't in Scheme.
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
Christophe Rhodes wrote:
>
> "Anton van Straaten" <·····@appsolutions.com> writes:
>
> > [ (let ((x "foo")) (eval (list 'eq? x x)))
> > vs
> > (let ((x "foo")) (eval (list eq? x x))) ]
> >
> > Erann was trying to demonstrate limitations on the specification of EVAL in
> > Scheme, but the example he gave didn't seem to do that. The change I
> > proposed intentionally passed a procedure object to EVAL, demonstrating the
> > point I *think* Erann might have been getting at. The result of EVAL on
> > something like a procedure object doesn't appear to be defined in R5RS.
>
> I'm not sure, but I think possibly Erann meant what he wrote.
>
> The point about the first form is that the CADR and the CADDR of the
> list you're passing to EVAL are the same object; while this has an
> external representation in CL, namely '(eq? #1="foo" #1#), I believe
> it doesn't in Scheme.
>
That's an extension supported by many schemes, but it's not part of
R5RS. If you are unsure about whether it's in your current scheme,
check to see if srfi-38 is supported.
Scheme eval actually takes two arguments: a datum and an
environment-specifier. The datum is a datum parseable by the
(read) procedure, which basically means a list, number, character,
symbol, vector, string, or pair, or some structure built out of
these. In most schemes, there is a direct external representation
for procedures, and it is usually identical with the external
representation for the (lambda ...) list expression which created
it. So in practice, as long as you're using a scheme with a direct
external representation for procedures, there is no problem with
passing procedures directly into eval, because they are self-quoting
like numbers or characters, and the read call that eval makes will
handle them correctly. Most schemes allow this, but also allow you
to set a compiler warning for it, in case you want to develop
ultra-portable r5rs-only code.
If the datum is a symbol, it will check the specified environment to
see if it's a variable and if so return whatever the value of the
variable is in that environment. So you could call
(eval 'eq? (current-environment))
and get back whatever is bound to the variable eq? in the current
environment. Usually this will be the procedure that compares
references
to see whether two things are the same object, but in pathological code
it might not be. If you want to be absolutely sure you're getting that
procedure, you might call
(eval 'eq? (scheme-report-environment 5))
To specifically bypass any bizarre tricks someone may have done with
bindings of important variables and get the eq? procedure.
If the first argument is a list, it's evaluated as a function call. For
example
(eval '(foo 1 2 3) (current-environment))
is pretty much the same as calling
(foo 1 2 3)
and
(eval '(lambda (a b c) ... ) (top-level-environment))
Is a way to get an anonymous function which is not subject to the local
lexical scope, even if you need to "splice in" local definitions in
order to form it correctly. You can then assign the resulting function
to a local variable, and use it to bypass local bindings for shadowed
top-level environment stuff. I'm not saying it's a good idea, but you
can certainly do it.
And of course, you can use unquote-splicing, quasiquote, etc, in the
first argument, just as you can in any list.
R5RS does not require it, but most schemes also allow things like
(eval '(define foo (lambda (...)...)) (top-level-environment))
to mutate the top-level environment; this is very handy if you are
doing OO code and want defining a new object type to automatically
make it opaque to regular accessors, define a type predicate, define
accessors with a bunch of names, etc. I'm pretty sure Meroon (a
popular OO package) relies on this, and it's portable to most if not
all of the big schemes out there.
Bear
In article <·················@sonic.net>, Ray Dillinger <····@sonic.net> wrote:
> Scheme eval actually takes two arguments: a datum and an
> environment-specifier. The datum is a datum parseable by the
> (read) procedure, which basically means a list, number, character,
> symbol, vector, string, or pair, or some structure built out of
> these.
The only datum parsable by the read procedure is a string. (Actually,
READ doesn't work directly on strings, only on ports, but a port is a
source of characters (and only characters).) I think what you meant to
say was that the datum (passed as an argument to eval) is a datum whose
printed representation is parsable by the read procedure, and whose
structure is isomorphic to the structure produced when its printable
representation is in fact parsed by the read procedure. But that's not
what you said, and that's certainly not what R5RS says.
> In most schemes, there is a direct external representation
> for procedures, and it is usually identical with the external
> representation for the (lambda ...) list expression which created
> it.
Hm, every Scheme I've ever used printed procedures as #<closure> or some
such thing. But the point is moot, because replacing a procedure with its
equivalent lambda expression does not preserve semantics. Coming up with
an example is left as an excercise for the reader, but here's a hint: you
get a *new* procedure every time you evaluate a lambda expression.
> So in practice, as long as you're using a scheme with a direct
> external representation for procedures, there is no problem with
> passing procedures directly into eval, because they are self-quoting
> like numbers or characters, and the read call that eval makes will
> handle them correctly.
I think you are very confused. Whether or not procedures are
self-evaluting has nothing whatsoever to do with whether they have a
readable external representation.
E.
Erann Gat wrote:
> In article <·················@sonic.net>, Ray Dillinger <····@sonic.net> wrote:
> > Scheme eval actually takes two arguments: a datum and an
> > environment-specifier. The datum is a datum parseable by the
> > (read) procedure, which basically means a list, number, character,
> > symbol, vector, string, or pair, or some structure built out of
> > these.
> The only datum parsable by the read procedure is a string.
Is there some sense in which
'(car foo)
is a list in a Common Lisp eval statement but somehow a string
in a Scheme eval statement? If there is, then I believe that it
must be a distinction which makes no difference. To make it more
explicit, I can say things like this:
(define expr (list 'fnord '(a b) '(+ a b)))
and after I've said that,
(begin
(set-car! expr 'lambda)
(eval (list expr 2 3) (current-environment)))
evaluates to 5. So, you're saying I can use (list) to build
something, and (set-car!) to modify its structure, and then when
I pass it into eval, somehow it's magically no longer a list?
You understand, I suppose, why I think you are just being silly?
> Hm, every Scheme I've ever used printed procedures as #<closure> or some
> such thing.
Frequently seen for unimplementable primitives like +, and sometimes
for compiled user code in implementations like Bigloo that throw away
symbols and try to reduce everything to machine code. Annoying in
the latter case, but allowed by the standard. Certainly one of the
reasons I don't use Bigloo for development.
> But the point is moot, because replacing a procedure with its
> equivalent lambda expression does not preserve semantics. Coming up with
> an example is left as an excercise for the reader, but here's a hint: you
> get a *new* procedure every time you evaluate a lambda expression.
The effects of passing a raw procedure into eval are unspecified; it
"is an error" in the language of the standard. But in order for
function identity to to make any difference, you have to have an
extension not required by R5RS, that allows mutable environments
(other than (current-environment)) in eval, because function identity
can only matter when the function causes side effects in an
environment.
However, if you have mutable environments in eval, the problem is
already solved; you can just pass a (define) expression in to create
a procedure in that environment and thereafter refer to it in
subsequent eval calls using the name of the variable you defined
in that environment.
The basic problem here is that procedures are not just instruction
sequences; their semantics is also linked to their environments and
bindings. Passing a procedure directly from one environment to
another is not well-defined and that's why R5RS doesn't mandate it.
Scheme's eval allows you to refer to (and most implementations allow
you to mutate) additional environments, but the only case in which
passing a procedure directly into eval makes any semantic sense is
for (current-environment), where the bindings that the function
refers to are guaranteed to exist.
Some schemes allow functions to be passed directly into eval as
though they were self-quoting data; but if it's in a context where
those functions are later called, you may get unexpected
consequences when they refer to things that were defined in the
environment where they were created but which are not defined in
the environment in which they are evaluated.
It is far safer to do it the "right" way -- create new procedures
in those environments using lambda expressions evaluated in those
environments. If the eval environments are mutable, then side
effects in those environments are possible and therefore function
identity can be an issue. But if eval environments are mutable,
then you can solve function-identity issues anyway using define
expressions in eval to bind named variables in that environment
to the newly-created function.
> I think you are very confused. Whether or not procedures are
> self-evaluting has nothing whatsoever to do with whether they have a
> readable external representation.
I think your mind is made up and you will not be swayed by the facts.
No hard feelings though; your opinions about what I can do certainly
don't stop me from doing it.
Speaking of which, I must get back to work.
Bear
In article <·················@sonic.net>, Ray Dillinger <····@sonic.net> wrote:
> Erann Gat wrote:
>
> > In article <·················@sonic.net>, Ray Dillinger
<····@sonic.net> wrote:
>
> > > Scheme eval actually takes two arguments: a datum and an
> > > environment-specifier. The datum is a datum parseable by the
> > > (read) procedure, which basically means a list, number, character,
> > > symbol, vector, string, or pair, or some structure built out of
> > > these.
>
> > The only datum parsable by the read procedure is a string.
> ... So, you're saying ...
No, I am not saying anything even remotely like that. I said, "The only
datum parsable by the READ procedure is a string." That's what I said,
and that's what I meant.
> You understand, I suppose, why I think you are just being silly?
Not that it matters, but no.
> > I think you are very confused. Whether or not procedures are
> > self-evaluting has nothing whatsoever to do with whether they have a
> > readable external representation.
>
> I think your mind is made up and you will not be swayed by the facts.
I think we are talking about two completely different things.
E.
Christophe Rhodes <·····@cam.ac.uk> writes:
> "Anton van Straaten" <·····@appsolutions.com> writes:
>
> > [ (let ((x "foo")) (eval (list 'eq? x x)))
> > vs
> > (let ((x "foo")) (eval (list eq? x x))) ]
> >
> > Erann was trying to demonstrate limitations on the specification of EVAL in
> > Scheme, but the example he gave didn't seem to do that. The change I
> > proposed intentionally passed a procedure object to EVAL, demonstrating the
> > point I *think* Erann might have been getting at. The result of EVAL on
> > something like a procedure object doesn't appear to be defined in R5RS.
>
> I'm not sure, but I think possibly Erann meant what he wrote.
>
> The point about the first form is that the CADR and the CADDR of the
> list you're passing to EVAL are the same object; while this has an
> external representation in CL, namely '(eq? #1="foo" #1#), I believe
> it doesn't in Scheme.
And to head off any objections, this obviously continues to (sequences
of) forms that *don't* have an external representation in CL, eg:
(let ((x "foo")
(y (cl:copy-seq "foo")))
(eval (list 'define 'same-foo-p
(list 'lambda (list 'x)
(list 'eq? 'x x))))
(list (eval (list 'same-foo-p x))
(eval (list 'same-foo-p y))))
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
"Anton van Straaten" <·····@appsolutions.com> writes:
> > Eval is only useful if it can do the work of evaluating. 'eq? *must* be
> > able to be passed in, presumably to be looked up in the current
> > environment.
>
> Yes, that's why Erann's original example doesn't demonstrate any limitation
> of EVAL, and why I questioned it.
I thought the point was to show the ambiguity of the boolean result in the
(unspecified) presence constant folding, and/or objects crossing the eval
barrier:
(let ( (x "foo") ) (eval (list 'eq? x x)))
could result in evaluating:
(eq? "foo" "foo")
which may or may not be true in and of itself.
Or, it could result in evaluating:
(eq? x x)
which must return #t.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
········@STRIPCAPStelus.net The Rhythm has my soul.
In article <·············@STRIPCAPStelus.net>, Ray Blaak
<········@STRIPCAPStelus.net> wrote:
> "Anton van Straaten" <·····@appsolutions.com> writes:
> > > Eval is only useful if it can do the work of evaluating. 'eq? *must* be
> > > able to be passed in, presumably to be looked up in the current
> > > environment.
> >
> > Yes, that's why Erann's original example doesn't demonstrate any limitation
> > of EVAL, and why I questioned it.
>
> I thought the point was to show the ambiguity of the boolean result in the
> (unspecified) presence constant folding, and/or objects crossing the eval
> barrier:
>
> (let ( (x "foo") ) (eval (list 'eq? x x)))
>
> could result in evaluating:
>
> (eq? "foo" "foo")
>
> which may or may not be true in and of itself.
>
> Or, it could result in evaluating:
>
> (eq? x x)
>
> which must return #t.
Or it could be an error because the list passed to EVAL is not one that
could be generated by READ.
E.
Erann Gat wrote:
> In article <···················@newsread1.news.atl.earthlink.net>, "Anton
> van Straaten" <·····@appsolutions.com> wrote:
>
> > I'm not sure what your point here is.
>
> My point is that Lisp defines an API for program objects that can be
> operated on by the language itself (lists) and Scheme doesn't.
Fine. That's not the same as saying that Scheme's semantics are defined on
strings.
And, I'll note one last time, that although the R5RS standard doesn't
defined such an API, a rich version of such an API exists in the form of
syntax-case, which has a highly portable implementation and numerous papers
which describe its implementation and rationale. So "Scheme" does in fact
have such an API, it's just optional. As I've pointed out, a big aspect of
this discussion is simply refusal to accept differences in the respective
roles of the "standards" for CL and Scheme.
Anton
In article <····················@newsread1.news.atl.earthlink.net>, "Anton
van Straaten" <·····@appsolutions.com> wrote:
> Erann Gat wrote:
> > In article <···················@newsread1.news.atl.earthlink.net>, "Anton
> > van Straaten" <·····@appsolutions.com> wrote:
> >
> > > I'm not sure what your point here is.
> >
> > My point is that Lisp defines an API for program objects that can be
> > operated on by the language itself (lists) and Scheme doesn't.
>
> Fine. That's not the same as saying that Scheme's semantics are defined on
> strings.
That's true. But Scheme's semantics are nonetheless defined on strings ;-)
Look, what I'm really trying to say is this: the semantics of nearly all
programming languages are defined the same way. Whether you want to call
that "defined on strings" or not doesn't really matter. The point is that
Scheme's semantics are defined in the same way as Algol, C, C++, Java,
Ada, Cobol, Eiffel, etc. etc. etc. Common Lisp is unique in defining its
semantics directly on a data structure that is accessible by the language
itself.
Most people consider the way most programming languages are defined to be
"defined on strings." The syntax of the language is defined using a BNF
grammer whose terminals are characters and the sentences it generates are
called "the legal strings of the language." There is no (and can be no)
BNF grammar for Common Lisp. CL's syntax is defined in terms of the
reader algorithm.
> And, I'll note one last time, that although the R5RS standard doesn't
> defined such an API, a rich version of such an API exists in the form of
> syntax-case, which has a highly portable implementation and numerous papers
> which describe its implementation and rationale. So "Scheme" does in fact
> have such an API, it's just optional.
That's not a fair characterization. The standard, minimal as it is,
already includes things that are optional, so there is a difference
between optional things that are in the standard and things that are
outside of the standard (and are therefore optional). So such a thing may
exist in Scheme as a de-facto standard, but that doesn't change the fact
that it's not in R5RS.
> As I've pointed out, a big aspect of
> this discussion is simply refusal to accept differences in the respective
> roles of the "standards" for CL and Scheme.
I don't dispute that.
E.
Erann Gat wrote:
> > > In article <···················@newsread1.news.atl.earthlink.net>,
"Anton
> > > van Straaten" <·····@appsolutions.com> wrote:
> > >
> > > > I'm not sure what your point here is.
> > >
> > > My point is that Lisp defines an API for program objects that can be
> > > operated on by the language itself (lists) and Scheme doesn't.
> >
> > Fine. That's not the same as saying that Scheme's semantics are defined
on
> > strings.
>
> That's true. But Scheme's semantics are nonetheless defined on strings
;-)
>
> Look, what I'm really trying to say is this: the semantics of nearly all
> programming languages are defined the same way. Whether you want to call
> that "defined on strings" or not doesn't really matter. The point is that
> Scheme's semantics are defined in the same way as Algol, C, C++, Java,
> Ada, Cobol, Eiffel, etc. etc. etc. Common Lisp is unique in defining its
> semantics directly on a data structure that is accessible by the language
> itself.
>
> Most people consider the way most programming languages are defined to be
> "defined on strings." The syntax of the language is defined using a BNF
> grammer whose terminals are characters and the sentences it generates are
> called "the legal strings of the language." There is no (and can be no)
> BNF grammar for Common Lisp. CL's syntax is defined in terms of the
> reader algorithm.
The reason I'm taking issue with the "defined on strings" claim is because
of the way you've been contrasting it with "defined on lists (or forms)".
What I'm saying is that given the consequences you're claiming of a language
defined on lists (or forms), that Scheme offers those same capabilities, and
characterizing it as being "defined on strings" doesn't capture this.
Your eyebrows may have raised when I wrote that "Scheme offers those same
capabilities", so I'll demonstrate what I mean with some code. Here's an
R5RS-standard definition of 'define-makro', a rough facsimile of CL's
defmacro:
(define-syntax define-makro
(syntax-rules ()
((_ name (param ...) macro-body)
(define-syntax name
(syntax-rules ()
((_ . args)
(eval (apply (lambda (param ...) macro-body) (quote args))
(scheme-report-environment 5))))))))
This is obviously a minimal implementation, which has various shortcomings.
However, given this macro, we can now do things like this (taken from the
CLHS):
(define-makro mac1 (a b)
`(+ ,a (* ,b 3)))
(mac1 4 5) => 19
IOW, we can manipulate lists, i.e. data objects, as a representation of
program code, and define macros that work by doing this - all using standard
R5RS Scheme. Earlier, you wrote:
> My point is that Lisp defines an API for program objects that can be
> operated on by the language itself (lists) and Scheme doesn't."
The above code demonstrates that R5RS Scheme defines exactly such an API,
and thus refutes the quoted point. Scheme merely defines the API at a
different level from CL. In Scheme, program "objects" are not constrained
to be anything other than abstract types, and not even first class ones,
*except* at the interfaces to operations in the language which require a
concrete type or representation, in particular, EVAL and the macro system.
The macro system deals with syntactic patterns, and eval deals with programs
"expressed as data". There's no ambiguity about the minimum specification
for what "expressed as data" means - code such as the above, which works
with lists that could have been produced by READ, are required to work by
R5RS.
The point that I draw from this is that it is not necessary for a language
to define its semantics on lists (or forms) in the way that CL does, to
achieve the things that CL achieves. R5RS demonstrates this how this can be
done, by leaving program representations as abstract when they can be, and
requiring a concrete representation when one is needed. From the point of
view of a specification, this is a good thing, since it avoids overly
constraining implementations in ways that don't have to affect the semantics
of the language.
However, confusing the issue is that R5RS is a minimal spec. The points
that have been raised about the differences in actual behavior between CL
and Scheme could be addressed without requiring that Scheme define its
semantics in the same way that CL does - for example, a standard external
representation for lists with shared structure and a definition of the
semantics of programs with such a structure would address the example of
(eval (list 'eq? x x)).
That's why talking about semantics "defined on lists" vs. "defined on
strings" doesn't capture or explain this issue satisfactorily. The real
issue for the features you seem to be concerned with is the availability of
EVAL in the language.
Anton
In article <····················@newsread1.news.atl.earthlink.net>, "Anton
van Straaten" <·····@appsolutions.com> wrote:
[scnip]
> This is obviously a minimal implementation, which has various shortcomings.
But those shortcomings are salient.
> The above code demonstrates that R5RS Scheme defines exactly such an API,
The above code demonstrates nothing. It assumes an API for EVAL and then
uses that assumption to "prove" that this API exists. It's circular
reasoning.
(There are other problem as well, like the fact that makro [sic] expansion
necessarily happens at run-time.)
> Scheme merely defines the API at a
> different level from CL. In Scheme, program "objects" are not constrained
> to be anything other than abstract types, and not even first class ones,
> *except* at the interfaces to operations in the language which require a
> concrete type or representation, in particular, EVAL and the macro system.
> The macro system deals with syntactic patterns, and
Yes.
> eval deals with programs "expressed as data".
Whatever that means.
> There's no ambiguity about the minimum specification
> for what "expressed as data" means
Yes there is.
> - code such as the above, which works
> with lists that could have been produced by READ, are required to work by
> R5RS.
Maybe. What about lists that could not have been produced by READ?
> The point that I draw from this is that it is not necessary for a language
> to define its semantics on lists (or forms) in the way that CL does, to
> achieve the things that CL achieves.
That is a different issue altogether. However, I'm still waiting to see a
satisfactory implementation of compile-time-factorial in R5RS Scheme.
> R5RS demonstrates this how this can be
> done, by leaving program representations as abstract when they can be, and
> requiring a concrete representation when one is needed. From the point of
> view of a specification, this is a good thing, since it avoids overly
> constraining implementations in ways that don't have to affect the semantics
> of the language.
That is a matter of opinion. Having macros that can perform arbitrary
computations at compile time is very handy as far as I'm concerned. But
to each his own.
E.
Erann Gat wrote:
> In article <····················@newsread1.news.atl.earthlink.net>, "Anton
> van Straaten" <·····@appsolutions.com> wrote:
>
> [scnip]
>
> > This is obviously a minimal implementation, which has various
shortcomings.
>
> But those shortcomings are salient.
They apparently intersect some of the points you want to make, but the macro
has also refuted some of your stronger claims on the matter. I'm interested
in defining those actual differences more precisely than they seem to have
been so far, and the macro was a tool to help do that.
> > The above code demonstrates that R5RS Scheme defines exactly such an
API,
>
> The above code demonstrates nothing. It assumes an API for EVAL and then
> uses that assumption to "prove" that this API exists. It's circular
> reasoning.
Not at all. It does not assume an API for EVAL, it uses the API defined by
R5RS. I've addressed that in another post, the reply to the post in which
you wrote "we're getting off track here".
> (There are other problem as well, like the fact that makro [sic] expansion
> necessarily happens at run-time.)
Yes, I'm not addressing that here, only the issue of whether Scheme defines
an API for operating on programs as data - the macro demonstrates that it
does, that it specifically can operate on expressions represented as lists.
> > eval deals with programs "expressed as data".
>
> Whatever that means.
It's perfectly well-defined. I think in this respect, you're simply taking
issue with the language of R5RS, rather than either its intent or its
accepted meaning. If you're aware of other sources which discuss some
underspecification of the spec regarding programs expressed as data, I'd
appreciate a reference. Note that I'm not referring to how it deals with
shared structure or datum that can't be obtained from READ, but simply about
whether there's any question that EVAL must accept lists that represent
expressions.
> > There's no ambiguity about the minimum specification
> > for what "expressed as data" means
>
> Yes there is.
The absolute minimum specification is well-defined, specifically those
expressions that can be produced by READ. Ambiguity only arises beyond
that.
> > - code such as the above, which works
> > with lists that could have been produced by READ, are required to work
by
> > R5RS.
>
> Maybe. What about lists that could not have been produced by READ?
R5RS does not specify.
> > The point that I draw from this is that it is not necessary for a
language
> > to define its semantics on lists (or forms) in the way that CL does, to
> > achieve the things that CL achieves.
>
> That is a different issue altogether.
I see it as quite closely related to the discussion, certainly to claims
related to the significance of CL semantics being defined on lists.
> However, I'm still waiting to see a
> satisfactory implementation of compile-time-factorial in R5RS Scheme.
Using macros to achieve compile-time computation is a hack - at best, a
conflation of two features under a single name. It really has nothing to do
with the real purpose of macros, other than historically. C and C++ can
also do compile time evaluation via macros, but I wouldn't take any
satisfaction from that, if I were you.
I'm not saying that Scheme has a perfect solution to this, by any means,
although some implementations do perform partial evaluation which achieves
the same end more generally. However, my interest is not particularly in CL
vs. Scheme but rather in the most effective ways to implement features of
languages - how *should* these things be done? If we don't have answers to
that question, we can't have any positive influence on future directions.
I'm not one who believes that language evolution has somehow reached its
end, regardless of how old and stable CL or Scheme happen to be.
> > R5RS demonstrates this how this can be
> > done, by leaving program representations as abstract when they can be,
and
> > requiring a concrete representation when one is needed. From the point
of
> > view of a specification, this is a good thing, since it avoids overly
> > constraining implementations in ways that don't have to affect the
semantics
> > of the language.
>
> That is a matter of opinion. Having macros that can perform arbitrary
> computations at compile time is very handy as far as I'm concerned. But
> to each his own.
I think what you really mean is that being able to perform arbitrary
computations at some point prior to runtime is very handy. I agree. But
what does this have to do with macros, other than this happens to be the
place that this feature has historically been implemented, for reasons of
expedience?
Anton
In article <·····················@newsread1.news.atl.earthlink.net>,
"Anton van Straaten" <·····@appsolutions.com> wrote:
> > > eval deals with programs "expressed as data".
> >
> > Whatever that means.
>
> It's perfectly well-defined.
No it's not. What is written in R5RS is rife with ambiguity, particularly
when it comes to handling lists with shared structure. We've been focused
on this idea of "lists that could have been generated by READ". But we
invented that idea out of whole cloth. One could just as easily argue
that EVAL should accept lists whose printed representation is a valid
Scheme program, which is a different set of lists than the set of lists
which could have been generated by READing a valid Scheme program.
If it were perfectly well defined we would not be having this discussion.
> > > There's no ambiguity about the minimum specification
> > > for what "expressed as data" means
> >
> > Yes there is.
>
> The absolute minimum specification is well-defined, specifically those
> expressions that can be produced by READ. Ambiguity only arises beyond
> that.
As I just pointed out, ambiguity arises well before that.
> > > The point that I draw from this is that it is not necessary for a
> language
> > > to define its semantics on lists (or forms) in the way that CL does, to
> > > achieve the things that CL achieves.
> >
> > That is a different issue altogether.
>
> I see it as quite closely related to the discussion, certainly to claims
> related to the significance of CL semantics being defined on lists.
But this discussion hasn't been about about the significance of the
difference between CL and Scheme, only about the nature of that
difference, except for brief tangents like:
> > However, I'm still waiting to see a
> > satisfactory implementation of compile-time-factorial in R5RS Scheme.
>
> Using macros to achieve compile-time computation is a hack
That may well be, but it's an effective hack.
> It really has nothing to do with the real purpose of macros
Who appointed you Arbiter of the Real Purpose of Things?
> C and C++ can
> also do compile time evaluation via macros, but I wouldn't take any
> satisfaction from that, if I were you.
Actually, I think template metaprogramming is a good benchmark against
which to compare CL macro programming. Scheme has nothing comparable to
offer, and no straightforward path to having something comparable to offer
precisely because the Scheme mindset considers such things "hacks", and
that the "right way" to compile-time computation is behind the scenes with
partial evaluation built into a Sufficiently Smart Compiler (TM) or some
such thing. In any event, *programmers* in the Scheme mindset should
under no circumstances be bothered with such details.
> I think what you really mean is that being able to perform arbitrary
> computations at some point prior to runtime is very handy. I agree. But
> what does this have to do with macros, other than this happens to be the
> place that this feature has historically been implemented, for reasons of
> expedience?
Nothing. Except that it works. Today. Portably. Reliably. But again,
whether this matters depends on what you care about, and Schemers seem to
tend not to care about such things.
E.
Erann Gat wrote:
> In article <·····················@newsread1.news.atl.earthlink.net>,
> "Anton van Straaten" <·····@appsolutions.com> wrote:
>
> > > > eval deals with programs "expressed as data".
> > >
> > > Whatever that means.
> >
> > It's perfectly well-defined.
>
> No it's not. What is written in R5RS is rife with ambiguity, particularly
> when it comes to handling lists with shared structure. We've been focused
> on this idea of "lists that could have been generated by READ". But we
> invented that idea out of whole cloth.
No, I focused on that because it's easy to draw the chain which *requires*
that EVAL accept the output of READ. A more direct reading is also
possible, and Joe Marshall gave it.
> One could just as easily argue
> that EVAL should accept lists whose printed representation is a valid
> Scheme program, which is a different set of lists than the set of lists
> which could have been generated by READing a valid Scheme program.
I agree, but I didn't argue that because it does introduce ambiguities, such
as the behavior on lists with shared structure. The output of READ defines
a minimal and non-ambiguous specification for what EVAL accepts.
> > > However, I'm still waiting to see a
> > > satisfactory implementation of compile-time-factorial in R5RS Scheme.
> >
> > Using macros to achieve compile-time computation is a hack
>
> That may well be, but it's an effective hack.
I agree. But what does this have to do with the semantic-defined-on-lists
mindset?
> > It really has nothing to do with the real purpose of macros
>
> Who appointed you Arbiter of the Real Purpose of Things?
Please define "macro" for me, then. I'm suggesting, as a practicing
software engineer, that it's usually a good idea to identify separate pieces
of functionality. Macros as they exist in CL have two different and
essentially unrelated functions, even though they overlap in various ways.
> > C and C++ can
> > also do compile time evaluation via macros, but I wouldn't take any
> > satisfaction from that, if I were you.
>
> Actually, I think template metaprogramming is a good benchmark against
> which to compare CL macro programming. Scheme has nothing comparable to
> offer
Again, you mean R5RS. See my reply to Thomas F. Burdick.
> and no straightforward path to having something comparable to offer
> precisely because the Scheme mindset considers such things "hacks", and
> that the "right way" to compile-time computation is behind the scenes with
> partial evaluation built into a Sufficiently Smart Compiler (TM) or some
> such thing. In any event, *programmers* in the Scheme mindset should
> under no circumstances be bothered with such details.
I didn't say that. I think a means to explicitly control partial evaluation
is perfectly reasonable. I think it's silly for that keyword to be
"defmacro".
> > I think what you really mean is that being able to perform arbitrary
> > computations at some point prior to runtime is very handy. I agree.
But
> > what does this have to do with macros, other than this happens to be the
> > place that this feature has historically been implemented, for reasons
of
> > expedience?
>
> Nothing. Except that it works. Today. Portably. Reliably.
Yes, an effective, useful hack.
> But again, whether this matters depends on what you care about, and
Schemers
> seem to tend not to care about such things.
In article <····················@newsread1.news.atl.earthlink.net>, "Anton
van Straaten" <·····@appsolutions.com> wrote:
> > > It really has nothing to do with the real purpose of macros
> >
> > Who appointed you Arbiter of the Real Purpose of Things?
>
> Please define "macro" for me, then.
You're the one who made the claim, don't you think that you're the one who
should be defining what you meant by it?
But I think this discussion has reached the point of diminishing returns.
E.
Accidentally sent that last post off early...
> > > But
> > > what does this have to do with macros, other than this happens to be
the
> > > place that this feature has historically been implemented, for reasons
> > > of expedience?
> >
> > Nothing.
Hey, you've accepted my definition of "the real purpose of macros" already!
Great. ;)
> Except that it works. Today. Portably. Reliably.
>
> Yes, an effective, useful hack.
>
> > But again, whether this matters depends on what you care about, and
> > Schemers seem to tend not to care about such things.
If I want serious performance, I'll use an optimizing compiler which does
such things automatically. But I suspect Schemers will resort to defmacro
if they want it, and that's where this whole discussion tends to fall down -
real Scheme programs aren't somehow deprived of all these capabilities, and
that's been part of my point. However, they have them without having
semantics defined on lists as first-class data objects.
Anton
From: ·············@comcast.net
Subject: Re: Lisp vs. Scheme
Date:
Message-ID: <fzig5x9b.fsf@comcast.net>
··························@jpl.nasa.gov (Erann Gat) writes:
> In article <·····················@newsread1.news.atl.earthlink.net>,
> "Anton van Straaten" <·····@appsolutions.com> wrote:
>
>> > > eval deals with programs "expressed as data".
>> >
>> > Whatever that means.
>>
>> It's perfectly well-defined.
>
> No it's not. What is written in R5RS is rife with ambiguity, particularly
> when it comes to handling lists with shared structure. We've been focused
> on this idea of "lists that could have been generated by READ". But we
> invented that idea out of whole cloth. One could just as easily argue
> that EVAL should accept lists whose printed representation is a valid
> Scheme program, which is a different set of lists than the set of lists
> which could have been generated by READing a valid Scheme program.
The grammar of data is described in 7.1.2, and the subgrammar of
programs is defined in in section 7.1.3
`lists that could have been generated by read' is an informal description
of the subgrammar of programs. It is easily seen that most of the
productions in the program grammar are lists, and it is stated at the
top of 7.1.2 that the data grammar describes objects generated by read.
There are grey areas, but the existance of a grey area doesn't preclude
there being black and white areas as well.
Anton van Straaten wrote:
>
> Erann Gat wrote:
> > However, I'm still waiting to see a
> > satisfactory implementation of compile-time-factorial in R5RS Scheme.
>
> Using macros to achieve compile-time computation is a hack - at best, a
> conflation of two features under a single name. It really has nothing to do
> with the real purpose of macros, other than historically. C and C++ can
> also do compile time evaluation via macros, but I wouldn't take any
> satisfaction from that, if I were you.
Y'know, I use scheme a lot more than CL and like it better, but I don't
think compile-time macros are a hack at all. In some cases they are a
performance requirement.
If I have a long-ass computation to find, eg, a suitable Carmichael
number for something, I'll be happy to be using an implementation
where I can force that computation to happen at compile time when
I'm shrink-wrapping an application - nobody wants an extra minute
gone every time an application starts up.
That said, I don't think it's a language issue, except that the
language ought to define a macro language that *can* be
implemented to do that; whether it actually does it or not, like
most optimization choices, is an implementation issue rather than
a language issue. constant-propagation+Partial-evaluation of
macroexpanded code usually nails it in scheme, but not every
compiler does that.
> I'm not one who believes that language evolution has somehow reached its
> end, regardless of how old and stable CL or Scheme happen to be.
:-) Me either.
Bear
Ray Dillinger wrote:
> Anton van Straaten wrote:
> >
> > Erann Gat wrote:
>
> > > However, I'm still waiting to see a
> > > satisfactory implementation of compile-time-factorial in R5RS Scheme.
> >
> > Using macros to achieve compile-time computation is a hack - at best, a
> > conflation of two features under a single name. It really has nothing
to do
> > with the real purpose of macros, other than historically. C and C++ can
> > also do compile time evaluation via macros, but I wouldn't take any
> > satisfaction from that, if I were you.
>
> Y'know, I use scheme a lot more than CL and like it better, but I don't
> think compile-time macros are a hack at all. In some cases they are a
> performance requirement.
I'm just saying that compile-time computation doesn't have to be done with
"macros". I'm using the term "macro" as meaning something designed to do
syntactic transformation, and saying that this job can - and should,
conceptually - be separated from other kinds of staged computation.
> If I have a long-ass computation to find, eg, a suitable Carmichael
> number for something, I'll be happy to be using an implementation
> where I can force that computation to happen at compile time when
> I'm shrink-wrapping an application - nobody wants an extra minute
> gone every time an application starts up.
I have no objection to a keyword or something that says "hey compiler,
evaluate this bit of code at compile time". It doesn't have to involve a
macro, though. I guess I'm saying that "compile-time macro" is a poor way
to talk about user-controlled partial evaluation.
> That said, I don't think it's a language issue, except that the
> language ought to define a macro language that *can* be
> implemented to do that; whether it actually does it or not, like
> most optimization choices, is an implementation issue rather than
> a language issue. constant-propagation+Partial-evaluation of
> macroexpanded code usually nails it in scheme, but not every
> compiler does that.
I agree that reliable ways to control this are important.
Anton
Erann Gat wrote:
> You are mixing apples and oranges. I have expressed an (implicit) opinion
> about the Scheme standard as a whole by calling it "impoverished", a
> characterization which is shared by many people and which I stand by. I
> have expressed no opinion about the objective fact [1] that Scheme's
> semantics are defined on strings.
This is interesting, because I routinely pass lists to scheme's eval
and it routinely returns routines and/or other data which are precisely
what I'd expect from list semantics. If scheme semantics are on
strings,
it seems to me to be a distinction that makes no difference. Besides,
you can read from string turning a string into a list, or write to
string
turning a list into a string, at any moment.
I'd have used the word "minimal" rather than the word "impoverished".
Scheme tries very hard to be as small as a complete, useful language
can be without sacrifice of anything important. Basically, you can
implement (I think) just about any "standard" CL functionality you
really
need in your application in a very straightforward way in scheme; most
scheme people have libraries of standard functions that they grab
whatever "basics" they need out of.
There is a scheme prolog implementation that weighs in under 800 lines
if you need a unification language, and I routinely write "objects"
(function closures) blithely ignoring the absence of a standard for
"object oriented" programming and implement message contexts blithely
ignoring the absence of a standard for "data directed" programming.
If you want an extended read/write for data potentially containing
cycles, use the r5rs library for read/ss and write/ss in srfi-38.
If you need threads, there's a thread package in r5rs scheme in
another srfi, or lots of people have rolled their own. And so on.
If there were significant things you couldn't do, or significant
techniques you couldn't use in standard scheme, then I'd consider
the standard impoverished. But, really, short of directly handling
hardware and directly calling the operating system (my personal pet
peeves about scheme) there aren't. So I would call the standard
"minimal" instead.
Scheme aims for the ability to have very small implementations. LispMe,
for example, is a scheme implementation that runs on a palm pilot, and
SIOD weighs in, IIRC, under 150K and is frequently embedded in products
and/or applications. I know that several computer game companies
routinely link SIOD or other schemes into their programs so they can
do their AI and game trees using a LISPy language and still write
C-to-the-bare-metal or C++-to-the-raw-API's for graphics and display
hacks. As another example, GIMP, the photoeditor that is packaged with
most linuxes, defines its macros and filters using scheme with an
embedded scheme compiler. Common Lisp is a great lisp, but just
plain inappropriate in contexts like this because it's too big for
this type of use.
Scheme is very definitely a lisp; you can manipulate lists, pass
them to eval, and get functions back, or construct compile-time
macros, etc, using lists. It just happens to be a small lisp. It
has list semantics as far as I can see because there is a nice
straightforward way to transform lists into functions, and define
functions that take lists of arguments. Also, there are
implementations for a huge variety of library stuff if you want
it. And, no matter how you slice it, it was a lisp dialect before
common lisp even existed and it hasn't changed all that much. To
claim that because common lisp exists, it is no longer, is to claim
that what it means to *be* a lisp has changed because common lisp
exists.
Bear
In article <·················@sonic.net>, Ray Dillinger <····@sonic.net> wrote:
> Erann Gat wrote:
>
> > You are mixing apples and oranges. I have expressed an (implicit) opinion
> > about the Scheme standard as a whole by calling it "impoverished", a
> > characterization which is shared by many people and which I stand by. I
> > have expressed no opinion about the objective fact [1] that Scheme's
> > semantics are defined on strings.
>
> This is interesting, because I routinely pass lists to scheme's eval
> and it routinely returns routines and/or other data which are precisely
> what I'd expect from list semantics. If scheme semantics are on
> strings,
> it seems to me to be a distinction that makes no difference. Besides,
> you can read from string turning a string into a list, or write to
> string
> turning a list into a string, at any moment.
Right, because the syntax for Scheme code happens to be a subset of the
syntax for Scheme data, so there is an isomorphism between Scheme code and
lists.
> I'd have used the word "minimal" rather than the word "impoverished".
...
> If there were significant things you couldn't do, or significant
> techniques you couldn't use in standard scheme, then I'd consider
> the standard impoverished.
There is nothing you "can't" do, but there are things that are
substantially harder (like using macros to do computation at compile
time).
But I won't quibble over this. "Minimal" is a fair characterization.
> Scheme is very definitely a lisp; you can ... construct compile-time
> macros, etc, using lists.
Not in standard Scheme you can't.
> It just happens to be a small lisp. It
> has list semantics as far as I can see because there is a nice
> straightforward way to transform lists into functions, and define
> functions that take lists of arguments. Also, there are
> implementations for a huge variety of library stuff if you want
> it. And, no matter how you slice it, it was a lisp dialect before
> common lisp even existed and it hasn't changed all that much. To
> claim that because common lisp exists, it is no longer, is to claim
> that what it means to *be* a lisp has changed because common lisp
> exists.
Let's be clear that I'm not taking sides on this issue, but the reason
that some people consider Scheme not to be a Lisp is not that Common Lisp
exists, but that Scheme as defined by the standard is wishy-washy over
whether programs are lists.
E.
Ray Dillinger wrote:
> ... I routinely write "objects"
> (function closures) blithely ignoring the absence of a standard for
> "object oriented" programming and implement message contexts blithely
> ignoring the absence of a standard for "data directed" programming.
> If you want an extended read/write for data potentially containing
> cycles, use the r5rs library for read/ss and write/ss in srfi-38.
> If you need threads, there's a thread package in r5rs scheme in
> another srfi, or lots of people have rolled their own. And so on.
Just curious (really!): does this roll-your-own mentality make it hard
for Schemers to share code? ie, to use my neato Graphical whatever you
also need my OO code and lots of my other code and even then my stuff
cannot multiply inherit with your stuff because you have a different
"OO" hack?
kenny
ps. congrats to theLifter for sucking everyone back into this well-trod
thread. Too easy, wasn't it? :) What's next, "Why do they call it Free
Software if I have to do something if I use it?"?
k
Kenny Tilton wrote:
>
> Ray Dillinger wrote:
>
> > ... I routinely write "objects"
> > (function closures) blithely ignoring the absence of a standard for
> > "object oriented" programming and implement message contexts blithely
> > ignoring the absence of a standard for "data directed" programming.
> > If you want an extended read/write for data potentially containing
> > cycles, use the r5rs library for read/ss and write/ss in srfi-38.
> > If you need threads, there's a thread package in r5rs scheme in
> > another srfi, or lots of people have rolled their own. And so on.
>
> Just curious (really!): does this roll-your-own mentality make it hard
> for Schemers to share code? ie, to use my neato Graphical whatever you
> also need my OO code and lots of my other code and even then my stuff
> cannot multiply inherit with your stuff because you have a different
> "OO" hack?
Yes, it does. Different infrastructure sometimes does and sometimes
doesn't interoperate nicely, especially if the person who implemented
it was rude or careless in his/her use of namespace. (Yes, scheme has
package systems... dozens of them... which don't interoperate with
each other well at all!)
I personally like scheme better. Its syntax is nice, its simpler
constructs more general, there aren't as many "gotchas" in the way
things work, and there are a smaller number of simpler parts that
all fit together beautifully.
Still, one of the things I tell people who are deciding which
language to use for a project is that it depends on how many coders
they want to hire(N) and how many different sources they want to
import code from(M). If N+3M is greater than about 15, and they
don't actually need it to be small for any reason, or need semantics
which only exist in scheme (like continuations with unlimited extent)
then I recommend CL over scheme just to save them from headaches
from the roll-your-own-infrastructure issues. (sigh - this is
partly wishful thinking, in that it assumes someone who is not
scared to death of LISPy languages is asking my advice...)
Almost as much of a problem as package/OO incompatibility though,
is rude use of scheme namespace. In order to not be rude, you
must *use* scheme's lexical scoping aggressively and not define
any names at top level other than those which are the interface
to your code. But alas, people who have not fully grokked that
lexical scoping *is* scheme's perfectly-adequate native package
system will happily define hundreds of top-level names because they
figure something else will control the namespace for them. The
problem is made worse by some popular debugging systems that only
work on top-level definitions. Such code is almost never a good
candidate for incorporation into larger projects, regardless of
what bag-on-the-side package system they wrap it in.
Probably the two most popular object systems for scheme are
Tiny-CLOS, which basically is a subset of CLOS, and "Meroon",
which is a particularly nifty OO system by Christian Quinnec
(whose last name I have probably misspelled again...).
You can easily use both in the same program, but it's not as easy
for them to interoperate (ie, you can't derive tinyCLOS classes
from Meroon classes).
But I ignore both because (a)- they are relatively bulky, (b)-
I usually only need a tiny set of OO capabilities, and (c)- I
try to write code that anybody can import into scheme programs
anywhere without raising infrastructure issues or requirements
beyond r5rs itself.
Bear
Kenny Tilton wrote:
> Ray Dillinger wrote:
>
> > ... I routinely write "objects"
> > (function closures) blithely ignoring the absence of a standard for
> > "object oriented" programming and implement message contexts blithely
> > ignoring the absence of a standard for "data directed" programming.
> > If you want an extended read/write for data potentially containing
> > cycles, use the r5rs library for read/ss and write/ss in srfi-38.
> > If you need threads, there's a thread package in r5rs scheme in
> > another srfi, or lots of people have rolled their own. And so on.
>
> Just curious (really!): does this roll-your-own mentality make it hard
> for Schemers to share code? ie, to use my neato Graphical whatever you
> also need my OO code and lots of my other code and even then my stuff
> cannot multiply inherit with your stuff because you have a different
> "OO" hack?
The latter situation is certainly possible, although in Lisp/Scheme, it's
not usually very difficult to glue two things together with a wrapper or
macro or whatever. But as Ray implied, there are various de facto standard
among Schemes. Syntax-case and defmacro are two examples. SLIB is a
largish general-purpose library (30K lines) that runs on most Schemes. And
then there are the SRFIs, which are another rich source of standardized
functionality.
If you want to write very portable, shareable code, you can do so by relying
on portable, shareable things, like the ones mentioned above. But in many
situations, that may not be a priority, and you may choose to roll your own
specific solution to some problem, or make use of specific features of some
implementation. Not every application needs to be portable across
implementations. I've written both: code that's portable across any
R5RS-compliant Scheme, and code that's specific to some implementation like
PLT, SISC, JScheme, Scsh, or SIOD.
In fact, not long ago I did have to port some code from JScheme to SISC
because I decided I preferred the latter's Java integration technique. The
nature of the porting was entirely connected to changing the calls involving
Java objects. The CL standard wouldn't have helped me any there...
> ps. congrats to theLifter for sucking everyone back into this well-trod
> thread. Too easy, wasn't it? :) What's next, "Why do they call it Free
> Software if I have to do something if I use it?"?
Oh, that one's easy: "Free" doesn't mean the same thing as "free". ;)
Anton
"Anton van Straaten" <·····@appsolutions.com> writes:
> The benefit of this is that in the better implementations, the features of
> the available syntax objects go beyond what a direct list representation of
> source code can provide.
Interesting. So there is a difference? So if you write
(quote 12 3 45) ;; A piece of scheme source code
instead of
(quote 12 3 45) ;; A piece of Common Lisp code
there is something additional to be found in the former that is not
present in the latter?
I would say the first is just a ghost, empty, sad and dim, whereas the
second is a list, which has identity, breathes, and is alive :)
But giving you the benefit of the doubt: could you isolate a simple
example where "the scheme way" of writing code is somehow better?
> So you're objecting to the very aspect of the Scheme spec that has
> allowed Scheme implementations to improve on the feature you're
> actually interested in.
Improve upon what?
Mario S. Mommer wrote:
> "Anton van Straaten" <·····@appsolutions.com> writes:
>
>>The benefit of this is that in the better implementations, the features of
>>the available syntax objects go beyond what a direct list representation of
>>source code can provide.
>
> Interesting. So there is a difference? So if you write
>
> (quote 12 3 45) ;; A piece of scheme source code
...
> Improve upon what?
For one: You can write macros which when used incorrectly gives
a custom made syntax error including line and column number.
See Dybvig's paper: "Writing ******* Macros in Scheme with Syntax-Case".
<ftp://ftp.cs.indiana.edu/pub/scheme-repository/doc/pubs/iucstr356.ps.gz>
--
Jens Axel S�gaard
Jens Axel S�gaard <······@jasoegaard.dk> writes:
> > Improve upon what?
>
> For one: You can write macros which when used incorrectly gives
> a custom made syntax error including line and column number.
(What happens when you evaluate a list expression with said macro being
misused - using eval, or compile? (btw, does scheme have "compile"?))
I've been using cmucl intensively for a few years now, and if it
weren't for your post, I would have sworn it gave me that information
(line and column number). Turns out I never missed it.
So I don't think this is the killer app you think, because if the
macro decided to do (error ...), I would certainly get enough
information from the implementation to help me find the problem.
Mario S. Mommer wrote:
> Jens Axel S�gaard <······@jasoegaard.dk> writes:
>
>>>Improve upon what?
>>
>>For one: You can write macros which when used incorrectly gives
>>a custom made syntax error including line and column number.
>
>
> (What happens when you evaluate a list expression with said macro being
> misused - using eval, or compile? (btw, does scheme have "compile"?))
As I said: The macro writer decides. Hand on heart: Did you skim the
paper?
> I've been using cmucl intensively for a few years now, and if it
> weren't for your post, I would have sworn it gave me that information
> (line and column number). Turns out I never missed it.
>
> So I don't think this is the killer app you think,
Killer app? (Gat: I need help over here)
> because if the
> macro decided to do (error ...), I would certainly get enough
> information from the implementation to help me find the problem.
It's nice to have the error worded in terms of the original syntax,
especially if you use somebody elses macro.
--
Jens Axel S�gaard
In article <·························@dread12.news.tele.dk>,
=?ISO-8859-1?Q?Jens_Axel_S=F8gaard?= <······@jasoegaard.dk> wrote:
> Mario S. Mommer wrote:
> > Jens Axel S�gaard <······@jasoegaard.dk> writes:
> >
> >>>Improve upon what?
> >>
> >>For one: You can write macros which when used incorrectly gives
> >>a custom made syntax error including line and column number.
> >
> >
> > (What happens when you evaluate a list expression with said macro being
> > misused - using eval, or compile? (btw, does scheme have "compile"?))
>
> As I said: The macro writer decides. Hand on heart: Did you skim the
> paper?
>
> > I've been using cmucl intensively for a few years now, and if it
> > weren't for your post, I would have sworn it gave me that information
> > (line and column number). Turns out I never missed it.
> >
> > So I don't think this is the killer app you think,
>
> Killer app? (Gat: I need help over here)
Sorry, I've not been following this sub-thread, and you didn't include
enough context for me to figure out what's being discussed.
E.
On Mon, 22 Sep 2003 11:30:32 -0700,
··························@jpl.nasa.gov (Erann Gat) wrote:
>In article <·························@dread12.news.tele.dk>,
>=?ISO-8859-1?Q?Jens_Axel_S=F8gaard?= <······@jasoegaard.dk> wrote:
>
>> Mario S. Mommer wrote:
>> > Jens Axel S�gaard <······@jasoegaard.dk> writes:
>> >
>> >>>Improve upon what?
>> >>
>> >>For one: You can write macros which when used incorrectly gives
>> >>a custom made syntax error including line and column number.
>> >
>> >
>> > (What happens when you evaluate a list expression with said macro being
>> > misused - using eval, or compile? (btw, does scheme have "compile"?))
>>
>> As I said: The macro writer decides. Hand on heart: Did you skim the
>> paper?
>>
>> > I've been using cmucl intensively for a few years now, and if it
>> > weren't for your post, I would have sworn it gave me that information
>> > (line and column number). Turns out I never missed it.
>> >
>> > So I don't think this is the killer app you think,
>>
>> Killer app? (Gat: I need help over here)
>
>Sorry, I've not been following this sub-thread, and you didn't include
>enough context for me to figure out what's being discussed.
>
>E.
Killer App is a reference to a term that was thrown around a lot about
5 years ago. There was a book written about Killer Apps, you can get
the text of it on this web site:
http://www.killer-apps.com/
Doug Tolton
(format t ···@~a~a.~a" "dtolton" "ya" "hoo" "com")
"Mario S. Mommer" wrote:
> "Anton van Straaten" <·····@appsolutions.com> writes:
> > The benefit of this is that in the better implementations, the features
of
> > the available syntax objects go beyond what a direct list representation
of
> > source code can provide.
>
> Interesting. So there is a difference? So if you write
>
> (quote 12 3 45) ;; A piece of scheme source code
>
> instead of
>
> (quote 12 3 45) ;; A piece of Common Lisp code
>
> there is something additional to be found in the former that is not
> present in the latter?
You might find "Syntactic Abstraction in Scheme" informative, which also
talks about issues with Lisp macros:
http://citeseer.nj.nec.com/88826.html
In addition to the source line number info which Jens mentioned, lexical
info after macro expansion is also part of these first-class structures.
So...
> I would say the first is just a ghost, empty, sad and dim, whereas the
> second is a list, which has identity, breathes, and is alive :)
Ah, but do they have *awareness* of their lexical context? The unreflective
life is not worth living... :)
> But giving you the benefit of the doubt: could you isolate a simple
> example where "the scheme way" of writing code is somehow better?
>
> > So you're objecting to the very aspect of the Scheme spec that has
> > allowed Scheme implementations to improve on the feature you're
> > actually interested in.
>
> Improve upon what?
For example, if you're using Scheme to build custom or domain-specific
languages, this additional syntactic information can be very useful. I'll
see if I can post a small example in the next few days.
Anton
"Anton van Straaten" <·····@appsolutions.com> wrote in message news:<·················@newsread1.news.atl.earthlink.net>...
> "Mario S. Mommer" wrote:
> > Interesting. So there is a difference? So if you write
> >
> > (quote 12 3 45) ;; A piece of scheme source code
> >
> > instead of
> >
> > (quote 12 3 45) ;; A piece of Common Lisp code
> >
> > there is something additional to be found in the former that is not
> > present in the latter?
>
> You might find "Syntactic Abstraction in Scheme" informative, which also
> talks about issues with Lisp macros:
> http://citeseer.nj.nec.com/88826.html
(yawn) Variable capture? Oh please stop scaring me, I'm trembling.
> In addition to the source line number info which Jens mentioned, lexical
> info after macro expansion is also part of these first-class structures.
> So...
Afaict, CL has that too:
http://www.lispworks.com/reference/HyperSpec/Body/03_dd.htm#AMenvironment
> > I would say the first is just a ghost, empty, sad and dim, whereas the
> > second is a list, which has identity, breathes, and is alive :)
>
> Ah, but do they have *awareness* of their lexical context? The unreflective
> life is not worth living... :)
How do you know? ;)
········@yahoo.com (Mario S. Mommer) writes:
> "Anton van Straaten" <·····@appsolutions.com> wrote in message
> news:<·················@newsread1.news.atl.earthlink.net>...
> > In addition to the source line number info which Jens mentioned, lexical
> > info after macro expansion is also part of these first-class structures.
> > So...
>
> Afaict, CL has that too:
>
> http://www.lispworks.com/reference/HyperSpec/Body/03_dd.htm#AMenvironment
This is true, but environments are unfortunately opaque in CL, and there
is very little one can do portably with these environments except to pass
them around in code and macros which accept them. The X3J13 standards
committee had proposed an environments access style
(http://www.lispworks.com/reference/HyperSpec/Issues/iss343_w.htm),
and Steele wrote about it in CLtL2 (pp 207-214), but it was retracted
and never made it into the standard. There were a few semantic
difficulties with the proposal, and the proposal had never actually
been implemented (which also went against the stated goals of the
committee).
We've been working on this problem for several years and have added
environments access to Allegro CL, with a very similar interface
as that in the CLtL2 description, having (hopefully) fixed the
semantic difficulties in the description. This facility has already
been in use in our interpreter since version 6.1 (I did this first
because I wanted to be sure that the facility was not compiler-specific,
but purely general purpose) and will be fully functional and integrated
with our compiler in our next major release. We are also considering
the possibility of opensourcing the environments module.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig wrote:
> We've been working on this problem for several years and have added
> environments access to Allegro CL, with a very similar interface
> as that in the CLtL2 description, having (hopefully) fixed the
> semantic difficulties in the description. This facility has already
> been in use in our interpreter since version 6.1 (I did this first
> because I wanted to be sure that the facility was not compiler-specific,
> but purely general purpose) and will be fully functional and integrated
> with our compiler in our next major release. We are also considering
> the possibility of opensourcing the environments module.
This would be a great service to the community because it would allow
writing portable code walkers!
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
Pascal Costanza <········@web.de> writes:
> Duane Rettig wrote:
>
> > We've been working on this problem for several years and have added
> > environments access to Allegro CL, with a very similar interface
> > as that in the CLtL2 description, having (hopefully) fixed the
> > semantic difficulties in the description. This facility has already
> > been in use in our interpreter since version 6.1 (I did this first
> > because I wanted to be sure that the facility was not compiler-specific,
> > but purely general purpose) and will be fully functional and integrated
> > with our compiler in our next major release. We are also considering
> > the possibility of opensourcing the environments module.
>
> This would be a great service to the community because it would allow
> writing portable code walkers!
That's the idea. What better way to promulgate an introspective
language-building-language than to provide introspection into the
language-building itself!
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig <·····@franz.com> writes:
> Pascal Costanza <········@web.de> writes:
> > Duane Rettig wrote:
> > > We've been working on this problem for several years and have added
> > > environments access to Allegro CL, with a very similar interface
> > > as that in the CLtL2 description
> >
> > This would be a great service to the community because it would allow
> > writing portable code walkers!
>
> That's the idea. What better way to promulgate an introspective
> language-building-language than to provide introspection into the
> language-building itself!
SBCL has envionment access also, in its sb-cltl2 contrib module.
--
Lars Brinkhoff, Services for Unix, Linux, GCC, HTTP
Brinkhoff Consulting http://www.brinkhoff.se/
Lars Brinkhoff wrote:
> Duane Rettig <·····@franz.com> writes:
>
>>Pascal Costanza <········@web.de> writes:
>>
>>>Duane Rettig wrote:
>>>
>>>>We've been working on this problem for several years and have added
>>>>environments access to Allegro CL, with a very similar interface
>>>>as that in the CLtL2 description
>>>
>>>This would be a great service to the community because it would allow
>>>writing portable code walkers!
>>
>>That's the idea. What better way to promulgate an introspective
>>language-building-language than to provide introspection into the
>>language-building itself!
>
>
> SBCL has envionment access also, in its sb-cltl2 contrib module.
>
How are the SBCL and ACL version different?
Cheers
--
Marco
Marco Antoniotti <·······@cs.nyu.edu> writes:
> Lars Brinkhoff wrote:
> > Duane Rettig <·····@franz.com> writes:
> >
>
> >>Pascal Costanza <········@web.de> writes:
> >>
> >>>Duane Rettig wrote:
> >>>
> >>>>We've been working on this problem for several years and have added
> >>>>environments access to Allegro CL, with a very similar interface
> >>>>as that in the CLtL2 description
> >>>
> >>>This would be a great service to the community because it would allow
> >>>writing portable code walkers!
> >>
> >>That's the idea. What better way to promulgate an introspective
> >>language-building-language than to provide introspection into the
> >>language-building itself!
> > SBCL has envionment access also, in its sb-cltl2 contrib module.
>
> How are the SBCL and ACL version different?
I can't speak for SBCL, and so can't draw that contrast. However,
since one of our foremost goals was to follow the original idea
(as documented in CLtL2) as closely as possible, I can point out
some of the more major differences between Allegro CL's current
version and the CLtL2 description. It's actually mostly the same -
all in all, I think if you have ever studied the CLtL2 description,
you would tend for the most part to recognize code written for
environments access in Allegro CL.
Other goals, besides mirroring the CLtL2 description, were:
- Environment consistency: There are several categorizations of
"environment", including the running lisp itself, in the CL spec.
We wanted to make sure that our system can play well with all of
these styles. One test of this early on was the remaking of our
interpreter in terms of this new environments access protocol.
[You can even now see environments when you run Allegro CL 6.2;
if you break within some nontrivial interpreted code, you can
look at bound specials on the stack and see environments in the
variable called 'excl::%lexical-environment%. We have since
renamed this variable to be sys:*interpreter-environment*, to
aid portability. If you find one that is non-nil, chances are it
will have an #<augmentable evaluation environment...> there.]
- Speed: Due to the fact that we were replacing push/pop list
technology with environments (think of it as push/pop hashtable
technology) we needed to make it as fast as possible. The
resultant interpreter was somewhat slower, but still acceptable.
But to do this, we had to minimize consing. The CLtL2 description
implies consing to a great degree, so a few key tweaks were made
to the description to minimize this.
A few specifics:
1. Besides variable-information, function-information, and
declaration-information, we added block-information and
tag-information, which were overlooked in the CLtL2 definition.
2. Environments are distinguished (but only by a slot) as either
evaluation or compilation. An evaluation environment [*] needs
no declaration information, except for the special declaration,
and so conses much more minimally than compilation environments.
([*] not to be confused with the "evaluation environment" described
in 3.2.1 of the CL spec; I may change the above name to avoid
such confusion)
3. The CLtL2 definition considers environments to be immutable, and
for the most part, they are. However, there is one value called
the locative (it is just a cons cell, which is small and every CL
has) which holds a mutable value definition. In the interpreter,
this might be the value of a lexically bound variable, or the
function object named by the lexical function name. In the
compiler, this might be a structure representing a compiler node.
This approach allows much more work to be done than just analysis
of presence or absence. It is, in a sense, a similar approach to
that taken by hash-tables, where the environment corresponds to
the hash-table, the name is the hash-key, and the locative is part
of the value for that key.
4. define-declaration is enhanced significantly to specify behaviors
not only in the lexical environment, but also how the dynamic and
global environments are accessed when necessary. Also, either
CLtL2 or the X3J13 issue (I can't remember which) mentioned that
define-declaration handles all known cases except for the SPECIAL
declaration, but our version handles that one, too.
Appetites whetted, yet?
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Thanks Duane,
maybe is there anything about ENVIRONMENTS you guys wrote similar to
SIMPLE-STREAM spec?
Marco
Duane Rettig wrote:
> Marco Antoniotti <·······@cs.nyu.edu> writes:
>
>
>>Lars Brinkhoff wrote:
>>
>>>Duane Rettig <·····@franz.com> writes:
>>>
>>
>>>>Pascal Costanza <········@web.de> writes:
>>>>
>>>>
>>>>>Duane Rettig wrote:
>>>>>
>>>>>
>>>>>>We've been working on this problem for several years and have added
>>>>>>environments access to Allegro CL, with a very similar interface
>>>>>>as that in the CLtL2 description
>>>>>
>>>>>This would be a great service to the community because it would allow
>>>>>writing portable code walkers!
>>>>
>>>>That's the idea. What better way to promulgate an introspective
>>>>language-building-language than to provide introspection into the
>>>>language-building itself!
>>>
>>>SBCL has envionment access also, in its sb-cltl2 contrib module.
>>
>>How are the SBCL and ACL version different?
>
>
> I can't speak for SBCL, and so can't draw that contrast. However,
> since one of our foremost goals was to follow the original idea
> (as documented in CLtL2) as closely as possible, I can point out
> some of the more major differences between Allegro CL's current
> version and the CLtL2 description. It's actually mostly the same -
> all in all, I think if you have ever studied the CLtL2 description,
> you would tend for the most part to recognize code written for
> environments access in Allegro CL.
>
> Other goals, besides mirroring the CLtL2 description, were:
>
> - Environment consistency: There are several categorizations of
> "environment", including the running lisp itself, in the CL spec.
> We wanted to make sure that our system can play well with all of
> these styles. One test of this early on was the remaking of our
> interpreter in terms of this new environments access protocol.
>
> [You can even now see environments when you run Allegro CL 6.2;
> if you break within some nontrivial interpreted code, you can
> look at bound specials on the stack and see environments in the
> variable called 'excl::%lexical-environment%. We have since
> renamed this variable to be sys:*interpreter-environment*, to
> aid portability. If you find one that is non-nil, chances are it
> will have an #<augmentable evaluation environment...> there.]
>
> - Speed: Due to the fact that we were replacing push/pop list
> technology with environments (think of it as push/pop hashtable
> technology) we needed to make it as fast as possible. The
> resultant interpreter was somewhat slower, but still acceptable.
> But to do this, we had to minimize consing. The CLtL2 description
> implies consing to a great degree, so a few key tweaks were made
> to the description to minimize this.
>
>
> A few specifics:
>
> 1. Besides variable-information, function-information, and
> declaration-information, we added block-information and
> tag-information, which were overlooked in the CLtL2 definition.
>
> 2. Environments are distinguished (but only by a slot) as either
> evaluation or compilation. An evaluation environment [*] needs
> no declaration information, except for the special declaration,
> and so conses much more minimally than compilation environments.
>
> ([*] not to be confused with the "evaluation environment" described
> in 3.2.1 of the CL spec; I may change the above name to avoid
> such confusion)
>
> 3. The CLtL2 definition considers environments to be immutable, and
> for the most part, they are. However, there is one value called
> the locative (it is just a cons cell, which is small and every CL
> has) which holds a mutable value definition. In the interpreter,
> this might be the value of a lexically bound variable, or the
> function object named by the lexical function name. In the
> compiler, this might be a structure representing a compiler node.
> This approach allows much more work to be done than just analysis
> of presence or absence. It is, in a sense, a similar approach to
> that taken by hash-tables, where the environment corresponds to
> the hash-table, the name is the hash-key, and the locative is part
> of the value for that key.
>
> 4. define-declaration is enhanced significantly to specify behaviors
> not only in the lexical environment, but also how the dynamic and
> global environments are accessed when necessary. Also, either
> CLtL2 or the X3J13 issue (I can't remember which) mentioned that
> define-declaration handles all known cases except for the SPECIAL
> declaration, but our version handles that one, too.
>
> Appetites whetted, yet?
>
>
Marco Antoniotti <·······@cs.nyu.edu> writes:
> Thanks Duane,
>
> maybe is there anything about ENVIRONMENTS you guys wrote similar to
> SIMPLE-STREAM spec?
Yes, I've been given permission to put something out in this way.
I have to get it up to snuff, though, since it's mostly just a
collection of notes, in plaintext format, and we're still finding a
few issues that require changes. I'll try to have it available
before I leave for ILC.
The complete description will be in a document that will be coming
out sometime during our beta period, which will be starting very
soon. And, of course, the implementation itself will be in the
beta, so if you want to play around with the real thing, sign up
to be a beta tester :-)
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig <·····@franz.com> writes:
> > >>>>We've been working on this problem for several years and have added
> > >>>>environments access to Allegro CL, with a very similar interface
> > >>>>as that in the CLtL2 description
LispWorks for Windows also has a CLtL2 environment interface, but
there hasn't been any recent development on it AFAIK.
> - Environment consistency: There are several categorizations of
> "environment", including the running lisp itself, in the CL spec.
> We wanted to make sure that our system can play well with all of
> these styles.
Agreed. We (at Harlequin/Xanalys) always considered that the various
references to "environment" essentially described the same concept,
even if it might have different representations in different
situations.
> - Speed: Due to the fact that we were replacing push/pop list
> technology with environments (think of it as push/pop hashtable
> technology) we needed to make it as fast as possible.
The LWW interpreter does not use the environment structures at
run-time, because it's based on preprocessing the code. By the time
it's evaluated, all the lookups have been done (this involves some
renaming of lexical names and indirecting accesses to closed-over
variables). Very fast interpretation - not that it matters much these
days.
> 2. Environments are distinguished (but only by a slot) as either
> evaluation or compilation.
We also found this necessary and useful. Can use it to decide whether
to invoke compiler macros, for example. Did you add public accessors
for this?
Good stuff. It's high time to finish up this work, and write those
portable code walkers.
--
Pekka P. Pirinen
If it's spam, it's a scam. Don't do business with net abusers.
···············@globalgraphics.com (Pekka P. Pirinen) writes:
> Duane Rettig <·····@franz.com> writes:
> > > >>>>We've been working on this problem for several years and have added
> > > >>>>environments access to Allegro CL, with a very similar interface
> > > >>>>as that in the CLtL2 description
>
> LispWorks for Windows also has a CLtL2 environment interface, but
> there hasn't been any recent development on it AFAIK.
Pity. What about _in_ it?
> > - Environment consistency: There are several categorizations of
> > "environment", including the running lisp itself, in the CL spec.
> > We wanted to make sure that our system can play well with all of
> > these styles.
>
> Agreed. We (at Harlequin/Xanalys) always considered that the various
> references to "environment" essentially described the same concept,
> even if it might have different representations in different
> situations.
Yes. What forces the issue is that there is only one &environment
variable in those functions which accept it. So that variable must
be able to describe the whole thing, lexical and dynamic, or else
it must be describable via global state.
Speaking of which: We also added property lists for dynamic environment
state, and accessors for them. They include properties for objects
which are not symbols, which allows global environment bindings for
names like (setf foo), etc. These properties can be global in the
running lisp, or they can be attached to an environment object.
> > - Speed: Due to the fact that we were replacing push/pop list
> > technology with environments (think of it as push/pop hashtable
> > technology) we needed to make it as fast as possible.
>
> The LWW interpreter does not use the environment structures at
> run-time, because it's based on preprocessing the code. By the time
> it's evaluated, all the lookups have been done (this involves some
> renaming of lexical names and indirecting accesses to closed-over
> variables). Very fast interpretation - not that it matters much these
> days.
Hmm. So macros (and especially symbol-macros) have already been
expanded? Sounds very much like a minimal compilation step, to me.
> > 2. Environments are distinguished (but only by a slot) as either
> > evaluation or compilation.
>
> We also found this necessary and useful. Can use it to decide whether
> to invoke compiler macros, for example. Did you add public accessors
> for this?
Good point. Right now it's just an unexported slot in a structure,
and it would probably be a good idea to have a reader function for
it, as a shield. Trouble is, if we do get a chance to opensource it,
it is likely that every vendor will have to change this accessor,
at least for bootstrapping purposes; in Allegro CL, we have an
unexported function excl::compilation-environment-p which checks to see
if the environment is a structure or a cons, and decides on that basis.
I can now remove the cons determination, but it was necessary until
we snapped all of the links to the old cons-environment style.
> Good stuff. It's high time to finish up this work, and write those
> portable code walkers.
and continue the tradition of Lisp being the language to catch up to.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Mario S. Mommer wrote:
> "Anton van Straaten" <·····@appsolutions.com> wrote in message news:<·················@newsread1.news.atl.earthlink.net>...
>
>>"Mario S. Mommer" wrote:
>>
>>>Interesting. So there is a difference? So if you write
>>>
>>>(quote 12 3 45) ;; A piece of scheme source code
>>>
>>>instead of
>>>
>>>(quote 12 3 45) ;; A piece of Common Lisp code
>>>
>>>there is something additional to be found in the former that is not
>>>present in the latter?
>>
>>You might find "Syntactic Abstraction in Scheme" informative, which also
>>talks about issues with Lisp macros:
>>http://citeseer.nj.nec.com/88826.html
>
>
> (yawn) Variable capture? Oh please stop scaring me, I'm trembling.
I don't think Anton intended to refer to macro hygiene here.
Pascal
Pascal Costanza <········@web.de> writes:
> I don't think Anton intended to refer to macro hygiene here.
Well, cleanliness *is* next to godliness.
--
David Magda <dmagda at ee.ryerson.ca>, http://www.magda.ca/
Because the innovator has for enemies all those who have done well under
the old conditions, and lukewarm defenders in those who may do well
under the new. -- Niccolo Machiavelli, _The Prince_, Chapter VI
Mario S. Mommer wrote:
> "Anton van Straaten" <·····@appsolutions.com> wrote in message
news:<·················@newsread1.news.atl.earthlink.net>...
> > "Mario S. Mommer" wrote:
> > > Interesting. So there is a difference? So if you write
> > >
> > > (quote 12 3 45) ;; A piece of scheme source code
> > >
> > > instead of
> > >
> > > (quote 12 3 45) ;; A piece of Common Lisp code
> > >
> > > there is something additional to be found in the former that is not
> > > present in the latter?
> >
> > You might find "Syntactic Abstraction in Scheme" informative, which also
> > talks about issues with Lisp macros:
> > http://citeseer.nj.nec.com/88826.html
>
> (yawn) Variable capture? Oh please stop scaring me, I'm trembling.
I think you're scaring yourself. The paper discusses program
representations in "traditional Lisp macro systems", and points out that
"the concrete syntax of Lisp is best seen as consisting of internal data
structures rather than text" (sec 4.1). As a result, it defines an abstract
data type for expressions. The paper answers, in detail, your question
about whether and why "there is something present in the former that is not
present in the latter".
This is what much of the current discussion has been about: in CL, the
abstract data type for expressions is lists, whereas the Scheme spec allows
other data types. As Erann Gat points out, since R5RS neither defines nor
requires a *specific* datatype, this could in theory lead to portability
limitations if you were restricting yourself to R5RS and avoiding standard
portable systems such as syntax-case.
In general, this paper is good background for the aspect of this discussion
relating to "semantics defined on lists".
> > In addition to the source line number info which Jens mentioned, lexical
> > info after macro expansion is also part of these first-class structures.
> > So...
>
> Afaict, CL has that too:
>
> http://www.lispworks.com/reference/HyperSpec/Body/03_dd.htm#AMenvironment
That's not quite the same, particularly because of the environment access
issues which Duane Rettig referred to. Sec 4.2 of the Dybvig et al. paper
describes the way these things are handled with syntax-case.
I liked what Duane said: "What better way to promulgate an introspective
language-building-language than to provide introspection into the
language-building itself!" That's exactly the point here. Macro expansion
does a whole lot of work - even more so in the case of hygienic macros,
whether you think they're necessary or not - and giving programs access to
the results of this work can be useful.
> > Ah, but do they have *awareness* of their lexical context? The
unreflective
> > life is not worth living... :)
>
> How do you know? ;)
I beta-reduce, therefore I am.
Anton
"Anton van Straaten" <·····@appsolutions.com> writes:
> Ah, but do they have *awareness* of their lexical context? The unreflective
> life is not worth living... :)
*Ouch*. But all the French existentialism in the world won't get you
your Engineering merit badge :)
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Thomas F. Burdick wrote:
> "Anton van Straaten" <·····@appsolutions.com> writes:
>
> > Ah, but do they have *awareness* of their lexical context? The
unreflective
> > life is not worth living... :)
>
> *Ouch*. But all the French existentialism in the world won't get you
> your Engineering merit badge :)
Lucky for me that was ancient Greek existentialism, then!
Anton
"Anton van Straaten" <·····@appsolutions.com> writes:
> Thomas F. Burdick wrote:
> > "Anton van Straaten" <·····@appsolutions.com> writes:
> >
> > > Ah, but do they have *awareness* of their lexical context? The
> unreflective
> > > life is not worth living... :)
> >
> > *Ouch*. But all the French existentialism in the world won't get you
> > your Engineering merit badge :)
>
> Lucky for me that was ancient Greek existentialism, then!
*blush* I realized that reight after I hit C-c C-c. I was hoping no
one would notice. Nonetheless, I stand by my merit badge
colloquialism :)
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
thelifter wrote:
> Can anyone give a simple example where you do some computational task
> with Lisp that would be much harder to do with Scheme so that the
> advantage of Lisp becomes more apparent?
>
> Thank you very much...
See this validating URI parser @
http://www3.telus.net/public/whumeniu/uri.lisp
The judicious use of macros, especially in the pseudo.lisp
implementation allows easy translation of the URI BNF
syntax to a lisp like representation.
Wade
Wade Humeniuk wrote:
> thelifter wrote:
>
>> Can anyone give a simple example where you do some computational task
>> with Lisp that would be much harder to do with Scheme so that the
>> advantage of Lisp becomes more apparent?
>>
>> Thank you very much...
>
>
> See this validating URI parser @
>
> http://www3.telus.net/public/whumeniu/uri.lisp
>
> The judicious use of macros, especially in the pseudo.lisp
> implementation allows easy translation of the URI BNF
> syntax to a lisp like representation.
>
> Wade
>
If you want the supporting code to run uri.lisp see
http://www3.telus.net/public/whumeniu/pseudo.lisp
and
http://www3.telus.net/public/whumeniu/system.lisp
system.lisp contains the package definitions for uri and pseudo as
well as other sundry LW system definitions. I assume the uri code will run on any
compliant CL.
Wade
Wade Humeniuk <········@nospamtelus.net> writes:
> thelifter wrote:
>
>> Can anyone give a simple example where you do some computational task
>> with Lisp that would be much harder to do with Scheme so that the
>> advantage of Lisp becomes more apparent?
>> Thank you very much...
>
> See this validating URI parser @
>
> http://www3.telus.net/public/whumeniu/uri.lisp
>
> The judicious use of macros, especially in the pseudo.lisp
> implementation allows easy translation of the URI BNF
> syntax to a lisp like representation.
>
> Wade
See also the URL parser provided with DrScheme in
collects/net/url-unit.ss
in the DrScheme distribution.
·········@gmx.net (thelifter) writes:
> /quote> <!-- sidenote: you see one advantage of XML over S-expr here.
> Unlike a parenthesis you immediately know what this closing tag refers
> to -->
Wrong. If you have multiple <quote> or whatever tags, you can't tell
anything without a smart editor. In this case XML is the _worst_ of
all possible worlds. You have all this heavy <....> tag crap but it
doesn't go the extra mile and require the tags to be labeled and so
it's all for nothing.
Worse yet, a smart editor harder to write and it's brittle - you need
to know the "syntax" of all this crappy tag stuff and if some idiot at
W3C adds some more tags or attributes, you need to _change_ your
editor or it will no longer work. Really, anyone who thinks there is
any advantage of XML in any sense for anything is really lost and is
part of the current _problems_ with software, not any solution.
/Jon
·········@rcn.com (Jon S. Anthony) wrote in message news:<··············@rigel.goldenthreadtech.com>...
> Wrong. If you have multiple <quote> or whatever tags, you can't tell
> anything without a smart editor. In this case XML is the _worst_ of
> all possible worlds. You have all this heavy <....> tag crap but it
> doesn't go the extra mile and require the tags to be labeled and so
> it's all for nothing.
If not for XML, some things about s-ex's would have eluded me. For
example, should nodes and attributes share the same namespace? On
first glance, that sounds absurd. That gives insight into the lisp-2
debates; coming from certain complicated OOP languages, one doesn't
always appreciate how separate functions are from everything else, as
means of combination.
But also, if I had only Windows notepad to edit small bits of text,
which would I prefer it in: XML or s-ex's? Generally I'd prefer XML.
When people argue that one just needs a decent IDE for s-ex's, does
that actually imply XML just doesn't have great IDE support yet? I
should neither need to think about closing tags nor close-parens.
Tayss wrote:
> But also, if I had only Windows notepad to edit small bits of text,
> which would I prefer it in: XML or s-ex's? Generally I'd prefer XML.
>
> When people argue that one just needs a decent IDE for s-ex's, does
> that actually imply XML just doesn't have great IDE support yet? I
> should neither need to think about closing tags nor close-parens.
This is pure rhetorics, isn't it? I mean, we don't live in a world in
which we only have notepad at our disposal...
And even if this were the case, XML wouldn't be the only alternative,
let alone the best.
See http://www.pault.com/pault/pxml/xmlalternatives.html for some more
possibilities.
Pascal
Pascal Costanza <········@web.de> wrote in message news:<············@newsreader2.netcologne.de>...
> Tayss wrote:
> > But also, if I had only Windows notepad to edit small bits of text,
> > which would I prefer it in: XML or s-ex's? Generally I'd prefer XML.
> This is pure rhetorics, isn't it? I mean, we don't live in a world in
> which we only have notepad at our disposal...
What is XML? It's a mainstream format. Therefore it is aimed at the
lowest common denominator.
I've seen teamleader-type programmers open up XML docs using Windows
notepad. Why? Using an IDE, you have to navigate the filesystem in a
little box that isn't as deeply engineered as the OS shell; or you
have to bind the app to open files of your type (or use a right-click
menu) and wait a couple seconds for his favorite heavy-duty IDE to
open your file.
On my 1.8 ghz machine, emacs still takes a sec or two to start up.
Notepad is instant gratification and therefore gives the user a
feeling of control.
Further, one large goal is for every HTML document to be a conforming
XML document. People still like using notepad to quickly edit web
pages.
Finally, note Jef Raskin's assertion that IDEs haven't evolved
usability-wise:
http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=22
> And even if this were the case, XML wouldn't be the only alternative,
> let alone the best.
And they all seem reasonably isomorphic. But I'm not arguing this.
His assertion was there are no advantages of XML over s-ex's. My
counterassertion is that there exist advantages. I will not attempt
to shift to a weaker position since I personally prefer s-ex's. The
checksummed binary s-ex format seemed interesting, if you can't assume
you'll get safety on a transport level.
Tayss wrote:
>>And even if this were the case, XML wouldn't be the only alternative,
>>let alone the best.
>
> And they all seem reasonably isomorphic. But I'm not arguing this.
> His assertion was there are no advantages of XML over s-ex's. My
> counterassertion is that there exist advantages.
To make this more concrete, I have tried to translate the OP's example
code into XML:
<defun>
<name>foo</name>
<body>
<quote>
<list>
<number>1</number>
<number>2</number>
<number>3</number>
</list>
</quote>
</body>
</defun>
<eq>
<list>foo</list>
<list>foo</list>
</eq>
Is this correct? Is this better than s-expr? I don't think so.
BTw, I don't think any experienced Lisp programmer has problems with
making small changes to Lisp source code with only notepad at hand.
I am convinced that for larger changes you need tool support, both for
s-expr and XML.
Pascal
Pascal Costanza <········@web.de> wrote in message news:<············@newsreader2.netcologne.de>...
> To make this more concrete, I have tried to translate the OP's example
> code into XML:
You're not going to drag me away from my position, which is, "There
exist advantages of XML over s-ex's." Think of me as a Catholic who's
comfortable with saying, "You know, the Beast sometimes has a point."
;)
In that last post I made clear I prefer s-ex's. But I don't mind
drawing lessons from other syntaxes.
# Python's syntax reminds me of seasoning, emphasizing certain parts.
# And maybe it's a decent conceptual step to lisp. After all, Java
# made the mainstream demand GC.
def foo(): return [1, 2, 3]
foo() is foo()
;; Scheme is always cute in these microexamples. And
;; its function def syntax seems like an improvement,
;; since it saves from having to move the open-paren
;; when cut 'n pasting.
(define (foo) '(1 2 3))
(eq? (foo) (foo))
// Java reminds me to ice my wrists. Maybe write some emacs
// scripts. And I certainly feel I got a lot done!
package org.pentaside.lisp_newsgroup_throwaway_code;
import java.util.List;
import java.util.ArrayList;
/**
* Usage: <code>java -classpath=.
* org.pentaside.lisp_newsgroup_throwaway_code.Throwaway</code>
*
* NOTE: I don't have time to test this code.
*
* @author <a ·······················@yahoo.com">Tayssir John
Gabbour</a>
* @version %I%, %G%
*/
public class Throwaway {
/**
* Check how this Java implementation treats object creation.
*
* @param args This class method doesn't take use its params.
* @see #foo()
*/
public static void main( String[] args ) {
System.out.println( foo() == foo() );
}
/**
* Returns a <code>List</code> of three consecutive integers,
* starting at 1.
*
* No more, no less. Three shalt be the number thou shalt
* List, and the number of the Listing, shall be three.
* Four shalt thou not return, neither returnst thou two,
* excepting that thou then procede to three. Five is right
* out. Once the number three, being the third number, be
* Listed, then returnst thou.
*
* @return List of three consecutive integers, starting at 1.
*/
private static List foo() {
List list = new ArrayList();
// 21sep03: OPTIMIZATION -- used <code>Integer</code>
// instead of <code>BigInteger</code>.
list.add(new Integer(1));
list.add(new Integer(2));
list.add(new Integer(3));
return list;
}
}
··········@yahoo.com (Tayss) writes:
> # Python's [...]
> def foo(): return [1, 2, 3]
> foo() is foo()
>
> ;; Scheme [...]
> (define (foo) '(1 2 3))
> (eq? (foo) (foo))
>
> // Java reminds me to ice my wrists. Maybe write some emacs
> // scripts. And I certainly feel I got a lot done!
[big stuff elided]
Be fairer with Java here. You don't necessarily have to show the
"infrastructure" for getting things to run. That will exist anyway if one is
using Java. That is, there will necessarily be a class declared, a main
method, etc. Consider also that one might have evaluated things inside of a
debugger.
In terms of expressivity, the important thing is to show a method, and a
comparison. The real problem with Java in this case is revealed: the object vs
primitive type conflict, and the inflexible integer (vs big integer) type:
List foo()
{
Integer ints = {new Integer(1), new Integer(2), new Integer(3)};
return java.util.Arrays.asList(ints);
}
Furthermore, if one is really comparing sets of canonical integers, one should
use the "natural" representation for Java, which in fact moves things closer
to the heart of the original quoting issue (I am ignoring XML vs s-exps here,
except to say that I prefer s-exps):
int[] foo()
{
int[] ints = {1, 2, 3};
return ints;
}
but this is equivalent to:
int[] foo()
{
return new int[] {1, 2, 3};
}
and so we see that java does not in fact have the quoting issue at all: the
language semantics define quoted arrays to be distinct. Sharing, if desired,
must be explicit:
private int[] ints = {1, 2, 3};
int[] foo()
{
return ints;
}
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
········@STRIPCAPStelus.net The Rhythm has my soul.
Ray Blaak <········@STRIPCAPStelus.net> writes:
> List foo()
> {
> Integer ints = {new Integer(1), new Integer(2), new Integer(3)};
> return java.util.Arrays.asList(ints);
> }
That should be:
Integer[] ints = {new Integer(1), new Integer(2), new Integer(3)};
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
········@STRIPCAPStelus.net The Rhythm has my soul.
Ray Blaak <········@STRIPCAPStelus.net> writes:
> Ray Blaak <········@STRIPCAPStelus.net> writes:
> > List foo()
> > {
> > Integer ints = {new Integer(1), new Integer(2), new Integer(3)};
> > return java.util.Arrays.asList(ints);
> > }
>
> That should be:
>
> Integer[] ints = {new Integer(1), new Integer(2), new Integer(3)};
And not like this:
Integer [] ints = new Integer[] {...};
?
--
Janis Dzerins
Common Lisp -- you get more than what you see.
Janis Dzerins wrote:
>Ray Blaak <········@STRIPCAPStelus.net> writes:
>
>
>
>>That should be:
>>
>> Integer[] ints = {new Integer(1), new Integer(2), new Integer(3)};
>>
>>
>
>And not like this:
>
> Integer [] ints = new Integer[] {...};
>
>?
>
>
>
That's what I thought, but the former syntax does work. I'd never seen
it before, but I'll always use it from now on; anything that reduces the
(huge) percentage of java code devoted to type declarations being a good
thing.
Janis Dzerins <·····@latnet.lv> writes:
> Ray Blaak <········@STRIPCAPStelus.net> writes:
> > That should be:
> >
> > Integer[] ints = {new Integer(1), new Integer(2), new Integer(3)};
>
> And not like this:
>
> Integer [] ints = new Integer[] {...};
The former is a short hand for the latter, and works only for variable
declarations.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
········@STRIPCAPStelus.net The Rhythm has my soul.
BTW, if you really want to debate my point that XML has certain
usability advantages...
> <defun>
> <name>foo</name>
> <body>
> <quote>
> <list>
> <number>1</number>
[snip...]
> Is this correct? Is this better than s-expr? I don't think so.
Under what context do you want me to decide if this is more
appropriate than s-ex's? As a "computer professional," I can't render
my opinion without context. If this were an interview, you would be
justified in not hiring if I just gave an absolute opinion without
getting a sense of context. In fact, I would say the problem with
this form of communication is that there's so much back & forth
because clarifying context is tedious.
> BTw, I don't think any experienced Lisp programmer has problems with
> making small changes to Lisp source code with only notepad at hand.
I feel my points were ignored about mainstream usability.
"Experienced Lisp programmers" are in a totally different league of
computer literacy than other computer users.
> I am convinced that for larger changes you need tool support, both for
> s-expr and XML.
We agree.
··········@yahoo.com (Tayss) writes:
> BTW, if you really want to debate my point that XML has certain
> usability advantages...
>
>
>> <defun>
>> <name>foo</name>
>> <body>
>> <quote>
>> <list>
>> <number>1</number>
> [snip...]
>> Is this correct? Is this better than s-expr? I don't think so.
>
> Under what context do you want me to decide if this is more
> appropriate than s-ex's? As a "computer professional," I can't render
> my opinion without context. If this were an interview, you would be
> justified in not hiring if I just gave an absolute opinion without
> getting a sense of context.
Oh well, I guess I wouldn't get the job.
The XML version is clearly inferior. Why?
First, there is no information content in the XML version that is
not present in the S-EXP version. (We are all assuming that there
is an unambiguous transformation available.)
Second, there is *shitload* of excess `phase space' in the XML
version. By `phase space' I'm making an analogy to the
configuration space or phase space of a physical system. Consider
the small fragment "<number>1</number>". This consists of eighteen
characters. If we have 96 standard characters, this string
represents a single point in an 96^18 element space. Now, by the
first assumption, the information content of the string is about 3
bits, so there are about 115 excess bits.
The extra bits do *nothing* to help `error correction': it would be
impossible to determine if <number>2</number> is a mistaken version
of <number>1</number>, and although you could correct
"<number>2</nubmer>", there is no useful information content there!
If you want error correction, there many ways to achieve that in
fewer than 115 excess bits per 3 bit chunk.
The end result is that for this fragment there are *two orders of
magnitude* of space inefficiency for no reason whatsoever. I might as
well be putting a single character on each disk block or in each
ethernet packet.
Joe Marshall <···@ccs.neu.edu> writes:
> ··········@yahoo.com (Tayss) writes:
>
> > BTW, if you really want to debate my point that XML has certain
> > usability advantages...
> >
> >
> >> <defun>
> >> <name>foo</name>
> >> <body>
> >> <quote>
> >> <list>
> >> <number>1</number>
> > [snip...]
> >> Is this correct? Is this better than s-expr? I don't think so.
> >
> > Under what context do you want me to decide if this is more
> > appropriate than s-ex's? As a "computer professional," I can't render
> > my opinion without context. If this were an interview, you would be
> > justified in not hiring if I just gave an absolute opinion without
> > getting a sense of context.
>
> Oh well, I guess I wouldn't get the job.
>
> The XML version is clearly inferior. Why?
>
> First, there is no information content in the XML version that is
> not present in the S-EXP version. (We are all assuming that there
> is an unambiguous transformation available.)
Not so. When Pascal generated the XML, he annotated it
with a lot more information than is present in the s-expression, such
as integrating the semantics of the defun into the synctactical
structure of the XML, and giving additional type information. I'd
suggest this is an equally valid, mostly idiomatic XML version:
<defun>foo<sep />'<sep /><list>1 2 3</list></defun>
(less idiomatic, but probably closer to the s-expression:
<list>defun<sep/>foo<sep/>'<sep/><list>1<sep/>2<sep/>3<sep/></list></list>
)
Sure, there is a tendency to get a lot more structured in XML, because
once you're using the mechanism, why not? There's no real
requirements, and most XML (that I've seen) in which humans are
reading and writing uses more convenient notation (unsurprisingly).
I mean, maybe there aren't many advantages of XML over S-expressions,
and vice-versa, since they're mostly isomorphic[0], but there's a lot
of strawman beating going on here.
[0] XML has some advantages of being an entire language, and thus
having a variety of conveniences that S-expressions lack.
For example, XML has the concept of processor instructions:
<?interpret semantics="common lisp" when="runtime" ?>
<defun>foo<sep/>'<sep /><list>1 2 3</list></defun> which provide a
straightforward way for out-of-band data to be transmitted to
applications.
XML has namespaces (or, at least, later later versions of XML do). One
effect of the namespaces is that if you read two XML fragments
'<x:f/>' and '<airlineReservation:f/>', you can make no pronouncements
regarding their equivalence unless you know the namespaces to which
the prefixes x and airlineReservation are bound.
S-expressions don't really get into that issue, I don't believe, since
they're just focusing with syntax, rather than objects. (Checking
McCarthy's paper first using S-expressions
http://www-formal.stanford.edu/jmc/recursive/node4.html it's not clear
to me what exactly is an s-expression, much less whether it's defined
on strings or objects ;-), so chalk up XML's standard reference, and
version numbers, as another advantage of XML ;-)
XML is defined over Unicode, with a clear, consistent, and concise way
to refer to any Unicode character (e.g., ¤, further enhanced by
the ability to declare entity references within a DTD).
Of course, S-expressions have the advantage of conciseness, and there
being full-fledged programming languages which can work with them
natively.
There may be things I'm overlooking, or I'm mistaken on, but so it
goes.
--
I'm awfully glad I'm a Beta, because I don't work so hard.
> Joe Marshall <···@ccs.neu.edu> writes:
>
>> First, there is no information content in the XML version that is
>> not present in the S-EXP version. (We are all assuming that there
>> is an unambiguous transformation available.)
Brian Palmer <·······@rescomp.Stanford.EDU> writes:
> Not so. When Pascal generated the XML, he annotated it
> with a lot more information than is present in the s-expression, such
> as integrating the semantics of the defun into the syntactical
> structure of the XML, and giving additional type information.
Unfortunately, then, Pascal has asked us to compare two different
notations using two non-equivalent objects. It is quite difficult
to do such a comparison.
> I mean, maybe there aren't many advantages of XML over S-expressions,
> and vice-versa, since they're mostly isomorphic[0], but there's a lot
> of strawman beating going on here.
>
> [0] XML has some advantages of being an entire language, and thus
> having a variety of conveniences that S-expressions lack.
Obviously we need to define some sort of common ground for comparison.
S-expressions are not a computer language, they are simply an input
syntax. XML is sort of both a computer language *and* an input syntax.
But we can factor this out. As S-Expressions may be the input syntax
to any number of computer languages (Lisp, Scheme, Cakewalk scripts,
etc.) so can we consider XML from a `syntax only' standpoint.
Your examples:
<defun>foo<sep />'<sep /><list>1 2 3</list></defun>
<list>defun<sep/>foo<sep/>'<sep/><list>1<sep/>2<sep/>3<sep/></list></list>
show that it is possible to make XML quite a bit less verbose than
Pascal's example, but that doesn't change my argument that XML is much
more verbose than S-exprs, and that the verbosity is detriment.
> there's a lot of strawman beating going on here.
Somebody find me a dead horse.
Brian Palmer wrote:
> Not so. When Pascal generated the XML, he annotated it
> with a lot more information than is present in the s-expression, such
> as integrating the semantics of the defun into the synctactical
> structure of the XML, and giving additional type information. I'd
> suggest this is an equally valid, mostly idiomatic XML version:
>
> <defun>foo<sep />'<sep /><list>1 2 3</list></defun>
Heck, why not go the whole way?
<expr>(defun foo () '(1 2 3))</expr>
There we go. XML is at most boundedly more verbose than
s-expressions. Hooray!
> XML has namespaces (or, at least, later later versions of XML do). One
> effect of the namespaces is that if you read two XML fragments
> '<x:f/>' and '<airlineReservation:f/>', you can make no pronouncements
> regarding their equivalence unless you know the namespaces to which
> the prefixes x and airlineReservation are bound.
Common Lisp s-expressions have packages. If you read
two s-expressions
(x:f) and (airline-reservation:f)
then you can make no pronouncements regarding their equivalence
unless you know the underlying package structure.
> XML is defined over Unicode, with a clear, consistent, and concise way
> to refer to any Unicode character (e.g., ¤, further enhanced by
> the ability to declare entity references within a DTD).
There are CL implementations that grok Unicode pretty well.
(In particular, that permit symbols and strings to contain
arbitrary characters from the Unicode character set.)
Doubtless XML has the edge over them in standardization,
though.
--
Gareth McCaughan
.sig under construc
Gareth McCaughan <················@pobox.com> writes:
> Brian Palmer wrote:
>
> > Not so. When Pascal generated the XML, he annotated it
> > with a lot more information than is present in the s-expression, such
> > as integrating the semantics of the defun into the synctactical
> > structure of the XML, and giving additional type information. I'd
> > suggest this is an equally valid, mostly idiomatic XML version:
> >
> > <defun>foo<sep />'<sep /><list>1 2 3</list></defun>
>
> Heck, why not go the whole way?
>
> <expr>(defun foo () '(1 2 3))</expr>
>
> There we go. XML is at most boundedly more verbose than
> s-expressions. Hooray!
Yay! :-)
> > XML has namespaces (or, at least, later later versions of XML do). One
> > effect of the namespaces is that if you read two XML fragments
> > '<x:f/>' and '<airlineReservation:f/>', you can make no pronouncements
> > regarding their equivalence unless you know the namespaces to which
> > the prefixes x and airlineReservation are bound.
>
> Common Lisp s-expressions have packages. If you read
> two s-expressions
>
> (x:f) and (airline-reservation:f)
>
> then you can make no pronouncements regarding their equivalence
> unless you know the underlying package structure.
Yep, I know. I had started to mention that (referencing the recent
thread about reading a list that contacts package references), but
then stopped because I don't think most discussion of using S
expressions as an 'on-the-wire', or configuration file, format talk
about Common Lisp specific features like packages. This goes both to
my point that I don't think S-expressions are as rigourously or as
richly standardized as XML. (Of course, things can be built atop of
S-expressions fairly easily; but there's a lot of advantages to having
had people nail the specification down to the ground).
It sort of seems like CSV (comma-separated value) formats; the basic
idea is simple, but some programs ignore blank lines, some have
special escape codes for commas in fields, some let you have comment
characters (with the comment character alternately being '#' and '%'),
and so on.
If, when people say S-expression, they actually mean that they want to
use Common Lisp from one end to the other, well that's a different
matter :-)
--
I'm awfully glad I'm a Beta, because I don't work so hard.
Brian Palmer <·······@rescomp.Stanford.EDU> writes:
> This goes both to my point that I don't think S-expressions are as
> rigourously or as richly standardized as XML.
http://theory.lcs.mit.edu/~rivest/sexp.txt
In article <··············@g.mccaughan.ntlworld.com>, Gareth McCaughan
<················@pobox.com> wrote:
> Brian Palmer wrote:
>
> > Not so. When Pascal generated the XML, he annotated it
> > with a lot more information than is present in the s-expression, such
> > as integrating the semantics of the defun into the synctactical
> > structure of the XML, and giving additional type information. I'd
> > suggest this is an equally valid, mostly idiomatic XML version:
> >
> > <defun>foo<sep />'<sep /><list>1 2 3</list></defun>
>
> Heck, why not go the whole way?
>
> <expr>(defun foo () '(1 2 3))</expr>
>
> There we go. XML is at most boundedly more verbose than
> s-expressions. Hooray!
It's not quite that simple:
<expr>(defun foo () '</expr>)</expr>
E.
··························@jpl.nasa.gov (Erann Gat) writes:> In article <··············@g.mccaughan.ntlworld.com>, Gareth McCaughan
> > Heck, why not go the whole way?
> >
> > <expr>(defun foo () '(1 2 3))</expr>
> >
> > There we go. XML is at most boundedly more verbose than
> > s-expressions. Hooray!
>
> It's not quite that simple:
>
> <expr>(defun foo () '</expr>)</expr>
CDATA helps here:
<expr><![CDATA[(defun foo () '</expr>)]]></expr>
and for (defun foo () ']]>) we can do:
<expr>(defun foo () ']]>)</expr>
For readability and reducing verbosity, try and use the straight string. If
there are XML control chars, then try CDATA. If CDATA's end pattern is there
and &-quote all XML control chars as necessary.
Someone mentioned compressing XML. XML is sort of supposed to be human
readable. In practice humans tend to look at XML data. If this is not a
consideration, then why bother with XML at all? Just use the most efficient to
maintain binary format.
Verbosity matters. It creates unnecessary processing, both in terms at runtime
and in terms of development effort.
The idea of XML's "universal understandability" is completely false. Any data
producer/consumer pair needs to speak the same "language", and XML does not
change that. It simply provides a standard way of encoding heirarchical
character data, so that you can use readily available tools for generating and
parsing it. This is a win of sorts, but XML's advantages are far overblown,
and quite often in practice makes things far more complicated and error prone
than they need to be.
I hate XML, but it is better than adhoc property files and binary formats. I
do wish though, that s-exps could take over the world.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
········@STRIPCAPStelus.net The Rhythm has my soul.
Brian Palmer wrote:
> Not so. When Pascal generated the XML, he annotated it
> with a lot more information than is present in the s-expression, such
> as integrating the semantics of the defun into the synctactical
> structure of the XML, and giving additional type information. I'd
> suggest this is an equally valid, mostly idiomatic XML version:
>
> <defun>foo<sep />'<sep /><list>1 2 3</list></defun>
>
> (less idiomatic, but probably closer to the s-expression:
> <list>defun<sep/>foo<sep/>'<sep/><list>1<sep/>2<sep/>3<sep/></list></list>
> )
These two are not equally valid. Someone has to decide whether the XML
expression <list>1 2 3</list> represents a list with three elements -
the numbers 1, 2 and 3 - or a list with one element - the string "1 2
3". In the general case, you need to be able to express both variants,
so you need to define tags that distinguish between them. That's what I did.
XML is not self-describing.
Pascal
Joe Marshall <···@ccs.neu.edu> wrote in message news:<············@ccs.neu.edu>...
> ··········@yahoo.com (Tayss) writes:
> > BTW, if you really want to debate my point that XML has certain
> > usability advantages...
>
> Oh well, I guess I wouldn't get the job.
Depends on your interviewer.
First, bring forward all my unanswered points about
lowest-common-denominator use, slowness and inadequacy of IDEs,
similarity to HTML, educational use, and Jef Raskin's critique. Also
bring forward the point that these formats are reasonably isomorphic,
mitigating many of any single one's disadvantages.
In fact, that should end all discussion right here until those points
are dealt with. I have taken very, very, very much care to say that
my position was only that "there exist advantages to XML." Not that
XML is better overall.
However, every-single-one of your counter arguments initially assumes
XML has no advantage. (Then from those assumptions you proceed to
argue a position that XML has no advantage...) Not only have you
refused to give a word about my previous points, but the mere fact of
giving new arguments does nothing to change the situation. If I
wanted to, I could concede all of your new arguments, because
certainly s-ex's can have advantages too without affecting my
position.
> The XML version is clearly inferior. Why?
>
> First, there is no information content in the XML version that is
> not present in the S-EXP version. (We are all assuming that there
> is an unambiguous transformation available.)
Then you're assuming we have this translation around? In this
scenario, do you have the enduser running the translation program so
she knows what this bag of parens means:
(defun foo () '(1 2 3))
(eq (foo) (foo))
Or is the translation in some big lisp book in the CS dept?
Maybe that is a form of compression. Like assigning 1 to "lambda h .
(lambda x . h(x x)) (lambda x . h(x x))"
> Second, there is *shitload* of excess `phase space' in the XML
> version. By `phase space' I'm making an analogy to the
> configuration space or phase space of a physical system. Consider
> the small fragment "<number>1</number>". This consists of eighteen
> characters. If we have 96 standard characters, this string
> represents a single point in an 96^18 element space. Now, by the
> first assumption, the information content of the string is about 3
> bits, so there are about 115 excess bits.
a) This is why we have compression. This mitigates many problems
depending on the context.
b) You've shown me a theoretical disadvantage, but no context. My GUI
system associates a heavyweight amount of data to each char it
displays -- a font. Usually I don't give a damn what the font is, so
it's "useless."
c) Look at any book on lisp. There's a lot of info in many books
telling you what all of the parts of the defun mean. Sometimes it
doesn't do a good job; it may be ambiguous or glib. Then you transfer
that information to your head and carry it around so you know what
those little parts mean. We deal with heavyweight information. All
this info takes much far more space on dead trees, plastics and glue
than they would on electronic media. With all the distribution
channels, planes, labor, etc included, we have no doubt passed the
point where it takes less natural resources not to keep things in our
heads.
> The extra bits do *nothing* to help `error correction': it would be
> impossible to determine if <number>2</number> is a mistaken version
> of <number>1</number>, and although you could correct
> "<number>2</nubmer>", there is no useful information content there!
> If you want error correction, there many ways to achieve that in
> fewer than 115 excess bits per 3 bit chunk.
Hmm, I mentioned that: "The checksummed binary s-ex format seemed
interesting, if you can't assume you'll get safety on a transport
level." Not every part of every format needs to "help" error
correction, unless that's its purpose in life.
Why not program in K, or some very compressed lisp? lambda could be
"l", car could be "a"... For most coding I'll probably need to
correct my compiler's output often to make sure it isn't too flabby.
There were actually times I've cared about the compiled size of my
Java code. I used obfuscators. Compression is in the
error-corrector's bag of tricks.
In fact, I take up entirely too much space in my emacs buffers and
filespace. Kill the middleman -- compile directly from mind to hex
editor. That'll show people who use purely interpreted languages.
It's not enough to transport obfuscated, compressed binary programs.
We need to show them we're serious!
Hmm, my desk has too much legroom...
> The end result is that for this fragment there are *two orders of
> magnitude* of space inefficiency for no reason whatsoever. I might as
> well be putting a single character on each disk block or in each
> ethernet packet.
Note my earlier point about isomorphisms: If you need the space,
which probably costs less than the toilet paper the average programmer
uses, then compress the sucker or store it in your favorite s-ex's.
That's right, we've hit the important point about isomorphisms -- they
insulate us from most problems that come from their representations.
··········@yahoo.com (Tayss) writes:
> Joe Marshall <···@ccs.neu.edu> wrote in message news:<············@ccs.neu.edu>...
>> ··········@yahoo.com (Tayss) writes:
>> > BTW, if you really want to debate my point that XML has certain
>> > usability advantages...
>>
>> Oh well, I guess I wouldn't get the job.
>
> Depends on your interviewer.
>
> However, every-single-one of your counter arguments initially assumes
> XML has no advantage. (Then from those assumptions you proceed to
> argue a position that XML has no advantage...) Not only have you
> refused to give a word about my previous points, but the mere fact of
> giving new arguments does nothing to change the situation. If I
> wanted to, I could concede all of your new arguments, because
> certainly s-ex's can have advantages too without affecting my
> position.
I wasn't responding to the earlier posts. I was simply responding to
your post that the XML version that Pascal posted wasn't clearly
inferior to the S-exp version. I think the XML version is.
There are some good reasons to use XML: the primary one is that you
may wish to interface to a product that uses XML as an API. XML is
clearly superior to s-exprs in this case because s-exprs simply
won't work.
>> The XML version is clearly inferior. Why?
>>
>> First, there is no information content in the XML version that is
>> not present in the S-EXP version. (We are all assuming that there
>> is an unambiguous transformation available.)
>
> Then you're assuming we have this translation around? In this
> scenario, do you have the enduser running the translation program so
> she knows what this bag of parens means:
> (defun foo () '(1 2 3))
> (eq (foo) (foo))
>
> Or is the translation in some big lisp book in the CS dept?
>
> Maybe that is a form of compression. Like assigning 1 to "lambda h .
> (lambda x . h(x x)) (lambda x . h(x x))"
If we *don't* assume some sort of isomorphism between the two
expressions, then there is no way to compare them. In the absence
of a stated translation, I assumed the `obvious' one. Mea maxima culpa.
>> Second, there is *shitload* of excess `phase space' in the XML
>> version. By `phase space' I'm making an analogy to the
>> configuration space or phase space of a physical system. Consider
>> the small fragment "<number>1</number>". This consists of eighteen
>> characters. If we have 96 standard characters, this string
>> represents a single point in an 96^18 element space. Now, by the
>> first assumption, the information content of the string is about 3
>> bits, so there are about 115 excess bits.
>
> a) This is why we have compression. This mitigates many problems
> depending on the context.
Er, yes. Wearing a thick helmet will mitigate many of the problems
that come from hitting yourself on the head with a hammer.
> b) You've shown me a theoretical disadvantage, but no context. My GUI
> system associates a heavyweight amount of data to each char it
> displays -- a font. Usually I don't give a damn what the font is, so
> it's "useless."
The information specifying the font probably is useless. It's not
that heavy, either: a filename. The information specifying the *glyph*
is pretty heavyweight, but I bet you'd really like your glyphs to be
easily distinguishable upon sight.
> Why not program in K, or some very compressed lisp? lambda could be
> "l", car could be "a"... For most coding I'll probably need to
> correct my compiler's output often to make sure it isn't too flabby.
It's a tradeoff. As in natural language, common forms get abbreviated
and uncommon ones stay long. We could program in bits, but as you
stated, people don't think in bits. I am of the opinion that XML is
*way* too far on the verbose side. In the example of <number>3</number>,
there is just *way* too much excess crap. I might complain a tad if
I had to enter numbers as #3 or $3$ or 3.0, but this is much closer
to a reasonable balance between readability and conciseness.
> Note my earlier point about isomorphisms: If you need the space,
> which probably costs less than the toilet paper the average programmer
> uses, then compress the sucker or store it in your favorite s-ex's.
> That's right, we've hit the important point about isomorphisms -- they
> insulate us from most problems that come from their representations.
Here is a repost of an article by Jonathan Shapiro.
It basically renders the whole conversation moot. (Actually, it
contradicts me: it says, in XML, something that I have been
failing to say more concisely in prose. Oh well.)
---------------------------------------
Jonathan Shapiro writes:
This is purely for your amusement, and not an attempt at anything serious.
If you do not have a strong stomach, do not read on. The idea came up in a
discussion with David Braun, and I couldn't resist giving it a try.
The enclosed XSLT transformer will take an arbitrary well-formed XML input
document and turn it into an arbitrary (if ugly, but its a quick hack)
lisp-style list that can be processed using modern processing tools, such as
any scheme implementation after about 1974. Given this initial
transformation, all of the current processing tools provided by W3C can be
implemented by a better than average undergraduate in roughly one (caffeine
assisted) weekend. Proof of this assertion is left as an exercise for the
student.
It's been a long time since I programmed in scheme, so it's conceivable that
I missed some necessary escaping -- like the XML ':' namespace separator,
which has significance in scheme atoms.
Since entities in the XML input are clobbered by the time the transformer
gets them, there is little you can do about those, but if you know the set
of entities in advance you can modify the transformer to turn them into
elements using an inline doctype subset and thus capture them. For entities
undefined (due to non-inclusion of the DTD) a straightforward further string
transformation hack could be used to extract them as lisp forms.
shap
<?xml version="1.0" encoding="UTF-8"?>
<!--
Transformer from the test.dtd input to well-formed HTML..
-->
<!DOCTYPE xsl:stylesheet [
<!ENTITY nbsp " ">
]>
<xsl:stylesheet
version ="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns="http://www.w3.org/TR/REC-html40">
<xsl:output method="text" indent="yes"/>
<!-- The cure for XML in one transform: -->
<xsl:template match="/">
<xsl:text>'(</xsl:text>
<xsl:apply-templates/>
<xsl:text>)</xsl:text>
</xsl:template>
<xsl:template match="*">
<xsl:text>(elem </xsl:text>
<xsl:value-of select="name()"/>
<xsl:text> </xsl:text>
<xsl:apply-templates ········@*"/>
<xsl:apply-templates/>
<xsl:text>)</xsl:text>
</xsl:template>
<xsl:template ·······@*">
<xsl:text>(attr </xsl:text>
<xsl:value-of select="name()"/>
<xsl:text> </xsl:text>
<xsl:apply-templates/>
<xsl:text>)</xsl:text>
</xsl:template>
<!-- Following piece of incredible ugliness outputs an XML text node
as a quoted scheme string -->
<xsl:template match="text()" priority="2">
<xsl:text>(text "</xsl:text>
<xsl:call-template name="quote-the-text">
<xsl:with-param name="text" select="."/>
</xsl:call-template>
<xsl:text>")</xsl:text>
</xsl:template>
<xsl:template match="text()" name="quote-the-text">
<xsl:variable name="dquote" value='"'/>
<xsl:param name="text" select="."/>
<xsl:choose>
<!-- First need to escape embedded backslash characters, as
these are the scheme escape character -->
<xsl:when test="contains($text, '\')">
<!-- recurse on the first part to process the " characters too -->
<xsl:call-template name="quote-the-text">
<xsl:with-param name="string" select="substring-before($text,
'\')"/>
</xsl:call-template>
<!-- output escaped backslash character -->
<xsl:text>\\</xsl:text>
<!-- recurse on the second part -->
<xsl:call-template name="quote-the-text">
<xsl:with-param name="string" select="substring-after($text,
'\')"/>
</xsl:call-template>
</xsl:when>
<!-- If text contains the " character, escape it with a backslash.
Note that if the text makes it this far into the choose, we
know that it does not contain a \ character, and we need not
recursively process it for one. -->
<xsl:when test="contains($text, '$dquote')">
<!-- output the part up to the quote character -->
<xsl:value-of select="substring-before($text, '$dquote')" />
<!-- output escaped quote character -->
<xsl:text>\"</xsl:text>
<xsl:call-template name="quote-the-text">
<xsl:with-param name="string" select="substring-after($text,
'$dquote')"/>
</xsl:call-template>
</xsl:when>
<xsl:otherwise>
<xsl:value-of select="." />
</xsl:otherwise>
</xsl:choose>
</xsl:template>
</xsl:stylesheet>
Tayss wrote:
> First, bring forward all my unanswered points about
> lowest-common-denominator use, slowness and inadequacy of IDEs,
> similarity to HTML, educational use, and Jef Raskin's critique. Also
> bring forward the point that these formats are reasonably isomorphic,
> mitigating many of any single one's disadvantages.
>
> In fact, that should end all discussion right here until those points
> are dealt with. I have taken very, very, very much care to say that
> my position was only that "there exist advantages to XML." Not that
> XML is better overall.
You haven't stated the "mitigating" part before (or I haven't recognized
it ;).
The fact that the formats are isomorphic (and, as I said before, XML is
in fact underspecified) doesn't tell you anything about advantages.
That's similar to the statement about Turing-complete programming
languages. The fact that a programming language is Turing-complete
doesn't say anything about its suitability for programming.
It's about convenience, not about completeness!
Pascal
Tayss wrote:
>>BTw, I don't think any experienced Lisp programmer has problems with
>>making small changes to Lisp source code with only notepad at hand.
>
>
> I feel my points were ignored about mainstream usability.
> "Experienced Lisp programmers" are in a totally different league of
> computer literacy than other computer users.
You have made the point that it is easier to make localized changes to
XML files. I don't think that that's the case. Someone who is used to
Lisp won't have any difficulties with making localized changes to s-expr
files and at the same time, any inexperienced user will have problems
with XML files. This is what I have meant.
Of course, this is only a conjecture - I haven't checked this. I simply
don't believe that the designers of XML made serious usability studies
beforehand. So the folklore that XML is easily accessible for
inexperienced users is also just a conjecture.
There are some interesting papers in the "psychology of programming"
community about problems of non-programmers with programming languages -
you will probably be very surprised where the real issues are. (and
s-expressions don't look too bad in that light...)
Pascal
Pascal Costanza <········@web.de> wrote in message news:<············@newsreader2.netcologne.de>...
> Of course, this is only a conjecture - I haven't checked this. I simply
> don't believe that the designers of XML made serious usability studies
> beforehand. So the folklore that XML is easily accessible for
> inexperienced users is also just a conjecture.
[...]
> There are some interesting papers in the "psychology of programming"
> community about problems of non-programmers with programming languages -
> you will probably be very surprised where the real issues are. (and
> s-expressions don't look too bad in that light...)
Hmm, points taken. Maybe I am thinking that s-ex's will be formatted
in the lisp style, but newbies often prefer indenting end-parens like
C does with end-braces. And it really enforces a tree when all the
parens are there...
Tayss wrote:
> Pascal Costanza <········@web.de> wrote in message news:<············@newsreader2.netcologne.de>...
>
>>Of course, this is only a conjecture - I haven't checked this. I simply
>>don't believe that the designers of XML made serious usability studies
>>beforehand. So the folklore that XML is easily accessible for
>>inexperienced users is also just a conjecture.
>
> [...]
>
>>There are some interesting papers in the "psychology of programming"
>>community about problems of non-programmers with programming languages -
>>you will probably be very surprised where the real issues are. (and
>>s-expressions don't look too bad in that light...)
>
>
> Hmm, points taken. Maybe I am thinking that s-ex's will be formatted
> in the lisp style, but newbies often prefer indenting end-parens like
> C does with end-braces. And it really enforces a tree when all the
> parens are there...
...but I think that this relies mainly on what you have seen first as a
newbie. If newbies start with an s-expr based language they will find it
more natural than the other style.
See for example http://www.teach-scheme.org/ - especially
http://home.adelphi.edu/sbloch/class/hs/testimonials/ and
http://home.adelphi.edu/sbloch/papers/sjfy/
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
[You have asked to go into details. Here we go.]
Tayss wrote:
> Pascal Costanza <········@web.de> wrote in message news:<············@newsreader2.netcologne.de>...
>
>>Tayss wrote:
>>
>>>But also, if I had only Windows notepad to edit small bits of text,
>>>which would I prefer it in: XML or s-ex's? Generally I'd prefer XML.
>>
>>This is pure rhetorics, isn't it? I mean, we don't live in a world in
>>which we only have notepad at our disposal...
>
>
> What is XML? It's a mainstream format. Therefore it is aimed at the
> lowest common denominator.
What do you mean by "lcd"? XML is underspecified, so in a sense lower
than the lowest common denominator. Why didn't they provide distinctions
between some of the standard types (numbers, strings, and so on)? That's
not rocket science!
What's the content of the following XML element?
<tag>cafebabe</tag>
> I've seen teamleader-type programmers open up XML docs using Windows
> notepad. Why? Using an IDE, you have to navigate the filesystem in a
> little box that isn't as deeply engineered as the OS shell; or you
> have to bind the app to open files of your type (or use a right-click
> menu) and wait a couple seconds for his favorite heavy-duty IDE to
> open your file.
I have seen IDEs that have better engineered file selection boxes. Most
IDEs just reuse the ones that come with the OS.
Some IDEs have a fast startup time.
> On my 1.8 ghz machine, emacs still takes a sec or two to start up.
You don't want to say that you are worried about two seconds, do you?
> Notepad is instant gratification and therefore gives the user a
> feeling of control.
...unless the file is bigger than 64 kBytes. ;)
> Further, one large goal is for every HTML document to be a conforming
> XML document. People still like using notepad to quickly edit web
> pages.
Check out LML and the likes. You might want to use them.
> Finally, note Jef Raskin's assertion that IDEs haven't evolved
> usability-wise:
> http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=22
I don't understand this argument. Just because IDEs aren't perfect we
should use notepad? I don't really think this is what you mean. What do
you mean here?
>>And even if this were the case, XML wouldn't be the only alternative,
>>let alone the best.
>
> And they all seem reasonably isomorphic. But I'm not arguing this.
> His assertion was there are no advantages of XML over s-ex's. My
> counterassertion is that there exist advantages. I will not attempt
> to shift to a weaker position since I personally prefer s-ex's. The
> checksummed binary s-ex format seemed interesting, if you can't assume
> you'll get safety on a transport level.
The only advantage I see for XML is that everyone is using it. This can
change pretty quickly, especially because XML doesn't provide any
technical advantages.
In this regarg XML is even worse than Java...
Pascal
Pascal Costanza <········@web.de> wrote in message news:<············@newsreader2.netcologne.de>...
> I have seen IDEs that have better engineered file selection boxes.
Could you give an example? I'd like to study an IDE that is so
careful; I suspect it's one of those Smalltalk or LispM deals.
I have never seen an Open dialogbox quite as comfortable as the
Windows GUI shell. Yes, I'm bringing up more ugly technologies. For
all its ugliness, Microsoft threw a huge amount of usability testing
at Windows, and even the MacOS X machine I maintained until Feb was
arguably less usable overall. Emacs may have dir caching and other
nifty things, but so does Windows in its own way.
>Most IDEs just reuse the ones that come with the OS.
This is not a great thing. I don't usually wish Apple/Microsoft
dumped the desktop metaphor for an Open-dialogbox one.
> Some IDEs have a fast startup time.
It can work if they stayed in memory like Word/OpenOffice can. I
haven't seen an IDE do it yet, though there has to be at least one.
Eclipse perhaps? (Oftentimes MacOS does this for free, since if you
close a document, you don't really close the app. But I suspect the
document-centric worldview has its own problems.)
> > On my 1.8 ghz machine, emacs still takes a sec or two to start up.
>
> You don't want to say that you are worried about two seconds, do you?
For an old program like Emacs, yeah. How long would it take other
envs to start up? Dr. Scheme feels like forever, and it's one of my
favorite IDEs.
The Human Interface Guidelines for platforms tend to beg you not to
let GUI interactions take more than some small fraction of a second,
lest the user feel the app and maybe the entire platform sluggish.
Consider a typical overworked user. "Hmm, my fancy iEdit takes 10
seconds to start up. Sluggish; I just need to write a couple simple
html pages pronto with notepad. It's not just the startup time, but
it stutters for a couple more seconds when I just wanna pop up a quick
search/replace dialog. Did I just pay $2000 for this notebook to
encourage bloatware???"
This is the same reason Swing and the stable NT 3.5 both failed.
(It's not because of bad programmers; it's not like programmers
grautitously blocked up the EventQueue or ignored JGoodies just to be
jerks to Sun.)
This does not only hold true for computers. Good waiters learn this
too; one minute can turn into ten for customers. (Incidentally, I
highly recommend Michael Ruhlman's _Making of a Chef_. I think it
contains a lot that applies to user experience and even the life of a
developer.)
> > Finally, note Jef Raskin's assertion that IDEs haven't evolved
> > usability-wise:
> > http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=22
>
> I don't understand this argument. Just because IDEs aren't perfect we
> should use notepad? I don't really think this is what you mean. What do
> you mean here?
I don't use notepad. Many people do though, that I've observed.
This point feeds into the other issues.
a) IDEs are like the shoes for the cobbler's children (worse than the
customers' shoes) -- programmers are expected to work around problems,
unlike endusers. This is why a company's inhouse apps are usually
buggier than released shrinkwrap apps. You can tell a coworker to
avoid bugs, which you really can't with a customer. When you need to
allocate resources to produce software, often you let experienced
users carry a bigger burden. Unfortunately, that means enduser
(non-IDE) apps can be initially more pleasant to use. And most
programmers don't want to delve deep into their IDE or technologies.
b) IDEs occasionally impose their worldview on users. JBuilder used
to do it; I hear the same about Eclipse. They want users to adopt
certain oversimplified abstractions that get in the way and feel like
more bloat.
c) The "it's fine if you use an IDE" argument makes an immediate
dependency on some program outside your spec's control. So the
effects of rough IDEs are magnified onto the whole experience of using
s-ex's.
> The only advantage I see for XML is that everyone is using it. This can
> change pretty quickly, especially because XML doesn't provide any
> technical advantages.
I think so too. All these formerly obscure things like lisp are
increasingly mounting in popularity. I wish a company like Franz
hinted at trends in their markets. If they did, I'm sure that would
encourage people to write more Lisp apps and deepen their platform.
> In this regarg XML is even worse than Java...
Agreed. I guess my position is this: I don't care. I don't like
programming in Java, but I like the fact it popularized things like
using an interpreter for security, experimenting with a bazaar model
for certain things, officially sanctioned tools that recognize doc
strings, etc... And as long as I don't ever have to write in pure
Java or XSLT or other monstrous things, I'm content with their
positive influence on the programming community. I'm actually a fan
of different views on the same thing.
I'm sure many teachers have had this experience... Take a smart, say,
mathematician who occasionally programs and thinks witty C/Java
optimization tricks are "elegant." Then he uses Python, feeling it's
not real programming but it's certainly easy. He's building up his
basic repertoire and IMs you about helping with generalized
composition -- applying multiple functions together. Well, that's the
easiest thing in the world for a lisp programmer. Keep on going,
eventually he's a lisp programmer in drag. The conceptual leap is
almost zero, and something like a CL-Emacs will tip him over easily.
This precise scenario is happening with a friend.
> > Notepad is instant gratification and therefore gives the user a
> > feeling of control.
>
> ...unless the file is bigger than 64 kBytes. ;)
Yeah, I guess it's hard for me to call notepad "gratification" with a
straight face...
Tayss wrote:
> Pascal Costanza <········@web.de> wrote in message news:<············@newsreader2.netcologne.de>...
>
>>I have seen IDEs that have better engineered file selection boxes.
>
>
> Could you give an example? I'd like to study an IDE that is so
> careful; I suspect it's one of those Smalltalk or LispM deals.
I haven't checked this recently. I recall using an IDE on an Atari ST
whose file selection box was better than anything the system provided. I
don't remember the details though. (and I haven't recognized any serious
advances in GUI design since then - everything has gotten a little bit
more flashy and colorful, but that's it except for minor advances)
The Oberon System is another very productive environment. It
successfully blurred the boundaries between OS, IDE and user
environment. It probably borrowed a lot from Lisp Machines and Smalltalk
environments, but I hadn't discovered such dynamic languages yet at that
time.
If you are only interested in IDEs that run on currently popular
operating systems then I am sorry that I can't help you. I think this
would already be a far too narrow view.
> I have never seen an Open dialogbox quite as comfortable as the
> Windows GUI shell. Yes, I'm bringing up more ugly technologies. For
> all its ugliness, Microsoft threw a huge amount of usability testing
> at Windows, and even the MacOS X machine I maintained until Feb was
> arguably less usable overall.
It's true that Mac OS X has some quirks here and there, but overall I
highly prefer it over Windows.
> Emacs may have dir caching and other
> nifty things, but so does Windows in its own way.
I don't know too much about Emacs - I have only recently started using
it and haven't yet familiarized with it enough.
>>Most IDEs just reuse the ones that come with the OS.
>
>
> This is not a great thing. I don't usually wish Apple/Microsoft
> dumped the desktop metaphor for an Open-dialogbox one.
>
>
>
>>Some IDEs have a fast startup time.
>
>
> It can work if they stayed in memory like Word/OpenOffice can. I
> haven't seen an IDE do it yet, though there has to be at least one.
> Eclipse perhaps? (Oftentimes MacOS does this for free, since if you
> close a document, you don't really close the app. But I suspect the
> document-centric worldview has its own problems.)
I have read in a tutorial about Emacs that it's a good idea to start it
up when logging into the computer and then leave it open for the rest of
the session. This seems to work quite well.
I also tend to keep my MCL environment running when working on something
bigger that takes a few days. This seems to be a widely employed
practice among Lispniks. I can sense that you keep you IDE up longer the
more you get experienced with Lisp. It takes a little getting used to to
make the switch from thinking about editing source code towards shaping
a Lisp image.
>>>On my 1.8 ghz machine, emacs still takes a sec or two to start up.
>>
>>You don't want to say that you are worried about two seconds, do you?
>
>
> For an old program like Emacs, yeah. How long would it take other
> envs to start up? Dr. Scheme feels like forever, and it's one of my
> favorite IDEs.
Hmm, this doesn't seem to cover my objection. If you said that it takes
2 minutes then I would understand your worries. But I don't understand
how even 10 - 15 seconds would be a big deal. Are you really in such a
hurry? ;)
> The Human Interface Guidelines for platforms tend to beg you not to
> let GUI interactions take more than some small fraction of a second,
> lest the user feel the app and maybe the entire platform sluggish.
'>
> Consider a typical overworked user. "Hmm, my fancy iEdit takes 10
> seconds to start up. Sluggish; I just need to write a couple simple
> html pages pronto with notepad. It's not just the startup time, but
> it stutters for a couple more seconds when I just wanna pop up a quick
> search/replace dialog. Did I just pay $2000 for this notebook to
> encourage bloatware???"
>
> This is the same reason Swing and the stable NT 3.5 both failed.
> (It's not because of bad programmers; it's not like programmers
> grautitously blocked up the EventQueue or ignored JGoodies just to be
> jerks to Sun.)
I think one should distinguish between startup time and general
sluggishness.
> This does not only hold true for computers. Good waiters learn this
> too; one minute can turn into ten for customers. (Incidentally, I
> highly recommend Michael Ruhlman's _Making of a Chef_. I think it
> contains a lot that applies to user experience and even the life of a
> developer.)
>
>
>>>Finally, note Jef Raskin's assertion that IDEs haven't evolved
>>>usability-wise:
>>>http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=22
>>
>>I don't understand this argument. Just because IDEs aren't perfect we
>>should use notepad? I don't really think this is what you mean. What do
>>you mean here?
>
>
> I don't use notepad. Many people do though, that I've observed.
>
> This point feeds into the other issues.
>
> a) IDEs are like the shoes for the cobbler's children (worse than the
> customers' shoes) -- programmers are expected to work around problems,
> unlike endusers. This is why a company's inhouse apps are usually
> buggier than released shrinkwrap apps. You can tell a coworker to
> avoid bugs, which you really can't with a customer. When you need to
> allocate resources to produce software, often you let experienced
> users carry a bigger burden. Unfortunately, that means enduser
> (non-IDE) apps can be initially more pleasant to use. And most
> programmers don't want to delve deep into their IDE or technologies.
>
> b) IDEs occasionally impose their worldview on users. JBuilder used
> to do it; I hear the same about Eclipse. They want users to adopt
> certain oversimplified abstractions that get in the way and feel like
> more bloat.
Incidentally, I don't like JBuilder nor Eclipse. ;)
> c) The "it's fine if you use an IDE" argument makes an immediate
> dependency on some program outside your spec's control. So the
> effects of rough IDEs are magnified onto the whole experience of using
> s-ex's.
I surely don't want to suggest that _any_ IDE is better than notepad. I
only say that there are IDEs that are better.
As soon as you use a suitable editor, XML loses its advantages.
So it seems to me that your position can be summarized like this: for
someone who doesn't want to invest _anything_ to make his working
environment more productive, XML provides some advantages.
I don't know whether this is a valid argument, but it sounds somewhat
circular to me.
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
Pascal Costanza <········@web.de> writes:
> I have read in a tutorial about Emacs that it's a good idea to start
> it up when logging into the computer and then leave it open for the
> rest of the session. This seems to work quite well.
In the last 18 months, I have booted the desktop I use at work four
(4) times. Twice, because I had to power it down to move to a new
office. Once after a power cut. Once because I was given a new, more
powerful, machine.
I believe that in that time, I have started Emacs on the desktop I use
at work 6 times[*]; once after each boot, and on two other occasions
after Emacs was killed by some catastrophe which did not crash my machine.
Don't be mislead into thinking that I don't use Emacs much; I use it
for almost everything, including writing and posting this article.
The ratio of Emacs' startup time, to the time I actually use it is
almost certainly much lower than for any other program.
> >>> On my 1.8 ghz machine, emacs still takes a sec or two to start up.
That's a lot faster than GNU/Linux.
Out of all the operating systems I use, Emacs has by far the fastest
start-up time :-)
[*] To be perfectly honest, sometimes I start a second Emacs process,
when I want to try something out in a fresh Emacs environment, so
the number is actualy greater than 6. Such sessions, however, are
always very short lived, and do not form part of my actual _usage_
of Emacs.
··········@yahoo.com (Tayss) writes:
> ·········@rcn.com (Jon S. Anthony) wrote in message news:<··············@rigel.goldenthreadtech.com>...
> > Wrong. If you have multiple <quote> or whatever tags, you can't tell
> > anything without a smart editor. In this case XML is the _worst_ of
> > all possible worlds. You have all this heavy <....> tag crap but it
> > doesn't go the extra mile and require the tags to be labeled and so
> > it's all for nothing.
>
> If not for XML, some things about s-ex's would have eluded me. For
> example, should nodes and attributes share the same namespace?
That says more about you than either XML or S-Exps.
> But also, if I had only Windows notepad to edit small bits of text,
> which would I prefer it in: XML or s-ex's? Generally I'd prefer XML.
Do you actually think this has any bearing on whether XML makes any
sense???
> When people argue that one just needs a decent IDE for s-ex's, does
> that actually imply XML just doesn't have great IDE support yet? I
> should neither need to think about closing tags nor close-parens.
And what possible relevance is this? For crying out loud, the point
made was simply that XML tags don't provide _any_ value without some
automated support. Hence, in this respect they have _nothing_ over
s-exps. It's all the other idiocies of XML that make it a total loser
wrt s-exps.
/Jon
·········@rcn.com (Jon S. Anthony) wrote in message news:<··············@rigel.goldenthreadtech.com>...
> It's all the other idiocies of XML that make it a total loser
> wrt s-exps.
You have an interesting definition of "loser"...
It interests me when something good fails. I do not think I like to
fail. So part of my subconscious mind pores over it. What excuse
does something, gifted with every possible advantage, have for
failure?
If it's "politics," well that is certainly a common excuse.
··········@yahoo.com (Tayss) writes:
> ·········@rcn.com (Jon S. Anthony) wrote in message news:<··············@rigel.goldenthreadtech.com>...
> > It's all the other idiocies of XML that make it a total loser
> > wrt s-exps.
>
> You have an interesting definition of "loser"...
Say that again in another 45 years.
(Just FYI, s-expressions were predate Lisp qua computer language. And
they'll surely outlive it:
(lambda (x)
(lambda (y)
(lambda (z)
(x (+ x ((ypsilon (z) z) z))))))
AFAIK, ypsilon isn't used as a binding letter (yet?), but it could be.
Compare the equivalent lambda-calculus-inspired notation.)
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
·········@gmx.net (thelifter) writes:
> Can anyone give a simple example where you do some computational task
> with Lisp that would be much harder to do with Scheme so that the
> advantage of Lisp becomes more apparent?
Can someone give an example of a driving task that is much harder to do
with an American car than a Japanese or German car? Yet some people
strongly prefer one to the other, and not just for reasons of national
pride. There are material design details that really matter to people
even though if you examine any one of them in isolation someone will
always make some plausible argument about why they are really equivalent.
The same is true about wine and beer choices, or even coke vs pepsi.
The reason I say this is that there is an apparent subtext of the question
quoted here which is "If no one does, I'm going to conclude that this
doesn't matter as much as people say and that they're just making it up."
You came close to doing that that earlier in the same post by saying:
> The [equality of literals] example is good, but it doesn't SEEM to be
> practically relevant. I'm not saying it isn't.
The "I'm not saying it isn't." seems to be more a disclaimer in case you're
wrong than a legitimate statement of your feelings, which I worry is that
you're dismissing the issue.
The thing that makes the issue practically relevant is that it occurs
"in the large". Someone has cited a small example so it's easy to talk
about, not because the same issue doesn't happen in larger contexts.
It's just harder to describe because it involves really a lot of code.
I started to sketch an example but even the sketch quickly became
bigger than I had the time or patience to set up. Sigh.
I'm not saying this is the only difference between Scheme and Lisp,
nor even The criterial one, but I think it's an important one.
And that saying "oh, there's a mapping" misses the point. In fact,
it weirds me out given how much more "mathematical" the Scheme community
seems to be than the Lisp community (preferring "formal semantics" and
all kinds of otehr stuff like that with greek symbols all over) that
people will use a term like mapping without the important modifiers
"many to one" or "one to many" and be willing therefore to hide the
loss of information that occurs in that mapping, and the significance
of making compilation be based on objectness. Hygienic macro systems
notwithstanding, the meaning of (eval `(eql 'foo ',(copy-symbol 'foo)))
in scheme, that is, the meaning of using a gensym in code, is not
well-defined. That seems significant to me linguistically in a language
that purports to be [original meaning] object-oriented, that is, about
objects (rather than program texts).
Kent M Pitman wrote:
>
> The thing that makes the issue practically relevant is that it occurs
> "in the large". Someone has cited a small example so it's easy to talk
> about, not because the same issue doesn't happen in larger contexts.
> It's just harder to describe because it involves really a lot of code.
> I started to sketch an example but even the sketch quickly became
> bigger than I had the time or patience to set up. Sigh.
That is why I posted my larger URI example. It involves using
packages - I did not have to worry about name conflicts
special variables - for parsing context
macros - compactified the code by creating a mini language
clos - creating a uri type
conditions - to signal parsing errors
property lists - used in the grunt parsing work
Alone the power of each is not obvious, but used together,
in real coding situations, there is no standard analog in Scheme.
It would just be more difficult. Even renaming each function in the
pseudo and uri packages would take more thought and effort in
(Standard) Scheme to accomplish.
Erann's defmacro example is analogous to this macro in the
pseudo package, same problem and less contrived.
(defmacro ~match~ (exp)
(etypecase exp
(character
`(when (and (< ~index~ ~end~) (funcall ~char-test~ (char ~string~ ~index~) ,exp))
(prog1 t (incf ~index~))))
(string
`(when (and (< ~index~ ~end~)
(<= ,(length exp) (- ~end~ ~index~))
(funcall ~string-test~ ~string~ ,exp :start1 ~index~ :end1 (+ ~index~
,(length exp))))
(prog1 t (incf ~index~ ,(length exp)))))
(cons
(case (first exp)
(quote
(assert (and (= (length exp) 2) (and (symbolp (second exp)) (not (keywordp exp))))
(exp) "~~MATCH~~ will only accept quoted symbols, not ~A" exp)
`(when (and (< ~index~ ~end~) (funcall ,exp (char ~string~ ~index~)))
(prog1 t (incf ~index~))))
((or function lambda)
`(when (and (< ~index~ ~end~) (funcall ,exp (char ~string~ ~index~)))
(prog1 t (incf ~index~))))
(type
`(when (and (< ~index~ ~end~) (typep (char ~string~ ~index~) ,(second exp)))
(prog1 t (incf ~index~) t)))
(one-of
`(or ,@(loop for match in (rest exp)
collect `(~match~ ,match))))
(member
`(when (and (< ~index~ ~end~) (find (char ~string~ ~index~)
,(second exp) :test ~char-test~))
(prog1 t (incf ~index~))))))))
Wade
Kent M Pitman wrote:
> In fact, it weirds me out given how much more "mathematical" the
> Scheme community seems to be than the Lisp community (preferring
> "formal semantics" and all kinds of otehr stuff like that with greek
> symbols all over)
Kent, you are really scraping the bottom of the barrel.
Anton
"Anton van Straaten" <·····@appsolutions.com> writes:
> Kent M Pitman wrote:
> > In fact, it weirds me out given how much more "mathematical" the
> > Scheme community seems to be than the Lisp community (preferring
> > "formal semantics" and all kinds of otehr stuff like that with greek
> > symbols all over)
>
> Kent, you are really scraping the bottom of the barrel.
Perhaps for descriptive prose, but I think my point in general is true.
If someone disagrees, I'd be curious. It seems to me like people who
self-identify as mathemeticians tend toward Scheme and people who
self-identify as engineers or practioners of some applied science
tend toward CL, for exactly the same reasons that Scheme has a stronger
bias toward aesthetics in design and CL has a stronger bias toward
practicality in design. I certainly have no concrete data on this, but
I've observed a lot of personal preferences over the years and haven't
heard too many complaints from people I have steered one way or another
in a triage setting where they were seeking to learn one or the other
language and I used this criterion. I'm open to claims that this is not
the nature of the partition, but I'd be curious along with this to hear
what the nature of the partition is... since that's what the thread
topic is, after all.
Kent M Pitman <······@world.std.com> wrote in message news:<···············@shell01.TheWorld.com>...
> It seems to me like people who
> self-identify as mathemeticians tend toward Scheme and people who
> self-identify as engineers or practioners of some applied science
> tend toward CL, for exactly the same reasons that Scheme has a stronger
> bias toward aesthetics in design and CL has a stronger bias toward
> practicality in design. I certainly have no concrete data on this, but
> I've observed a lot of personal preferences over the years and haven't
> heard too many complaints from people I have steered one way or another
> in a triage setting where they were seeking to learn one or the other
> language and I used this criterion. I'm open to claims that this is not
> the nature of the partition, but I'd be curious along with this to hear
> what the nature of the partition is... since that's what the thread
> topic is, after all.
I think roughly the difference in preferences described above is
plausible, but there are certainly also people who prefer scheme for
*practical* reasons. From my newbie perspective, some of those are
that it is smaller, has many more implementations (most of them free)
and I have the impression that is generally more suitable as a
lightweight scripting language.
--
Grzegorz
On 19 Sep 2003 18:00:14 -0700, ········@pithekos.net (Grzegorz
Chrupala) wrote:
>Kent M Pitman <······@world.std.com> wrote in message news:<···············@shell01.TheWorld.com>...
>> It seems to me like people who
>> self-identify as mathemeticians tend toward Scheme and people who
>> self-identify as engineers or practioners of some applied science
>> tend toward CL, for exactly the same reasons that Scheme has a stronger
>> bias toward aesthetics in design and CL has a stronger bias toward
>> practicality in design. I certainly have no concrete data on this, but
>> I've observed a lot of personal preferences over the years and haven't
>> heard too many complaints from people I have steered one way or another
>> in a triage setting where they were seeking to learn one or the other
>> language and I used this criterion. I'm open to claims that this is not
>> the nature of the partition, but I'd be curious along with this to hear
>> what the nature of the partition is... since that's what the thread
>> topic is, after all.
>
>I think roughly the difference in preferences described above is
>plausible, but there are certainly also people who prefer scheme for
>*practical* reasons. From my newbie perspective, some of those are
>that it is smaller, has many more implementations (most of them free)
>and I have the impression that is generally more suitable as a
>lightweight scripting language.
I think has more to do with the recurrent discussion on this list
about the difference between easy to use and easy to learn. I think
Scheme is easier to learn, but more difficult to use for industrial
strength programs, whereas CL is harder to learn but easier to use.
Just like the difference between Emacs and Notepad. Notepad is a lot
easier to learn, but Emacs is easier to use for real tasks than
Notepad is. (Yes I'm comparing Scheme to Notepad and CL to Emacs :p )
Doug Tolton
(format t ···@~a~a.~a" "dtolton" "ya" "hoo" "com")
Doug Tolton <·······@yahoo.com> writes:
> Just like the difference between Emacs and Notepad. Notepad is a lot
> easier to learn, but Emacs is easier to use for real tasks than
> Notepad is. (Yes I'm comparing Scheme to Notepad and CL to Emacs :p )
Cute analogy...
Though in "defense" of Scheme it would be maybe a little more
structurally correct if you compared Scheme to the Windows text widget
underlies Notepad, in the sense that the widget is conservatively
defined yet, in principle, extensible. (Notepad looks pretty
non-extensible to me.)
Or maybe you should have compared Scheme to DEC Teco and CL to
ITS Teco-based Emacs. Then at least it would be clear both were
extensible, and one just started with "more stuff" than the other.
(Also, ITS Teco had more hair in its underlying engine, including
more "dimensionality" to its q-register model than DEC Teco did,
so you could claim that was like a Teco1/Teco2 distinction. ;)
Kent M Pitman <······@world.std.com> wrote in message news:<···············@shell01.TheWorld.com>...
> Doug Tolton <·······@yahoo.com> writes:
>
> > Just like the difference between Emacs and Notepad. Notepad is a lot
> > easier to learn, but Emacs is easier to use for real tasks than
> > Notepad is. (Yes I'm comparing Scheme to Notepad and CL to Emacs :p )
>
> Cute analogy...
One of the most absurd analogies I ever heard, even if you are
comparing the corresponding standards. Another point is that the
Scheme you use for "real world" is not r5rs, but a particular
implementation. One can, and does, choose one that provides all the
necessary machinery for the task at hand.
To make things clear, I have absolutely nothing against CL, I just
find Scheme (or rather the implementations I like, such as PLT and
Gauche) more practical for many tasks.
--
Grzegorz
········@pithekos.net (Grzegorz Chrupala) writes:
> Kent M Pitman <······@world.std.com> wrote in message news:<···············@shell01.TheWorld.com>...
> > Doug Tolton <·······@yahoo.com> writes:
> >
> > > Just like the difference between Emacs and Notepad. Notepad is a lot
> > > easier to learn, but Emacs is easier to use for real tasks than
> > > Notepad is. (Yes I'm comparing Scheme to Notepad and CL to Emacs :p )
> >
> > Cute analogy...
>
> One of the most absurd analogies I ever heard, even if you are
> comparing the corresponding standards. Another point is that the
> Scheme you use for "real world" is not r5rs, but a particular
> implementation. One can, and does, choose one that provides all the
> necessary machinery for the task at hand.
>
> To make things clear, I have absolutely nothing against CL, I just
> find Scheme (or rather the implementations I like, such as PLT and
> Gauche) more practical for many tasks.
This is exactly why I included the text that you elided after the above
snippet... maybe you missed my point about extensibility.
Kent M Pitman <······@world.std.com> wrote in message news:<···············@shell01.TheWorld.com>...
> This is exactly why I included the text that you elided after the above
> snippet... maybe you missed my point about extensibility.
I was mainly reacting to the previous post making the comparison. I
included a bit of your post because it rather shocked me someone could
think the analogy was in any way "cute". I did get your point about
extensibility and agreed with it. I should have made that clear.
Apologies,
--
Grzegorz
Doug Tolton <·······@yahoo.com> writes:
> I think has more to do with the recurrent discussion on this list
> about the difference between easy to use and easy to learn. I think
> Scheme is easier to learn, but more difficult to use for industrial
> strength programs, whereas CL is harder to learn but easier to use.
>
> Just like the difference between Emacs and Notepad. Notepad is a lot
> easier to learn, but Emacs is easier to use for real tasks than
> Notepad is. (Yes I'm comparing Scheme to Notepad and CL to Emacs :p )
I think this is a great analogy.
Grzegorz Chrupala <········@pithekos.net> wrote:
+---------------
| I think roughly the difference in preferences described above is
| plausible, but there are certainly also people who prefer scheme for
| *practical* reasons. From my newbie perspective, some of those are
| that it is smaller, has many more implementations (most of them free)...
+---------------
CMUCL & CLISP are both free, as are the trial or "personal" versions
of most commercial implementations.
+---------------
| and I have the impression that is generally more suitable as a
| lightweight scripting language.
+---------------
Well, times change. Given how well the VM systems on modern Unixes --
{Free,Net,Open}BSD, Linux, etc. -- cache executables and mmap'd files
(used to map the Lisp image), even "large" Common Lisp system (e.g., CMUCL)
run very quickly after the first run of the day. In fact, on my Athlon
desktop at home with FreeBSD, when running the same[1] "#!/interp"
script in MzScheme v.103 and CMUCL-18e, the "time" command reports
both of them being about the same, between 10-20ms, with CMUCL being
on average just slightly *faster*!
Said another way, I use both CLISP & CMUCL all the time as "lightweight
scripting languages"...
-Rob
[1] Modulo tiny changes for differing syntax.
-----
Rob Warnock, PP-ASEL-IA <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
····@rpw3.org (Rob Warnock) wrote in message news:<······················@speakeasy.net>...
> CMUCL & CLISP are both free, as are the trial or "personal" versions
> of most commercial implementations.
So that's two good open source implementations, and I never said there
weren't any. I said "many more" free Schemes than Common Lisps and
that is a fact, and hardly surprising given the relative ease of
implementation of CL vs. Scheme.
> (used to map the Lisp image), even "large" Common Lisp system (e.g., CMUCL)
> run very quickly after the first run of the day. In fact, on my Athlon
> desktop at home with FreeBSD, when running the same[1] "#!/interp"
> script in MzScheme v.103 and CMUCL-18e, the "time" command reports
> both of them being about the same, between 10-20ms, with CMUCL being
> on average just slightly *faster*!
>
> Said another way, I use both CLISP & CMUCL all the time as "lightweight
> scripting languages"...
Good to hear. I used to fool around with CLisp scripts, too. But last
time I looked at Clisp, it was still quite a bit behind Scsh or
Gauche in terms of real world scripting facilities. I mean support for
OS interface, regex and string operations etc, not just startup speed.
(No idea about CMUCL, though).
Grzegorz
········@pithekos.net (Grzegorz Chrupala) writes:
> ····@rpw3.org (Rob Warnock) wrote in message news:<······················@speakeasy.net>...
>
>> CMUCL & CLISP are both free, as are the trial or "personal" versions
>> of most commercial implementations.
>
> So that's two good open source implementations, and I never said there
> weren't any. I said "many more" free Schemes than Common Lisps and
No, but Rob didn't say that you said there weren't any either. When
you said that there are "many more" free Schemes, you were talking
about practical reasons to prefer Scheme over Lisp.
So the real question is: how many implementations do you need before
using CL is not a practical disadvantage on that score? I rarely use
more than two CL implementations (and one of them mostly to build the
other) and given that R5RS has even less library stuff than ANSI CL,
I'd have assumed the "stick toa single implementation" urge is even
more pronounced for Schemers. If you're primarily using scsh, say,
what do you get from the (1- many) other free Schemes?
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
Daniel Barlow <···@telent.net> wrote in message news:<··············@noetbook.telent.net>...
> I'd have assumed the "stick toa single implementation" urge is even
> more pronounced for Schemers. If you're primarily using scsh, say,
> what do you get from the (1- many) other free Schemes?
I don't mean that one user would necessarily use them all, or even
many of them. My point is, that for any enviroment/domain you can
choose from a wide variety of implementations the one that is most
suitable and then "stick to it". E.g. if you are teaching, you would
probably go for PLT, if you do sysadmin stuff, you choose Scsh or
Gauche, and if you need Java integration you simply pick one of the
Java based implementations such as Kawa or Jscheme or SISC. Once
you've made your choice you can forget the other Schemes until your
needs change.
So given a specific domain, there is on average a better chance that
one of the Scheme implementations gives you what you want than that
CLisp, CMUCL or GCL provide it, simply because there is more variety
and more specialization in the Scheme world.
Of course if you have to do work in many different domains
simultaneously, and you already use CL for all your needs, then even
if you need to do, say, a web application where Scheme continuations
would come in handy, you may well be better off sticking to CL rather
than switching to an appropriate Scheme implementation just for this
job.
But it doesn't invalidate my original point that there are situations
when Scheme is a better choice that CL due to *practical* rather that
*esthetic* considerations.
--
Grzegorz
> Said another way, I use both CLISP & CMUCL all the time as "lightweight
> scripting languages"...
It depends on what you want to do. CMUCL has a rather large memory
footprint. If you're writing a system script, that's fine, but it
might not be appropriate for something like an embedded scripting
language in an application, because the CMUCL runtime will have a big
impact on the cache and memory footprint of the host application.
"Kent M Pitman" <······@world.std.com> wrote in message
····················@shell01.TheWorld.com...
> "Anton van Straaten" <·····@appsolutions.com> writes:
>
> > Kent M Pitman wrote:
> > > In fact, it weirds me out given how much more "mathematical" the
> > > Scheme community seems to be than the Lisp community (preferring
> > > "formal semantics" and all kinds of otehr stuff like that with greek
> > > symbols all over)
> >
> > Kent, you are really scraping the bottom of the barrel.
>
> Perhaps for descriptive prose, but I think my point in general is true.
> If someone disagrees, I'd be curious. It seems to me like people who
> self-identify as mathemeticians tend toward Scheme and people who
> self-identify as engineers or practioners of some applied science
> tend toward CL, for exactly the same reasons that Scheme has a stronger
> bias toward aesthetics in design and CL has a stronger bias toward
> practicality in design. I certainly have no concrete data on this, but
> I've observed a lot of personal preferences over the years and haven't
> heard too many complaints from people I have steered one way or another
> in a triage setting where they were seeking to learn one or the other
> language and I used this criterion. I'm open to claims that this is not
> the nature of the partition, but I'd be curious along with this to hear
> what the nature of the partition is... since that's what the thread
> topic is, after all.
>
>
Kent,
I am a mathematician by training, and I was definitely more attracted toward
Scheme than Common Lisp. The minimal simplicity and elegance is very
appealing to a mathematican. After awhile I thought I should take a look at
Common Lisp. When I did, I found it that it seemed ugly by comparison.
Normally, that would be the end of the story, but I was also doing software
engineering and had a strong desire to find better languages to work with. I
eventually reexamined Common Lisp and realized that this was a serious
industrial strength language with features developed by people working on
nasty problems. It is now hard for me to imagine going back to Scheme.
-R. Scott McIntire
Kent Pitman wrote:
> Perhaps for descriptive prose, but I think my point in general is true.
> If someone disagrees, I'd be curious. It seems to me like people who
> self-identify as mathemeticians tend toward Scheme and people who
> self-identify as engineers or practioners of some applied science
> tend toward CL, for exactly the same reasons that Scheme has a stronger
> bias toward aesthetics in design and CL has a stronger bias toward
> practicality in design.
I'm a mathematician (and by training and preference a pure
mathematician, though what I get paid for is more applied),
and I prefer CL. I do feel the aesthetic appeal of Scheme,
but ... well, programming languages are primarily for
programming in :-).
--
Gareth McCaughan
.sig under construc
I am also from a Pure Mathematics background. Even in
mathematics the world is a messy place, many thereoms
use "tricks" or "klunges" to get the work done. I
definitely prefer CL.
Wade
On 19 Sep 2003 15:00:39 -0400, Kent M Pitman <······@world.std.com> wrote:
> It seems to me like people who self-identify as mathemeticians tend
> toward Scheme and people who self-identify as engineers or
> practioners of some applied science tend toward CL, for exactly the
> same reasons that Scheme has a stronger bias toward aesthetics in
> design and CL has a stronger bias toward practicality in design.
Just to provide one data point: I'm a mathematician who specialized in
pure mathematics (logic and set theory). I have a strong bias towards
Common Lisp. But maybe that's because I'm working as a free-lance
developer since 1997 or so.
Edi.
Kent M Pitman wrote:
> "Anton van Straaten" <·····@appsolutions.com> writes:
>
> > Kent M Pitman wrote:
> > > In fact, it weirds me out given how much more "mathematical" the
> > > Scheme community seems to be than the Lisp community (preferring
> > > "formal semantics" and all kinds of otehr stuff like that with greek
> > > symbols all over)
> >
> > Kent, you are really scraping the bottom of the barrel.
>
> Perhaps for descriptive prose, but I think my point in general is true.
> If someone disagrees, I'd be curious. It seems to me like people who
> self-identify as mathemeticians tend toward Scheme and people who
> self-identify as engineers or practioners of some applied science
> tend toward CL, for exactly the same reasons that Scheme has a stronger
> bias toward aesthetics in design and CL has a stronger bias toward
> practicality in design. I certainly have no concrete data on this, but
> I've observed a lot of personal preferences over the years and haven't
> heard too many complaints from people I have steered one way or another
> in a triage setting where they were seeking to learn one or the other
> language and I used this criterion. I'm open to claims that this is not
> the nature of the partition, but I'd be curious along with this to hear
> what the nature of the partition is... since that's what the thread
> topic is, after all.
If you'd left it at "more mathematical", I wouldn't have responded. More
mathematical can mean an appreciation for the benefits of referential
transparency, for the use of precisely defined and powerful abstractions for
solving problems, and so on. Although as has been pointed out, there are
people with that perspective in both communities. But it was your claim
about ``preferring "formal semantics" and all kinds of otehr stuff like that
with greek symbols all over'', which aside from the strange childish ring it
has, seems (a) wrong, and (b) prejudicial, for a certain audience.
Like you, I have no concrete data, but I've seen little evidence of Scheme
programmers in general ``preferring "formal semantics" and all kinds of
otehr stuff like that with greek symbols all over''. I'd be surprised if a
significant proportion of "the Scheme community" knows very much about the
formal semantics of Scheme, beyond that the semantics exist, and the general
purpose of those semantics.
One reason for this is that the denotational semantics provided in the
Scheme spec tend to be seen as not very accessible, due specifically to
things like the heavy use of Greek characters, lambda-calculus notation, and
CPS. This is compounded by a lack of coverage of the topic in books and
other reference materials, other than materials specifically covering
denotational semantics; i.e., it's not covered as widely as subjects such
as, say, parser design.
Perhaps you're thinking of the small subset of the Scheme community actually
active in the study of language semantics, but are those the same people
that are making the arguments you were trying to disparage? Ironically, you
complained about imprecise or not-fully-detailed "mappings" while at the
same time mapping theoretical semanticists onto the entire Scheme community
and then mapping that fictitious community back onto some unspecified subset
whose arguments you apparently wanted to complain about.
Anton
"Anton van Straaten" <·····@appsolutions.com> writes:
> Perhaps you're thinking of the small subset of the Scheme community actually
> active in the study of language semantics, but are those the same people
> that are making the arguments you were trying to disparage? Ironically, you
> complained about imprecise or not-fully-detailed "mappings" while at the
> same time mapping theoretical semanticists onto the entire Scheme community
> and then mapping that fictitious community back onto some unspecified subset
> whose arguments you apparently wanted to complain about.
Fair enough.
On 19 Sep 2003 15:00:39 -0400, Kent M Pitman <······@world.std.com>
wrote:
>If someone disagrees, I'd be curious. It seems to me like people who
>self-identify as mathemeticians tend toward Scheme and people who
>self-identify as engineers or practioners of some applied science
>tend toward CL, for exactly the same reasons that Scheme has a stronger
>bias toward aesthetics in design and CL has a stronger bias toward
>practicality in design. I certainly have no concrete data on this, but
>I've observed a lot of personal preferences over the years and haven't
>heard too many complaints from people I have steered one way or another
>in a triage setting where they were seeking to learn one or the other
>language and I used this criterion. I'm open to claims that this is not
>the nature of the partition, but I'd be curious along with this to hear
>what the nature of the partition is... since that's what the thread
>topic is, after all.
>
An interesting observation. I'm a software engineer by trade but
somewhere along the line I aquired the (old time) hacker notion of
"the right thing" - the cleanest and simplest way to do something.
I'm offended by kludges and prefer integrated, systemic solutions
whenever possible.
I haven't used CL enough to comment on its "right thing" relationship
to Scheme - either can look that way after fighting with C++ or Java.
George
George Neuner <········@no.comcast.spam.net> writes:
> I'm a software engineer by trade but somewhere along the line I
> aquired the (old time) hacker notion of "the right thing" - the
> cleanest and simplest way to do something. I'm offended by kludges
> and prefer integrated, systemic solutions whenever possible.
Sometimes the cleanest way isn't the simplest way (and vice versa). I
think this is where Scheme and CL diverge. What `the right thing' is
depends a lot on what you are trying to do.
On Mon, 22 Sep 2003 11:14:57 -0400, Joe Marshall <···@ccs.neu.edu>
wrote:
>George Neuner <········@no.comcast.spam.net> writes:
>
>> I'm a software engineer by trade but somewhere along the line I
>> aquired the (old time) hacker notion of "the right thing" - the
>> cleanest and simplest way to do something. I'm offended by kludges
>> and prefer integrated, systemic solutions whenever possible.
>
>Sometimes the cleanest way isn't the simplest way (and vice versa). I
>think this is where Scheme and CL diverge. What `the right thing' is
>depends a lot on what you are trying to do.
I agree with that.
The "right thing" is an ideal seldom achieved, an implementation
that's both "elegant" (to some definition of elegance - YMMV) and as
direct as possible without needless abstraction.
George
On 19 Sep 2003 13:04:27 -0400, Kent M Pitman <······@world.std.com>
wrote:
>Can someone give an example of a driving task that is much harder to do
>with an American car than a Japanese or German car?
Have you driven a BMW lately? In the 2000 model year they reversed
shift direction in the manual mode of their steptronic transmission -
you push away to downshift and pull toward the body to upshift.
The design violates 100+ years of driver conditioning for moving the
gear lever: namely that lower gears are closer to your body and higher
gears are farther away. This is true of every standard (think layout
of the H or 5-speed) and every automatic transmission I've ever seen.
An example? Even after driving one for several days (a loaner while
my older one was being serviced), I still shifted the wrong way when
preoccupied by turning.
George
In article <··································@4ax.com>,
George Neuner <········@no.comcast.spam.net> wrote:
> On 19 Sep 2003 13:04:27 -0400, Kent M Pitman <······@world.std.com>
> wrote:
>
> >Can someone give an example of a driving task that is much harder to do
> >with an American car than a Japanese or German car?
>
> Have you driven a BMW lately? In the 2000 model year they reversed
> shift direction in the manual mode of their steptronic transmission -
> you push away to downshift and pull toward the body to upshift.
This is exactly the same as every motorcycle I've ever owned. You press
the lever down (away from you) to get a lower/slower gear, and pull it
up (towards you) to get a higher/faster gear. All they've done
(conceptually) is to position the lever rotated 90 degrees on the same
shaft.
I also note that the gears that it is intended that you will shift
between the most often and therefore the most easily -- 3rd and 4th --
are in my experience always in exactly the relationship you dislike:
forward to downshift and backward to upshift.
> The design violates 100+ years of driver conditioning for moving the
> gear lever: namely that lower gears are closer to your body and higher
> gears are farther away. This is true of every standard (think layout
> of the H or 5-speed) and every automatic transmission I've ever seen.
Well, this is untrue for anyone living in a country in which they drive
on the left hand side of the road (which means that you sit on the right
haqnd side of the car, and change gears with your left hand).
I live in New Zealand, and have been to the USA eight times, and have
driven cars there each time. So I've switched between left hand and
right hand drive sixteen times. It's never taken more than a minute or
two to sort it out -- and there's a lot more than just the location of
the gearshift to worry about.
-- Bruce
On Sat, 20 Sep 2003 19:20:50 +1200, Bruce Hoult <·····@hoult.org>
wrote:
>In article <··································@4ax.com>,
> George Neuner <········@no.comcast.spam.net> wrote:
>
>> On 19 Sep 2003 13:04:27 -0400, Kent M Pitman <······@world.std.com>
>> wrote:
>>
>> >Can someone give an example of a driving task that is much harder to do
>> >with an American car than a Japanese or German car?
>>
>> Have you driven a BMW lately? In the 2000 model year they reversed
>> shift direction in the manual mode of their steptronic transmission -
>> you push away to downshift and pull toward the body to upshift.
>
>This is exactly the same as every motorcycle I've ever owned. You press
>the lever down (away from you) to get a lower/slower gear, and pull it
>up (towards you) to get a higher/faster gear. All they've done
>(conceptually) is to position the lever rotated 90 degrees on the same
>shaft.
Bicycle shifts are the same way (at least for the rear gears - I've
seen the front gears work both ways). Never had a motorcycle.
>I also note that the gears that it is intended that you will shift
>between the most often and therefore the most easily -- 3rd and 4th --
>are in my experience always in exactly the relationship you dislike:
>forward to downshift and backward to upshift.
On a standard transmission ... yes. However, the "standard" vehicle
layout puts 1st and 2nd closest to the driver and each progressing
pair of gears, 3rd/4th, 5th/6th (ad naseum for trucks), farther away.
I could have made this part more clear before.
However I'm not talking about the standard transmission - I'm talking
about the auto/manual transmission that BMW has sold since around 1990
and which is now their preferred automatic transmission. In one mode
it shifts automatically and in the other the driver shifts manually
but with auto clutching. It's good for aging weenies like me who want
more convenience for city traffic (I live and work near Boston, MA)
and to still have some balls for the occasional race.
BMW has sold a floor shift automatic for 30 years. Around 1990, they
introduced a positive shifting, auto/manual 4-speed for a number of
years and then replaced it with an auto/manual 5-speed transmission
which has positive shift in the automatic mode (but only for PRND) and
joystick-like "tip" operation in manual mode. For two design years
(98,99), it followed the shifting convention of BMW's previous auto
and auto/manual transmissions (ie., push to upshift, pull to
downshift). Then in 2000, the joystick direction of operation was
reversed.
My BMW dealership (in Peabody, MA) has the largest service operation
in New England - over 100 techs with 23 class 1's (the ones who can
rebuild the cars blindfolded). According to their service reps,
nearly 3% of their calls in the last three years have been for
transmissions damaged by shifting the wrong way at speed in manual
mode. The drivers were mostly ones who "upgraded" from a previous
auto/manual or came from multiple car families with a mix of old and
new models and had "switched" cars.
My car (an old auto/manual 4-speed) will need to be replaced soon. I
never had trouble with the new design until they reversed the joystick
operation - now when I get one as a loaner I'm scared to drive it in
manual mode (the longer the service to my car takes the tougher it is
to resist the urge). I suppose I could probably get used to it if I
drove one all the time - but after driving for more than 20 years
(standards, automatics and these hybrids) it just feels weird and is
backward to the operation of nearly every other car on the road in the
US.
>> The design violates 100+ years of driver conditioning for moving the
>> gear lever: namely that lower gears are closer to your body and higher
>> gears are farther away. This is true of every standard (think layout
>> of the H or 5-speed) and every automatic transmission I've ever seen.
>
>Well, this is untrue for anyone living in a country in which they drive
>on the left hand side of the road (which means that you sit on the right
>hand side of the car, and change gears with your left hand).
I didn't consider right hand steering wheels ... you're absolutely
right regarding cars with a standard transmission. But while we're on
this subject and since I have never seen one, I'd like to ask on which
side of a right handed steering wheel is the lever for a column shift
(auto or standard transmission)? And in which direction do you move
said lever to down shift?
FWIW, there are only a handful of countries that drive on the left
(and bother to enforce their laws). The vast majority of cars sold in
the world have the steering wheel on the left so I think that layout
has a better claim to being "standard".
George
In article <··································@4ax.com>,
George Neuner <········@no.comcast.spam.net> wrote:
> I didn't consider right hand steering wheels ... you're absolutely
> right regarding cars with a standard transmission. But while we're on
> this subject and since I have never seen one, I'd like to ask on which
> side of a right handed steering wheel is the lever for a column shift
> (auto or standard transmission)? And in which direction do you move
> said lever to down shift?
Left hand side, 1-2-D-N-R-P as you go clockwise. Manual transmission
(the old "three on the tree" in mostly Holdens and Fords) is:
R - forward and up
1 - forward and down
2 - back (spring loaded) and up
3 - back (spring loaded) and down
The other stalks are these days standardised on wipers on the left
(downwards/anticlockwise for faster) and turn signals on the right
(up/anticlockwise for left). Back in the 70's and early 80's a few cars
were reversed from this (English Ford models, as I recall e.g. the
Escort and Cortina)
Again, I seldom make a mistake when moving between NZ and US cars.
> FWIW, there are only a handful of countries that drive on the left
> (and bother to enforce their laws).
The entire English-speaking world apart from North America, you mean.
Plus Japan.
> The vast majority of cars sold in the world have the steering
> wheel on the left so I think that layout has a better claim to
> being "standard".
The vast majority of cars sold in the world are *made* in a country
where the steering wheel goes on the right :-) Which is good for us in
NZ, because it means we get the more powerful Japanese Domestic Market
versions of many models (e.g. up to 300 HP turbocharged Subaru Legacy
and Impreza for the last dozen years, while the US got one turbo model
in '03 and finally most of the range in '04)
-- Bruce
On Mon, 22 Sep 2003 21:54:40 +1200, Bruce Hoult <·····@hoult.org>
wrote:
>In article <··································@4ax.com>,
> George Neuner <········@no.comcast.spam.net> wrote:
>
>> I didn't consider right hand steering wheels ... you're absolutely
>> right regarding cars with a standard transmission. But while we're on
>> this subject and since I have never seen one, I'd like to ask on which
>> side of a right handed steering wheel is the lever for a column shift
>> (auto or standard transmission)? And in which direction do you move
>> said lever to down shift?
>
>Left hand side, 1-2-D-N-R-P as you go clockwise. Manual transmission
>(the old "three on the tree" in mostly Holdens and Fords) is:
>
>R - forward and up
>1 - forward and down
>2 - back (spring loaded) and up
>3 - back (spring loaded) and down
>
Interesting ... thank you!
>> FWIW, there are only a handful of countries that drive on the left
>> (and bother to enforce their laws).
>
>The entire English-speaking world apart from North America, you mean.
>Plus Japan.
That's what I said - a handful of countries 8-)
I haven't seen statistics on vehicle ownership overseas, but I would
feel safe in wagering that the combined ownership of California and
New York covers a very large percentage of the combined ownership of
the (non NA) English speaking world.
>> The vast majority of cars sold in the world have the steering
>> wheel on the left so I think that layout has a better claim to
>> being "standard".
>
>The vast majority of cars sold in the world are *made* in a country
>where the steering wheel goes on the right :-) Which is good for us in
>NZ, because it means we get the more powerful Japanese Domestic Market
>versions of many models (e.g. up to 300 HP turbocharged Subaru Legacy
>and Impreza for the last dozen years, while the US got one turbo model
>in '03 and finally most of the range in '04)
We have a stupid law here that forces domestically produced cars to be
electronically limited to 120 mph. That law may affect what power
trains are offered as most Japanese cars sold in the US are
manufactured here rather than being imported (almost all European cars
are still imported).
We're far off topic now and should probably stop.
George
Bruce Hoult <·····@hoult.org> writes:
> In article <··································@4ax.com>,
> George Neuner <········@no.comcast.spam.net> wrote:
>
> > Have you driven a BMW lately? In the 2000 model year they reversed
> > shift direction in the manual mode of their steptronic transmission -
> > you push away to downshift and pull toward the body to upshift.
>
> This is exactly the same as every motorcycle I've ever owned.
Motorcycles are like CL in this sense -- if you don't like it, you can
change it (we want to stay on topic, right?). Like I have done for
all motorcycles I've owned (all two :). But for motorcycle the
shifting is done in up/down direction, which is perpendicular to the
driving direction and does not bear the mental connection of where you
have to shift to get the desired effect.
The analogy with motorcycles maybe more apparent with accelerator --
you turn it to yourself to accelerate, and away from yourself to
decelerate.
> You press the lever down (away from you) to get a lower/slower gear,
> and pull it up (towards you) to get a higher/faster gear.
The directions "away from me down" and "away from me forward" are
quite different.
--
Janis Dzerins
Common Lisp -- you get more than what you see.
In article <···············@gulbis.latnet.lv>,
Janis Dzerins <·····@latnet.lv> wrote:
> Bruce Hoult <·····@hoult.org> writes:
>
> > In article <··································@4ax.com>,
> > George Neuner <········@no.comcast.spam.net> wrote:
> >
> > > Have you driven a BMW lately? In the 2000 model year they reversed
> > > shift direction in the manual mode of their steptronic transmission -
> > > you push away to downshift and pull toward the body to upshift.
> >
> > This is exactly the same as every motorcycle I've ever owned.
>
> Motorcycles are like CL in this sense -- if you don't like it, you can
> change it (we want to stay on topic, right?). Like I have done for
> all motorcycles I've owned (all two :). But for motorcycle the
> shifting is done in up/down direction, which is perpendicular to the
> driving direction and does not bear the mental connection of where you
> have to shift to get the desired effect.
>
> The analogy with motorcycles maybe more apparent with accelerator --
> you turn it to yourself to accelerate, and away from yourself to
> decelerate.
Except for the 3- and 4-wheeled motorcycles, where you push a lever away
from you to accelerate. On tractors you pull a lever towards you to
accelerate. In aircraft you push a lever away from you (except Cessnas
where you push in a knob).
Sailplanes don't have a throttle, but they have airbrakes. In every
case you pull a lever back to deploy the brakes, and push it forward to
put them away (normal flight position). Flaps are also always pulled
back for slow speed, pushed forward for high speed. Strangely,
manufacturers don't seem to agree whether the undercarriage lever should
be pushed forward to retract or extend the wheel, so I make a point of
checking the labels every time [1].
-- Bruce
[1] to date I remain "one of those who will"
Bruce Hoult <·····@hoult.org> writes:
> In article <···············@gulbis.latnet.lv>,
> Janis Dzerins <·····@latnet.lv> wrote:
> >
> > The analogy with motorcycles maybe more apparent with accelerator --
> > you turn it to yourself to accelerate, and away from yourself to
> > decelerate.
>
> Except for the 3- and 4-wheeled motorcycles, where you push a lever away
> from you to accelerate. On tractors you pull a lever towards you to
> accelerate. In aircraft you push a lever away from you (except Cessnas
> where you push in a knob).
>
> Sailplanes don't have a throttle, but they have airbrakes. In every
> case you pull a lever back to deploy the brakes, and push it forward to
> put them away (normal flight position). Flaps are also always pulled
> back for slow speed, pushed forward for high speed. Strangely,
> manufacturers don't seem to agree whether the undercarriage lever should
> be pushed forward to retract or extend the wheel, so I make a point of
> checking the labels every time [1].
And remember the trouble Will Smith had in "Independance Day" getting out of
the garage with the alien vessel? I guess reversal of labels and controls
is a Universal problem (i.e. not just Earth bound)...
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
On Sat, Sep 20, 2003 at 07:20:50PM +1200, Bruce Hoult wrote:
> This is exactly the same as every motorcycle I've ever owned. You press
> the lever down (away from you) to get a lower/slower gear, and pull it
> up (towards you) to get a higher/faster gear. All they've done
> (conceptually) is to position the lever rotated 90 degrees on the same
> shaft.
Have you ever driven a motorcycle with gears 1-N-2-3-4 or similar? The
neutral "gear" is a half-click up from first, or a half-click down from
second. I'm kinda curious how common this is, since I haven't driven
such vehicles in a long time now.
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
* Matthew Danish <·······@andrew.cmu.edu>
| On Sat, Sep 20, 2003 at 07:20:50PM +1200, Bruce Hoult wrote:
| > This is exactly the same as every motorcycle I've ever owned. You press
| > the lever down (away from you) to get a lower/slower gear, and pull it
| > up (towards you) to get a higher/faster gear. All they've done
| > (conceptually) is to position the lever rotated 90 degrees on the same
| > shaft.
|
| Have you ever driven a motorcycle with gears 1-N-2-3-4 or similar? The
| neutral "gear" is a half-click up from first, or a half-click down from
| second. I'm kinda curious how common this is, since I haven't driven
| such vehicles in a long time now.
This is the usual setup in every (modern) bike. BTW, racing
bikes have gears in reverse order (down -> higer gear).
--
Eduardo Mu�oz | (prog () 10 (print "Hello world!")
http://213.97.131.125/ | 20 (go 10))
Eduardo Mu�oz <······@terra.es> writes:
> * Matthew Danish <·······@andrew.cmu.edu>
>
> | Have you ever driven a motorcycle with gears 1-N-2-3-4 or similar? The
> | neutral "gear" is a half-click up from first, or a half-click down from
> | second. I'm kinda curious how common this is, since I haven't driven
> | such vehicles in a long time now.
>
> This is the usual setup in every (modern) bike. BTW, racing
> bikes have gears in reverse order (down -> higer gear).
They don't by default (i.e., when out of the factory) -- users do it
themselves. And racers' preference is about 50/50 on this one. I
prefer the reverse order, for instance.
--
Janis Dzerins
Common Lisp -- you get more than what you see.
In article <·····················@mapcar.org>,
Matthew Danish <·······@andrew.cmu.edu> wrote:
> On Sat, Sep 20, 2003 at 07:20:50PM +1200, Bruce Hoult wrote:
> > This is exactly the same as every motorcycle I've ever owned. You press
> > the lever down (away from you) to get a lower/slower gear, and pull it
> > up (towards you) to get a higher/faster gear. All they've done
> > (conceptually) is to position the lever rotated 90 degrees on the same
> > shaft.
>
> Have you ever driven a motorcycle with gears 1-N-2-3-4 or similar? The
> neutral "gear" is a half-click up from first, or a half-click down from
> second. I'm kinda curious how common this is, since I haven't driven
> such vehicles in a long time now.
That's near universal. In fact the only modern exception I can think of
is the 1970s Honda CT90 step-through.
-- Bruce
>
> That's near universal. In fact the only modern exception I can think of
> is the 1970s Honda CT90 step-through.
>
Is this like the dozenth time a Lisp vs Scheme conversation has turned to cars?
: )
Matthew Danish wrote in message <·····················@mapcar.org>...
>On Sat, Sep 20, 2003 at 07:20:50PM +1200, Bruce Hoult wrote:
>> This is exactly the same as every motorcycle I've ever owned. You press
>> the lever down (away from you) to get a lower/slower gear, and pull it
>> up (towards you) to get a higher/faster gear. All they've done
>> (conceptually) is to position the lever rotated 90 degrees on the same
>> shaft.
>
>Have you ever driven a motorcycle with gears 1-N-2-3-4 or similar? The
>neutral "gear" is a half-click up from first, or a half-click down from
>second. I'm kinda curious how common this is, since I haven't driven
>such vehicles in a long time now.
They were all like that when I was riding. A biker usually loses track of
what gear they are in, especially in a six-speed rice-burner. So you just
keep downshifting until there aint no more. In an N-1-2-3-4-5-6 setup that
would leave you in neutral as you jump on the throttle to exit that hairpin
at Laguna Seca.
:)
kenny
"Kenny Tilton" <·······@nyc.rr.com> schrieb im Newsbeitrag
·························@twister.nyc.rr.com...
>
> Matthew Danish wrote in message <·····················@mapcar.org>...
> >On Sat, Sep 20, 2003 at 07:20:50PM +1200, Bruce Hoult wrote:
> >> This is exactly the same as every motorcycle I've ever owned. You
press
> >> the lever down (away from you) to get a lower/slower gear, and pull
it
> >> up (towards you) to get a higher/faster gear. All they've done
> >> (conceptually) is to position the lever rotated 90 degrees on the
same
> >> shaft.
> >
> >Have you ever driven a motorcycle with gears 1-N-2-3-4 or similar? The
> >neutral "gear" is a half-click up from first, or a half-click down from
> >second. I'm kinda curious how common this is, since I haven't driven
> >such vehicles in a long time now.
>
> They were all like that when I was riding. A biker usually loses track
of
They still are.
robert - still motorcycling
"thelifter" <·········@gmx.net> wrote in message
·································@posting.google.com...
> <quote>
[snip]
> </quote> <!-- sidenote: you see one advantage of XML over S-expr here.
> Unlike a parenthesis you immediately know what this closing tag refers
> to -->
1) No, you may just have nested tags with same name, in which case you
still need to refer to the indentation or count the tags.
2) With s-expr you also immediately know what parentheses correspond to,
and that's all handled by your editor.
Really, other than being an industry standard, I don't see any advantage
to XML compared to s-expr.
--
Matthieu Villeneuve
"thelifter" wrote:
> I read the recent thread:
>
> "Why some people think that Scheme is not a Lisp":
>
http://groups.google.com/groups?dq=&hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=sfwk
786uzh0.fsf%40shell01.TheWorld.com&prev=/groups%3Fq%3Dcomp.lang.lisp%26ie%3D
UTF-8%26oe%3DUTF-8%26hl%3Den%26btnG%3DGoogle%2BSearch
>
> I understand that Lisp semantics are based on lists and
> Scheme semantics are based on Strings.
You've paraphrased an initial claim which was subsequently refuted, if you
read the thread in question. At least two things are wrong with the
above-quoted statement:
1. The fact that "the semantics of [Common Lisp] programs are defined on
lists" (to use one of the original phrasings) is an essentially unimportant
implementation decision, except insofar as it has real, unavoidable, and
unduplicatable consequences for programs. The only such consequence that
has been raised, afaict, is this example which you quoted:
> (defun foo () '(1 2 3))
> (eq (foo) (foo))
However, this is not an unavoidable consequence of "the semantics of
programs being defined on lists". It also depends on the semantics of
quotation, and those quotation semantics could also exist in other contexts
in which semantics are not defined on lists. The claim was made that the
quotation semantics in question are the only reasonable quotation semantics,
but this is unsupportable. There are various perfectly reasonable
definitions for the semantics of quotation, which I'll be happy to explicate
for anyone interested.
The real semantic characteristic demonstrated by the above example is that
Common Lisp assigns identity to literal objects based in part on their
position in the program source code. Note that they don't necessarily
assign a *unique* identity to such objects, since apparently it is legal for
such objects to be merged.
It is certainly possible to require, in a language specification, that the
identity of literal objects should depend partly on their position in the
program source code. This requirement does not mandate that the semantics
of programs be defined on lists.
Given this, and absent some other more relevant example, we're left with the
fact that semantics defined on lists is of no practical consequence to the
Lisp programmer - at best, it's a way to characterize an aspect of the
language semantics in terms of a common implementation strategy, but it's
unfortunately too loose to have much meaning on its own.
2. The claim that "Scheme semantics are based on strings" is simply wrong.
At best, it's based on some language lawyering which focuses on alleged
weaknesses in the spec and misunderstands or ignores or its intent. The
Scheme spec makes its intent clear: "A Scheme program consists of a sequence
of expressions, definitions, and syntax definitions." Whether these
expressions are implemented as strings, lists, or - as is the case in some
Scheme implementations - as abstract syntax objects, is not relevant. The
semantics of Scheme are not determined by this issue, and nor are the
semantics of Common Lisp.
The idea of treating the representation of program code as an abstraction
(other than linked lists) is a useful one, which can be applied to Common
Lisp as well as to Scheme. If such a model had unavoidable consequences for
the semantics of a language, that would be a serious disadvantage. However,
this hasn't been shown to be the case. The real difference here is simply
one of the chosen specification for particular features of the semantics of
the respective languages, such as the identity of literal objects.
> Can anyone give a simple example where you do some computational
> task with Lisp that would be much harder to do with Scheme so that
> the advantage of Lisp becomes more apparent?
Not every difference between languages is an advantage or a disadvantage.
Anton