Alain Picard <apicard+die-spammer-...@optushome.com.au> writes: > 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.
no. you got it right. The bottom line, and the key point, is that the wads of elisp code don't suddenly break. You want to support all that legacy stuff. So, for example, you could go to Xanalys, add some features to their editor to support Emacs Lisp, and Emacs features, and that would be a solution. Or you can go to (X)Emacs, rip out the Emacs Lisp engine and replace it with an embeddable CL. It's really the same difference.
I think the cleanest way is to start from scratch, which in the CL world means starting from the CL environment. One would have to implement the basics of what (X)Emacs has (windows, buffers, etc.)
Am I wrong, or is it not a good idea to start from the CL side, throwing away a lot of the C code that's now part of (X)Emacs?
>> 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.
>no. you got it right. The bottom line, and the key point, is that the >wads of elisp code don't suddenly break. You want to support all that >legacy stuff. So, for example, you could go to Xanalys, add some >features to their editor to support Emacs Lisp, and Emacs features, and >that would be a solution. Or you can go to (X)Emacs, rip out the Emacs >Lisp engine and replace it with an embeddable CL. It's really the same >difference.
>I think the cleanest way is to start from scratch, which in the CL world >means starting from the CL environment. One would have to implement the >basics of what (X)Emacs has (windows, buffers, etc.)
>Am I wrong, or is it not a good idea to start from the CL side, throwing >away a lot of the C code that's now part of (X)Emacs?
Didn't Tim Bradshaw among others only recently state, earlier on in this very thread, that there were enormous economic barriers against this (in reply to my observation that there was no technical barrier)? I thought you were agreeing with Tim then.
d...@goldshoe.gte.com (Dorai Sitaram) wrote in message <news:ansuao$lm3$1@news.gte.com>... > In article <c29ptumt628....@nerd-xing.mit.edu>, > Dave Bakhash <ca...@alum.mit.edu> wrote: > >Am I wrong, or is it not a good idea to start from the CL side, throwing > >away a lot of the C code that's now part of (X)Emacs?
> Didn't Tim Bradshaw among others only recently state, > earlier on in this very thread, that there were > enormous economic barriers against this (in reply to my > observation that there was no technical barrier)? > I thought you were agreeing with Tim then.
I said it, and I stand by it. There are so many things that are more useful to do than reimplement Emacs. There's not even the Linux justification that it isn't free already.
>[...] >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.
gnus entering a newsgroup with many articles? Things where you wait an eternity for gnus, while trn just flies? *g*
Dave Bakhash <ca...@alum.mit.edu> writes: > Scheme is a degenerate -- a mutation, if you will. [...] > It's just as in biology: most mutations are bad, though some are good.
The goodness or badness of a mutation can depend heavily on the organisms environment.
Scheme is good for what the Scheme community wants to do and Common Lisp is good for what the CL community wants to do.
Trying to merge these two communities and create a compromise Lisp that everybody can use is bound to be a failure.
Rather than posting negative views of the other groups icon, you should just accept that they are happy with what they have. Leave them be.
tfb+goo...@tfeb.org (Tim Bradshaw) writes: > > Didn't Tim Bradshaw among others only recently state, earlier on in > > this very thread, that there were enormous economic barriers against > > this (in reply to my observation that there was no technical > > barrier)? I thought you were agreeing with Tim then.
> I said it, and I stand by it. There are so many things that are more > useful to do than reimplement Emacs. There's not even the Linux > justification that it isn't free already.
first off, the argument of how something would, should, and could be done has little to do with whether or not to do it at all. However, on this note, I do think that it's probably worthwhile to redo the Emacs thing, and do it right...i.e. with CL. Just my $0.02
Since I live inside Emacs, an Emacs that I could program with CL would eventually subsume almost all of the applications I use. Not to mention that using CL instead of the broken Emacs Lisp that doesn't really allow for multiprocessing is painful. It's slow, and it's a memory beast. I think seeing a CL-based Emacs as a useless project is short-sighted. To me, even a moderately deep knowledge of Emacs and its shortcomings would unveil the potential benefits of a rewrite in CL...on so many levels.
> first off, the argument of how something would, should, and could be > done has little to do with whether or not to do it at all. However, on > this note, I do think that it's probably worthwhile to redo the Emacs > thing, and do it right...i.e. with CL. Just my $0.02
I'm not sure I understand this. If you're trying to argue that there is some domain of theoretical possibility which is different from the enginerring domain where cost matters: well, yes there is, of course. But I live in a world where money and time matters, and so I'm pretty interested in spending my time sensibly: as I argued before, the US can technically send people to pluto, but you might not want to pay 70% tax for 10 years to do so, especially when there are other things competing for your time & money.
> Since I live inside Emacs, an Emacs that I could program with CL would > eventually subsume almost all of the applications I use. Not to mention > that using CL instead of the broken Emacs Lisp that doesn't really allow > for multiprocessing is painful. It's slow, and it's a memory beast. I > think seeing a CL-based Emacs as a useless project is short-sighted. To > me, even a moderately deep knowledge of Emacs and its shortcomings would > unveil the potential benefits of a rewrite in CL...on so many levels.
Well, I guess we have to differ on that - I have a moderately deep knowledge of Emacs, and I just disagree. (The memory beast thing is just unambiguously false unless you live on really old HW - XEmacsen that have been running VM for many weeks with many tens of large mail files open seem to grow to about 30-40Mb. I guess this is a lot of memory if you live in 1990). If there was nothing else left to do int he world, then sure, rewrite emacs. But there are other things competing for time & money in fact, and some of them might just be more useful. (I hope the stupid myth that there is infinite time & money has died with the stupid dot-com myth that spawned it...)
Dave Bakhash <ca...@alum.mit.edu> writes: > To me, even a moderately deep knowledge of Emacs and its shortcomings would > unveil the potential benefits of a rewrite in CL...on so many levels.
it is good to have understanding. next, find some time to take action.
Greg> No doubt CL is a better technical choice, but scheme has a lower Greg> learning-curve initially. Maybe RMS wants to compete against the Dr. Greg> Scheme folks...
Having started with elisp and later CL, learning scheme was actually rather difficult because it looks like lisp but it isn't. Things like Lisp-1 vs Lisp-2, lots of functions that I'd become accustomed to having available aren't, etc., etc., etc.
If I didn't know either, and came from a C/C++ world, I think Lisp would be easier since C/C++ are "Lisp-2" languages since functions and variables are different. In some very rough sense.
I find it extremely odd to use scheme for elisp when elisp is closer to Lisp than scheme....
greg_new_...@yahoo.com (Greg Neumann) wrote in message <news:44d4f61c.0210140635.c78df51@posting.google.com>... > > I was dumbfounded that Richard Stallman himself was advocating using a > > Scheme interpreter instead of Lisp.
> All the guile/emacs projects make it clear that there'll be backwards > compatability, because they're not suicidal.
> No doubt CL is a better technical choice, but scheme has a lower > learning-curve initially.
Binary code has a lower initial learning curve too: there are just two symbols to learn. And look how adding two numbers reduces to simple logical operations that can be represented by tiny truth tables; it's so *pure*! Why doesn't the whole world just ditch its alphabets and digits 2 through 9?
Could it be that taking out the complexity from something really just pushes it elsewhere? Taking out the complexity from a programming language pushes it into the program. Moving complexity from one place to another, in itself, wouldn't be a problem, if it were not the case that there is a class-instance relationship between a notation and utterances in that notation. Countless instances of utterances have to contain individual instantiations of the extra complexity that was factored out from the notation.
>> I was dumbfounded that Richard Stallman himself was advocating using a >> Scheme interpreter instead of Lisp.
> All the guile/emacs projects make it clear that there'll be backwards > compatability, because they're not suicidal.
> No doubt CL is a better technical choice, but scheme has a lower > learning-curve initially. Maybe RMS wants to compete against the Dr. > Scheme folks...
How can Scheme have a lower learning curve when it forces you to learn many of its idiosyncrasies straight away?
I discovered Scheme shortly before ANSI Common Lisp and found I was fighting it at every turn. Why can't I use a variable named list? Why do I need to use the apparently redundant keyword lambda in every function definition? Why do I have to fake iteration using recursion? Why aren't the most elementary constructs built into the language? Does it have to be this slow? Why does this only feel suitable for scripting?
It soon became apparent that I was fighting the Scheme ethos of conceptual elegance and simplicity. To put it a less polite way you dump most of the work onto the programmer and let them deal with all the inconsistencies between implementations.
It is much smaller than Common Lisp; the language specification is about 50 pages, compared to Common Lisp's 1300 page draft standard. Advocates of Scheme often find it amusing that the entire Scheme standard is shorter than the index to Guy Steele's Common Lisp: the Language, 2nd Edition. Unlike the Scheme standard, the Common Lisp standard has a large library of utility functions, a standard object-oriented programming facility (CLOS), and a sophisticated condition handling system.
(Comparing the size of the Scheme specification with the ANSI CL Loop specification may also provide amusement).
So much has been left out of the Scheme specification that you cannot even rely upon an implementation to evaluate arguments from left to right:
I did make the effort to at least *try* the code I posted, and it worked just as I said it did, on MIT Scheme.
What's the difference? MzScheme evaluates left-to-right and MIT Scheme evaluates right-to-left.
This is the kind of error that that even professions shouldn't need to avoid when attempting to create portable code. Plus there is no standard package specification for building large projects without naming conflicts.
What this amounts to is that Guile Scheme cannot possibly solve the problem of replacing Emacs Lisp with a less idiosyncratic implementation. You will end up having to know the idiosyncrasies of a particular Scheme implementation just like currently happens with Emacs Lisp.
It's a squandered opportunity to extend Emacs in a way that would allow people to apply their learning of a well specified standard directly to Emacs, regardless of the particular ANSI Common Lisp implementation that programmers use.
> I discovered Scheme shortly before ANSI Common Lisp and found I was > fighting it at every turn. Why can't I use a variable named list? Why do I > need to use the apparently redundant keyword lambda in every function > definition? Why do I have to fake iteration using recursion?
For the sake of accuracy, I should point out that all three of these are false. 1. You can rebind/redefine the identifier 'list' to mean whatever you want it to, you simply can't, within the scope of that binding, refer to the predefined 'list' by its original name. This might seem like quibbling, but the next two points are not quibbling. The original points are solidly false. 2. There is no need to use 'lambda' in function definitions. See section 5.2 of r5rs. 3. There is a built-in iteration syntax in scheme: 'do'. See section 4.2.4 of r5rs.
> "Adam Warner" <use...@consulting.net.nz> wrote in message > news:pan.2002.10.15.01.04.46.328094@consulting.net.nz... >> I discovered Scheme shortly before ANSI Common Lisp and found I was >> fighting it at every turn. Why can't I use a variable named list? Why >> do I need to use the apparently redundant keyword lambda in every >> function definition? Why do I have to fake iteration using recursion?
The complete list was my impressions as a newbie to Scheme. Your clarifications are helpful.
> For the sake of accuracy, I should point out that all three of these are > false. > 1. You can rebind/redefine the identifier 'list' to mean whatever you > want it to, you simply can't, within the scope of that binding, refer to > the predefined 'list' by its original name. This might seem like > quibbling, but the next two points are not quibbling.
Yes it's quibbling because you cannot use the essential function list (which almost certainly has no place being redefined) at the same time. The response was directed to Greg who seems to believe that Scheme is easier to learn than Lisp. The fact that any newbie who creates a symbol called list will soon discover that their code breaks is a reason that Scheme isn't easier to learn.
I'm at two minds about multiple namespaces: While it allows greater expressiveness and it helps to futureproof code against specification expansion (because future function names won't sit badly with current variables using the same name) parsing the code seems harder. You have to understand the forms being used to determine which namespace is being accessed.
> 2. There is no need to use 'lambda' in function definitions. See section > 5.2 of r5rs.
(define (<variable> <formals>) <body>) <Formals> should be either a sequence of zero or more variables, or a sequence of one or more variables followed by a space-delimited period and another variable (as in a lambda expression). This form is equivalent to
(define <variable> (lambda (<formals>) <body>)).
Ah, so this syntax trick is the way to distinguish between a function definition and a variable definition. So Scheme does have two different definition mechanisms: (define (<variable> <formals>) <body>) could have been expressed as (defun <variable> (<formals>) <body>).
> 3. There is a built-in iteration syntax in scheme: 'do'. See section > 4.2.4 of r5rs.
When I talk to a software vendor about my thoughts as a user, I expect her to second guess me if she really is an expert. But I also expect her to listen and not think I'm attacking.
If you think my words are wrong or dangerous, and you think this perception is widespread enough to affect things you like badly, maybe it's time to think about correcting that perception in an effective way. I so far have no reason to think that Scheme has a worse initial learning curve than Lisp, because Scheme was designed for this. Maybe it's a Visual Basic, but VB has been useful for many.
I don't know what to say. I have a copy of Graham's ANSI CL, have read many of the Pitman posts (which is 3/4 of what I read here), and I still prefer Scheme. You all have mused about this subject longer than I.
Anyway, if you want to correct this perception and find out what madness lies in the mind of a Schemer, feel free to ask. But there are profs more knowledgeable than I...
> I don't know what to say. I have a copy of Graham's ANSI CL, have read > many of the Pitman posts (which is 3/4 of what I read here), and I still > prefer Scheme. You all have mused about this subject longer than I.
That you still prefer Scheme is not the issue Greg. The issue is your (innocent and offhand) comment that "scheme has a lower learning-curve initially." I would like to understand how this could be the case.
All I see is a lower plateau that requires a new programmer to quickly move to implementation-specific constructs (in ways that are slow and bug prone). How can it be easier for a new programmer to have to go off and build what is already available in CL?
How is it easier that a new programmer must learn CAR, CADR, CADDR and CDR instead of FIRST, SECOND, THIRD and REST?
How is it easier for a new programmer to be continually told that what they are trying to achieve is not in the specification, and implementation X does it one way while implementation Y does it another?
To put the question less abstractly, where does the extra functionality of CL get in the way of a new programmer learning CL compared to learning Scheme?
k...@ashi.footprints.net (Kaz Kylheku) wrote in message <news:cf333042.0210141435.4b728e23@posting.google.com>... > > No doubt CL is a better technical choice, but scheme has a lower > > learning-curve initially. [snip...] > Could it be that taking out the complexity from something really just > pushes it elsewhere?
I think you're basically elaborating on my point. My point was abouu taking the complexity from one place and putting it elsewhere.
> Moving complexity from one place > to another, in itself, wouldn't be a problem, if it were not the case > that there is a class-instance relationship between a notation and > utterances in that notation.
Well, I'm sure elisp will always be there for you as a backwards compat layer. Maybe neither Lisp nor Latin will save the world, but beautiful things have been written in them. And I don't even see the transition to Scheme as even a greatly desirable thing for Gnu. Is this the best place to focus efforts? Are enough programmers even motivated to tackle this relatively unsexy project?
If you sense a disconnect between us, it's that in this case my thoughts are about what is best for Emacs, not solely the technical aspects. There are a few issues at hand:
1) integration with Guile means a better UI for users of other Guile-extended packages -- and Guile is the big gnu-supported scripting language 2) scheme has very good free educational materials, which strive to teach more than just scheme 3) lisp users will probably find the transition to scheme no more jarring than the schemer's transition to lisp 4) it's free software, so emacs can be forked whether or not rms wants it to 5) this is a gnu project, and presumably they like to use scheme, so they should work on what they like. Plus rms just might know a thing or two about emacs, lisp and scheme.
* Greg Neumann | Anyway, if you want to correct this perception
I would greatly prefer if such "perceptions" did not have to be corrected all the time from relative beginners in Scheme who have only picked up its serious attitude problem when they do /actually/ not start to learn Common Lisp. (Amazing response to my one-line, btw.)
-- 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.
* Greg Neumann | 3) lisp users will probably find the transition to scheme no more jarring | than the schemer's transition to lisp
So much approximation and so many statements without foundation... Most Scheme users at least have attained a level of precision in the regular communication.
This is not so, either. From Scheme to Common Lisp is like a refugee from very rural Pakistan who gets relocated to Oslo, Norway, and still thinks that he could make better food if he were only allowed to light a fire in his living room instead of using that complex electric stove. (This is a real news item. Every now and then, landlords discover indoor fireplaces and occasionally the "newbies" to civilization burn down the building.) While it may seem "jarring" to the newbie to learn the ropes of a society that has evolved at least a thousand years further than what they left, it would not be the same for us to try out their lifestyle.
| 4) it's free software, so emacs can be forked whether or not rms wants it | to
Wrong. The illusion of freedom with supposedly free software is blinding to people who have never tried to make use of it.
| 5) this is a gnu project, and presumably they like to use scheme, so they | should work on what they like. Plus rms just might know a thing or two | about emacs, lisp and scheme.
Why does he need you to be a go-between to the Common Lisp community?
Please remove some of your attitude and listen a little more.
-- 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.
> Wrong. The illusion of freedom with supposedly free software is blinding > to people who have never tried to make use of it.
I'm sorry, do you mean the illusion of freedom with GPLed free software? You wouldn't say that CMUCL isn't free, would you? (Still free as in freedom, not in cost.) Or is there something I'm not getting here?
Hi Adam. I've looked through my code to see what makes me feel uncomfortable with Lisp. It was mostly having to remember again that you need to funcall/quote this and defun that... And my defuns didn't stay local to their environment, unlike in Python and Scheme. (A purely elisp issue?) Little things. Maybe superficial, but when you introduce to a beginner, these little things are so huge.
How many people will write huge scripts in emacs? Less than the number who write tiny ones. Everyone has some tiny need they want to fulfill that the bigger packages don't.
"Adam Warner" <use...@consulting.net.nz> wrote in message <news:pan.2002.10.15.04.51.48.22395@consulting.net.nz>... > All I see is a lower plateau that requires a new programmer to quickly > move to implementation-specific constructs (in ways that are slow and bug > prone). How can it be easier for a new programmer to have to go off and > build what is already available in CL?
Yup, Scheme isn't a "comes with batteries" language. But keep in mind that a lot of what many programmers want to do is access platform APIs, like Java or Cocoa. Not so much on the serverside, but on the client. So with lisp you're already at the mercy of impl-dependent constructs.
I like that Scheme can be ported quickly to Java. (Admittedly this is a bit confusing to me though, since I'd think a lot of lisp is in lisp...) And the scheme community is a bit more promiscuous, so there's always someone porting Scheme to the craziest thing.
But again, if porting elisp to CL is a great improvement, I'm all for it. There should be a Bothner or Norvig to do it.
Erik Naggum <e...@naggum.no> writes: > The illusion of freedom with supposedly free software is blinding to > people who have never tried to make use of it.
Is "it" here referring to use of the software itself, or of the freedom this software promises? You're hinting at some trouble here. Please elaborate.
