Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

"Well, I want to switch over to replace EMACS LISP with Guile." (was Re: Lisp in Python)

707 views
Skip to first unread message

Adam Warner

unread,
Sep 26, 2002, 5:35:30 AM9/26/02
to
That quotation from a December 1999 interview with RMS left an indelible
impression:
http://www.linuxcare.com/viewpoints/os-interviews/12-14-99.epl

I was dumbfounded that Richard Stallman himself was advocating using a
Scheme interpreter instead of Lisp.

Regards,
Adam

Dave Bakhash

unread,
Sep 26, 2002, 11:30:49 AM9/26/02
to
"Adam Warner" <use...@consulting.net.nz> writes:

I'm not dumbfounded about anything RMS says these days. What dumbfounds
me, though, is that people would rather use Guile that CL as an
embedded application and extension language.

Fortunately, there are numerous threads that you can read on this, both
here and in other newsgroups (e.g. comp.emacs.xemacs). Scheme/Guile
seems to be strongly advocated among many open-source developers and
projects. I think they've done a better job making Guile something that
can be bundled. I would also guess that CLISP can be just as easily
bundled.

There are lots of applications for which CL might have seemed like
overkill...but even for those, i think CL would be better. The greatest
loss, though, is in (X)Emacs. This is the very application that used
Lisp as an extension language in the first place, and is one of the
reason for Lisp's current popularity. Without Emacs, I don't know if
Lisp would have the the following that it does. Many Lisp programmers
get into Lisp by first editing their .eamcs files, modifying elisp
packages, and then eventually writing their own.

I don't think that the CL community realized the importance of a
complete version of Emacs done in CL, with the ability to process legacy
Emacs Lisp files. A version of Emacs, based on CLISP, would have done
wonders. The timing was right just before this aweful idea came up to
replacing elisp with Guile.

CL already has a nice package system that would solve a lot of the
namespace issues that Elisp has. Lexical scoping, an efficient object
system, a more complete set of built-in functions and constructs...would
together fix the problems that Elisp has now.

dave

Bruce Stephens

unread,
Sep 26, 2002, 11:57:54 AM9/26/02
to
Dave Bakhash <ca...@alum.mit.edu> writes:

> "Adam Warner" <use...@consulting.net.nz> writes:
>
>> That quotation from a December 1999 interview with RMS left an indelible
>> impression:
>> http://www.linuxcare.com/viewpoints/os-interviews/12-14-99.epl
>>
>> I was dumbfounded that Richard Stallman himself was advocating using a
>> Scheme interpreter instead of Lisp.
>
> I'm not dumbfounded about anything RMS says these days. What dumbfounds
> me, though, is that people would rather use Guile that CL as an
> embedded application and extension language.

This discussion started years ago, though. At the time, I'd guess CL
just looked too darn big, and probably the free implementations
weren't that mature (or amenable to embedding). At the time, if you
wanted a low-footprint very well-defined lisp, then Scheme was an
obviously good choice.

> Fortunately, there are numerous threads that you can read on this,
> both here and in other newsgroups (e.g. comp.emacs.xemacs).
> Scheme/Guile seems to be strongly advocated among many open-source
> developers and projects. I think they've done a better job making
> Guile something that can be bundled. I would also guess that CLISP
> can be just as easily bundled.

Yes, <http://ecls.sourceforge.net/index.html> looks attractive.

Inverting the problem a bit, rep's cool, too:
<http://librep.sourceforge.net/>. It's a dialect of lisp that's
fairly close to emacs-lisp, so it's easy to embed an emacs-lisp-like
interpreter into other applications (notably sawfish).

[...]

Dorai Sitaram

unread,
Sep 26, 2002, 12:15:21 PM9/26/02
to
In article <c29wup8...@no-knife.mit.edu>,

My how lugubriously you write.... One would think that
Emacs Lisp was being given up for a brace-semicolon
language or something. Guile is very Lisp-y, and has
all the things you mention, viz, namespace-discipline
mechanism, lexical scoping, object system, complete set
of builtins -- just not compatibly with CL. If it
weren't for the drawn knives here, I would simply let
down my guard and concede that Guile is a Lisp.

Dave Bakhash

unread,
Sep 26, 2002, 12:32:41 PM9/26/02
to
ds...@goldshoe.gte.com (Dorai Sitaram) writes:

> My how lugubriously you write.... One would think that Emacs Lisp was
> being given up for a brace-semicolon language or something.

may as well be.

> Guile is very Lisp-y, and has all the things you mention, viz,
> namespace-discipline mechanism, lexical scoping, object system,
> complete set of builtins -- just not compatibly with CL.

Remember that you should not forget that you're starting with Emacs
Lisp, and that this more closely resembles CL than Guile. That part of
the problem should not be downplayed.

Also, it's nice that CL is ANSI-standardized, and has a long track
record, and a pretty strong community. Sometimes it's better to go with
something that works than to start all over.

> weren't for the drawn knives here, I would simply let down my guard
> and concede that Guile is a Lisp.

Guile may be a Lisp. But so is Emacs Lisp. What is your point?

dave

Dorai Sitaram

unread,
Sep 26, 2002, 1:34:04 PM9/26/02
to
In article <c29ofak...@no-knife.mit.edu>,
Dave Bakhash <ca...@alum.mit.edu> wrote:

>ds...@goldshoe.gte.com (Dorai Sitaram) writes:
>> Guile is very Lisp-y, and has all the things you mention, viz,
>> namespace-discipline mechanism, lexical scoping, object system,
>> complete set of builtins -- just not compatibly with CL.
>
>Remember that you should not forget that you're starting with Emacs
>Lisp, and that this more closely resembles CL than Guile. That part of
>the problem should not be downplayed.

In the Lisp world where code is data, these things can
be downplayed.

>Also, it's nice that CL is ANSI-standardized, and has a long track
>record, and a pretty strong community. Sometimes it's better to go with
>something that works than to start all over.

Yes, a CL-based Emacs would also have been quite
interesting.

>> weren't for the drawn knives here, I would simply let down my guard
>> and concede that Guile is a Lisp.
>
>Guile may be a Lisp. But so is Emacs Lisp. What is your point?

Your message suggested that Emacs was tragically moving
away from Lisp by switching to Guile, so I
reassured you that it wasn't. Maybe I misread
what exactly you were being regretful about.

Tim Bradshaw

unread,
Sep 26, 2002, 1:49:58 PM9/26/02
to
* Dave Bakhash wrote:

> There are lots of applications for which CL might have seemed like
> overkill...but even for those, i think CL would be better. The greatest
> loss, though, is in (X)Emacs. This is the very application that used
> Lisp as an extension language in the first place, and is one of the
> reason for Lisp's current popularity. Without Emacs, I don't know if
> Lisp would have the the following that it does. Many Lisp programmers
> get into Lisp by first editing their .eamcs files, modifying elisp
> packages, and then eventually writing their own.

> I don't think that the CL community realized the importance of a
> complete version of Emacs done in CL, with the ability to process legacy
> Emacs Lisp files. A version of Emacs, based on CLISP, would have done
> wonders. The timing was right just before this aweful idea came up to
> replacing elisp with Guile.

I think it was discussed (among many other things...) when xemacs was
still lemacs. I used to be on the mailing list but I didn't keep
anything other than the most juicy stuff about great schism[1] so I
can't remember any details.

Personally I think the idea of replacing elisp by anything is (a)
insane and (b) incredibly unlikely to happen. XEmacs *ships* with
more than 2 million lines of emacs lisp[2], and I bet there is far
more than that in code that is either not bundled or is not
distributed at all (I have ~10,000 lines, I bet other people have as
much or more). No one is going to convert that stuff before hell
freezes over. So any replacement system has to *precisely* support
the semantics of elisp, including all the weird gotchas, and it has to
do it essentially for ever. And to what end? What will the huge win
be? Sure, elisp is bad, but it's not that bad. The stuff that holds
back big elisp systems isn't the terrible language or performance
(other than in a few cases), it's that they're big and complicated and
some of the emacs primitives suck. Easy wins would be adding proper
packages and proper structures - these could be added in mostly
transparently to old code. Gutting the system sounds like a vast
amount of work for some mistaken idea of purity. It works now, and it
works mostly really well, why does it need fixing so badly?

--tim

Footnotes:
[1] In real life I'm a tabloid journalist.

[2] Actually this isn't quite right: XEmacs + the most recent sumo
bundle (which is all the elisp packages, I think, or at least
it's all I ever fetch) is more than 2 million lines. I'm a
tabloid journalist, I'm allowed to lie.

Christopher Browne

unread,
Sep 26, 2002, 5:03:21 PM9/26/02
to
A long time ago, in a galaxy far, far away, Dave Bakhash <ca...@alum.mit.edu> wrote:
> CL already has a nice package system that would solve a lot of the
> namespace issues that Elisp has. Lexical scoping, an efficient object
> system, a more complete set of built-in functions and constructs...would
> together fix the problems that Elisp has now.

Bolting CLISP onto Emacs certainly has some attractive properties.

The one downside: CLISP doesn't support a threading system. If it
did, this would address the One Great Big Wishlist Item.
--
(concatenate 'string "aa454" "@freenet.carleton.ca")
http://www.ntlug.org/~cbbrowne/advocacy.html
Who's afraid of ARPA?

Dorai Sitaram

unread,
Sep 26, 2002, 5:30:55 PM9/26/02
to
In article <ey3smzw...@cley.com>, Tim Bradshaw <t...@cley.com> wrote:

>* Dave Bakhash wrote:
>
>> I don't think that the CL community realized the importance of a
>> complete version of Emacs done in CL, with the ability to process legacy
>> Emacs Lisp files. A version of Emacs, based on CLISP, would have done
>> wonders. The timing was right just before this aweful idea came up to
>> replacing elisp with Guile.
>
>I think it was discussed (among many other things...) when xemacs was
>still lemacs. I used to be on the mailing list but I didn't keep
>anything other than the most juicy stuff about great schism[1] so I
>can't remember any details.
>
>Personally I think the idea of replacing elisp by anything is (a)
>insane and (b) incredibly unlikely to happen.

The prevalence in the CL community of this quite
reasonable attitude, rather than any actual technical
barrier, may be why CL was able to successfully avoid
being considered as a candidate for successor to elisp.

>XEmacs *ships* with
>more than 2 million lines of emacs lisp[2], and I bet there is far
>more than that in code that is either not bundled or is not
>distributed at all (I have ~10,000 lines, I bet other people have as
>much or more). No one is going to convert that stuff before hell
>freezes over. So any replacement system has to *precisely* support
>the semantics of elisp, including all the weird gotchas, and it has to
>do it essentially for ever. And to what end? What will the huge win
>be? Sure, elisp is bad, but it's not that bad. The stuff that holds
>back big elisp systems isn't the terrible language or performance
>(other than in a few cases), it's that they're big and complicated and
>some of the emacs primitives suck. Easy wins would be adding proper
>packages and proper structures - these could be added in mostly
>transparently to old code. Gutting the system sounds like a vast
>amount of work for some mistaken idea of purity. It works now, and it
>works mostly really well, why does it need fixing so badly?

I find your reasoning quite understandable. Scheme is
only being used for something that the CL community
didn't want to touch anyway. This should answer
Dave Bakhash's unnecessarily regret-filled article.

Tim Bradshaw

unread,
Sep 26, 2002, 7:53:37 PM9/26/02
to
* Dorai Sitaram wrote:
> The prevalence in the CL community of this quite
> reasonable attitude, rather than any actual technical
> barrier, may be why CL was able to successfully avoid
> being considered as a candidate for successor to elisp.

> I find your reasoning quite understandable. Scheme is


> only being used for something that the CL community
> didn't want to touch anyway. This should answer
> Dave Bakhash's unnecessarily regret-filled article.

I think it's about wheel reinvention. I see that CL is a reasonable
wheel, and I'd rather get on and do stuff now. Similarly I consider
Emacs / Elisp a reasonable wheel, and I'd rather get on and do stuff
with it than gut the whole thing, yet again. I've watched the effects
of a much more minor gutting on emacs (the 18->19 transition and the
associated schism), and I'm pretty convinced that the much
larger change to a new lisp-dialect would be extremely traumatic.
Sometimes a wheel is good enough.

What is it with this endless desire to pull things to bits, again,
anyway, and the sneering at those who would rather do something else?
The IT/CS community needs to get its head round the fact that this
kind of thing can be *cripplingly* expensive, and that deciding not to
do it on grounds of cost is an absolutely *fine* reason. This stupid
`technical barrier' phrase is just so bloody *dumb*. It's like saying
there's no *technical* barrier to the US sending a manned mission to
Proxima Centuri. Sure, there isn't, but I guess most people in the
USA would kind of rather live in first world conditions rather than
blow the entire GDP of the country for the next hundred years on doing
it. Cost is a factor in engineering decisions and software used in
the real world, like it or not, is not some academic play thing.

The prevalence in the CL community of `this quite reasonable attitude'
is pretty much what I like about CL. It certainly isn't that CL is
some ultimate language: there probably are some parts of the language
that I wouldn't redesign if given a free hand, but I can't quite think
of any. But there's no such thing as a free hand in the real world:
redesign costs real money - lots and lots money. Even for CL,
incompatible changes would cost millions and millions of dollars.
Sometimes what you have is adequate to get real work done, and
stability is more important than reinvention.

Screwed-up initial design together with endless reinvention is why IT
is such a disaster. C not good enough for you? let's have C++, or
this other version of C++, or this one. No, let's reimplement in
Java. Or C#. Or Python. Perl. Ruby. SGML no good? Let's have XML.
Whoops, XML is no good, OK have these other standards which patch it.
Still not getting rich? Damn, have some more hacks. Your macro
system not hygenic? Have this one - just rewrite all those thousands
of lines of macros you've used for years. Upper case identifiers look
ugly? Use this incompatible hack. Don't like prefix syntax? Have
this similar-but-incompatible infix language - just rewrite your code,
why don't you? Just so long as we keep changing stuff fast enough and
waving our hands around *really fast* no one will notice how badly we
are screwing up and how much it is costing them.

Except, you know, they will. The 90s is over now, our hands have
finally parted company from our arms and the bubble has burst. Lots
of people spent billions of dollars on IT because it would transform
the economy and make everyone rich. Software would be too cheap to
meter: we would live in a `gift economy'. But somehow it didn't quite
happen - the economy is somehow untransformed, and all that money
seems to have vanished somewhere. 5% of e-commerce sites work, and 5%
of them ever made any money. But never fear, web services are here!
Just reinvent everything once again, use XML (it must work, it's so
big and complicated by now - how can anything that big not work), and
we'll all get rich this time. Right. Sure. I'll just do something
else, if you don't mind.

--tim

(my last post on this subject)

Kurt B. Kaiser

unread,
Sep 26, 2002, 9:03:37 PM9/26/02
to
Tim Bradshaw <t...@cley.com> writes:

> (my last post on this subject)

I doubt it. But that were a good 'un.

I refer to it my prediliction for sharpening tools instead of getting
work done, and I'm at _least_ as guilty as the next guy. Then there's
discussing the best way to sharpen tools....

You sharpen and sharpen, and the years go by....

KBK

Petr Swedock

unread,
Sep 27, 2002, 12:07:23 AM9/27/02
to
Tim Bradshaw <t...@cley.com> writes:

> * Dorai Sitaram wrote:
> > The prevalence in the CL community of this quite
> > reasonable attitude, rather than any actual technical
>

> I think it's about wheel reinvention. I see that CL is a reasonable
> wheel, and I'd rather get on and do stuff now. Similarly I consider
> Emacs / Elisp a reasonable wheel, and I'd rather get on and do stuff
> with it than gut the whole thing, yet again. I've watched the effects
> of a much more minor gutting on emacs (the 18->19 transition and the
> associated schism), and I'm pretty convinced that the much
> larger change to a new lisp-dialect would be extremely traumatic.
> Sometimes a wheel is good enough.
>
> What is it with this endless desire to pull things to bits, again,
> anyway, and the sneering at those who would rather do something else?

Why? Because the dialogue and the work, such as it is, is hijacked and
determined by the high priest of the church of recursive purity. RMS
isn't your regular 9to5 coder who owns a house, has a family, or even
a semblance of 'normal' life. He's a rather hedonistic monk with a
driven adolescent anti-hero ego AND all the free time that goes
with it... With the titular leadership of the open/free/whatever-
software movement solely because he's dedicated his full time to it.
The rest of us are out there earning money, worrying about rent,
having kids, etc; generally living a life not consumed by the politics
of code and the whims of an ascetic drive for perfection. He's a
MacArthur Genuis Grant gone horribly amok!

Stallman can re-invent the wheel as often as he likes because he's
got the luxury of that adolescent mentality and the support of people
who think his shit don't stink. And then there's the amen chorus
whe see RMS legitimating wheel-re-invention and become liberated
from doing actual work. Most code gets written by having one
person (the boss) direct requirements and specs at another person
(the coder). Not so with Stallman and by extension the FSF and
the question of cost doesn't even come into it.

One of the real problems in IT/CS/software is the un-sexy work that goes
un-done because many admins/engineers/coders lack discipline. RMS
exemplifies this. I've seen many a sysadmin, or network engineer, or
programmer who'd rather re-invent a dozen wheels, usually for the sake
of standing out or apart from the crowd, then to get the job done
right first, or by tweaking existing systems, or cleaning up prior
bad work: Stallman wants to replace Elisp with Guile because Elisp
has some problems that might not be there had he taken more care the
first time around.

Peace,

Petr

Friedrich Dominicus

unread,
Sep 27, 2002, 3:50:54 AM9/27/02
to
Petr Swedock <pe...@blade-runner.mit.edu> writes:
> Stallman wants to replace Elisp with Guile because Elisp
> has some problems that might not be there had he taken more care the
> first time around.
I agree with a lot you've written before but this is terrible
unfair. How often have you sit on code finding a first working
solution, but after that you polish it and it looks completly
different. You can put in as much effort as you want, you will always
find points after finishing that you consider bad done. Than you've to
decide
- fix it
- keep it

What I simply do not understand is that RMS has worked on Lisp
Machines, which do have had all the things in place like Packages, OO-Systems,
System development tools and and and, but nevertheless, he did not
keep that stuff in Emacs Lisp. I guess no-one will know what he has
thought about it while working on it I bet even he does not know any
longer.

It seems to me that Emacs Lisp falls even short behind the Lisps
available to that time. And that is what I can't understand.

Regards
Friedrich

Lars Brinkhoff

unread,
Sep 27, 2002, 2:43:26 AM9/27/02
to
Tim Bradshaw <t...@cley.com> writes:
> Personally I think the idea of replacing elisp by anything is (a)
> insane and (b) incredibly unlikely to happen. XEmacs *ships* with
> more than 2 million lines of emacs lisp, and I bet there is far more

> than that in code that is either not bundled or is not distributed
> at all (I have ~10,000 lines, I bet other people have as much or
> more). No one is going to convert that stuff before hell freezes
> over. So any replacement system has to *precisely* support the
> semantics of elisp, including all the weird gotchas, and it has to
> do it essentially for ever.

elisp.lisp in CLOCC seems to be a good start at loading elisp code
into a Common Lisp.

http://cvs.sf.net/cgi-bin/viewcvs.cgi/clocc/clocc/src/cllib/elisp.lisp?rev=2.10

--
Lars Brinkhoff http://lars.nocrew.org/ Linux, GCC, PDP-10,
Brinkhoff Consulting http://www.brinkhoff.se/ HTTP programming

Alain Picard

unread,
Sep 27, 2002, 6:08:04 AM9/27/02
to
ds...@goldshoe.gte.com (Dorai Sitaram) writes:

> Your message suggested that Emacs was tragically moving
> away from Lisp by switching to Guile, so I
> reassured you that it wasn't. Maybe I misread
> what exactly you were being regretful about.

You didn't misread him. He, and many others, think that
switching to Guile is moving away from lisp.

My only comfort is that I give them very long odds of success
with that project; there's just too damn much elisp code out
there.

Alain Picard

unread,
Sep 27, 2002, 6:11:04 AM9/27/02
to
Tim Bradshaw <t...@cley.com> writes:

> Easy wins would be adding proper
> packages and proper structures - these could be added in mostly
> transparently to old code.

Indeed. An emacs which efficiently implemented (require 'cl) out of the box
would be a nice start.

Getting more and more off topic, I noted that Xemacs can be compiled
with a whole bunch of different C libraries, to give (native) access to things
like databases, etc. A standardized elisp FFI? Anyone? :-)


Jeremy H. Brown

unread,
Sep 27, 2002, 11:58:19 AM9/27/02
to
Alain Picard <apicard+die...@optushome.com.au> writes:
> You didn't misread him. He, and many others, think that
> switching to Guile is moving away from lisp.

Can someone explain this to me? Seriously. What is it about Guile
that has less of the "True Lisp Essence" than Elisp?

Jeremy

Christopher Browne

unread,
Sep 27, 2002, 12:16:42 PM9/27/02
to
Quoth jhb...@ai.mit.edu (Jeremy H. Brown):

It's presumably some aspect of the "we despise Scheme" thing..
--
(reverse (concatenate 'string "moc.enworbbc@" "enworbbc"))
http://www.ntlug.org/~cbbrowne/x.html
JOHN CAGE (strapped to table): Do you really expect me to conduct this
antiquated tonal system?
LEONARD BERNSTEIN: No, Mr. Cage, I expect you to die!
[With apologies to music and James Bond fans the world over...]

Jeremy H. Brown

unread,
Sep 27, 2002, 12:23:54 PM9/27/02
to
Christopher Browne <cbbr...@acm.org> writes:
> It's presumably some aspect of the "we despise Scheme" thing..

If that's really all it is, I'll go back to bed now.

Jeremy

Friedrich Dominicus

unread,
Sep 27, 2002, 2:57:02 PM9/27/02
to

Don't ask such a question. You will get banned ;-) I guess I know some
of the answers, but I do not think that I agree with them. Anyway I do
not like Guile for diverse reasons. The most disturbing is that it's
full in spirit of NIH.

The re-invent things again and again and ...

Others mileage may vary but you will know for sure soon.

Regards
Friedrich

Thien-Thi Nguyen

unread,
Sep 27, 2002, 1:07:48 PM9/27/02
to
jhb...@ai.mit.edu (Jeremy H. Brown) writes:

> Can someone explain this to me? Seriously.

seems to be a (classic + recurrent => chronic) log[ix]or confusion:

(eval-in-context '(or guile elisp) 'human-language) => guile
(eval-in-context '(or guile elisp) 'GNU) => t

if a .el file needs to be changed that is almost certainly a bug. if people
don't follow future guidelines for new code that is a bug in the guidelines,
not the people. if people don't help form these guidelines that is a bug in
the process ultimately (giving rise to more bugs) concerning all the people.

for a wider interpretation:
s/a .el file/history/
s/guideline/law/
s/new code/day to day living/
s/process/society/
s/bug/misfortune/

you cannot harmonize the clans w/ logxor (although it is useful elsewhere,
like in screensavers and other cave-wall-watching exercises).

thi

ozan s yigit

unread,
Sep 27, 2002, 2:56:15 PM9/27/02
to
Friedrich Dominicus:

> The re-invent things again and again and ...

reminds me of a quote: "reinvention is commonplace in any field where
the inventors are amateurs."

oz
---
there is a fault in reality. do not adjust your minds. -- salman rushdie

Dorai Sitaram

unread,
Sep 27, 2002, 3:32:38 PM9/27/02
to
In article <86wup7n...@gondolin.local.net>,

Alain Picard <apicard+die...@optushome.com.au> wrote:
>He, and many others, think that
>switching to Guile is moving away from lisp.
>
>My only comfort is that I give them very long odds of success
>with that project; there's just too damn much elisp code out
>there.

What would you gain by their failure and/or what
would lose by their success?

Erik Naggum

unread,
Sep 27, 2002, 3:35:55 PM9/27/02
to
* Christopher Browne

| It's presumably some aspect of the "we despise Scheme" thing..

It is some aspect of the "let's discard all the community effort and start
over from scratch because we're smarter than everybody else" thing.

Each and every time someone in the Computer Science field has a Bright Idea,
the world had better be prepared to adapt, because Here Comes Genius and
everything everybody has done needs to be done differently from now on,
because This Genius Knows Best.

Gratuitous re-invention is very appealing to some people. It means that they
do not have to cope with anybody else's ideas. They may hope to garner
support behind them, but they sure are not going to be behind anybody else.

I have desired /longevity/ of things for as long back as I can remember. I
got involved with SGML because I thought it could help our data survive
beyond the application. (That was a mistake, of course. XML hit the fan and
now you cannot trust XML data any more than you trust binary files.) I have
been a strong fan of the 125-year-old Dewey Decimal Classification ever since
I learned it as a child from our school librarian. Such a large system that
has been both able to adapt and provide for long-range stability is no small
feat. I prefer a society based in the rule of law to groups of eager people
with bright ideas who ignore everything that has gone before them. It is not
only that I want some stability and predictability, I want to make sure that
we actually evolve. Computer Science is a field that shows some danger signs
of not evolving. Each and every Bright Idea is a revolution, and the primary
purpose of a revolusion is to throw away everything everybody had done up to
some point in time. Revolutions sometimes do work, but their cost in human
terms is /enormous/. Time and again we see that that which moves slowly from
here to there win and that which tries to make it across the incompatibility
abyss in one leap usually fall into it, instead.

The Novice has been the focus of an alarming amount of attention in the
computer field. It is not just that the preferred user is unskilled, it is
that the whole field in its application rewards novices and punishes experts.
What you learn today will be useless a few years hence, so why bother to
study and know /anything/ well? I think this is the main reason for the IT
winter we are now experiencing.

Of course, Scheme was /also/ a "let's have a revolution and make it better
this time" language, and as such is attractive to revolutionaries.

--
Erik Naggum, Oslo, Norway

Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.

Erik Naggum

unread,
Sep 27, 2002, 3:45:35 PM9/27/02
to
* Dorai Sitaram

| The prevalence in the CL community of this quite reasonable attitude, rather
| than any actual technical barrier, may be why CL was able to successfully
| avoid being considered as a candidate for successor to elisp.

Your paranoia only feeds those of us who think Scheme is dangerous.

| I find your reasoning quite understandable. Scheme is only being used for
| something that the CL community didn't want to touch anyway. This should
| answer Dave Bakhash's unnecessarily regret-filled article.

Your need to defend Scheme so hysterically must have some deeper causation
that makes sane people want to avoid Scheme after watching the Scheme
defenders in action. You do Scheme a great disservice. Then again, that
may be a good thing in the really big picture, so perhaps I should not ask
you to stop, after all. However, I think posting Scheme paranoia in this
newsgroup is also hurtful to Common Lisp. People will have reason to wonder
whether Common Lisp people are insane with regards to Scheme whether they
love it or hate it. That is not good for Common Lisp.

Jeremy H. Brown

unread,
Sep 27, 2002, 3:53:55 PM9/27/02
to
Erik Naggum <er...@naggum.no> writes:
> It is some aspect of the "let's discard all the community effort and start
> over from scratch because we're smarter than everybody else" thing.

If you actually went and read the emacs-guile description, you'd note
that the stated intent of that project (I won't speak to random RMS
statements in other places) is not to eliminate elisp, but rather to
integrate guile as another option. Nothing that has gone before is
lost. What is available to those who come after is more flexible than
before. Where's the harm?

Jeremy

Bulent Murtezaoglu

unread,
Sep 27, 2002, 4:29:03 PM9/27/02
to
>>>>> "EN" == Erik Naggum <er...@naggum.no> writes:
[...]
EN> Each and every time someone in the Computer Science field
EN> has a Bright Idea, the world had better be prepared to adapt,
EN> because Here Comes Genius and everything everybody has done
EN> needs to be done differently from now on, because This Genius
EN> Knows Best.

I don't know if "This Genius" himself is to blame for this. There
usually are other factors to consider. While I am fairly certain that
the geniuses (genii?) in question usually have the stuff to back up
their arrogance their marketing apparatus clearly lacks it. As do,
unfortunately, the targets of that marketing themselves.

EN> Gratuitous re-invention is very appealing to some people.
EN> It means that they do not have to cope with anybody else's
EN> ideas. They may hope to garner support behind them, but they
EN> sure are not going to be behind anybody else.

There's also some percieved economy in there, in a way. Reinvention
sometimes takes less time than understanding the state of the art. This
perception is usually misleading, but not always.

EN> I have desired /longevity/ of things for as long back as I
EN> can remember.

You are in good company. Knuth does also (re: TeX).

EN> I got involved with SGML because I thought it
EN> could help our data survive beyond the application. (That was
EN> a mistake, of course. XML hit the fan and now you cannot
EN> trust XML data any more than you trust binary files.) [...]

Am I wrong in assuming that with XML you are roughly as safe as you would
be with a _documented_ binary format?

[...]
EN> The Novice has been the focus of an alarming amount of
EN> attention in the computer field. It is not just that the
EN> preferred user is unskilled, it is that the whole field in its
EN> application rewards novices and punishes experts.

It is unclear what 'expert' means any more. The blind has been
leading the blind for so long that sight is becoming irrelevant in
signifacnt parts of the marketplace.

EN> What you
EN> learn today will be useless a few years hence, so why bother
EN> to study and know /anything/ well? [...]

It is _worse_ than that. The semantics of knowing anything well is
shifting. I am noticing that (and Tim B. sometimes reminds me) that
most of our grumpy observations (rants?) here are observations about
_literacy_. You are implying a conscious decision above -- I am not so
sure about that.

cheers,

BM

Erann Gat

unread,
Sep 27, 2002, 4:40:02 PM9/27/02
to
In article <32421441...@naggum.no>, Erik Naggum <er...@naggum.no> wrote:

> Of course, Scheme was /also/ a "let's have a revolution and make it better
> this time" language, and as such is attractive to revolutionaries.

This is revisionist history. Scheme was an accident, as related by
Sussman and Steele in [1]:

"Sometimes a judicious designer can sort through the accumulated set of
ideas, discard the less important ones, and produce a new design that is
small and clean. ... Scheme wasn't like that at all. We were actually
trying to build something complicated and discovered, serenedipitously,
that we had accidentally designed something that ... was much simpler than
we had intended."

Erann Gat
g...@jpl.nasa.gov

----
References

[1] Sussman and Steele, Journal of Higher Order and Symbolic Computation,
1, 399-404(1998).

Kurt B. Kaiser

unread,
Sep 27, 2002, 6:13:09 PM9/27/02
to
Erik Naggum <er...@naggum.no> writes:
[...]
> I have desired /longevity/ of things for as long back as I can
> remember. I got involved with SGML because I thought it could
> help our data survive beyond the application. (That was a
> mistake, of course. XML hit the fan and now you cannot trust XML
> data any more than you trust binary files.) I have been a strong
> fan of the 125-year-old Dewey Decimal Classification ever since I
> learned it as a child from our school librarian. Such a large
> system that has been both able to adapt and provide for long-range
> stability is no small feat.

I always thought it better than the Library of Congress system. When
they introduced that I was very young, but I remember thinking, "Who
needs that? Dewey is fine, and I know it! Why do I have to start
over?"

> I prefer a society based in the rule of law to groups of eager
> people with bright ideas who ignore everything that has gone
> before them. It is not only that I want some stability and
> predictability, I want to make sure that we actually evolve.
> Computer Science is a field that shows some danger signs of not
> evolving. Each and every Bright Idea is a revolution, and the
> primary purpose of a revolusion is to throw away everything
> everybody had done up to some point in time. Revolutions
> sometimes do work, but their cost in human terms is /enormous/.
> Time and again we see that that which moves slowly from here to
> there win and that which tries to make it across the
> incompatibility abyss in one leap usually fall into it, instead.

True, but I think people are realizing that the "bright ideas" are
over-hyped and don't pan out. You get burned out after a dozen or so.
The "solutions" are getting increasingly frothy and lightweight.

Object-oriented design is down to half a shelf at my local Borders,
and Java's decreasing markedly. C/C++ holding its own. .NET's coming
up. Whole sections on Web tools, Maya, etc., though. The
"programmers" are mostly just users these days.

Sadly, no Lisp books whatsoever most of the time.

> The Novice has been the focus of an alarming amount of attention
> in the computer field. It is not just that the preferred user is
> unskilled, it is that the whole field in its application rewards
> novices and punishes experts. What you learn today will be
> useless a few years hence, so why bother to study and know
> /anything/ well? I think this is the main reason for the IT
> winter we are now experiencing.

As soon as you learn Pearl there's Python, then hey, it's Ruby! HTML
begets XHTML, then we start again with XML. But most of the new stuff
is just applications to create end user content, or toolboxes to wire
up and maintain systems.

The alphabet soup in the job ads is astounding. Who has time to
become an expert before it all changes again?

> Of course, Scheme was /also/ a "let's have a revolution and make
> it better this time" language, and as such is attractive to
> revolutionaries.

That's true. OTOH, it predates CL by about eight years. Some of the
"revolutionary" Scheme concepts, like lexical scope, influenced the
design of CL.

And the revolutionaries have white hair by now and take laxatives :)

In the case of CL, it was "let's form a federation and resolve our
differences." Scheme is, for practical purposes, an academic language
(let them play, for heavens sake!!), while CL is by far our best
production language, even though it's a camel.

"The Evolution of Lisp" [0] has many interesting and amusing remarks
on the origin of CL (among other things) and gives a flavor of the era:

===========
[...]

"The MacLisp-descended groups came off in a way that can be best
demonstrated with an anecdote. Each group stood up and presented
where they were heading and why. Some questions arose about the
ill-defined direction of the MacLisp community in contrast to the
Interlisp community. Scott Fahlman said, "the MacLisp community is
not in a state of chaos. It consists of four well-defined groups
going in four well-defined directions." There was a moment's pause
for the laughter to subside.

Gabriel attended the Interlisp pow-wow the day before the ARP meeting,
and he also witnessed the spectacle of the MacLisp community at the
meeting. He didn't believe that the differences between the MacLisp
groups were insurmountable, so he began to try to sell the idea of
some sort of cooperation among the groups."

[this may be just Gabriel tooting his horn :-]

[...]

"After a day and a half of technical discussion, this group went off
to the Oakland Original, a greasy submarine sandwich place not far
from CMU. During and after lunch the topic of the name for the Lisp
came up, and such obvious names as NIL and SPICE Lisp were proposed
and rejected--as giving too much credit to one group and not enough to
others--and such non-obvious names as Yu-Hsiang Lisp were also
proposed and reluctantly rejected.
[...]
Later in E-mail, Moon referred to "whatever we call this common Lisp,"
and this time, amongst great sadness and consternation that a better
name could not be had, it was selected."

[...]

"The [draft of the manual], called the Swiss Cheese Edition--because it
was full of large holes--was partly a ballot in which various
alternatives and yes-no questions were proposed.
[...]
Three more drafts were made--the Colander Edition (July 29, 1982), the
Laser Edition (November 16, 1982), and the Mary Poppins Edition. The
cute names are explained by their subtitles:

Colander: Even More Holes Than Before--But They're Smaller!

Laser Edition: Supposed to be Completely Coherent

Mary Poppins Edition: Practically Perfect in Every Way

The final draft was the Excelsior Edition. Recall that "excelsior" is
not only a term of high praise but also the name for shredded paper
used as packing material."

===========

Some things don't change. After 20 years, we're still arguing. In
fact, we have a whole new generation of arguers! OTOH, both CL and
Scheme have been pretty stable (ossified?) over that period.

Surely CL isn't the last Lisp. I suspect that one of these days a
wholly new Lisp will pop up from somewhere and everyone will jump on
it. Until then, IMO, we should support the CL federation as the
practical solution for production work. Gradual change might be
practical for sparrows or English, but it's not going to work for
production Lisp.

(But I think they had more fun in the old days.)

KBK

[0] Gabriel and Steele, http://citeseer.nj.nec.com/steele93evolution.html

Christopher Browne

unread,
Sep 27, 2002, 6:35:26 PM9/27/02
to
After takin a swig o' grog, Bulent Murtezaoglu <b...@acm.org> belched out...:

>>>>>> "EN" == Erik Naggum <er...@naggum.no> writes:
> EN> I got involved with SGML because I thought it
> EN> could help our data survive beyond the application. (That was
> EN> a mistake, of course. XML hit the fan and now you cannot
> EN> trust XML data any more than you trust binary files.) [...]

> Am I wrong in assuming that with XML you are roughly as safe as you
> would be with a _documented_ binary format?

The problem with XML is that the W3C keeps on having to modify the
standards because people need one extension or another.

Pretty characteristic of this is to compare XML-RPC to SOAP.

SOAP keeps getting "extended" as companies lobby for one piece of
extended functionality or another. I'm currently editing/reviewing a
book on "Web Services Security," and am pretty nonplussed by the
tremendously frivolous set of security additions that people keep
making. By the time SOAP gets as aged as CORBA, it is unlikely that
anyone will be able to /imagine/ creating a "complete" SOAP
implementation.

And it's NOT 'changing subjects' for me to talk about SOAP rather than
'just XML.' The problems that occur with SOAP are likely to be pretty
nicely characteristic of /any/ "XML Application." Any of the
"interesting" XML Applications are fair game for the 'dueling
standards' game where different companies propose differing layered
standards at OASIS/IETF/W3C.

By the way, the specification for XML-RPC, which SOAP was based on,
fits on two pages. But none of the big companies are interested in
XML-RPC. It's probably comparable with SOAP in much the same manner
that "Algol60 was superior to many of its successors."


--
(reverse (concatenate 'string "moc.enworbbc@" "enworbbc"))

http://cbbrowne.com/info/
Sleep is a poor subsititute for caffeine. -Pat Dughi

ozan s yigit

unread,
Sep 27, 2002, 6:55:41 PM9/27/02
to
g...@jpl.nasa.gov (Erann Gat) writes:

> This is revisionist history. Scheme was an accident, as related by
> Sussman and Steele in [1]:

another paper that may provide insight into why, when, how etc. is
the excellent Steele/Gabriel "the evolution of lisp" paper from the
second HOPL in 1993. it is probably online someplace, though i doubt
it would include the presentation transcript and the assorted family
graphs. it may answer some questions for some people. the book that
was published after the conference is an indispensible reference
for PL types, if it is still in print.

oz
---
[1] Thomas J. Bergin and Richard G. Gibson (eds)
History of Programming Languages
Addison-Wesley, 1996
--

Bruce Stephens

unread,
Sep 27, 2002, 7:33:34 PM9/27/02
to
ozan s yigit <o...@blue.cs.yorku.ca> writes:

> g...@jpl.nasa.gov (Erann Gat) writes:
>
>> This is revisionist history. Scheme was an accident, as related by
>> Sussman and Steele in [1]:
>
> another paper that may provide insight into why, when, how etc. is
> the excellent Steele/Gabriel "the evolution of lisp" paper from the
> second HOPL in 1993. it is probably online someplace,

<http://citeseer.nj.nec.com/steele93evolution.html>

[...]

ozan s yigit

unread,
Sep 27, 2002, 8:45:10 PM9/27/02
to
Bruce Stephens <bruce+...@cenderis.demon.co.uk> writes:

> <http://citeseer.nj.nec.com/steele93evolution.html>

ah. since i have the book, i never bothered to search for it.

oz
--
take the long short cut. -- animation rule of thumb (richard williams)

Alain Picard

unread,
Sep 27, 2002, 9:14:35 PM9/27/02
to
ds...@goldshoe.gte.com (Dorai Sitaram) writes:

The answer to both questions is the same; what is at stake is not
having to learn yet another language; one, moreover, whose essence is
_less_ like what I want, rather than more (i.e., if anything, I want
elisp to be more like CL). I pretty much understand elisp; I can
read 3rd party extensions, see what they do, fix things which don't
work.

Am I lazy to not want to learn another language? You bet. The combined
laziness of myself and thousands of other elisp hackers should count for
something, it seems to me.

Pascal Costanza

unread,
Sep 27, 2002, 10:17:13 PM9/27/02
to
ozan s yigit wrote:
> g...@jpl.nasa.gov (Erann Gat) writes:
>
>>This is revisionist history. Scheme was an accident, as related by
>>Sussman and Steele in [1]:
>
>
> another paper that may provide insight into why, when, how etc. is
> the excellent Steele/Gabriel "the evolution of lisp" paper from the
> second HOPL in 1993. it is probably online someplace, though i doubt
> it would include the presentation transcript and the assorted family
> graphs.

Both the proceedings version and an uncut version are available at
http://www.dreamsongs.com/Essays.html; if you take a closer look at the
description of this paper you will also find a link to the downloadable
slides.

Pascal


John Paul Wallington

unread,
Sep 27, 2002, 11:23:59 PM9/27/02
to
jhb...@ai.mit.edu (Jeremy H. Brown) wrote:

> If you actually went and read the emacs-guile description, you'd note
> that the stated intent of that project (I won't speak to random RMS
> statements in other places) is not to eliminate elisp, but rather to
> integrate guile as another option.

Do you mean http://sourceforge.net/projects/gemacs/ ?

"Guile Emacs is a variant of Emacs which is integrating the
Guile Scheme interpreter as an extension language in addition to
Emacs Lisp."

Because that isn't Emacs.

Or do you mean http://www.mit.edu/~raeburn/guilemacs/ ?

Guile-based Emacs: "This project that I (Ken Raeburn) have started is
for converting GNU Emacs to use Guile as its programming
language. Backwards support for Emacs Lisp will continue to exist, of
course, but it'll be through translation and/or interpretation; the
Lisp engine itself will no longer be the core of the program."

--
John Paul Wallington

Erik Naggum

unread,
Sep 27, 2002, 11:31:26 PM9/27/02
to
* Jeremy H. Brown
| Where's the harm?

Have you ever tracked Emacs versions over an extended period of time and
seen how much Emacs Lisp changes in a five-year period? Have you ever
tracked anything that attempted to have two interfaces over an extended
period of time?

The definite harm is that Emacs Lisp and Guile /will/ diverge and that one
is more maintained than the other, but even so, the community effort that
goes into Emacs will need to be increased just to maintain status quo.

And where are all the /new/ users and developers for Emacs coming from?

Erik Naggum

unread,
Sep 27, 2002, 11:52:44 PM9/27/02
to
* Bulent Murtezaoglu

| Reinvention sometimes takes less time than understanding the state of the
| art. This perception is usually misleading, but not always.

Right now, I am working with project to evaluate the applicability of Dewey
for automated classification, compared to the Open Directory stunt. My main
objection to such stunts it that they get can easily get very enthusiastic
people at the start of the project, but over time need paid staff to maintain
them and it develops into the dreaded "committee work" when it becomes
successful. My take on this is actually deeply social: It is not successful
until it becomes a "democratic" committee project. The idiot individualist
with megalomania will think that others are his inferiors, that people who
work in groups never get anything done while he can get a lot done alone.

A system needs to be alive and workable even when other people than the first
enthusiasts start using it. Reinvention and revolution are enthusiast stuff.
Invention and evolution are engineering.

| Am I wrong in assuming that with XML you are roughly as safe as you would be
| with a _documented_ binary format?

It is a myth that XML is documented. You have no idea what the elements
/actually/ mean (and have warped into over time) until you see the source code
for the application. XML becomes /more/ application-dependent over time than
binary formats because it provides a false security and an appearance that
belies its true nature. XML /is/ a binary format, it is just that it is the
kind of binary formats that line printers and raw text editors can use, too,
and it is no less dependent on the exactness and precision that other binary
formats require. At least when you have a binary format, you know that you
need to have a version field and proper version management. People who think
SGML or XML will save them tend to forget version management and rely on
stupid human tendencies to believe that that which they can "read" must also
be understandable to the machine. The combination of ignorance of computing
principles and programming with the kind of fuzzy thinking we find in people
who have never paid attention to details is seriously deadly to information.

| It is unclear what 'expert' means any more. The blind has been leading the
| blind for so long that sight is becoming irrelevant in signifacnt parts of
| the marketplace.

It saddens me to find that I think this is very good summary of the situation.

| It is _worse_ than that. The semantics of knowing anything well is shifting.
| I am noticing that (and Tim B. sometimes reminds me) that most of our grumpy
| observations (rants?) here are observations about _literacy_. You are
| implying a conscious decision above -- I am not so sure about that.

You may be right. I am far more conscious in general than other people.
But with these saddening words, I shall go and be unconscious for a while.

Erik Naggum

unread,
Sep 27, 2002, 11:55:13 PM9/27/02
to
* Erann Gat
| This is revisionist history.

Really? What you quoted was not in any way contradicting what I said.

Erann Gat

unread,
Sep 28, 2002, 1:42:12 AM9/28/02
to
In article <32421741...@naggum.no>, Erik Naggum <er...@naggum.no> wrote:

> * Erann Gat
> | This is revisionist history.
>
> Really? What you quoted was not in any way contradicting what I said.

PETRUCHIO. I say it is the moon.
KATHERINA. I know it is the moon.
PETRUCHIO. Nay, then you lie; it is the blessed sun.
KATHERINA. Then, God be bless'd, it is the blessed sun;
But sun it is not, when you say it is not;
And the moon changes even as your mind.
What you will have it nam'd, even that it is,
And so it shall be so for all readers of comp.lang.lisp

E.

Erik Naggum

unread,
Sep 28, 2002, 9:53:29 AM9/28/02
to
* Erann Gat
[ typical Erann Gat response ]

Your lack of ability to argue for your case must be seen as agreement that
it was not in any way contradicting what I said. This is progress.

Erann Gat

unread,
Sep 28, 2002, 12:51:07 PM9/28/02
to
In article <32422100...@naggum.no>, Erik Naggum <er...@naggum.no> wrote:

> * Erann Gat
> [ typical Erann Gat response ]
>
> Your lack of ability to argue for your case must be seen as agreement that
> it was not in any way contradicting what I said. This is progress.

It is a lack of willingness, not a lack of ability (though you may
consider it progress nonetheless). I am sick and tired of arguing with
you. My intent in responding to your comment about Scheme was not to
start an argument, but to make other people who might be reading that
thread aware of a fairly obscure historical fact. I leave it up to them
to decide whether what I quoted contradicts what you said or not.

If you (or anyone else) want to know why I think that what I quoted does
contradict your position (as if it isn't blatantly obvious) then *ask* me,
and I'll be happy to answer. But if you simply want to state flat-out
that it doesn't, then fine, it is the blessed sun. I have had my fill of
pointless pissing matches.

E.

Erik Naggum

unread,
Sep 28, 2002, 2:56:06 PM9/28/02
to
* Erann Gat

| I am sick and tired of arguing with you.

You may wish to read an article I posted recently on the indecency of
flaunting your personal problems for others to care about in public.

If you are so sick and tired, the rational response is not to do what you are
so sick and tired of. Having to tell the whole world that you are sick and
tired only communicates to that world that you have such huge problems coping
with your own emotions that you need professional care to get over them and
start to take charge of your own life and take responsibility for your own
actions. /You/ and /only/ you are responsible for continuing to do what you
are so sick and tired of. Your immense lack of intelligent response to your
exasperation is not to your professional credit.

| I leave it up to them to decide whether what I quoted contradicts what you
| said or not.

No, you don't. You want to control other people's conclusions. Be honest.

| I have had my fill of pointless pissing matches.

If that were so, you would simply not engage in more of them, would you? So
it is simply not true. You want to blame the people you piss on for your own
stupid behavior. That is so disgusting that words fail to describe it. Quit!

Grow the hell up, Erann Gat. And, /please/ seek professional help with your
coping problems. This is not a good place to tell the whole world that you
are unable to act rationally on your disturbed emotions. I consider you to
be a disgusting disgrace to the community because you never seem to be able
to hold your emotions back from poisoning your interactions with others. You
rank near the top of the most /unprofessional/ people I have ever met.

And do us all a huge favor and shut the fuck up about how badly you feel.
/Do/ something to feel better, damnit!

--
Erik Naggum, Oslo, Norway Today, the sum total of the money I
would retain from the offers in the
more than 7500 Nigerian 419 scam letters received in the past 33 months would
have exceeded USD 100,000,000,000. You can stop sending me more offers, now.

ilias

unread,
Sep 28, 2002, 3:36:21 PM9/28/02
to

as i've said again: you are fascinating ungentle!

and i've never saw again so precise argumentation-lines against 'one-self'!

but i've to assimilate lisp.

-

cool down.

drink water.

Erann Gat

unread,
Sep 28, 2002, 4:19:11 PM9/28/02
to
In article <32422281...@naggum.no>, Erik Naggum <er...@naggum.no> wrote:

> you never seem to be able to hold your emotions back from poisoning your
> interactions with others

and

> Grow the hell up,

> shut the fuck up

Res ipsa loquitur.

But, sigh, we have had *this* conversation before too.

E.

Erik Naggum

unread,
Sep 28, 2002, 6:14:40 PM9/28/02
to
* Erann Gat

| But, sigh, we have had *this* conversation before too.

What is /wrong/ with you? Do you /have/ to keep pissing on me?

I am beginning to think you are about as toxic as ilias to this forum.

Tim Josling

unread,
Sep 28, 2002, 6:53:06 PM9/28/02
to
Erik Naggum wrote:
>
> It is a myth that XML is documented. You have no idea what the elements
> /actually/ mean (and have warped into over time) until you see the source code
> for the application. XML becomes /more/ application-dependent over time than
> binary formats because it provides a false security and an appearance that
> belies its true nature. XML /is/ a binary format, it is just that it is the
> kind of binary formats that line printers and raw text editors can use, too,
> and it is no less dependent on the exactness and precision that other binary
> formats require. At least when you have a binary format, you know that you
> need to have a version field and proper version management. People who think
> SGML or XML will save them tend to forget version management and rely on
> stupid human tendencies to believe that that which they can "read" must also
> be understandable to the machine. The combination of ignorance of computing
> principles and programming with the kind of fuzzy thinking we find in people
> who have never paid attention to details is seriously deadly to information.
>

XML is an encoding format, no more than that. It is a pretty good encoding
format because it is relatively simple and semi-human-readable, though
verbose. Compare with the alteratives - ad hoc binary formats or the IEEE's
binary format monstrosity whose name I forget.

But it is not a content model. It does not try to be a content model. It does
not define what any/every tag means. You have to define the content model.
Sometimes the tag name gives you an idea what the field means.

Content models all have problems:

Semantic drift - the meaning of fields gradually change.
Redefinition of tags e.g. if employee type is 'CEO' then salary is in millions
of dollars not dollars.
Dialects - different people use the message in different incompatible
undocumented ways.
Lack of clarity about which fields are optional and which are compulsary, and
what are the relationships between fields.

You can't blame this on XML. But nor does XML solve them, except in the
mendacious minds of marketing people.

Tim Josling

Erik Naggum

unread,
Sep 28, 2002, 10:28:24 PM9/28/02
to
* Tim Josling

| XML is an encoding format, no more than that.

You may find it illuminating to do a web search on my name and SGML.

| It is a pretty good encoding format because it is relatively simple and
| semi-human-readable, though verbose. Compare with the alteratives - ad hoc
| binary formats or the IEEE's binary format monstrosity whose name I forget.

As long as you actually believe that such are the alternatives, yes, XML is
better than the completely braindamaged. However, if you start to think
about the problem, XML starts to become an idiotic non-solution that only
creates more problems than it solves. It has all the disadvantages of an ad
hoc binary format, and none of the benefits -- namely compactness and
version sensitivity.

I am actually flabbergasted that anyone reading comp.lang.lisp would /not/
understand how to make something better than XML and even carp on this
"ad-hoc binary format" non-argument. You /do/ realize that Common Lisp
offers a ready-made data syntax, as well, do you not?

| But it is not a content model. It does not try to be a content model. It
| does not define what any/every tag means. You have to define the content
| model. Sometimes the tag name gives you an idea what the field means.

Again, do a quick search for the SGML bibliography. You may find that you
have embarrassed yourself, but if you have any new arguments that I have not
heard in the past 12 years, please feel free to present them after you have
familiarized yourself with what I have done in the SGML arena.

| You can't blame this on XML.

I can, and I do. Languages come with philosophies from which they cannot be
separated. The XML philosphy is stale, stupid, and counter-productive
relative to its own stated goals, among which the most important was supposed
to be the independence of data from the application, which is actually worse
with XML than even /your/ "alternatives".

--

ozan s yigit

unread,
Sep 28, 2002, 11:25:56 PM9/28/02
to
Tim Josling <t...@melbpc.org.au> writes:

> ... ad hoc binary formats or the IEEE's


> binary format monstrosity whose name I forget.

maybe you are thinking of ISO/OSI ASN.1... it is not really that
monstrous in its basic form, though it does have a macro system that
can make things very, very hairy...

oz
---

Tim Josling

unread,
Sep 29, 2002, 3:03:06 AM9/29/02
to
ozan s yigit wrote:
>
> Tim Josling <t...@melbpc.org.au> writes:
>
> > ... ad hoc binary formats or the IEEE's
> > binary format monstrosity whose name I forget.
>
> maybe you are thinking of ISO/OSI ASN.1... it is not really that
> monstrous in its basic form, though it does have a macro system that
> can make things very, very hairy...

Yes it is ASN.1. I personally prefer XML myself, but MYYV.

Tim Josling

Tim Josling

unread,
Sep 29, 2002, 3:22:17 AM9/29/02
to
Erik Naggum wrote:
>
> * Tim Josling
> | XML is an encoding format, no more than that.
>
> You may find it illuminating to do a web search on my name and SGML.
>
> | It is a pretty good encoding format because it is relatively simple and
> | semi-human-readable, though verbose. Compare with the alteratives - ad hoc
> | binary formats or the IEEE's binary format monstrosity whose name I forget.
>
> As long as you actually believe that such are the alternatives, yes, XML is
> better than the completely braindamaged. However, if you start to think
> about the problem, XML starts to become an idiotic non-solution that only
> creates more problems than it solves. It has all the disadvantages of an ad
> hoc binary format, and none of the benefits -- namely compactness and
> version sensitivity.
>

I keep my financial records in the form of a lisp object, so I understand that
lisp has an alternetive here. But it does not solve the problem of defining
the content model.

One project I worked on chose XML as the basis for the data format because

1. It is human readable and editable.
2. It is language and platform independent, more or less.
3. It is simple.
4. Vendor and tool support is good.

XML does not solve a lot of problems.

It does not define a content model. Until recently there was no standard
method to include binary data. Version control. So we added solutions to those
to our in house standard.

It has worked well. To me it has evident advantages that binary formats lack
i.e. ease of debugging. You can look at a message and see if it is OK which is
not possible e.g. with ASN.1. Free/cheap friendly editors exist.

> I am actually flabbergasted that anyone reading comp.lang.lisp would /not/
> understand how to make something better than XML and even carp on this
> "ad-hoc binary format" non-argument. You /do/ realize that Common Lisp
> offers a ready-made data syntax, as well, do you not?
>
> | But it is not a content model. It does not try to be a content model. It
> | does not define what any/every tag means. You have to define the content
> | model. Sometimes the tag name gives you an idea what the field means.
>
> Again, do a quick search for the SGML bibliography. You may find that you
> have embarrassed yourself, but if you have any new arguments that I have not
> heard in the past 12 years, please feel free to present them after you have
> familiarized yourself with what I have done in the SGML arena.
>

I found it but it is not evident to me what you are talking about. Searching
the sgml bib for your name produces 0 hits...

> | You can't blame this on XML.
>
> I can, and I do. Languages come with philosophies from which they cannot be
> separated. The XML philosphy is stale, stupid, and counter-productive
> relative to its own stated goals, among which the most important was supposed
> to be the independence of data from the application, which is actually worse
> with XML than even /your/ "alternatives".
>

My main beef with XML is that it is very oriented to 'text'. Thus the lack of
support for binary data, etc. That just reflects its origins. What do 'text
guys' care about binary data, or compaction for that matter?

If someone claimed XML makes data and applications independent, they were
lying. Unfortunately that it all too common in IT. We have found though that a
message passing architecture does help keep applications from becoming
pathologically coupled. However the determined programmer can still make it
happen if he wants to.

However I don't think anything known to date will solve the problem of making
programs data independent.

To do that would require creating a universal knowledge schema from which all
message types could be subclassed or otherwise derived.

Tim Josling

Erik Naggum

unread,
Sep 29, 2002, 3:43:57 AM9/29/02
to
* Tim Josling

| Yes it is ASN.1. I personally prefer XML myself, but MYYV.

Do you prefer XML to Common Lisp? Have you ever implemented anything that
talks ASN.1 in the native language compared to implementing something based
on DOM?

Knocking ASN.1 is common and accepted in some circles. I have yet to meet
one person who has been critical of ASN.1 who has any idea what it is like.
It has this property in common with Common Lisp -- it is usually attacked
only by people who have no idea what the language is like. It is an amazing
property of people who think they are so smart they do not need to know
something before they make pronouncement about it that they do not even
understand that their credibility is blown to bits. It is probably part of
the exaltation of illiteracy in the part of society that works with IT.

By the way, the SGML Document Interchange Format (ISO 9069) uses ASN.1 to
ship SGML documents around. I wrote an implementation of SDIF in three days.
Test runs showed that a major CALS application consumed approximately 40% of
the character count of the SGML file, and with the then commonly available
tools to parse and process SGML documents and ASN.1 processors, the SDIF data
stream took around 1/200th as much CPU time and about 75% of the memory to
reconstruct the identical in-memory version of the document. This experiment
was among the many data points that led me to conclude that SGML is insane
and that those who think it is rational to require parsing of character data
at each and every application interface are literally retarded and willfully
blind. Also, an SDIF data stream can only represent a validated document and
the kinds of errors you get when parsing ASN.1 are unforgiving. There is no
doubt in my mind that if SDIF had won over the insanely verbose text format,
even things like HTML would have been moderately sane. Not to mention the
fact that images could have been carried in the same data stream. The world
would have been a better place if SDIF had won over HTML, and if the nutjobs
who "invented" XML had been moderately in touch with reality, they would have
realized the insanity of requiring the verbose end-tags and the stupid syntax.
XML-RPC and SOAP and the like could have been fairly inexpensive things.
But, alas, people prefer buggy text formats that they can approximate rather
than precise binary formats that follow general rules that are make them as
easy to use as text formats. Rationality is not part of the SGML philosophy,
however, and SDIF was mainly an effort to keep the ODA and ODIF folks at bay
and was a purely political stunt, not intended to be implemented. When I
went ahead and did it, I was not exactly applauded for the effort. The fact
that it was /vastly/ more efficient in all respects than the stupid character
syntax was /most/ unwelcome by the community.

So, what is your actual experience with ASN.1?

--

Erik Naggum

unread,
Sep 29, 2002, 4:06:57 AM9/29/02
to
* Tim Josling
| [XML] does not define a content model.

Look, you are repeating this as if it is an argument. It is like saying that
Common Lisp does not define an application and shows a lack of insight.

| You can look at a message and see if it is OK which is not possible e.g.
| with ASN.1.

This is just plain wrong.

| Free/cheap friendly editors exist.

No difference from ASN.1 here.

| Searching the sgml bib for your name produces 0 hits...

Why make such a fool of yourself annoying people on purpose? What is /wrong/
with you? http://www.oasis-open.org/cover/biblio.html

| My main beef with XML is that it is very oriented to 'text'.

Wrong on this count, too. Do you have /any/ clue what you are talking about?

| Thus the lack of support for binary data, etc. That just reflects its
| origins. What do 'text guys' care about binary data, or compaction for that
| matter?

Enough to make very good to excellent support for it, given the framework.
XML's /origins/ were SGML and SGML has NOTATION declarations to communicate
the meaning of non-SGML data held in external entities. Most XML nuts do not
understand the entity structure in SGML so reinvent it badly, but generally
fail so miserably that they should feel ashamed.

You clearly are clueless and are not at all ashamed to demonstrate it.

| However I don't think anything known to date will solve the problem of making
| programs data independent. To do that would require creating a universal
| knowledge schema from which all message types could be subclassed or
| otherwise derived.

*SIGH* This does not even merit comment. You are in a /Lisp/ newsgroup, for
crying out loud! Why are you posting here? Did a google search for XML and
just had to chip in or something?

Tim Bradshaw

unread,
Sep 29, 2002, 6:30:07 AM9/29/02
to
* Erik Naggum wrote:

> Gratuitous re-invention is very appealing to some people. It means that they
> do not have to cope with anybody else's ideas. They may hope to garner
> support behind them, but they sure are not going to be behind anybody else.

This is a very interesting point, I think.

A related point, it seems to me, is that reinvention is more-or-less
inevitable if the existing art is so bad that coping with it is too
hard. So one escape from the wheel of reinvention is to try and come
up with systems that are well designed in the first place. This is
obvious of course, but it explains quite a lot.

Two concrete examples.

1. Anyone who's read my previous article(s?) in this thread knows I
think redoing emacs in scheme *or CL*[1] is insane. Well, the
underlying reason for that is that I think the existing system is
not too bad. Of course Emacs Lisp is far from perfect - I think
it's probably the worst Lisp in common use - but it's not *bad*,`
and the `API' to emacs is pretty usable. And there isn't some
enormous wall you have to climb before doing any programming of
emacs as far as I can see - people start by setting a few variables
and end up writing GNUS or something. So we have an acceptably good
system already - the desire to reinvent it indicates something bad.

2. Anyone who has read the drivel I write for a bit longer knows my
feelings about XML. Every time I have to do something for which
XML might seem suitable, I just invent something else, largely so
that I don't have to cope with the ideas behind XML - other
people's ideas. Am I falling into the trap Erik describes? Well,
yes, I am, but I think this is OK. XML and its encrustations seem
to me to be classic examples of the existing art being just too bad
to deal with. XML itself is essentially too simple to do anything
useful. On top of it there is now a huge mass of stuff, the great
majority of which is not well designed, which probably also fails
to solve my problems, or does it in a way which means that simply
dealing with the XML standards becomes about 90% of the code I need
to write - bloating the effort involved in solving the problem by a
factor of 10 over a reinvented solution.

So I think that in order to avoid endless reinvention it's *critical*
to use systems which are good enough[2] in the first place. There are
rather few of those around in IT, because they are *very* hard to
produce. The C/Unix pair is possibly one (but I think probably not),
Emacs/elisp is, I think, one. Common Lisp is the only system that I
am pretty sure is one.

--tim

Footnotes:
[1] That may not have been apparent to people I guess.

[2] Note that I use `good enough' quite deliberately. Perfection is
an unrealistic goal (and one that, if aimed for, will result in
endless reinvention): good enough is, well, enough.


Paolo Amoroso

unread,
Sep 29, 2002, 12:10:40 PM9/29/02
to
On 27 Sep 2002 15:53:55 -0400, jhb...@ai.mit.edu (Jeremy H. Brown) wrote:

> If you actually went and read the emacs-guile description, you'd note
> that the stated intent of that project (I won't speak to random RMS
> statements in other places) is not to eliminate elisp, but rather to

> integrate guile as another option. Nothing that has gone before is

So what was their point about Common Lisp being too large?


Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README

Erik Naggum

unread,
Sep 29, 2002, 1:04:58 PM9/29/02
to
* Tim Bradshaw

| A related point, it seems to me, is that reinvention is more-or-less
| inevitable if the existing art is so bad that coping with it is too hard.

This can be a good reason for re-invention, but then the smart re-inventor
knows the past and what he needs to be better than. If re-invention only
means that one treads the same old path all over again, it is very bad. And
of course knowing the past is going to be hard. That is why psychologists
have to study so many completely bogus psychological theories -- left to
their own devices, past psychologists have invented all these wacky ideas,
and future psychological inventors please take note: they were discarded.

| So one escape from the wheel of reinvention is to try and come up with
| systems that are well designed in the first place.

The force of genious lies behind a significant shift in perspective more
than in new ways to perform old tasks. We humans are pretty annoyingly
limited when it comes to getting stuck in a well-known pattern and those who
are not, tend to be more wacky than genius.

| 1. Anyone who's read my previous article(s?) in this thread knows I
| think redoing emacs in scheme *or CL*[1] is insane.

I once started down that path, but having spent a couple hundred hours on a
Common Lisp-based Emacs, decided that it was going to take a couple thousand
hours before I had a system I would use myself and would be able to attract
others to join in building. I still wonder what would have happened had I
not gotten fed up, but the better system would also be harder to maintain
than to build. Emacs moves on, and if I were to build another Emacs, would
have to duplicate a /lot/ of effort. It would, in brief, be what I would do
for the next few years.

| 2. Anyone who has read the drivel I write for a bit longer knows my feelings
| about XML. Every time I have to do something for which XML might seem
| suitable, I just invent something else, largely so that I don't have to
| cope with the ideas behind XML - other people's ideas.

What can I say? I wasted 6 years of my life on SGML and related technologies
only to find that when I wanted to translate my experience and knowledge and
significant grasp of this technology into a book that would teach what I had
found to others, I had to look real hard at all the braindamaged things that
I had been willing to sweep under the carpet and found, to my horror, that
SGML, once understood, could not possibly be worse implemented than SGML
itself -- if you get the very valuable core ideas behind SGML, SGML was self-
defeating because it had to cater to a huge number of idiotic requests and
requirements that took away from its ability to express what it wanted to
express, and it became such a horribly application-dependent language that
you would have to retarded to write anything worse. I could not publish this
in a book that would be a conceptual introduction to SGML and abandoned the
whole language and my investment in time. Once every two weeks or so, I get
mail from somebody else who have discovered the same thing after actually
having tried to use SGML for something other than a stupid markup language.

| XML and its encrustations seem to me to be classic examples of the existing
| art being just too bad to deal with.

I takes considerable time to understand this, however. If you do /not/ grasp
the core ideas behind SGML and XML, you will probabl invent something worse,
such as an ad-hoc binary format, and since most people would rather die than
think (in fact they do), XML is better than what a braindead ignorant fool
would invent from scratch.

| So I think that in order to avoid endless reinvention it's *critical* to use
| systems which are good enough[2] in the first place. There are rather few of
| those around in IT, because they are *very* hard to produce. The C/Unix pair
| is possibly one (but I think probably not), Emacs/elisp is, I think, one.
| Common Lisp is the only system that I am pretty sure is one.

I think Common Lisp is the only fundamental IT system that is better than
just Good Enough. I am, however, dismayed at what every single vendor does
with the language when it comes to presenting Common Lisp to "modern" stock
computers. For instance, the lack of the full range of hardware integers
really, really bugs me. I got a suggestion in the mail to look at the 8 new
xmm<n> (128-bit) and mm<n> (64-bit) registers in the IA32 platform, and found
that after spending a lot of time on programming specifically for these,
there is absolutely no reason to stick to 32-bit integers on IA32. The too
few legacy registers should be used for interaction with memory, and the mmx
registers should be used for integer arithmetic. Not doing this is not using
the Intel platform for what it's worth. However, this is not done in any of
the Common Lisps available for the Intel platform, although it would give the
compiler writer 8 64-bit integer registers and 8 128-bit numeric registers
that could both be split into smaller registers if need be, and this would
solve so many of the register starvation issues on that platform. This is
the kind of thing that bugs the hell out of me. Then there is the Unix
integration, which is abysmal and forces people to use other languages to do
anything resembling systems programming. Dsspite all I know about Unix and
Common Lisp, I do not feel that I write Common Lisp programs /under/ Unix.
It is as if the Common Lisp programs run on a separate machine somewhere.
And given that "feel", why not exploit the work in virtual machines and JIT
compilers and related efforts in the Java and even the .NET community and let
Common Lisp code become interchangeable and portable between all the
implementations so that there could be a component market and you could
actually develop on one platform and deploy on any number of others. These
are the developments in a significant part of the software market these days,
and it bugs the hell out of me that I have to choose whether to continue to
use Common Lisp if I want to be a part of this. The effort to make a JVM run
inside Common Lisp, for instance, is a really good idea. Now we need a CLVM
that actually supports CLOS. Notice that these are not "user land" things,
they require vendor support and just as much "develop a new system to use the
new ideas" as any other revolution, but at least the programming language
does not need to change, and we should be able to leverage off of all the
existing Common Lisp skills, the standard behind it, textbooks, courses, and
the long experience with the language to get things right. However, it takes
people who actually /like/ Common Lisp to do this and who are professional
enough to set aside their personal issues when implementing the standard
faithfully so others can trust that the specification will be sufficient and
they can concentrate on their application and not have to waste time on
subtle incompatibilities. This would be slightly more interesting than a
Common Lisp Emacs, but I actually think a Common Lisp Emacs would be so much
easier to build once such a system was in place.

Dave Bakhash

unread,
Sep 29, 2002, 5:04:22 PM9/29/02
to
ds...@goldshoe.gte.com (Dorai Sitaram) writes:

> I find your reasoning quite understandable. Scheme is only being used
> for something that the CL community didn't want to touch anyway. This
> should answer Dave Bakhash's unnecessarily regret-filled article.

You just can't seem to get it...that a sizeable chunk of the [Common]
Lisp community does not see things your way...does not like Scheme, and
considers it a significant step in a very different direction...not to
mention that they don't like it. I've seen some of your code that
facilitates inter-workings between Common Lisp and Scheme, and I think
it's great. However, your fundamental argument is not one you can
win...i.e. that Scheme is a good direction or replacement for Lisp-based
systems -- whether they be CL-based, elisp-based, etc.

(X)Emacs would improve if it adopted and incorporated CL as I mentioned
previously because

1) CL is a friendly, cleaner language to develop apps and extensions
in. (my own opinion, of course)
2) CL is well prepared for handling such a huge application, with so
many sub-units, sub-programs, features, and developers
3) CL is an ANSI-standardized language with a strong history and
excellent community.
4) CL would allow for a lot of simplification and performance gain
for the existing (X)Emacs distros. One would be the elimination of
(require 'cl), which (as you can see) many developers enjoy using.

It is important to note, on that last item, that (require 'cl) is (or at
least used to be) supported by GNU Emacs *only* in situations where
there were compile-time effects (i.e. macros). XEmacs allowed packages
to (require 'cl). GNU Emacs always seemed (to me) to shy away from CL.
I don't know too many details here, but I'm not terribly amazed that the
same community wanted Guile over CL. I've worked with a few Scheme guys
to dissociate them from the "Lisp" community. It's not just the
language definition...it's the mindset of the developers.

Of course, it would be ludicrous to have to go through wads of elisp
code, convirting it to something else. That was never an option. The
idea here was to provide additional programming interfaces into the
emacsen. I've seen some amazing feats in elisp of emulating
CL...everything from the 'cl package to a reasonable CL reader and an
implementation of CLOS. But these are all memory hogs, slow as hell,
and still lacking (i.e. not up to spec). A full CL is, in my opinion,
the right answer to the Emacs issue. Guile is something that would make
(X)Emacs *worse*. I think that is what you just don't get. So if you
think that I am unnecessarily remorseful, it is because of the
infectation of the Scheme/Guile community dealing with Lisp-related
issues. Keep diluting the already broad notion of what "Lisp" is with
Scheme Guile, and you just make the problem worse.

dave

Dave Bakhash

unread,
Sep 29, 2002, 5:07:55 PM9/29/02
to
jhb...@ai.mit.edu (Jeremy H. Brown) writes:

> Christopher Browne <cbbr...@acm.org> writes:
> > It's presumably some aspect of the "we despise Scheme" thing..
>
> If that's really all it is, I'll go back to bed now.

Sometimes, lying to yourself helps you sleep at nite.

It seems like this is one of those cases. In that case, good night and
sleep well.

dave

Dave Bakhash

unread,
Sep 29, 2002, 5:53:21 PM9/29/02
to
Alain Picard <apicard+die...@optushome.com.au> writes:

> ds...@goldshoe.gte.com (Dorai Sitaram) writes:
>
> > Your message suggested that Emacs was tragically moving away from
> > Lisp by switching to Guile, so I reassured you that it wasn't.
> > Maybe I misread what exactly you were being regretful about.
>
> You didn't misread him. He, and many others, think that switching to
> Guile is moving away from lisp.

This is correct. I'm glad that someone out there understands what I
meant to say, as well as tends to agree.

Scheme is a degenerate -- a mutation, if you will. There's enough
similarity to notice one of its ancestors, but more to show its
divergence (or deviance, depending on how you see it).

It's just as in biology: most mutations are bad, though some are good.
Scheme is a bad one. But like a cancer, it grows, feeding mostly on the
vast pool of beginners who think it's easy and elegant. Unfortunately,
it has grown into this newsgroup, as well as into applications some of
us care about.

Dorai can knock me all [s]he wants. But it won't change the fact that
Scheme is viewed as a perversion, lacking some of the best features of
Lisp-family languages, and adding little useful.

dave

ozan s yigit

unread,
Sep 29, 2002, 11:19:54 PM9/29/02
to
Dave Bakhash [on scheme]:

> ... Unfortunately,


> it has grown into this newsgroup, as well as into applications some of
> us care about.

i wrote a spec-compliant implementation of the language some thirteen years
ago with the sincere intention to replace elisp with scheme. when i was done
emacs was not as important, and the implementation ended up as an extension
language for one of the popular sgml editors of the time. so you see, there
has already been years of scheming in applications some of us cared about
and you may not even know anything about it.

oz
---
don't count your chickens in glass houses until the cows come home.
-- david vestal

Rob Warnock

unread,
Sep 30, 2002, 4:34:08 AM9/30/02
to
In the "replace EMACS LISP with Guile" thread,
Erik Naggum <er...@naggum.no> wrote:
+---------------
| * Tim Bradshaw

| | XML and its encrustations seem to me to be classic examples of the
| | existing art being just too bad to deal with.
|
| It takes considerable time to understand this, however. If you do /not/
| grasp the core ideas behind SGML and XML, you will probably invent
| something worse, such as an ad-hoc binary format...
+---------------

I'm very interested in learning what these "core ideas" are, since I
suspect I am missing something significant (and/or obvious!), and
would appreciate a pointer to any available literature (including
any of your articles archived at <URL:http://www.oasis-open.org/> or
<URL:ftp://ftp.ifi.uio.no/pub/SGML> or elsewhere). Even just a set of
"bullet items" (one-liners) would be appreciated as hints for what to
go look for.

I assume you're *not* talking about trivial stuff like "<tag>foo</tag>"
syntax [which to me is just verbose way of externally representing
(serializing) trees (though not DAGs or more complex structures),
and which S-exprs do a much better job of (especially if you allow
"#n=" & "#n#" for the more complex graphs)], but about one or more
deeper issues that you've hinted at several times but that (not having
studied SGML per se) I don't have the context to follow up on without
more explicit pointers.

Thanks in advance,


-Rob

-----
Rob Warnock, PP-ASEL-IA <rp...@rpw3.org>
627 26th Avenue <URL:http://www.rpw3.org/>
San Mateo, CA 94403 (650)572-2607

Dave Bakhash

unread,
Sep 30, 2002, 5:02:59 AM9/30/02
to
ozan s yigit <o...@blue.cs.yorku.ca> writes:

> i wrote a spec-compliant implementation of the language some thirteen
> years ago with the sincere intention to replace elisp with
> scheme. when i was done emacs was not as important, and the
> implementation ended up as an extension language for one of the
> popular sgml editors of the time. so you see, there has already been
> years of scheming in applications some of us cared about and you may
> not even know anything about it.

Sometimes it's important to recall the original problem, or goal. Emacs
is an editor. It came with an extension language (Emacs Lisp) which was
powerful enough so that over a score or so people have been able to
contribute mounds of useful add-ons providing mailers, news readers,
IDEs, games, etc.

However, Emacs Lisp is slow, and also ugly in several respects. This
became apparent when things like web browsers were attempted in elisp.
To cope with the problem, and to make programming more sophisticated
applications inside Emacs that would not require diving into C caused
serious discussion about how to make Emacs more easily programmable,
execute extension code more efficiently, and yet provide a clean
interface to legacy Emacs Lisp code.

There were many proposals. Two were CL and Guile, and I'd say that
within each of these are pros and cons. For me, the pros for the CL
camp were obvious:

o excellent CL compilers exist in the open source community
o CL is powerful and general enough to handle processing Emacs Lisp
o CL is more in the spirit of the original Emacs Lisp language
o CL is an ANSI-standardized language, and already had an impact
on literally thousands of Emacs Lisp programs, meaning that by
using CL, you are not turning your backs on the vast pool of
existing elisp contributors. You are giving them *more* rather than
something completely different.

I can go on for many pages about all of the features of CL that I think
are useful, and would make adding to Emacs a joy, but some of the main
reasons are the few above.

If you wanted to start an Emacs-like editor from scratch, without
understanding the history, the elisp developer community, and the elisp
language features and existing codebase, then yeah...sure...do it in
Scheme or whatever language you want for that matter (several people
have already). But we were talking about Emacs, and that's much more
than just an application at this point.

dave

Dave Bakhash

unread,
Sep 30, 2002, 5:19:26 AM9/30/02
to
Friedrich Dominicus <fr...@q-software-solutions.com> writes:

> What I simply do not understand is that RMS has worked on Lisp
> Machines, which do have had all the things in place like Packages,
> OO-Systems, System development tools and and and, but nevertheless, he
> did not keep that stuff in Emacs Lisp. I guess no-one will know what
> he has thought about it while working on it I bet even he does not
> know any longer.
>
> It seems to me that Emacs Lisp falls even short behind the Lisps
> available to that time. And that is what I can't understand.

I think this is what the poster meant when he said:

Stallman wants to replace Elisp with Guile because Elisp has some
problems that might not be there had he taken more care the first time
around.

I agree with this fully. But then again, I don't think that RMS really
knew what a phenomenon Emacs would become to care enough to do things
the right way. I get a strong feeling that RMS has some hacker
tendencies. That, coupled with 20/20 hindsight of what Emacs Lisp
should have been, can sometimes hurt his image a bit. It's the part
about RMS supporting Guile as the evolution of Emacs Lisp that gets me.

dave

Tim Josling

unread,
Sep 30, 2002, 7:00:07 AM9/30/02
to
Erik Naggum wrote:
>
> * Tim Josling
> | Yes it is ASN.1. I personally prefer XML myself, but MYYV.
>
> <...rant...>

> So, what is your actual experience with ASN.1?
>

I wrote some code to create and parse some asn.1 messages. I read the spec and
read people's comments about it.

Tim Josling

Tim Bradshaw

unread,
Sep 30, 2002, 7:25:02 AM9/30/02
to
* Erik Naggum wrote:
> This can be a good reason for re-invention, but then the smart re-inventor
> knows the past and what he needs to be better than.

I think this is right. I must admit though I sometimes cop out and
work on the basis of manual-inches to perform some trivial task -
usually something that I already know how to do in some other way. In
fact my metric is more complex than this, since I also look at the
first differential of manual-inches with time. Things like CORBA
clearly have a fairly large manual-inch count, but the rate of change
of manual-inches is not too bad, and if you look at what CORBA needs
to do (such as support COBOL...) then it's fairly clear why it's quite
big, even if it's pretty frustrating to use. XML though now has
really large manual-inches and a rate of change which seems to be
proportional to the manual-inches, with all that implies in the way of
collapsing floors. And whenever I look at doing something in XML I
could do it more easily with sexps, and this seems to be independent
of the manual-inch count.

Manual-inches, incidentally, is the best known unit. Some people have
suggested things like manual-words but this is not enough as it
ignores typographical issues - manuals with too few words per inch are
typically very hard to use as the density of information is so low.
Unfortunately even manual-inches has some problems as it encourages
very small type sizes and long lines...

--tim

Tim Bradshaw

unread,
Sep 30, 2002, 8:22:23 AM9/30/02
to
* Dave Bakhash wrote:

> However, Emacs Lisp is slow, and also ugly in several respects. This
> became apparent when things like web browsers were attempted in elisp.

I think the only web browser I know of in elisp (namely emacs w3) is
slow for reasons that a profiler would help with a whole lot more than
a new language. Other than w3, whenever I've profiled emacs I've
discovered that it spends about 90% of its time in redisplay, in C
code.

--tim

Tim Josling

unread,
Sep 30, 2002, 8:19:34 AM9/30/02
to
Erik Naggum wrote:

> ...(you are wrong... you are an idiot)...

Happy to learn that I am wrong, but it helps to be more specific.

As an example, pointing to a URL with a broken search engine does not help.
Google finds some text by EN, but it is mostly more of the same type of
material we are unfortunately already so familiar with.

I don't think anyone has anything to gain from continuing this discussion.

Anyway, XML verus ASN.1 or SGML is not really relevant to lisp, except by way
of analogy. In some ways it is similar to Lisp versus C as in the "Worse is
Better" paper.

Tim Josling

Erik Naggum

unread,
Sep 30, 2002, 8:47:00 AM9/30/02
to
* Tim Josling

| As an example, pointing to a URL with a broken search engine does not help.

Geez, you really are retarded. Such rank incompetence at finding
information is simply not possible in this day and age. Your laziness and
dishonesty speaks volume about your character.

Since you need to be speoon-fed and need assistance finding your own butt,
try <http://www.oasis-open.org/cover/bib-mn.html>, a link found on the very
same page you incompetently could not read. If you know how to avail
yourself of the search function in the browser, use it.

Jesus Christ, the idiots that storm the Net with their opinions these days.

| I don't think anyone has anything to gain from continuing this discussion.

The people who hire you need might gain from it.

Dorai Sitaram

unread,
Sep 30, 2002, 9:53:16 AM9/30/02
to
In article <86ofain...@gondolin.local.net>,
Alain Picard <apicard+die...@optushome.com.au> wrote:
>ds...@goldshoe.gte.com (Dorai Sitaram) writes:
>
>> In article <86wup7n...@gondolin.local.net>,
>> Alain Picard <apicard+die...@optushome.com.au> wrote:
>> >My only comfort is that I give them very long odds of success
>> >with that project; there's just too damn much elisp code out
>> >there.
>>
>> What would you gain by their failure and/or what
>> would lose by their success?
>
>The answer to both questions is the same; what is at stake is not
>having to learn yet another language; one, moreover, whose essence is
>_less_ like what I want, rather than more (i.e., if anything, I want
>elisp to be more like CL). I pretty much understand elisp; I can
>read 3rd party extensions, see what they do, fix things which don't
>work.

I quite understood the inertia argument for elisp.
What seems strange is that you expressed a desire for
something the near opposite of what you actually
needed. If the Guile-Emacs people succeed, you get to
negotiate it with your familiar elisp. If, OTOH, they
fail -- even if you keep the current non-Scheme Emacs
around -- you may have to willy-nilly deal with the new
Emacs's Scheme-like extension language, which would be
a waste of time for you.

>Am I lazy to not want to learn another language? You bet. The combined
>laziness of myself and thousands of other elisp hackers should count for
>something, it seems to me.

Well said. I personally wouldn't mind a little or even
huge tracts of failure in the Guile simulation of
elisp, because I never really developed a dependence on
emacs, let alone elisp. I use another editor purely
because of the vagaries of my job -- and like
you, I'm probably too lazy to shift too --, and
when I do use emacs for its convenient shelling
capabilities, I tend to stick to what used to be called
coke-bottle sequences. But clearly there are armies of
power users of emacs. It is imperative to get elisp
working perfectly or abandon (or at least rename) the
new emacs project altogether. I think we agree on that
one at least.

Editors are some of the most commonly created software
artifacts, and they always seem to find users. A
Scheme-based editor that is almost exactly like Emacs
would almost certainly find a considerable niche,
what with the Scheme users around. Of course, it
doesn't have to be The replacement for Emacs.

Dorai Sitaram

unread,
Sep 30, 2002, 10:30:09 AM9/30/02
to
In article <c291y7c...@nerd-xing.mit.edu>,

Dave Bakhash <ca...@alum.mit.edu> wrote:
>ds...@goldshoe.gte.com (Dorai Sitaram) writes:
>
>> I find your reasoning quite understandable. Scheme is only being used
>> for something that the CL community didn't want to touch anyway. This
>> should answer Dave Bakhash's unnecessarily regret-filled article.
>
>You just can't seem to get it...that a sizeable chunk of the [Common]
>Lisp community does not see things your way...does not like Scheme, and
>considers it a significant step in a very different direction...not to
>mention that they don't like it. I've seen some of your code that
>facilitates inter-workings between Common Lisp and Scheme, and I think
>it's great. However, your fundamental argument is not one you can
>win...i.e. that Scheme is a good direction or replacement for Lisp-based
>systems -- whether they be CL-based, elisp-based, etc.

I wasn't aware I was trying to win anything. For some
reason you seem to think I'm championing
Guile-Emacs over CL-Emacs, despite my explicit
statement to you that the latter would be very nice
indeed.

As an individual, I am just trying to deal with
reality too, and am observing that since you made an
explicit laundry-list of goodies (which you should be
thanked for), that you will find that you can deal with
Guile-Emacs if it happens.

Software is not always about what we want exactly how
we want it -- there is a large social component
to it. I am trying to find good points that I can deal
with. Yes, I think Guile-Emacs will be "good enough",
to use another poster's phrase. It will be dealable
with.

Do I personally absolutely want Guile-Emacs? No. Will
I use it if it came about? I'll probably have to, if I
want to keep in touch with the rest of the (not just
Lisp-) world. Is it really worth my while to
spend extraordinary amounts of negative energy putting
it down? I'd say not.

You say you've looked at my inter-language code.
That should tell you something at least about my
pragmatism in these matters.

--d

Thien-Thi Nguyen

unread,
Sep 30, 2002, 11:03:51 AM9/30/02
to
Dave Bakhash <ca...@alum.mit.edu> writes:

> I get a strong feeling that RMS has some hacker tendencies.

what would those be?

thi

Erik Naggum

unread,
Sep 30, 2002, 11:40:43 AM9/30/02
to
* Rob Warnock

| I'm very interested in learning what these "core ideas" are, since I
| suspect I am missing something significant (and/or obvious!)

To someone familiar with (Common) Lisp, it is much easier to grasp, and may
indeed appear obvious or trivial. These concepts are central:

· declarative elements with contents (not commands).
· hierarchical element structure.
· element structure validation (to a content model).
· element structure normalization (default values).
· element identity and referencing.
· declared entities with uniform references.
· declared notations.
· (abstract) public (entity and notation) identifiers
· a syntactic layer between entity and application.
· an access layer between file systems (networked, etc) and entity

Less central, but still important with respect to the processing model:

· separate specification of position-in-hierarchy-dependent information.
· possible specification of parent, child and left and right sibling relations.
· dynamic inheritance of processing information.
· complete mapping between document and processing element hierarchies.
· marked sections with conditional inclusion.

Things that the SGML community think are important, but which only detract
from the real issues and confuse people tremendously:

· attributes to elements, notations, entities.
· attribute types
· character entities.
· parameter entities.
· marked sections with special syntax for contents.
· elements with special syntax for contents.
· tag minimization and omission.
· the actual syntax.

Neither list should be deemed exhaustive.

| I assume you're *not* talking about trivial stuff like "<tag>foo</tag>"
| syntax [which to me is just verbose way of externally representing
| (serializing) trees (though not DAGs or more complex structures), and which
| S-exprs do a much better job of (especially if you allow "#n=" & "#n#" for
| the more complex graphs)]

The rank incompetence of SGML and XML aficionados has led people to believe
that the syntax cannot represent anything more complex than simple trees.
This is just as wrong as claiming that Common Lisp cannot express circular
lists and other forms of reused objects to preserve identity throughout the
printed form of a structured. Using ID and IDREF is exactly analogous to
using #n= and #n#. (And just as they have special syntax in Common Lisp,
they should have special syntax in an attribute-free SGML. It is the only
thing that /needs/ attributes in the SGML syntax.)

Erik Naggum

unread,
Sep 30, 2002, 12:31:53 PM9/30/02
to
* Tim Bradshaw

| Manual-inches, incidentally, is the best known unit.

I tend to measure things by the weight and thickness of the paper and the
spaciousness of the typography of the books you find on the market about
something. I have seen books on Visual Basic with the same page count as
books on C but with 3 times the shelf space. I have seen books on HTML with
same amount of contents as books on Ada with 9 times the volume. I have come
to believe that large print, thick and heavy paper, and wide margins and
oversize leading is indicative of the expected intelligence of the reader.
If the reader is expected to be unable to concentrate or experiences mental
fatigue just by looking at a page of text without oceans of whitespace, the
material is probably geared towards people whose reading skills plateaued
before they entered high school. Compare children's books and books on Web
Duhsign or other X-in-21-days books. If the reading level of a specification
is below college level, chances are the people behind it are morons and the
result morose.

If typography and reading level are comparable, manual-inches is probably a
good measure, but a children's specification for something may be thinner
than a solid work of engineering that it would actually take less time to
grasp because it is so hard to sink to the level of children who need to be
told things over and over and usually do not remeber subtle differences from
repetition to repetion like reasonably smart people do. (At least I find
that I cannot read material written by people who are too stupid. This was,
incidentally, how I first began to understand that sports in the newsmedia is
/intended/ to keep people in a semi-comatose, non-thinking state of mind
where cheering for some idiot gang of testosterone bombs could be regarded as
recreationally rewarding.)

--
Erik Naggum, Oslo, Norway

Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.

Tim Bradshaw

unread,
Sep 30, 2002, 12:57:42 PM9/30/02
to
* Erik Naggum wrote:

> I tend to measure things by the weight and thickness of the paper and the
> spaciousness of the typography of the books you find on the market about
> something.

Yes, this (including the elided stuff) is a much better summary than
mine. Thinking about it, I tend to judge things on whether they look
like a *book* rather than something else. I'm going to just fail to
define what I mean by `look like a book' because I probably can't
produce a decent definition without, aha, writing a book. But to
oversimplify horribly, I think that book design (including technical
book design) is something that has got fairly well sorted out after a
few hundred years of it, and it's quite hard to come up with a (paper[1])
presentation of something that is better than how well-designed books
look. So anything that looks too different (and lots of the
x-in-21-days `books' look very different) is either badly designed or
well-designed but trying to do something other than get information
across.

--tim

Footnotes:
[1] In fact, this is true (for me) for other media too. In
particular I really hate things that have too many (hyper)links
instead of giving a coherent presentation of something.
Obviously linking can be well done (something like a reference
manual or specification clearly needs a fair number of links) but
too often it is just an excuse to avoid structuring a document
well, or at all.

Dorai Sitaram

unread,
Sep 30, 2002, 1:19:46 PM9/30/02
to
In article <8765wri...@acm.org>, Bulent Murtezaoglu <b...@acm.org> wrote:
> EN> I have desired /longevity/ of things for as long back as I
> EN> can remember.
>
>You are in good company. Knuth does also (re: TeX).

Well, do Common Lispers really like TeX? Do they truly
appreciate it for being a rock of reliability? I
rather got the impression that they felt that the
"longevity by fiat" that DeK imposed on it was an
unfortunate thing, because he prevented himself and
others from going beyond the constraints of an
older era...

Dave Bakhash

unread,
Sep 30, 2002, 1:35:12 PM9/30/02
to
Tim Bradshaw <t...@cley.com> writes:

yeah...I think that I once read that XEmacs (and I think Emacs too) uses
its own redisplay engine. But I don't think that this is the problem
with w3. w3 spends a vast amount of time parsing the HTML, and then
another displaying it. The display engine runs through the parse tree,
building the page as it goes. But the part that hurts is not in the C
world AFAIK, because watching how many times XEmacs GC's while trying to
display a page suggests some very inefficient garbage
collection...another area where using a CL with a more efficient GC
would do wonders.

Of course, then there's the question of how efficient the w3 code is.

dave

Thomas F. Burdick

unread,
Sep 30, 2002, 2:14:27 PM9/30/02
to
ds...@goldshoe.gte.com (Dorai Sitaram) writes:

> In article <8765wri...@acm.org>, Bulent Murtezaoglu <b...@acm.org> wrote:
> > EN> I have desired /longevity/ of things for as long back as I
> > EN> can remember.
> >
> >You are in good company. Knuth does also (re: TeX).
>
> Well, do Common Lispers really like TeX?

This one does. If I want to have absolute, 100% control over
everything, I don't use TeX, I use PostScript. But TeX is intended
for setting type, and at that, I haven't found it deficient.

> Do they truly appreciate it for being a rock of reliability? I
> rather got the impression that they felt that the "longevity by
> fiat" that DeK imposed on it was an unfortunate thing, because he
> prevented himself and others from going beyond the constraints of an
> older era...

What "constraints of an older era" are you referring to? I use it all
the time to make hyperlinked PDFs, so if you meant something in that
area, it's all good. Honestly, I don't feel like I'm being held back
in time at all, when using it[*].

[*] Says the man who writes his papers using Emacs and LaTeX on Unix ;)
On the other hand, MS Word users never hear, "I really liked your
exposition of such-and-such a point in this paper ... and it's so
*pretty*, what did you write it in?"

--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'

sv0f

unread,
Sep 30, 2002, 2:52:35 PM9/30/02
to

On pp. xviii-xix of CLtL, Steele thanks Knuth for TEX,
Leslie Lamport for LATEX, and Blue Sky Research for
their Macintosh implementation of TEX. This is in 1989.

I also recall reading that Steele was one of the early
adopters of TEX many years before, but I have no
reference for this.

Tim Bradshaw

unread,
Sep 30, 2002, 3:26:24 PM9/30/02
to
* Dave Bakhash wrote:
> Of course, then there's the question of how efficient the w3 code is.

yes, that was my point. I looked at it (briefly), and it's not good.

--tim

ozan s yigit

unread,
Oct 1, 2002, 12:15:54 AM10/1/02
to
Tim Bradshaw [on judging books]:

> ... So anything that looks too different (and lots of the


> x-in-21-days `books' look very different) is either badly designed or
> well-designed but trying to do something other than get information
> across.

i should mention a couple of books [assuming the topics are of any interest]
that may get dropped on the floor because of their look, dimensions, title,
typefaces, line spacing, grade of paper, illustrations, dumb icons and
other non-content problems:

The Cartoon Guide to Statistics
Larry Gonick and Woollcott Smith
Harperparennial, 1993.
[probably one of the finest books on statistics ever written
and i even own a first edition freedman/pisani/purves...]

The Complete Idiot's Guide to Publishing Science Fiction
Cory Doctorow and Karl Schroeder
Alpha Books, 2000
[a very sharp, must-read book on becoming an SF writer and
publishing what you write.]

[nothing in my CS shelves jump at me right now, though i think meyer's
2nd ed may have given a fluffier impression to an innocent browser than
it actually is. on the other side, hopcroft/motwani/ullman "introduction
to automata theory [etc]" is a money-making exercise with much reduced
theory literacy and should be avoided while holding nose...]

oz
--
the balance of the programmed signal. -- mark v. shaney

Vassil Nikolov

unread,
Oct 1, 2002, 12:48:18 AM10/1/02
to
no...@vanderbilt.edu (sv0f) writes:

[...]


> On pp. xviii-xix of CLtL, Steele thanks Knuth for TEX,
> Leslie Lamport for LATEX, and Blue Sky Research for
> their Macintosh implementation of TEX. This is in 1989.

IIRC, that was CLtL2, which also said that the source of the first
edition, written in Scribe, was converted into LaTeX by a throwaway
program.

---Vassil.

Alain Picard

unread,
Oct 1, 2002, 3:39:08 AM10/1/02
to
ds...@goldshoe.gte.com (Dorai Sitaram) writes:

> Editors are some of the most commonly created software
> artifacts, and they always seem to find users. A
> Scheme-based editor that is almost exactly like Emacs
> would almost certainly find a considerable niche,
> what with the Scheme users around. Of course, it
> doesn't have to be The replacement for Emacs.

I admitted to laziness, so now, I'll admit to selfishness
as well: I'd rather that people write more elisp modules
(or enhance existing ones) from which _I_ can benefit than
re-implement existing functionality in yet another editor.

Ooooh, I'm so _bad_. 8-)

Rob Warnock

unread,
Oct 1, 2002, 7:08:13 AM10/1/02
to
Erik Naggum <er...@naggum.no> replied:
+---------------
| [...nicely bulleted list...]
+---------------

Thank you! That was exactly the sort of terse overview I was hoping for.

+---------------


| Things that the SGML community think are important, but which only
| detract from the real issues and confuse people tremendously:
|
| · attributes to elements, notations, entities.
| · attribute types

+---------------

Well, this list has certainly talked about *that* one enough before. ;-}
Clearly, since a DTD can specify that some subset of sub-elements (in
arbitrary order) *must* come before all the other permitted sub-elements,
then "attributes" could just as easily be expressed as sub-elements
with restrictions on order, much like declarations and documentation
strings in CL, yes?

+---------------
| | ...verbose way of externally representing (serializing) trees


| | (though not DAGs or more complex structures), and which S-exprs

| | do a much better job of (especially if you allow "#n=" & "#n#" ...)


|
| The rank incompetence of SGML and XML aficionados has led people to believe
| that the syntax cannot represent anything more complex than simple trees.
| This is just as wrong as claiming that Common Lisp cannot express circular
| lists and other forms of reused objects to preserve identity throughout the
| printed form of a structured. Using ID and IDREF is exactly analogous to
| using #n= and #n#.

+---------------

Aha! That's what I get for not having read the actual SGML specs, I guess.

+---------------


| (And just as they have special syntax in Common Lisp, they should have
| special syntax in an attribute-free SGML. It is the only thing that
| /needs/ attributes in the SGML syntax.)

+---------------

I need to think about that one a bit more (and maybe go read some more).
At the moment, it's certainly plausible to me that IDREF might need
special syntax, but it seems like one might to be able to provide ID
(albeit rather awkwardly!) with attribute-free elements [as above].

Anyway, thanks again for the concise summary,

Tim Bradshaw

unread,
Oct 1, 2002, 8:28:50 AM10/1/02
to
* Rob Warnock wrote:

> Well, this list has certainly talked about *that* one enough before.
> ;-} Clearly, since a DTD can specify that some subset of
> sub-elements (in arbitrary order) *must* come before all the other
> permitted sub-elements, then "attributes" could just as easily be
> expressed as sub-elements with restrictions on order, much like
> declarations and documentation strings in CL, yes?

We have had various fights with clients about just this kind of
thing. We have a system where define `modules', which are essentially
conceptual units of <something> in a build system. Modules have
various parameters such as dependencies, names, and so on. The native
syntax is completely regular and looks like:

(idl-files
(:name "f1"
...)
...)

And lo and behold this ends up as something like:

(let ((m (make-instance 'idl-files :name "f1" ...)))
(loop for b in body
do (add-item-for m b))
m)

(in fact it's a lot more complex than this, but this is the idea).

So of course the `natural' XML version of this is:

<idl-files name="f1">...</idl-files>

So people complained bitterly when we did this as:

<idl-files>
<parameters>
<parameter>...</parameter>
...
</parameters>
...
</idl-files>

So why did we do it like that? Because XML attributes can't have
structured data, so if you want, say, a list of things in an
attribute, you have to write your own little parser, oh joy. And (not
in the examples above) we *do* have structured data.

What we ended up with was a hack that looked for XML attributes and
translated them to parameters with stringy values.

--tim

Erik Naggum

unread,
Oct 1, 2002, 9:20:50 AM10/1/02
to
* Rob Warnock

| Thank you! That was exactly the sort of terse overview I was hoping for.

Happy to oblige, but I think I should whip up a web page on this now that
I think I got it reasonably right. The standing-on-one-leg stunt is hard.

| Clearly, since a DTD can specify that some subset of sub-elements (in
| arbitrary order) *must* come before all the other permitted sub-elements,
| then "attributes" could just as easily be expressed as sub-elements with
| restrictions on order, much like declarations and documentation strings
| in CL, yes?

There is a crucial difference between attributes and subelements today
that needs to be taken care of in an attribute-free SGML. Attributes are
local to their element and therefore can be the same name as an element.
They could also differ in type from element to element, which translates
to a different content model or notation as an element.

| | Using ID and IDREF is exactly analogous to using #n= and #n#.
|

| Aha! That's what I get for not having read the actual SGML specs, I guess.

But you may need to know #n= and #n# and that they are analogous to see
this because the application gets to maintain its own table of IDs and
map the IDREFs back to them, which is kind of unfortunate. Grasping that
this can be used for circular structures is apparently hard for SGMLers
when they have only learned to think of them in "See Figure 1" terms.

| I need to think about that one a bit more (and maybe go read some more).
| At the moment, it's certainly plausible to me that IDREF might need
| special syntax, but it seems like one might to be able to provide ID
| (albeit rather awkwardly!) with attribute-free elements [as above].

One curious effect of moving from attributes to elements is that quite
often, the best design is to let the attribute become a superelement
instead of a subelement.

--
Erik Naggum, Oslo, Norway

Act from reason, and failure makes you rethink and study harder.

Dorai Sitaram

unread,
Oct 1, 2002, 9:21:33 AM10/1/02
to
In article <868z1i7...@gondolin.local.net>,

Alain Picard <apicard+die...@optushome.com.au> wrote:
>
>I admitted to laziness, so now, I'll admit to selfishness
>as well: I'd rather that people write more elisp modules
>(or enhance existing ones) from which _I_ can benefit than
>re-implement existing functionality in yet another editor.

TANSTAAFL.

Rob Warnock

unread,
Oct 1, 2002, 11:03:55 AM10/1/02
to
Erik Naggum <er...@naggum.no> wrote:
+---------------
| * Rob Warnock

| | "attributes" could just as easily be expressed as sub-elements with
| | restrictions on order, much like declarations and documentation strings
| | in CL, yes?
|
| There is a crucial difference between attributes and subelements today
| that needs to be taken care of in an attribute-free SGML. Attributes are
| local to their element and therefore can be the same name as an element.
| They could also differ in type from element to element, which translates
| to a different content model or notation as an element.
+---------------

Good point. And also, as Tim Bradshaw pointed out in a parallel
reply <URL:news:ey3u1k6...@cley.com>, attributes are not
permitted to have sub-structure[1], while sub-elements may.

[1] Well, not *standard*, DTD-defined sub-structure, that is, though
as Tim noted, one can always hack up an ad-hoc serialization of
the sub-structure into the string value of an attribute... (*ugh!*)

+---------------


| | | Using ID and IDREF is exactly analogous to using #n= and #n#.
| |
| | Aha! That's what I get for not having read the actual SGML specs, I guess.
|
| But you may need to know #n= and #n# and that they are analogous to see
| this because the application gets to maintain its own table of IDs and
| map the IDREFs back to them, which is kind of unfortunate.

+---------------

Do you mean that the application is allowed to merge (remapping as needed)
IDs/IDREFs from *multiple* documents? ...or *across* multiple docs?
[Otherwise I don't see where any "table" or "mapping" is needed, other
than just the one necessary for #n=/#n# processing during the READ.]

Hmmm... The corresponding thing in CL might be trying to reference the
same #n=/#n# numbers across multiple occurrences of READ. Normally,
that wouldn't be a problem (because it's not possible), but my twisted
little brain just started wondering about how #n= & #n# might interact
with #. in pathological cases, as in:

(foo #1=bar #.(read-from-string "(a #1=b c #1# d)") gorp #1# blah)

Well, maybe that's not a good example -- both CLISP & CMUCL handle it,
yielding (FOO BAR (A B C B D) GORP BAR BLAH) -- but *this* one, maybe:

#1=(foo bar #.(read-from-string "#1=(a b c #1# d)") gorp #1# blah)

CLISP handles it this way [assuming (setq *print-circle* t), else it
core-dumps]:

> '#1=(foo bar #.(read-from-string "#1=(a b c #1# d)") gorp #1# blah)
#1=(FOO BAR #2=(A B C #2# D) GORP #1# BLAH)
>

While CMUCL complains:

Reader error at 3 on #<String-Input Stream>:
Multiply defined label: #1=

O.k., CLHS "2.4.8.15 Sharpsign Equal-Sign" says:

The scope of the label is the expression being read by the
outermost call to read; within this expression, the same label
may not appear twice.

So perhaps in CLISP's case the READ-FROM-STRING instance causes a
completely different instance of READ (and thus the two #1= aren't
"the same") and in CMUCL's case READ-FROM-STRING "knows" it's inside
an active READ and (legitmately) tosses an error.

But then why does CMUCL *accept* the first form at all?!? They both
have the same "outermost call to read"...

+---------------


| Grasping that this can be used for circular structures is apparently
| hard for SGMLers when they have only learned to think of them in
| "See Figure 1" terms.

+---------------

*ROTFLMAO!* Yes, I know what you mean, but... Does "See Figure 1"
have the same alternate meaning for you guys over there as it does
around here?!? ;-} ;-}

<URL:http://www.tuxedo.org/~esr/jargon/html/entry/See-figure-1.html>
<URL:http://www.things.org/~jym/fun/see-figure-1.html>

+---------------


| | I need to think about that one a bit more (and maybe go read some more).
| | At the moment, it's certainly plausible to me that IDREF might need
| | special syntax, but it seems like one might to be able to provide ID
| | (albeit rather awkwardly!) with attribute-free elements [as above].
|
| One curious effect of moving from attributes to elements is that quite
| often, the best design is to let the attribute become a superelement
| instead of a subelement.

+---------------

Yeah, I was starting to think in that direction, since it reduces the
number of levels of nesting you need in the common case of only one
attribute. It's much like CL WITH-XXX macros, in that way. (And why
am I suddenly thinking of CLOS "around" methods, too? ;-} )

Fred Gilham

unread,
Oct 1, 2002, 11:36:55 AM10/1/02
to

Dorai Sitaram wrote:
> Editors are some of the most commonly created software
> artifacts, and they always seem to find users. A
> Scheme-based editor that is almost exactly like Emacs
> would almost certainly find a considerable niche,
> what with the Scheme users around. Of course, it
> doesn't have to be The replacement for Emacs.

Somehow the word `edwin' keeps coming to mind. Wasn't that virtually
an emacs clone in scheme? How complete was it? I thought it ran
elisp.

--
Fred Gilham gil...@csl.sri.com || GOVERNMENT: A large charity
organization with a coercive fund-raising arm. PUBLIC SCHOOLS:
Government-run (see above) schools with coercive admissions
departments.

Christopher Browne

unread,
Oct 1, 2002, 11:57:35 AM10/1/02
to
In an attempt to throw the authorities off his trail, Fred Gilham <gil...@snapdragon.csl.sri.com> transmitted:
> Dorai Sitaram wrote:

>> Editors are some of the most commonly created software artifacts,
>> and they always seem to find users. A Scheme-based editor that is
>> almost exactly like Emacs would almost certainly find a
>> considerable niche, what with the Scheme users around. Of course,
>> it doesn't have to be The replacement for Emacs.
>
> Somehow the word `edwin' keeps coming to mind. Wasn't that
> virtually an emacs clone in scheme? How complete was it? I thought
> it ran elisp.

"This chapter describes how to start Edwin, the MIT Scheme text
editor. Edwin is very similar to GNU Emacs -- you should refer to
the GNU Emacs manual for information about Edwin's commands and key
bindings --- except that Edwin's extension language is MIT Scheme,
while GNU Emacs extensions are written in Emacs Lisp. This manual
does not discuss customization of Edwin."

Edwin is "sufficiently complete" that it will read your existing Info
configuration, and can browse Info files.

There does not appear to be any guide to writing extensions.

<http://www.cs.colorado.edu/~main/manuals/scheme/user_66.html>

Missing Subsystems

The following documented subsystems are implemented by Emacs but not
by Edwin.

* abbrev mode (edwin has dynamic abbreviations)
* emulation modes: edt, vi, vip
* file locks
* language modes: emacs-lisp, fortran, lisp, modula-2, prolog
* overwrite mode
* picture mode
* slow terminal incremental search
* spelling
* tab stops
* text formatter modes: nroff, scribe, tex, latex

It /does/ have modes for C and Scheme, so the "lack of language modes"
is about the notion of it not having Great Gobs of Modes.
--
(concatenate 'string "cbbrowne" "@cbbrowne.com")
http://www3.sympatico.ca/cbbrowne/spreadsheets.html
Would-be National Mottos:
Switzerland: "You wouldn't hit a country that's neutral, would you?"

Lieven Marchand

unread,
Oct 1, 2002, 1:26:58 PM10/1/02
to
no...@vanderbilt.edu (sv0f) writes:

> I also recall reading that Steele was one of the early
> adopters of TEX many years before, but I have no
> reference for this.

Knuth, Digital Typography, p. 648

In the 70s, I had a negative reaction to software that tried to be all
things to all people. Every system I looked at had its own universal
Turing machine built into it somehow, and everybody's machine was a
little different from everybody else's. So I thought, "Well, I'm not
going to design a programming language; I want to have just a
typesetting language." Little by little, however, I needed more
features and so the programming constructs grew. Guy Steele began
lobbying for more capabilities early on, and I put many such things
into the second version of TeX, TeX82, because of his urging.

--
Hai koe, zei de stier,
Kom mee met mij in de wei,
Dan zijn we tweezaam.
Lieven Marchand <m...@wyrd.be>

sv0f

unread,
Oct 1, 2002, 3:56:19 PM10/1/02
to
In article <877kh2d...@wyrd.be>, Lieven Marchand <m...@wyrd.be> wrote:

>no...@vanderbilt.edu (sv0f) writes:
>
>> I also recall reading that Steele was one of the early
>> adopters of TEX many years before, but I have no
>> reference for this.
>
>Knuth, Digital Typography, p. 648
>
>In the 70s, I had a negative reaction to software that tried to be all
>things to all people. Every system I looked at had its own universal
>Turing machine built into it somehow, and everybody's machine was a
>little different from everybody else's. So I thought, "Well, I'm not
>going to design a programming language; I want to have just a
>typesetting language." Little by little, however, I needed more
>features and so the programming constructs grew. Guy Steele began
>lobbying for more capabilities early on, and I put many such things
>into the second version of TeX, TeX82, because of his urging.

The collective memory of the group is a wonderful thing. Thanks.

Erik Naggum

unread,
Oct 1, 2002, 7:59:06 PM10/1/02
to
* Rob Warnock

| Good point. And also, as Tim Bradshaw pointed out in a parallel reply
| <URL:news:ey3u1k6...@cley.com>, attributes are not permitted to have
| sub-structure[1], while sub-elements may.

Well, actually, you can provide a NOTATION argument for attribute values.
This would indicate the standard or other document specifying the syntax
of the value, and the application would presumably know how to deal with
this. Also, there are actually some attribute types that require a flat
list of whitespace-separated values in the actually attribute value.

| Do you mean that the application is allowed to merge (remapping as
| needed) IDs/IDREFs from *multiple* documents? ...or *across* multiple
| docs?

ID and IDREF have many conflated uses. IDREF can only refer to IDs in
the same document instance, but with other mechanisms, you can refer to
elements with a given ID.

| The corresponding thing in CL might be trying to reference the same
| #n=/#n# numbers across multiple occurrences of READ. Normally, that
| wouldn't be a problem (because it's not possible), but my twisted little
| brain just started wondering about how #n= & #n# might interact with
| #. in pathological cases, as in:

I would have thought it fairly obvious that (list #.(foo #1=bar) #1#)
must fail, and it did not appear any less obvious that (list #1=foo
#.(foo #1#)) must fail. However, this is wrong. They work fine in
Allegro CL, CLISP and CMUCL (and SBCL). Hmm.

However, when you call a `read´ function without a true `recursive-p´
argument, that should mean that it establishes a new #n# context.

| +---------------
| | Grasping that this can be used for circular structures is apparently
| | hard for SGMLers when they have only learned to think of them in
| | "See Figure 1" terms.
| +---------------
|
| *ROTFLMAO!* Yes, I know what you mean, but... Does "See Figure 1"
| have the same alternate meaning for you guys over there as it does
| around here?!? ;-} ;-}

Yes, and it was intentional. (I always appreciate it when people "get"
such jokes.) I initially wrote "See Chapter 42" but that was hackneyed
and not entertaining at all.

Paolo Amoroso

unread,
Oct 2, 2002, 4:14:18 PM10/2/02
to
On Mon, 30 Sep 2002 08:34:08 -0000, rp...@rpw3.org (Rob Warnock) wrote:

> In the "replace EMACS LISP with Guile" thread,
> Erik Naggum <er...@naggum.no> wrote:
[...]
> | It takes considerable time to understand this, however. If you do /not/
> | grasp the core ideas behind SGML and XML, you will probably invent
> | something worse, such as an ad-hoc binary format...
> +---------------


>
> I'm very interested in learning what these "core ideas" are, since I

Erik also answered a similar question by me. See the comp.lang.lisp article
with Message-ID <32392820...@naggum.no>.


Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README

Dave Bakhash

unread,
Oct 3, 2002, 6:44:17 PM10/3/02
to
Tim Bradshaw <t...@cley.com> writes:

Now, as I recall, there is a Web browser that was out a couple of years
ago, written in CL (I think under ACL). If Emacs could handle CL, then
it could actually just plug in. That would have been nice.

Does anyone recall this CL browser? Anyone ever use it?

dave

Timmy Douglas

unread,
Oct 3, 2002, 8:23:37 PM10/3/02
to
Dave Bakhash <ca...@alum.mit.edu> writes:


I think it was called closure, but I never used it. Got this link from
google:

www.uni-karlsruhe.de/~unk6/closure/

It looks like it has it's own gui so I'm not sure if it would simply
plug into emacs.

Daniel Barlow

unread,
Oct 4, 2002, 4:39:35 AM10/4/02
to
Timmy Douglas <gtg...@mail.gatech.edu> writes:

> Dave Bakhash <ca...@alum.mit.edu> writes:
>> Does anyone recall this CL browser? Anyone ever use it?
>
> I think it was called closure, but I never used it. Got this link from
> google:

Current versions of closure are considerably changed from what you see
on that web page: it's now CLIM-based, and Gilbert Baumann (the
author) is also hacking on McCLIM (a.k.a FreeCLIM). Gilbert gave a
presentation on it at the Libre Software Meeting 2002, and there are a
few screenshots of it at http://ww.telent.net/cliki/Screenshots

> It looks like it has it's own gui so I'm not sure if it would simply
> plug into emacs.

I'm not sure why you'd want to plug a web browser into emacs any more
than you'd want to plug, say, a mua or usenet reader into emacs.


-dan

--

http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources

Alain Picard

unread,
Oct 4, 2002, 6:00:41 AM10/4/02
to
Daniel Barlow <d...@telent.net> writes:

> I'm not sure why you'd want to plug a web browser into emacs any more
> than you'd want to plug, say, a mua or usenet reader into emacs.

The reason for all these is the same: when composing messages,
articles, form fields in web forms, etc, you have the most
powerful editor at your command. In this respect, emacs users
have had the true IDE all along, and don't need to remember
27 ways of doing the same thing in 27 different applications.

Daniel Barlow

unread,
Oct 4, 2002, 8:10:26 AM10/4/02
to
Alain Picard <apicard+die...@optushome.com.au> writes:

I think I knew that. What I was getting at, though (and obviously
didn't make clear) is that "plug $foo into your text editor" is
essentially an inside-out view of the world, and as a general concept
I would far rather be able to plug my text editor into $foo.

Of course, this is emacs we're talking about, so the argument for
doing it in this inside-out fashion is usually more compelling. It
isn't the text editor as such you want to embed in, it's the rich
dynamic environment (GC, runtime typing, interactive evaluation) which
is (a) better than anything Unix typically offers, (b) rather too
"heavyweight" to blithely embed into another application without
feeling some twinge of guilt. And of course, (c) allows you to edit
text with _all_ your favourite gestures (a curse on whichever Mozilla
developer thought it would be funny to support C-k but not C-y ...)

In this specific case, though, we're talking about a Lisp app as the
other partner in this symbiosis. Closure runs in a _really_ rich (and
heavyweight) dynamic environment with generational GC, threading, CLX,
CLIM, etc (I believe that the McCLIM text editing component is
destined to end up looking pretty emacsy). So all I'm saying, really,
is "let's pause for a minute to consider which component is on top in
this relationship"

Alain Picard

unread,
Oct 5, 2002, 2:21:26 AM10/5/02
to
Daniel Barlow <d...@telent.net> writes:

> I think I knew that. What I was getting at, though (and obviously
> didn't make clear) is that "plug $foo into your text editor" is
> essentially an inside-out view of the world, and as a general concept
> I would far rather be able to plug my text editor into $foo.

I guess there's always export EDITOR=emacsclient for that.

> In this specific case, though, we're talking about a Lisp app as the

> other partner in this symbiosis. [snip] So all I'm saying, really,


> is "let's pause for a minute to consider which component is on top in
> this relationship"

Yes, but the earlier context of this was that we might be talking about
an emacs whose lisp was CL (hence the desire to embed closure instead
of the (slow) w3 code). If I misunderstood, my apologies.

Paolo Amoroso

unread,
Oct 6, 2002, 12:04:47 PM10/6/02
to
On 03 Oct 2002 18:44:17 -0400, Dave Bakhash <ca...@alum.mit.edu> wrote:

> Now, as I recall, there is a Web browser that was out a couple of years
> ago, written in CL (I think under ACL). If Emacs could handle CL, then
> it could actually just plug in. That would have been nice.
>
> Does anyone recall this CL browser? Anyone ever use it?

Do you mean Closure by Gilbert Baumann? It is still maintained, and it is
based on CLIM and runs fine also with McCLIM.

It is loading more messages.
0 new messages