Lisp vs. Scheme
thelifter
"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...
Wade Humeniuk
> 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
Erann Gat
thel...@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.
Wade Humeniuk
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
Matthieu Villeneuve
news:b295356a.03091...@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
Joe Marshall
(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
See also the URL parser provided with DrScheme in
collects/net/url-unit.ss
in the DrScheme distribution.
Mario S. Mommer
> (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!!
Jon S. Anthony
> /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
Jens Axel Søgaard
> Joe Marshall <j...@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
Kent M Pitman
> 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
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.
Mario S. Mommer
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.
Anton van Straaten
> Joe Marshall <j...@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
Wade Humeniuk
>
> 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
Joe Marshall
> Jens Axel Søgaard <use...@jasoegaard.dk> writes:
>> Mario S. Mommer wrote:
>> > Joe Marshall <j...@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.
Joe Marshall
> 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.
Anton van Straaten
> 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
Erann Gat
van Straaten" <an...@appsolutions.com> 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.)
E.
Kent M Pitman
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.
Edi Weitz
> 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.
Gareth McCaughan
> 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
Tayss
> 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.
Scott McIntire
"Kent M Pitman" <pit...@world.std.com> wrote in message
news:sfwd6dw...@shell01.TheWorld.com...
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
Wade Humeniuk
mathematics the world is a messy place, many thereoms
use "tricks" or "klunges" to get the work done. I
definitely prefer CL.
Wade
Pascal Costanza
> 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
Anton van Straaten
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
Grzegorz Chrupala
> 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
Anton van Straaten
> 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
Anton van Straaten
> 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
Kent M Pitman
Fair enough.
Doug Tolton
Chrupala) wrote:
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.~a" "dtolton" "ya" "hoo" "com")
Kent M Pitman
> 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. ;)
Erann Gat
"Anton van Straaten" <an...@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.
George Neuner
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
George Neuner
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
Bruce Hoult
George Neuner <gneu...@no.comcast.spam.net> wrote:
> On 19 Sep 2003 13:04:27 -0400, Kent M Pitman <pit...@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
Rob Warnock
+---------------
| 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
+---------------
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 <rp...@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Tayss
> 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.
> 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.
Grzegorz Chrupala
> Doug Tolton <dto...@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
Kent M Pitman
This is exactly why I included the text that you elided after the above
snippet... maybe you missed my point about extensibility.
Grzegorz Chrupala
> 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
Rayiner Hashem
> scripting languages"...
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.
Grzegorz Chrupala
> 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
Daniel Barlow
> rp...@rpw3.org (Rob Warnock) wrote in message news:<z-icnQEUoPz...@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
Anton van Straaten
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
Erann Gat
"Anton van Straaten" <an...@appsolutions.com> wrote:
> Erann Gat wrote:
> > In article <bDOab.39945$NM1....@newsread2.news.atl.earthlink.net>,
> > "Anton van Straaten" <an...@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.
Grzegorz Chrupala
> 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
Pascal Costanza
>>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
Tayss
> 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 href="mailto:tayss...@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;
}
}
George Neuner
wrote:
>In article <cpsnmvkfg9qcifm7j...@4ax.com>,
> George Neuner <gneu...@no.comcast.spam.net> wrote:
>
>> On 19 Sep 2003 13:04:27 -0400, Kent M Pitman <pit...@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
Tayss
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.
Anton van Straaten
> In article <du4bb.43194$NM1....@newsread2.news.atl.earthlink.net>,
> "Anton van Straaten" <an...@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
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
Janis Dzerins
> In article <cpsnmvkfg9qcifm7j...@4ax.com>,
> George Neuner <gneu...@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.
Bruce Hoult
George Neuner <gneu...@no.comcast.spam.net> wrote:
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
Bruce Hoult
Janis Dzerins <jo...@latnet.lv> wrote:
> Bruce Hoult <br...@hoult.org> writes:
>
> > In article <cpsnmvkfg9qcifm7j...@4ax.com>,
> > George Neuner <gneu...@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"
Joe Marshall
> 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
> 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.
Joe Marshall
> 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.
Erann Gat
"Anton van Straaten" <an...@appsolutions.com> wrote:
> Erann Gat wrote:
> > In article <du4bb.43194$NM1....@newsread2.news.atl.earthlink.net>,
> > "Anton van Straaten" <an...@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.
Mario S. Mommer
> 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?
Joe Marshall
> In article <x3ybb.55775$NM1....@newsread2.news.atl.earthlink.net>,
> "Anton van Straaten" <an...@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.
Brian Palmer
> tayss...@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.
Jens Axel Søgaard
> "Anton van Straaten" <an...@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
Ray Blaak
> # Python's [...]
> def foo(): return [1, 2, 3]
> foo() is foo()
>
> (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!
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,
rAYb...@STRIPCAPStelus.net The Rhythm has my soul.
Mario S. Mommer
> > 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.
Duane Rettig
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 du...@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
Jens Axel Søgaard
> Jens Axel Søgaard <use...@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
Tayss
> tayss...@yahoo.com (Tayss) writes:
> > BTW, if you really want to debate my point that XML has certain
> > usability advantages...
>
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.
Erann Gat
> 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.")
Joe Marshall
>
>> 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 <bpa...@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.
Gareth McCaughan
> 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
Joe Marshall
> In article <ad8w3i...@ccs.neu.edu>, Joe Marshall <j...@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....
Joe Marshall
> Joe Marshall <j...@ccs.neu.edu> wrote in message news:<r8283m...@ccs.neu.edu>...
>> tayss...@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 select="@*"/>
<xsl:apply-templates/>
<xsl:text>)</xsl:text>
</xsl:template>
<xsl:template match="@*">
<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>
Brian Palmer
> 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 :-)
Joe Marshall
> 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
Erann Gat
=?ISO-8859-1?Q?Jens_Axel_S=F8gaard?= <use...@jasoegaard.dk> wrote:
> Mario S. Mommer wrote:
> > Jens Axel Søgaard <use...@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.
Erann Gat
<gareth.m...@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.
Matthew Danish
> This is exactly the same as every motorcycle I've ever owned. You press
> (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 <mda...@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."
Ray Blaak
> > 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.
Eduardo Muñoz
* Matthew Danish <mda...@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))
Bruce Hoult
Matthew Danish <mda...@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
Rayiner Hashem
> That's near universal. In fact the only modern exception I can think of
> is the 1970s Honda CT90 step-through.
>
: )
Anton van Straaten
> > > 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
Erann Gat
"Anton van Straaten" <an...@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.
Jon S. Anthony
> j-an...@rcn.com (Jon S. Anthony) wrote in message news:<m365jol...@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
Ray Blaak
> 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)};
--
George Neuner
wrote:
>In article <6kvrmvg9mvg8boqeu...@4ax.com>,
> George Neuner <gneu...@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
Anton van Straaten
> 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
Anton van Straaten
> "Anton van Straaten" <an...@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
Kenny Tilton
Matthew Danish wrote in message <2003092220...@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
Robert Klemme
"Kenny Tilton" <kti...@nyc.rr.com> schrieb im Newsbeitrag
news:aYWbb.22695$u67....@twister.nyc.rr.com...
>
> Matthew Danish wrote in message <2003092220...@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
Erann Gat
van Straaten" <an...@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.
Mario S. Mommer
> "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? ;)
Pascal Costanza
> 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
Pascal Costanza
[You have asked to go into details. Here we go.]
Tayss wrote:
> Pascal Costanza <cost...@web.de> wrote in message news:<bkfvq2$o8h$1...@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
>>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
> 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
George Neuner
wrote:
>George Neuner <gneu...@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
Doug Tolton
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:
Doug Tolton
(format t "~a@~a~a.~a" "dtolton" "ya" "hoo" "com")