Heh! Funny you should mention. The most successful (so far) of my many attempts at coming up with a usable reader macro shorthand for LAMBDA provides implicitly-declared parameters with names of $1, $2, &c., like a shell script. [The choice of "#$" as the reader macro is supposed to be a reminder of that.] It's too ugly and non-standard for code you might ever want to release to others, but on the other hand it's sometimes kinda convenient if you're just messing around interactively:
Rayiner Hashem <heli...@mindspring.com> wrote: > > Why as a user should I care whether a language feature can be > > omitted from some irreduciably minimal core? > A user might not, but a language designer should. So should a language > implementor, and anyone who works with tools (source browsers, IDEs, > etc) for that language.
The language users pay the language implementors. If the implementor's goal is not to please the language users, then something is wrong.
No user (except perhaps pure language research users) cares about an irreducible core, so the question is whether having a standardized feature is worth the extra time it takes to implement. For anything that a lot of people in disparate coding worlds will want to build, I'd say yes. For anything that *everyone* in a particular, common coding world will want to build, the answer is also yes. In practice, serious implementations have built many of the things that meet these criteria even when they were not standardized. Which means that you then have a bunch of different kinds of code out there doing essentially the same thing that is not portable. If one of the choices were standardized, then code that used it would be completely portable.
> > I *want* the common idioms > > that can be built on top of that core to be standardized > There is nothing to stop that if you have a minimal core.
But you're claiming that things which aren't in that minimal set should be removed from the standard. That makes sense only if said features are somewhat crufty or little used, or if your language spec is intended as an academic gem, rather than as an industrial programming language.
> , and it's > > just fine with me if that means they're part of the language definition. > This, however, is unnecessary.
Without some kind of layered library standards, it most certainly is necessary. When you put it in the standard (or a generally accepted standardized library layer), implementors will implement to that standard, and code using it will be portable. If you don't, implementors will roll their own and nothing is portable.
> > I want more stuff standardized in the language (or, in a single set of > > standardized libraries, which in practice amounts to the same thing) > The two scenarios do not amount to the same thing. The only thing in > the language standard should be stuff that absolutely needs > implementation support to be implemented effectively. This keeps the > language core lightweight, easier to implement, and allows for the > language standard to go long periods without updates.
But you essentially have that in the Common Lisp Standard. Have you read it through? It's clear that there is a core set of standards, and then there are a number of separate sets of capabilities that could mostly be built on top of that basic standard.
If someone really wanted to implement a non-ANSI, bare-common-lisp that behaved very much like common lisp, but left out a ton of functions and macros in the standard which did not require implementation support, they could certainly use much of the existing standard document as a specification.
Whether there is a market for such an implementation is another question, but if there is, no one is stopping anyone from filling it right now. AFAICT, except for a few young'ns who'd like to deliver easy-packaged applications without having to hack resources together or pay a reasonable price for commercial software, there is no such market. Most people want more and better standard libraries for doing things which either did not exist, or were not common when the original standard was made.
wallacethinmi...@eircom.net (Russell Wallace) writes: > Well, I think lists should be immutable because this gives cleaner > semantics, and because mutable lists don't do anything arrays and hash > tables can't do better.
If arrays and hash tables can be used instead of mutable lists, then they can be used instead of immutable lists too (just don't modify them). So by your logic there's no need for lists at all?
On 10 Sep 2003 11:53:25 +0300, Janis Dzerins <jo...@latnet.lv> wrote:
>If arrays and hash tables can be used instead of mutable lists, then >they can be used instead of immutable lists too (just don't modify >them). So by your logic there's no need for lists at all?
Except that to define arrays and hash tables, you need to have some notion of values, and you can't use arrays and hash tables for this without getting a circular definition. If you have immutable lists and a finite alphabet of characters, you can define strings, symbols and numbers in terms of these; as far as I can see, this gets you the cleanest semantics while still providing all the important capabilities.
>OK, it'll be easier this way: Anybody /not/ working on a new LispLite >please raise your hand.
*raises hand, then hesitates most of the way up* I am shooting the bull about what a new Lisp-like language should contain if the market for such still existed, I'm just not actually going ahead and implementing it :)
+--------------- | But you essentially have that in the Common Lisp Standard. Have you | read it through? It's clear that there is a core set of standards, and | then there are a number of separate sets of capabilities that could | mostly be built on top of that basic standard. | | If someone really wanted to implement a non-ANSI, bare-common-lisp that | behaved very much like common lisp, but left out a ton of functions and | macros in the standard which did not require implementation support, | they could certainly use much of the existing standard document as a | specification. +---------------
Just as a reminder: One could even legitimately call it "a subset of Common Lisp" if it met the extremely minimal requirement given in CLHS "1.7 Language Subsets":
For a language to be considered a subset, it must have the property that any valid program in that language has equivalent semantics and will run directly (with no extralingual pre-processing, and no special compatibility packages) in any conforming implementation of the full language.
I dare say that one could probably create a legitimate subset of Common Lisp that was not much (if at all) bigger than an R5RS Scheme. This is not intended as flame bait, but as a SWAG that one could write the spec for such a thing in the same ~50 pages as the Scheme spec, even smaller if one were permitted to refer to the ANSI Standard for things which were exactly the same (e.g, the C[AD]*R functions come to mind) or the same with some documented restrictions.
[Hmmm... Sounds like a candidate for a student semester project, eh?]
+--------------- | Whether there is a market for such an implementation is another | question... +---------------
Yes, er... well... indeed. That is actually the important question.
+--------------- | ...but if there is, no one is stopping anyone from filling it right now. +---------------
Right. (See above.)
-Rob
----- Rob Warnock, PP-ASEL-IA <r...@rpw3.org> 627 26th Avenue <URL:http://rpw3.org/> San Mateo, CA 94403 (650)572-2607
r...@rpw3.org (Rob Warnock) writes: > I dare say that one could probably create a legitimate subset of Common > Lisp that was not much (if at all) bigger than an R5RS Scheme. This is > not intended as flame bait, but as a SWAG that one could write the spec > for such a thing in the same ~50 pages as the Scheme spec, even smaller > if one were permitted to refer to the ANSI Standard for things which > were exactly the same (e.g, the C[AD]*R functions come to mind) or the > same with some documented restrictions.
I've actually engaged serious people on a discussion of this and it usually comes down to that even those who are of a mind to try get saddened and give up when they find that the number of lines of denotational semantics will increase. (Sometimes I wonder if that's because a larger denotational semantics is bad, or if it's just that they're like microcode--something that's no fun to write and so you'd rather use one that's already there... I don't speak either myself, and have never felt held back, except in discussions like these where I have to speculate. I personaly find a denotational semantics redundant and therefore a risk of error (due to discrepancy); if I'm going ot have only one version, I want it to be approachable by people. Others' MMV.
>Donald Fisk wrote: >> I've been working on a new (not Common) Lisp implementation too,
>OK, it'll be easier this way: Anybody /not/ working on a new LispLite >please raise your hand.
>:)
I'm not...yet.
I wouldn't mind working on a Lisp implementation. Any of you that are working on it, need some gruntwork done? I'm still pretty new to Lisp, but I would love to get involved with a project. Kenny, need any help on cells? What better way to learn Lisp, than writing it!!
Doug Tolton (format t "~a@~a~a.~a" "dtolton" "ya" "hoo" "com")
> >Donald Fisk wrote: > >> I've been working on a new (not Common) Lisp implementation too,
> >OK, it'll be easier this way: Anybody /not/ working on a new LispLite > >please raise your hand.
> >:)
> I'm not...yet.
> I wouldn't mind working on a Lisp implementation. Any of you that are > working on it, need some gruntwork done? I'm still pretty new to > Lisp, but I would love to get involved with a project. Kenny, need > any help on cells? What better way to learn Lisp, than writing it!!
>>>I've been working on a new (not Common) Lisp implementation too,
>>OK, it'll be easier this way: Anybody /not/ working on a new LispLite >>please raise your hand.
>>:)
> I'm not...yet.
> I wouldn't mind working on a Lisp implementation. Any of you that are > working on it, need some gruntwork done? I'm still pretty new to > Lisp, but I would love to get involved with a project. Kenny, need > any help on cells? What better way to learn Lisp, than writing it!!
Cells and RoboCells are now both SourceForge projects, MIT-style license. I'll probably do Cello (the GUI built atop Cells) under the Cells project. Right now only the RoboCells project has source and doc, but that includes the latest/greatest in Cells, including a tiny bit of doc.
Cells are pretty much done in the sense of mature, tho they will be expanding all the time. I got part way thru implementing them for structures to get a lighter-weight implementation, and I might create a lazy option so I do not have to talk anymore to the ninnys who think that is a good idea. :)
If you have time, watch for the next release of RoboCells and jump on that. But if you are still learning Lisp it will be tough to contribute much before the conference in October.
As for Cello, now there we can talk. That needs an OpenGL wiz, or if I decide to switch to Gtk or Tk for window management and text/graphic support, someone strong there. And any of these projects could use someone to take a new release and validate it under any of the supported combos of Cl implementation and OS. I work on ACL under win32, so someone strong on Linux can be big help supporting that side of things.
thx for the interest. Good luck with whatever project you settle on. And watch for the "Lisp With Kenny Far Away!" distance learning series, to begin after ILC2003.
btw, the line-up for this conference is tremendous. when I heard the list of luminaries who will be talking, including John McCarthy Himself, I started getting a serious case of performance anxiety. i think we will point to ILC2003 and say that is when CL turned the corner and started its run for the gold. also, autumn is a beautiful time to be in NYC.
y'all should join us, :)
--
kenny tilton clinisys, inc http://www.tilton-technology.com/ --------------------------------------------------------------- "This is my simple religion. There is no need for temples; no need for complicated philosophy. Our own brain, our own heart is our temple; the philosophy is kindness." -- Tenzin Gyatso, the Dalai Lama
Kent M Pitman <pit...@world.std.com> wrote: +--------------- | r...@rpw3.org (Rob Warnock) writes: | > ...as a SWAG [] one could write the spec for [a workable subset | > of Common Lisp] in the same ~50 pages as the Scheme spec... | | I've actually engaged serious people on a discussion of this and it usually | comes down to that even those who are of a mind to try get saddened and | give up when they find that the number of lines of denotational semantics | will increase. ... I personaly find a denotational semantics redundant... +---------------
Ditto. In my hypothetical CL subset spec vs. Scheme spec comparison I was counting only the core "human readable" part of the spec, not the "Formal syntax and semantics" backend of the Scheme spec -- especially since the "rules" of CL subsetting say that the semantics of whatever is included in the subset must be the same as full CL, and therefore a CL subset spec writer would presumably simply point to the ANSI spec for that! [How's that for wiggling out of it?] ;-} ;-}
-Rob
----- Rob Warnock, PP-ASEL-IA <r...@rpw3.org> 627 26th Avenue <URL:http://rpw3.org/> San Mateo, CA 94403 (650)572-2607
Doug Tolton <dtol...@yahoo.com> writes: > I wouldn't mind working on a Lisp implementation. Any of you that are > working on it, need some gruntwork done? I'm still pretty new to > Lisp, but I would love to get involved with a project. Kenny, need
Doug Tolton <dtol...@yahoo.com> writes: > On Sat, 06 Sep 2003 22:03:43 GMT, Kenny Tilton <ktil...@nyc.rr.com> > wrote: >>OK, it'll be easier this way: Anybody /not/ working on a new LispLite >>please raise your hand.
:-)
> I'm not...yet.
Nor I. I'm working on an existing implementation of an existing standardized language. That way, I get all the benefit of the work that the ANSI committee, and the implementors before them, put into design, _and_ I don't have to care about implementing the cruftier bits (whichever bits you think they are[*]) because it's already been _done_.
> I wouldn't mind working on a Lisp implementation. Any of you that are > working on it, need some gruntwork done? I'm still pretty new to > Lisp, but I would love to get involved with a project. Kenny, need > any help on cells? What better way to learn Lisp, than writing it!!
There's all kinds of thing that could be done in SBCL: bug fixes, thread auditing, new contrib modules, enhancements to current contrib modules (there's always work to be done on SB-POSIX), new external asdf-installable (i.e. CCLAN) libraries. Or you could download CLX and McCLIM and try your hand at some CLIM programming, or check out Portable Hemlock and write some neat stuff in a real CL Emacs-like editor; help free us from ILISP. Or ...
Are you on the clump mailing list? Lots of stuff happening there.
Seriously, this is a good time to hack Lisp. And you don't have to hack the implementation directly either; there's lots of userland stuff to do.
-dan
[*] Personally I'd like a pathname abstraction that makes sense on arbitrary unix filenames, and an environment chapter defined tightly enough that you could actually do anything with the answers beyond reporting them to the user. But, hey. No big deal.
Daniel Barlow wrote: > There's all kinds of thing that could be done in SBCL:
Just kidding about the flamewar, I am just wondering if the whole LX world has shifted to SBCL without telling me. I have just started chipping away at the whole LX/CMUCL/EMACS/ILISP etc etc etc learning curve and will swap in SBCL for CMUCL if the former is surging ahead to stay. I know active development is going on in both, including nice PCL speed-up for CMUCL and a couple of hacks to permit callbacks to Lisp from C.
So...is SBCL ready for prime time? Can it do callbacks from C? Is CMUCL fading in popularity if not new development? Do some people use both? Email feedback is fine if your asbestos is at the cleaners. :)
And in case that does not succeed in starting a flamewar, why the divided effort? Why not CCCL (Common CMU Common Lisp)? Fundamental differences, I presume, so this should really get things going.
:)
--
kenny tilton clinisys, inc http://www.tilton-technology.com/ --------------------------------------------------------------- "This is my simple religion. There is no need for temples; no need for complicated philosophy. Our own brain, our own heart is our temple; the philosophy is kindness." -- Tenzin Gyatso, the Dalai Lama
On Thu, 11 Sep 2003 16:32:27 +0100, Daniel Barlow <d...@telent.net> wrote:
>There's all kinds of thing that could be done in SBCL: bug fixes, >thread auditing, new contrib modules, enhancements to current contrib >modules (there's always work to be done on SB-POSIX), new external >asdf-installable (i.e. CCLAN) libraries. Or you could download CLX >and McCLIM and try your hand at some CLIM programming, or check out >Portable Hemlock and write some neat stuff in a real CL Emacs-like >editor; help free us from ILISP. Or ...
>Are you on the clump mailing list? Lots of stuff happening there.
>Seriously, this is a good time to hack Lisp. And you don't have to >hack the implementation directly either; there's lots of userland >stuff to do.
>-dan
I just subscribed to the clump mailing list. It looks like there are some really good projects to get involved with, I am leaning towards SBCL, although I wouldn't mind helping with some of the other projects mentioned. Thank all of you for your suggestions, I am going to start looking through the code of some of these projects and hopefully get an idea about where to start.
Doug Tolton (format t "~a@~a~a.~a" "dtolton" "ya" "hoo" "com")
Kenny Tilton <ktil...@nyc.rr.com> writes: > So...is SBCL ready for prime time? Can it do callbacks from C? Is > CMUCL fading in popularity if not new development? Do some people use > both? Email feedback is fine if your asbestos is at the cleaners. :)
Define "prime time" ...
I'm going to tackle this by assuming that you consider CMUCL ready for prime time, so a comparison with CMUCL is useful. If you don't, it's not, and you need to ask some better-directed questions.
- Most of the library code is pretty similar between the two implementations except for the bits that don't exist in SBCL. Most of this (sockets, CLX, Posix access, date parsing etc) is available as add-on libraries; it might just take a little longer to assemble
- The compiler is still slower (though substantially faster in CVS than 0.8.3 was; we're catching up).
- Threads in SBCL are new and largely untested - they're native threads using the kernel scheduler, whereas CMUCL threads are scheduled by Lisp. There are advantages and disadvantages to each approach
- I _think_ SBCL is ahead on the number of currently working platforms. We're ahead on fashionable platforms, at least - we have PPC/MacOS X and they don't, ner ner ner
- ILISP probably gets more easily confused with SBCL (one of the reasons I want people to hack on Portable Hemlock ;-) especially where threads are concerned. I'll probably investigate this one day when I get sufficiently annoyed by it: I suspect ILISP may be trying to send an interrupt to the wrong process id or something.
- CMUCL (the CVS version of) has a generational GC on SPARC and X86, whereas SBCL only has it on x86. Our OS X guys are planning how to port it to PPC, though
> And in case that does not succeed in starting a flamewar, why the > divided effort? Why not CCCL (Common CMU Common Lisp)? Fundamental > differences, I presume, so this should really get things going.
Musical differences, yes. A little competition is good for everyone.
Plus which, the name CCCL is only going to get confused with MCL (ex-Coral Common Lisp) or Corman. So that's no good.
Stefan Scholl <ste...@no-spoon.de> wrote in message <news:sy6lb2jeox51.dlg@parsec.no-spoon.de>... > Funny thing is: you can edit CMUCL and SBCL with Emacs _and_ with > XEmacs! :-)
Well, CMUCL-18e with XEmacs/ilisp seems to have problems for some people. (see ilisp mailing list...). I don't know myself, I use plain gnu emacs+ilisp with CMUCL 18e with no problem.
Something to point out. There has been serious progress recently with Free CLIM. They have a lisp listener that actually seems to work pretty well and has lisp-listener-like features. It's something I tried to do on and off in various environments for years without any real success.
Also, the g-sharp group has put out an alpha (pre-alpha?) version of their CLIM-based music editor which shows a lot of potential.
As far as my own efforts are concerned, I've been trying to hack CMU Lisp so it will save executables. I've gotten to the point where it works reliably under FreeBSD. You can type
(save-lisp "foo" :executable t)
and you wind up with a stand-alone file that you can run, in which the CMU lisp spaces are elf sections.
I'm still having trouble with stable operation under Linux (which I'm beginning to believe may be more a result of the current state of the CMUCL Linux port than my stuff) otherwise I'd have released it for general consumption already.
I have to concur with others. There's a lot of stuff to do, and not that many people doing it. The field is wide open. Jump in. Become a celebrity like Kenny Tilton.
-- Fred Gilham gil...@csl.sri.com A step into the Way has been made by the person who ceases to say, "God, look how big my problems are!", and instead says, "Problems, look how big my God is!" -- Jonathan Hayward
Fred Gilham wrote: > There's a lot of stuff to do, and not > that many people doing it. The field is wide open. Jump in.
Yeah, it's nuts whining about "no Lisp jobs" if one is not working to fill in the library gap. Pick something of interest or in your area of strength and go.
> Become > a celebrity like Kenny Tilton.
I am a simple Lisp programmer.
--
clinisys, inc http://www.tilton-technology.com/ --------------------------------------------------------------- "I am a simple Buddhist monk. " -- Tenzin Gyatso, the Fourteenth Dalai Lama
Kenny Tilton <ktil...@nyc.rr.com> writes: > > Become > > a celebrity like Kenny Tilton.
> I am a simple Lisp programmer.
> --
> clinisys, inc > http://www.tilton-technology.com/ > --------------------------------------------------------------- > "I am a simple Buddhist monk. " > -- Tenzin Gyatso, the Fourteenth Dalai Lama
On top of everything else, humble too! :-)
-- Fred Gilham gil...@csl.sri.com The rage of dance and style that swept the country in the late '70s crumbled from serious backlash as disco freaks seemed to finally wake up and realize what they were wearing. -- Michael Okwu
Fred Gilham wrote: > Kenny Tilton <ktil...@nyc.rr.com> writes:
>>> Become >>>a celebrity like Kenny Tilton.
>>I am a simple Lisp programmer.
>>--
>> clinisys, inc >> http://www.tilton-technology.com/ >> --------------------------------------------------------------- >>"I am a simple Buddhist monk. " >> -- Tenzin Gyatso, the Fourteenth Dalai Lama
> On top of everything else, humble too! :-)
Oh, gosh, sorry. Just noticed that now!
:)
--
clinisys, inc http://www.tilton-technology.com/ --------------------------------------------------------------- "I'm non-violent, but if a hawk comes down when I'm feeding my birds, I lose my temper and get my air rifle." -- Tenzin Gyatso, the Fourteenth Dalai Lama
Fred Gilham <gil...@snapdragon.csl.sri.com> writes:
[...]
> I'm still having trouble with stable operation under Linux (which > I'm beginning to believe may be more a result of the current state > of the CMUCL Linux port than my stuff) otherwise I'd have released > it for general consumption already.
[...]
Perhaps post the patches anyways so that other people could perhaps have a shot at the problem? At the very least it will give the FreeBSD users the use of the enhancement. :>
"Given enough eyeballs, all bugs are shallow" (Linus's Law) and all that.
-- David Magda <dmagda at ee.ryerson.ca>, http://www.magda.ca/ Because the innovator has for enemies all those who have done well under the old conditions, and lukewarm defenders in those who may do well under the new. -- Niccolo Machiavelli, _The Prince_, Chapter VI
