* Re: About Emacs Modernisation Project [not found] <143c6d28-4423-4e43-9fc5-c0fb3340043b@c11g2000vbe.googlegroups.com> @ 2010-05-31 15:44 ` Pascal J. Bourguignon [not found] ` <0e994fe3-6dde-449f-879d-6701c7a195a9@e28g2000vbd.googlegroups.com> [not found] ` <87ljazofkn.fsf@rapttech.com.au> 1 sibling, 1 reply; 32+ messages in thread From: Pascal J. Bourguignon @ 2010-05-31 15:44 UTC (permalink / raw To: help-gnu-emacs Bernardo Barros <bernardobarros@gmail.com> writes: > I was reading about this topic on the group homepage. One thing I > though was how Emacs is really great because of Emacs Lisp, since it > is a real programming language and an text editor at the same time. > But maybe one of the reasons that Emacs is not so popular nowadays is > that Lisp itself is also not so popular anymore either. Someone told > something about less than 1%. > > I have just checked the Pymacs project [http://www.emacswiki.org/emacs/ > PyMacs] and I though to myself: "oh, that's a nice one, I could use > Python instead of elisp to extend Emacs, I would like that a lot!". > I'm a young guy and I don't work with lisp languages at all except > when I use Emacs and Lilypond (a music notation program). > > But it seems to me that PyMacs is not a mature project yet, I would > like to see this as a major version of Emacs. Maybe this is the way > for Emacs 24 or 25? :-) Lisp is a great language to implement compilers and interpreters with, including of other, very different languages. If you would like to customize, or have your users customize, emacs in a different language than emacs lisp, then you can use or implement easily such a different language in emacs lisp. For example, there's ejacs, implementing javascript in emacs lisp. There's emacs-cl, an implementation of Common Lisp in emacs lisp. There's cl-python, an implementation of Python in Common Lisp, that you could run on emacs-cl. And several others I don't know or that I don't recall. It's true that in all these cases, these packages would need some love and further integration with emacs (the editor functions library) to make them really usable. It is true also that it would be much easier to import various things such as these other languages in emacs if it was written in Common Lisp, because there are more of these things written in Common Lisp than in emacs lisp (which indeed, sounds restricted to, well, emacs). Unfortunately, this is not the direction taken by emacs' authors; but there are emacsen written in Common Lisp (eg. Porable Hemlock and Climacs, amongsts several others). And don't be affraid of stacking VM over VM, we've got hundreds of core nowadays in GPU, tomorrow in CPU! :-) -- __Pascal Bourguignon__ http://www.informatimago.com ^ permalink raw reply [flat|nested] 32+ messages in thread
[parent not found: <0e994fe3-6dde-449f-879d-6701c7a195a9@e28g2000vbd.googlegroups.com>]
* Re: About Emacs Modernisation Project [not found] ` <0e994fe3-6dde-449f-879d-6701c7a195a9@e28g2000vbd.googlegroups.com> @ 2010-05-31 19:41 ` Alessandro Piras [not found] ` <c41c63c0-b934-442d-8385-1abff6ab9b0b@s41g2000vba.googlegroups.com> ` (2 more replies) 0 siblings, 3 replies; 32+ messages in thread From: Alessandro Piras @ 2010-05-31 19:41 UTC (permalink / raw To: help-gnu-emacs LanX <lanx.perl@googlemail.com> writes: > Hi > > I doubt that Python would be a good choice, Perl for instance has much > more in common with LISP. > > And I doubt that eLISP is the reason why many people have problems > with emacs, it's more that many "modern" GUI mechanisms and > terminologies are not default in emacs, which frustrates newbies. > > > IMHO an alternative (but compatible ) eLISP-dialect simply allowing to > swap parens and functionnames and to write "message(...)" instead of > "(message...)" would increase the acceptance immidiately. Sounds Like M-expressions. It has been tried in the past in the Lisp world, without much success. Most programmers realize after few time the sweetness of S-expressions and macros. I think it would just lead to a small amount of M-expressions code that would be soon refactored as S-expressions.. Not worth the effort I suspect. > > (just think of how the different syntaxes of VBScript and JScript run > on the same engine) > > But the biggest issue are the data structures, most "modern" script > languages have extensive support for _dynamic_ "hashes" and "arrays", > but not for "linked lists" which is the main structure in elisp. > > No real idea how this could be solved... > > cheers > Rolf > > PS: forgot to mention this Slasheritis in regexes, IIRC Xemacs has > already rawstrings while GnuEmacs users are forced to escape every > regex symbol at least twice... __ Alessandro ^ permalink raw reply [flat|nested] 32+ messages in thread
[parent not found: <c41c63c0-b934-442d-8385-1abff6ab9b0b@s41g2000vba.googlegroups.com>]
* Re: About Emacs Modernisation Project [not found] ` <c41c63c0-b934-442d-8385-1abff6ab9b0b@s41g2000vba.googlegroups.com> @ 2010-06-01 0:40 ` Alessandro Piras 0 siblings, 0 replies; 32+ messages in thread From: Alessandro Piras @ 2010-06-01 0:40 UTC (permalink / raw To: help-gnu-emacs LanX <lanx.perl@googlemail.com> writes: >> Sounds Like M-expressions. It has been tried in the past in the Lisp world, >> without much success. > > I took a look at http://en.wikipedia.org/wiki/M-expression and it's > not quite what I was thinking of. > > I don't wanna _replace_ elisp with new semantics. Instead of this I'm > thinking about trying to have automatically translated second ALGOL > stile syntactic representation of the same code. New semantics? I don't see any new semantics in M-expressions, but maybe it's me. From the examples listed: (car lst) => car[lst] (car (append lst1 lst2)) => car[append[lst1; lst2]] Say you want to drop the ";" for argument separation (it's syntactic sugar after all), and say you want to use parens instead of brackets: car(append(lst1 lst2)) > > So it should be possible to easily switch between these two > representations. > > But thats only an idea, I'm not sure if it's really feasible. Switching can be maybe easy, but you lose quite some power: as Pascal said in the other post, code won't be data anymore, and it's not only a matter of evaluating code at runtime. __ Alessandro ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: About Emacs Modernisation Project 2010-05-31 19:41 ` Alessandro Piras [not found] ` <c41c63c0-b934-442d-8385-1abff6ab9b0b@s41g2000vba.googlegroups.com> @ 2010-06-02 6:07 ` Xah Lee [not found] ` <87iq63wsvt.fsf@kuiper.lan.informatimago.com> 2 siblings, 0 replies; 32+ messages in thread From: Xah Lee @ 2010-06-02 6:07 UTC (permalink / raw To: help-gnu-emacs On May 31, 12:41 pm, Alessandro Piras <lay...@gmail.com> wrote: > > IMHO an alternative (but compatible ) eLISP-dialect simply allowing to > > swap parens and functionnames and to write "message(...)" instead of > > "(message...)" would increase the acceptance immidiately. > > Sounds Like M-expressions. It has been tried in the past in the Lisp world, > without much success. Most programmers realize after few time the > sweetness of S-expressions and macros. I think it would just lead to a > small amount of M-expressions code that would be soon refactored as > S-expressions.. Not worth the effort I suspect. there are lisp languages with full M-expression and successful one at that. See the following articles for much detail and examples. • The Concepts and Confusions of Prefix, Infix, Postfix and Fully Nested Notations http://xahlee.org/UnixResource_dir/writ/notations.html • Fundamental Problems of Lisp http://xahlee.org/UnixResource_dir/writ/lisp_problems.html Xah ∑ http://xahlee.org/ ☄ ^ permalink raw reply [flat|nested] 32+ messages in thread
[parent not found: <87iq63wsvt.fsf@kuiper.lan.informatimago.com>]
* Re: About Emacs Modernisation Project [not found] ` <87iq63wsvt.fsf@kuiper.lan.informatimago.com> @ 2010-06-01 0:06 ` LanX 2010-06-01 8:44 ` Pascal J. Bourguignon 2010-06-02 6:17 ` Xah Lee 1 sibling, 1 reply; 32+ messages in thread From: LanX @ 2010-06-01 0:06 UTC (permalink / raw To: help-gnu-emacs > This feature is called "homoiconicity". I understand your point, but IMHO for most code users write, they don't need to eval code at runtime (which all script languages I know can do BTW) I have not doubt that it is a castration of LISP's possibilities to allow users to write function( [1,2,3], {k=>v}) which is then translated to (function '(1 2 3) (k . v) ) before compilation. IMHO this plus some flow control already covers everything most users ever want. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: About Emacs Modernisation Project 2010-06-01 0:06 ` LanX @ 2010-06-01 8:44 ` Pascal J. Bourguignon 2010-06-01 11:19 ` LanX 0 siblings, 1 reply; 32+ messages in thread From: Pascal J. Bourguignon @ 2010-06-01 8:44 UTC (permalink / raw To: help-gnu-emacs LanX <lanx.perl@googlemail.com> writes: >> This feature is called "homoiconicity". > > I understand your point, but IMHO for most code users write, they > don't need to eval code at runtime (which all script languages I know > can do BTW) > > I have not doubt that it is a castration of LISP's possibilities to > allow users to write > > function( [1,2,3], {k=>v}) > > which is then translated to > > (function '(1 2 3) (k . v) ) > > before compilation. > > IMHO this plus some flow control already covers everything most users > ever want. Do you realize that lisp is actually a very small core language? (eval fits on a single page). All the rest, the lisp programming language you _use_ is not this core lisp, it's only _MACROS_! And for them it is essential to have homoiconicity. Even if you don't write macros yourself you are constantly using them. Since (k . v) is not a form, what you call 'function' above MUST be a macro! -- __Pascal Bourguignon__ http://www.informatimago.com/ ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: About Emacs Modernisation Project 2010-06-01 8:44 ` Pascal J. Bourguignon @ 2010-06-01 11:19 ` LanX 2010-06-01 12:56 ` Pascal J. Bourguignon 0 siblings, 1 reply; 32+ messages in thread From: LanX @ 2010-06-01 11:19 UTC (permalink / raw To: help-gnu-emacs Hi > Do you realize that lisp is actually a very small core language? > (eval fits on a single page). I think that I made quite clear that I want this c/js/perl-style representation (lets call it PSILe) to be transformed to eLISP _before_ compilation. Macros will still work on the plain eLISP representation. (of course defining macros for PLISe wouldn't be easy feasible, but normal users won't miss macros...) The tricky part would be to find a representation that works without ambiguities in both directions, such that old lisp code could be used as a base for this "new" coding. I don't know if it's really feasible but it's for sure an interesting task. PLISe <-> eLISP -> Macro expansion -> compilation -> execution ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: About Emacs Modernisation Project 2010-06-01 11:19 ` LanX @ 2010-06-01 12:56 ` Pascal J. Bourguignon 0 siblings, 0 replies; 32+ messages in thread From: Pascal J. Bourguignon @ 2010-06-01 12:56 UTC (permalink / raw To: help-gnu-emacs LanX <lanx.perl@googlemail.com> writes: > Hi > >> Do you realize that lisp is actually a very small core language? >> (eval fits on a single page). > > I think that I made quite clear that I want this c/js/perl-style > representation (lets call it PSILe) to be transformed to eLISP > _before_ compilation. > > Macros will still work on the plain eLISP representation. > > (of course defining macros for PLISe wouldn't be easy feasible, but > normal users won't miss macros...) > > The tricky part would be to find a representation that works without > ambiguities in both directions, such that old lisp code could be used > as a base for this "new" coding. > > I don't know if it's really feasible but it's for sure an interesting > task. > > PLISe <-> eLISP -> Macro expansion -> compilation -> execution It is effectively entirely feasible. See for example parenscript (and jwacs) in CL. http://common-lisp.net/project/parenscript/ (or Liskell for another example, but there are a lot of them). Parenscript is a set of functions and macros that allows you to write javascript code as lisp sexps. The point of course is to allow lispers (emacs users) to be able to write barbaric languages (languages with barbaric syntaxes), on one hand, and to be able to define macros for these barbaric languages on the other hand (the macros written in lisp would transform parenscript forms into parenscript forms, before being translated to Javascript). (jwacs does the reverse transformation, parsing Javascript and producing lisp objects; I used it once to revert to the parenscript form so that I could go between both syntaxes). This covers the first <-> arrow. Now to compile parenscript to Common Lisp, you would still need to implement a run-time library of javascript semantics in lisp (eg. the object system is quite different, the data types, etc). In general, the core languages are easy to translate to Lisp, since they're often much less sophisticated than Lisp. -- __Pascal Bourguignon__ http://www.informatimago.com ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: About Emacs Modernisation Project [not found] ` <87iq63wsvt.fsf@kuiper.lan.informatimago.com> 2010-06-01 0:06 ` LanX @ 2010-06-02 6:17 ` Xah Lee 1 sibling, 0 replies; 32+ messages in thread From: Xah Lee @ 2010-06-02 6:17 UTC (permalink / raw To: help-gnu-emacs On May 31, 4:31 pm, p...@informatimago.com (Pascal J. Bourguignon) wrote: > Alessandro Piras <lay...@gmail.com> writes: > > LanX <lanx.p...@googlemail.com> writes: > > >> Hi > > >> I doubt that Python would be a good choice, Perl for instance has much > >> more in common with LISP. > > >> And I doubt that eLISP is the reason why many people have problems > >> with emacs, it's more that many "modern" GUI mechanisms and > >> terminologies are not default in emacs, which frustrates newbies. > > >> IMHO an alternative (but compatible ) eLISP-dialect simply allowing to > >> swap parens and functionnames and to write "message(...)" instead of > >> "(message...)" would increase the acceptance immidiately. > > > Sounds Like M-expressions. It has been tried in the past in the Lisp world, > > without much success. Most programmers realize after few time the > > sweetness of S-expressions and macros. I think it would just lead to a > > small amount of M-expressions code that would be soon refactored as > > S-expressions.. Not worth the effort I suspect. > > This is important to understand. > > Asking to write function(argument) in lisp, is like asking to write: > > int a[]=1{2,3,4}; > > in C. > > Yes, 1{2,3,4} instead of {1,2,3,4} is totally silly in C. Why would > you want to put the first element of a list of values outside of the > list? > > It just happen that code is data and there is no more any point in > putting the first element of a function application outside of the > list. > > f(a,b,c) goes in most languages, because they make an artificial > distinction between code and data, and the implication of this is that > they need big parsers, and cannot mix compilation time with run time. > > But in lisp, since we write (f a b c) like we write (1 2 3 4), the > parser becomes trivial, and the code can be processed as easily as any > other data, therefore we can write macros (which are compiler hooks) > and use the compiler at run-time. > > This feature is called "homoiconicity". The above opinion is biased and basically bullshit. The throwing in of the jargon homoiconicity is just to a sales pitch. if you read Wikipedia: http://en.wikipedia.org/wiki/Homoiconicity you see this paragraph: --------------- Languages which are considered to be homoiconic include members of the Lisp family, Nemerle, Curl, REBOL, SNOBOL, XSLT, XQuery, TRAC, Tcl, Io, Ioke, Joy, Factor, Pico, PostScript, Prolog, R, Mathematica, V and Clojure.[citation needed] In Von Neumann architecture systems (including the vast majority of general purpose computers today), raw machine code also has this property, the data type being bytes in memory. ---------------- So, this “homoiconicity” has little to do with lisp's syntax or whatever it is supposed to be relevant. also, note that XML also has lisp's advantage of regular syntax, and there are computing langs based on xml syntax today. Note that lisp syntax is not strictly regular. For a more regular syntax, there's XML and Mathematica. also, the oft quoted concept of “code is data” is seldom ever defined. When asked a lisp, each has different take. Basically, it means nothing more than a strictly uniform and regular syntax, which lisp's isn't the better example among languages. another thing lisp lovers inevitable love to cite is macros. Note that, a whole class of languages that are based on pattern matching, is a order of magnitude more powerful than classic lisps. For detail, see: • Fundamental Problems of Lisp http://xahlee.org/UnixResource_dir/writ/lisp_problems.html Xah ∑ http://xahlee.org/ ☄ ^ permalink raw reply [flat|nested] 32+ messages in thread
[parent not found: <87ljazofkn.fsf@rapttech.com.au>]
* Re: About Emacs Modernisation Project [not found] ` <87ljazofkn.fsf@rapttech.com.au> @ 2010-05-31 23:33 ` LanX 2010-06-01 10:28 ` Helmut Eller ` (2 more replies) 0 siblings, 3 replies; 32+ messages in thread From: LanX @ 2010-05-31 23:33 UTC (permalink / raw To: help-gnu-emacs > My personal feeling is that changing to something else will never happen > and is the wrong direction to go anyway. I really enjoyed reading this blog on ejacs http://steve-yegge.blogspot.com/2008/11/ejacs-javascript-interpreter-for-emacs.html It highlights the problems in elisp when trying to realize contemporaneous programming patterns. No name spaces, no real lexical variables, slow properties, and so on. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: About Emacs Modernisation Project 2010-05-31 23:33 ` LanX @ 2010-06-01 10:28 ` Helmut Eller 2010-06-01 11:27 ` LanX 2010-06-02 17:05 ` Xah Lee [not found] ` <87r5krh3e0.fsf@unm.edu> 2010-06-04 18:33 ` Joseph Brenner 2 siblings, 2 replies; 32+ messages in thread From: Helmut Eller @ 2010-06-01 10:28 UTC (permalink / raw To: help-gnu-emacs * LanX [2010-06-01 01:33+0200] writes: >> My personal feeling is that changing to something else will never happen >> and is the wrong direction to go anyway. > > I really enjoyed reading this blog on ejacs > > http://steve-yegge.blogspot.com/2008/11/ejacs-javascript-interpreter-for-emacs.html > > It highlights the problems in elisp when trying to realize > contemporaneous programming patterns. > > No name spaces, no real lexical variables, slow properties, and so > on. Why didn't he write the Javascript interpreter in Javascript? Or why did he write a Javascript interpreter at all? The only interesting place to run and debug Javascript is inside a browser with complete DOM access anyway. Helmut ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: About Emacs Modernisation Project 2010-06-01 10:28 ` Helmut Eller @ 2010-06-01 11:27 ` LanX 2010-06-01 12:29 ` Helmut Eller 2010-06-02 17:05 ` Xah Lee 1 sibling, 1 reply; 32+ messages in thread From: LanX @ 2010-06-01 11:27 UTC (permalink / raw To: help-gnu-emacs Hi > Why didn't he write the Javascript interpreter in Javascript? Or why > did he write a Javascript interpreter at all? The only interesting > place to run and debug Javascript is inside a browser with complete DOM > access anyway. No _CORE_ JS is a very lean and extendible language (not by macros but by prototype OO) which is embedded in many products not just browsers. Maybe the most embedded language today ... (PDF-reader, Flash-player,...) DOM and BOM (Browser OM) are just a local native library, the EOM (Emacs Object Model) would be represented in emacs by the core functions and variables, e.g. for manipulating buffers or faces. Many of these EOM features are already realized in C and not eLISP (like they are in Browsers) ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: About Emacs Modernisation Project 2010-06-01 11:27 ` LanX @ 2010-06-01 12:29 ` Helmut Eller 2010-06-01 12:55 ` LanX 2010-06-01 12:59 ` Pascal J. Bourguignon 0 siblings, 2 replies; 32+ messages in thread From: Helmut Eller @ 2010-06-01 12:29 UTC (permalink / raw To: help-gnu-emacs * LanX [2010-06-01 13:27+0200] writes: > Hi > >> Why didn't he write the Javascript interpreter in Javascript? Or why >> did he write a Javascript interpreter at all? The only interesting >> place to run and debug Javascript is inside a browser with complete DOM >> access anyway. > > No _CORE_ JS is a very lean and extendible language (not by macros but > by prototype OO) which is embedded in many products not just browsers. > Maybe the most embedded language today ... > (PDF-reader, Flash-player,...) > > DOM and BOM (Browser OM) are just a local native library, the EOM > (Emacs Object Model) would be represented in emacs by the core > functions and variables, e.g. for manipulating buffers or faces. > > Many of these EOM features are already realized in C and not eLISP > (like they are in Browsers) Just what I said: the interesting thing about JS is not the language but the DOM. I still fail to see why calling Emacs' C functions from a JS interpreter (written in Elisp) would be interesting. Helmut ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: About Emacs Modernisation Project 2010-06-01 12:29 ` Helmut Eller @ 2010-06-01 12:55 ` LanX 2010-06-01 12:59 ` Pascal J. Bourguignon 2010-06-01 12:59 ` Pascal J. Bourguignon 1 sibling, 1 reply; 32+ messages in thread From: LanX @ 2010-06-01 12:55 UTC (permalink / raw To: help-gnu-emacs > Just what I said: the interesting thing about JS is not the language but > the DOM. I still fail to see why calling Emacs' C functions from a JS > interpreter (written in Elisp) would be interesting. Much broader acceptance, nowadays JS is a lingua franca most programmers can at least read if not code. But I'm neither too fond about slowly emulating JS in elisp. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: About Emacs Modernisation Project 2010-06-01 12:55 ` LanX @ 2010-06-01 12:59 ` Pascal J. Bourguignon 0 siblings, 0 replies; 32+ messages in thread From: Pascal J. Bourguignon @ 2010-06-01 12:59 UTC (permalink / raw To: help-gnu-emacs LanX <lanx.perl@googlemail.com> writes: >> Just what I said: the interesting thing about JS is not the language but >> the DOM. I still fail to see why calling Emacs' C functions from a JS >> interpreter (written in Elisp) would be interesting. > > Much broader acceptance, nowadays JS is a lingua franca most > programmers can at least read if not code. > > But I'm neither too fond about slowly emulating JS in elisp. This is no problem since you can always add a compiler. -- __Pascal Bourguignon__ http://www.informatimago.com ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: About Emacs Modernisation Project 2010-06-01 12:29 ` Helmut Eller 2010-06-01 12:55 ` LanX @ 2010-06-01 12:59 ` Pascal J. Bourguignon 1 sibling, 0 replies; 32+ messages in thread From: Pascal J. Bourguignon @ 2010-06-01 12:59 UTC (permalink / raw To: help-gnu-emacs Helmut Eller <eller.helmut@gmail.com> writes: > * LanX [2010-06-01 13:27+0200] writes: > >> Hi >> >>> Why didn't he write the Javascript interpreter in Javascript? Or why >>> did he write a Javascript interpreter at all? The only interesting >>> place to run and debug Javascript is inside a browser with complete DOM >>> access anyway. >> >> No _CORE_ JS is a very lean and extendible language (not by macros but >> by prototype OO) which is embedded in many products not just browsers. >> Maybe the most embedded language today ... >> (PDF-reader, Flash-player,...) >> >> DOM and BOM (Browser OM) are just a local native library, the EOM >> (Emacs Object Model) would be represented in emacs by the core >> functions and variables, e.g. for manipulating buffers or faces. >> >> Many of these EOM features are already realized in C and not eLISP >> (like they are in Browsers) > > Just what I said: the interesting thing about JS is not the language but > the DOM. I still fail to see why calling Emacs' C functions from a JS > interpreter (written in Elisp) would be interesting. "User interface". Some users speak Javascript. Some others speak Python, etc. I agree that it's unfortunate that not everybody is taught Lisp in preschool, (like they should be taught Esperanto), but that's how it is... -- __Pascal Bourguignon__ http://www.informatimago.com ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: About Emacs Modernisation Project 2010-06-01 10:28 ` Helmut Eller 2010-06-01 11:27 ` LanX @ 2010-06-02 17:05 ` Xah Lee 2010-06-02 17:50 ` Helmut Eller 1 sibling, 1 reply; 32+ messages in thread From: Xah Lee @ 2010-06-02 17:05 UTC (permalink / raw To: help-gnu-emacs LanX [2010-06-01 01:33+0200] writes: « I really enjoyed reading this blog on ejacs http://steve-yegge.blogspot.com/2008/11/ejacs-javascript-interpreter-for-emacs.html » On Jun 1, 3:28 am, Helmut Eller <eller.hel...@gmail.com> wrote: «Why didn't he write the Javascript interpreter in Javascript? Or why did he write a Javascript interpreter at all?» Gah. Apparently you haven't spend much time reading the article. Steve created it because he's creating a javascript mode for emacs, with the goal of it being a full IDE beating any other javascript IDEs. That mode eventually became js2-mode. The js interpreter engine was a discarded by-product, because he ends up writing another engine. The name “ejacs” was attached to it later, and became a separate project, currently of little practical use. Steve has hinted in his blog, that he has the goal of making js a alternative to elisp for extending emacs. > The only interesting > place to run and debug Javascript is inside a browser with complete DOM > access anyway. yes but not really. JS as a scripting lang is used in lots of applications, in Flash, and lots others. (see wikipedia for full list) Basically, it has became practically what Scheme used to be or envisioned to be in academia, and replaced what perl, tcl, tried to be in the industry in the 1990s. Personally i think that's very good. See: • Proliferation of Computing Languages http://xahlee.org/UnixResource_dir/writ/new_langs.html Xah ∑ http://xahlee.org/ ☄ ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: About Emacs Modernisation Project 2010-06-02 17:05 ` Xah Lee @ 2010-06-02 17:50 ` Helmut Eller 0 siblings, 0 replies; 32+ messages in thread From: Helmut Eller @ 2010-06-02 17:50 UTC (permalink / raw To: help-gnu-emacs * Xah Lee [2010-06-02 19:05+0200] writes: > LanX [2010-06-01 01:33+0200] writes: > « > I really enjoyed reading this blog on ejacs > http://steve-yegge.blogspot.com/2008/11/ejacs-javascript-interpreter-for-emacs.html > » > > On Jun 1, 3:28 am, Helmut Eller <eller.hel...@gmail.com> wrote: > «Why didn't he write the Javascript interpreter in Javascript? Or why > did he write a Javascript interpreter at all?» > > Gah. Apparently you haven't spend much time reading the article. > > Steve created it because he's creating a javascript mode for emacs, > with the goal of it being a full IDE beating any other javascript > IDEs. > > That mode eventually became js2-mode. The js interpreter engine was a > discarded by-product, because he ends up writing another engine. The > name “ejacs” was attached to it later, and became a separate project, > currently of little practical use. So it turned out that writing a JS interpreter that runs inside Emacs is totally useless. I could have told him that before. Helmut ^ permalink raw reply [flat|nested] 32+ messages in thread
[parent not found: <87r5krh3e0.fsf@unm.edu>]
* Re: About Emacs Modernisation Project [not found] ` <87r5krh3e0.fsf@unm.edu> @ 2010-06-01 8:40 ` Pascal J. Bourguignon 2010-06-01 17:34 ` rustom 2010-06-01 19:50 ` Stefan Monnier 1 sibling, 1 reply; 32+ messages in thread From: Pascal J. Bourguignon @ 2010-06-01 8:40 UTC (permalink / raw To: help-gnu-emacs Evans Winner <thorne@unm.edu> writes: > LanX <lanx.perl@googlemail.com> writes: > > No name spaces, no real lexical variables [...] > > These are not bugs, they are features. One uses the right > tool for the job. It is highly unlikely that the language > of choice for serious hackers working on developing large, > complex systems is going to be the same language chosen for > casual text editor users who want to quickly and simply > customize some element of their editor. Possibly. However, if emacs was reprogrammed in Common Lisp, you could have both. Naive users could be provided with an environment with only dynamic binding and a unique namespace, while sophisticated programmers could use all the features of Common Lisp. Also, as mentionned in another post, it would be easier to implement other user-friend scripting languages in Common Lisp than in emacs lisp. > If I had to put up > with thinking about bugs from counter-intuitive effects of > lexical bindings, or package problems when writing code to > do every simple thing I want Emacs to do, I'd just forget > the whole stupid thing and go back to notepad.exe -- or more > precisely, a non-programmer like me would never have even > gotten a start with it. I've written some reasonably useful > code -- at least for my own purposes, and as a result of my > work with Emacs I have even learned a bit of Common Lisp, > but I don't think that I am alone in that for me Emacs Lisp > is just the exactly right language. It is simple and > intuitive while retaining a good deal of the expressiveness > of a Lisp. Just write one emacs lisp program slightly more complex, and you'll see that you'd rather program text processing scripts in Common Lisp. > If what you want to implement requires industrial-strength > language features, why do you want to implement it in a text > editor? No, that's the other way. Why isn't this text editor implemented in an industrial-strength language. History, of course. But it should be time to correct history errors. Otherwise have a look at Climacs. > -- I mean, I know there are borderline cases, like > gnus, which I use and which is a pretty large and complex > system, but for most purposes, I think Emacs Lisp actually > encourages the production of a lot of little, useful hacks. Unmaintainable hacks. That's the problem for me with emacs lisp code, it's often unmaintable, overly complex, and badly programmed. > Using a language like Python or Guile scheme doesn't strike me as > being as likely to encourage that kind of thing. > > P.S. Climacs, which Pascal mentioned, is useless to me > anyway, because it won't work in a TTY. I can't imagine > never wanting to just shell into a system and go, without > having to tunnel X and all that rot. Yes, I'd like it to work on a terminal too. Clearly, we need more time! -- __Pascal Bourguignon__ http://www.informatimago.com/ ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: About Emacs Modernisation Project 2010-06-01 8:40 ` Pascal J. Bourguignon @ 2010-06-01 17:34 ` rustom 2010-06-02 12:47 ` B. T. Raven 0 siblings, 1 reply; 32+ messages in thread From: rustom @ 2010-06-01 17:34 UTC (permalink / raw To: help-gnu-emacs On Jun 1, 1:40 pm, p...@informatimago.com (Pascal J. Bourguignon) wrote: > Evans Winner <tho...@unm.edu> writes: > > LanX <lanx.p...@googlemail.com> writes: > > > No name spaces, no real lexical variables [...] > > > These are not bugs, they are features. One uses the right > > tool for the job. It is highly unlikely that the language > > of choice for serious hackers working on developing large, > > complex systems is going to be the same language chosen for > > casual text editor users who want to quickly and simply > > customize some element of their editor. > > Possibly. However, if emacs was reprogrammed in Common Lisp, you > could have both. Naive users could be provided with an environment > with only dynamic binding and a unique namespace, while sophisticated > programmers could use all the features of Common Lisp. Also, as > mentionned in another post, it would be easier to implement other > user-friend scripting languages in Common Lisp than in emacs lisp. > I remember seeing a paper (by a German I think) in which he claimed that he could *fully automatically* translate elisp to scheme. Does anyone remember this? [My google foo is not up-to-the-mark...] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: About Emacs Modernisation Project 2010-06-01 17:34 ` rustom @ 2010-06-02 12:47 ` B. T. Raven 2010-06-02 17:20 ` rustom 0 siblings, 1 reply; 32+ messages in thread From: B. T. Raven @ 2010-06-02 12:47 UTC (permalink / raw To: help-gnu-emacs rustom wrote: > On Jun 1, 1:40 pm, p...@informatimago.com (Pascal J. Bourguignon) > wrote: >> Evans Winner <tho...@unm.edu> writes: >>> LanX <lanx.p...@googlemail.com> writes: >>> No name spaces, no real lexical variables [...] >>> These are not bugs, they are features. One uses the right >>> tool for the job. It is highly unlikely that the language >>> of choice for serious hackers working on developing large, >>> complex systems is going to be the same language chosen for >>> casual text editor users who want to quickly and simply >>> customize some element of their editor. >> Possibly. However, if emacs was reprogrammed in Common Lisp, you >> could have both. Naive users could be provided with an environment >> with only dynamic binding and a unique namespace, while sophisticated >> programmers could use all the features of Common Lisp. Also, as >> mentionned in another post, it would be easier to implement other >> user-friend scripting languages in Common Lisp than in emacs lisp. >> > > I remember seeing a paper (by a German I think) in which he claimed > that he could *fully automatically* translate elisp to scheme. Does > anyone remember this? [My google foo is not up-to-the-mark...] It might have been this (out of Freiburg and Tuebingen, 2001): http://www-pu.informatik.uni-tuebingen.de/users/sperber/papers/dynamic-scope-analysis.pdf Anyway, there is menttion of the el2scm project. Ed ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: About Emacs Modernisation Project 2010-06-02 12:47 ` B. T. Raven @ 2010-06-02 17:20 ` rustom 0 siblings, 0 replies; 32+ messages in thread From: rustom @ 2010-06-02 17:20 UTC (permalink / raw To: help-gnu-emacs On Jun 2, 5:47 pm, "B. T. Raven" <ni...@nihilo.net> wrote: > rustom wrote: > > On Jun 1, 1:40 pm, p...@informatimago.com (Pascal J. Bourguignon) > > wrote: > >> Evans Winner <tho...@unm.edu> writes: > >>> LanX <lanx.p...@googlemail.com> writes: > >>> No name spaces, no real lexical variables [...] > >>> These are not bugs, they are features. One uses the right > >>> tool for the job. It is highly unlikely that the language > >>> of choice for serious hackers working on developing large, > >>> complex systems is going to be the same language chosen for > >>> casual text editor users who want to quickly and simply > >>> customize some element of their editor. > >> Possibly. However, if emacs was reprogrammed in Common Lisp, you > >> could have both. Naive users could be provided with an environment > >> with only dynamic binding and a unique namespace, while sophisticated > >> programmers could use all the features of Common Lisp. Also, as > >> mentionned in another post, it would be easier to implement other > >> user-friend scripting languages in Common Lisp than in emacs lisp. > > > I remember seeing a paper (by a German I think) in which he claimed > > that he could *fully automatically* translate elisp to scheme. Does > > anyone remember this? [My google foo is not up-to-the-mark...] > > It might have been this (out of Freiburg and Tuebingen, 2001): > > http://www-pu.informatik.uni-tuebingen.de/users/sperber/papers/dynami... Yeah this may be it but now when I see it it says it cant handle eval. The last time I saw it it said it could handle eval (at least thats what I remember) because I remember finding it incredible [Without trying to prove it, translating eval correctly would amount to solving the halting problem. For those unfamiliar with CS technicalities this is as anomalous as making say a perpetual motion machine] > > Anyway, there is menttion of the el2scm project. > > Ed ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: About Emacs Modernisation Project [not found] ` <87r5krh3e0.fsf@unm.edu> 2010-06-01 8:40 ` Pascal J. Bourguignon @ 2010-06-01 19:50 ` Stefan Monnier 2010-06-01 23:22 ` LanX [not found] ` <87mxvegz12.fsf@unm.edu> 1 sibling, 2 replies; 32+ messages in thread From: Stefan Monnier @ 2010-06-01 19:50 UTC (permalink / raw To: help-gnu-emacs > No name spaces, no real lexical variables [...] > These are not bugs, they are features. No, they're not. Elisp is slow and unsuited to "large" programs (which do exist in Emacs, despite this barrier), and that is a problem. But it has a lot of legacy which is a large part of its popularity and longevity. If you want an Emacs that's not "hindered" by such legacy, there are plenty, but then you don't enjoy the benefits of having such a large legacy. You can't have your cake and eat it too. > editor? -- I mean, I know there are borderline cases, like > gnus, which I use and which is a pretty large and complex > system, but for most purposes, I think Emacs Lisp actually > encourages the production of a lot of little, useful hacks. Indeed. But lexical scoping and name spaces wouldn't make any difference in this respect. Stefan ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: About Emacs Modernisation Project 2010-06-01 19:50 ` Stefan Monnier @ 2010-06-01 23:22 ` LanX [not found] ` <slrni0b8nm.9k6.bergv@u00.math.uiuc.edu> [not found] ` <e73e123d-3f0c-4a6f-bbac-b91fb71bf07d@f14g2000vbn.googlegroups.com> [not found] ` <87mxvegz12.fsf@unm.edu> 1 sibling, 2 replies; 32+ messages in thread From: LanX @ 2010-06-01 23:22 UTC (permalink / raw To: help-gnu-emacs > > I think Emacs Lisp actually > > encourages the production of a lot of little, useful hacks. > > Indeed. But lexical scoping and name spaces wouldn't make any > difference in this respect. But the lack of namespaces leads to very long names which IMHO irritate newbies. At least it did irritate me at the time to find out that I need to type "M-x font-lock-fontify-buffer" to get highlighting, and it still irritates others when I explain to do so. Snippets manipulating different aspects of font-lock would look less intimidating, without the need to repeat "font-lock-" 20 times. And something like customize-group NAME-SPACE wouldn't need to list the prefix NAME-SPACE-... for each option. IMHO the option to use shorter identifiers for functions and variables would increase the acceptance of elisp and emacs! You might think that it's only a matter of getting used to, but maybe you should better ask the folks who turned away maybe thinking that a system with >20 char identifiers is far too complicated... When manipulating the DOM of a browser with JS I have standard mechanisms to considerately shorten the path to a variable or function. Are there any in eLisp? ^ permalink raw reply [flat|nested] 32+ messages in thread
[parent not found: <slrni0b8nm.9k6.bergv@u00.math.uiuc.edu>]
* Re: About Emacs Modernisation Project [not found] ` <slrni0b8nm.9k6.bergv@u00.math.uiuc.edu> @ 2010-06-02 11:39 ` Pascal J. Bourguignon 0 siblings, 0 replies; 32+ messages in thread From: Pascal J. Bourguignon @ 2010-06-02 11:39 UTC (permalink / raw To: help-gnu-emacs Maarten Bergvelt <bergv@math.uiuc.edu> writes: > On 2010-06-01, LanX <lanx.perl@googlemail.com> wrote: >> But the lack of namespaces leads to very long names which IMHO >> irritate newbies. >> [...] >> Snippets manipulating different aspects of font-lock would look less >> intimidating, without the need to repeat "font-lock-" 20 times. > > Have you discovered the tab-key? I am an incompetent 2 finger typer, > but with emacs I am pretty fast, as I can use all kinds of automatic > completions. > > Having long identifiers makes them easier to understand, and only > slightly harder to input. I've got the impression (this of course would need experimental input), that psychologically it's better indeed to have short names. It's not a question of typing them, with or without completion; we read much more than we write, usually. If long names weren't a psychological problem there wouldn't be so many acronyms, and even most of the words in our "natural" languages are nothing but acronyms or abreviations, if you're to believe Edo Nyland's theory. http://www.linguistic-archaeology.eu/ http://www.amazon.com/Linguistic-Archaeology-Introduction-Edo-Nyland/dp/1552126684 Summary: http://www.faculty.ucr.edu/~legneref/bronze/nytheory.htm Of course, short names lead to overloading, hence the need for context. Happily, our brains work marvellously on contextual data. This is what Common Lisp packages are and define: a context for the names used in programs. -- __Pascal Bourguignon__ http://www.informatimago.com ^ permalink raw reply [flat|nested] 32+ messages in thread
[parent not found: <e73e123d-3f0c-4a6f-bbac-b91fb71bf07d@f14g2000vbn.googlegroups.com>]
* Re: Emulating namespaces [not found] ` <e73e123d-3f0c-4a6f-bbac-b91fb71bf07d@f14g2000vbn.googlegroups.com> @ 2010-06-03 9:26 ` Pascal J. Bourguignon 2010-06-03 15:33 ` LanX 0 siblings, 1 reply; 32+ messages in thread From: Pascal J. Bourguignon @ 2010-06-03 9:26 UTC (permalink / raw To: help-gnu-emacs LanX <lanx.perl@googlemail.com> writes: > I was meditating about how namespaces are realized in perl and now I'm > wondering if this behaviour could be mimicked in elisp. Actually, emacs has already the primitive mechanism needed to implement packages. This can AFAIK be done entirely in emacs lisp. If only it had reader macros, we could provide the pack::sym and pack:sym syntax too (and correct the :keyword syntax). Emacs lisp stores symbols in obarrays. The variable obarray is used by intern, mapatom, etc. So, basically: (defvar *package-name-map* (make-hash-table :test (function equal))) (defvar *list-all-packages* '()) (defun list-all-packages () (copy-list *list-all-packages*)) (defstruct (package (:constructor %make-package)) name nicknames use-list used-by-list shadowing-symbols %obarray) (defun* make-package (name &key nicknames uses size) (assert (notany (function find-package) (cons name nicknames)) (name nicknames) "There is already a package with the same name or nickname") (let ((p (%make-package :name name :nicknames nicknames :use-list (or uses (find-package "EMACS-LISP")) :%obarray (make-vector size nil)))) (push p *list-all-packages*) (dolist (name (cons name nicknames)) (setf (gethash name *package-name-map*) p)) (internalize-used-symbols p) p)) ;; bootstrap the emacs-lisp package: (defvar *package* (let ((p (%make-package :name "EMACS-LISP" :nicknames '("ELISP") :use-list '() :%obarray obarray))) (push p *list-all-packages*) (dolist (name '("EMACS-LISP" "ELISP")) (setf (gethash name *package-name-map*) p)) p)) (defmacro in-package (package-designator) `(progn (setf *package* (find-package ,package-designator)) (setf obarray (package-%obarray *package*)) *package*)) So, if you take care to always :use "EMACS-LISP" to always have access to in-package, you can skip from one obarray to another for further reading, because without modifying the reader, you cannot use (elisp:in-package :elisp) to come back. You will need wrappers to map packages to obarray for function such as intern. Also, we could just use emacs-cl... -- __Pascal Bourguignon__ http://www.informatimago.com/ ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Emulating namespaces 2010-06-03 9:26 ` Emulating namespaces Pascal J. Bourguignon @ 2010-06-03 15:33 ` LanX 2010-06-03 17:41 ` Pascal J. Bourguignon 0 siblings, 1 reply; 32+ messages in thread From: LanX @ 2010-06-03 15:33 UTC (permalink / raw To: help-gnu-emacs do I get it right switching the package means that will bind variables in the following code to different symbol tables? > Also, we could just use emacs-cl... ehm do you wanna tell me that (require 'cl) already provides support for namespaces? So why bother? Could you plz show me some code that reflects the behavior of the perl snippet I posted? --------------- { package Namespace; our $var=666; sub tst {print $var } } package Outerspace; $var=42; Namespace::tst(); # prints 666 --------------- I'd like to run some tests... ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: Emulating namespaces 2010-06-03 15:33 ` LanX @ 2010-06-03 17:41 ` Pascal J. Bourguignon 0 siblings, 0 replies; 32+ messages in thread From: Pascal J. Bourguignon @ 2010-06-03 17:41 UTC (permalink / raw To: help-gnu-emacs LanX <lanx.perl@googlemail.com> writes: > do I get it right switching the package means that will bind variables > in the following code to different symbol tables? > >> Also, we could just use emacs-cl... > > ehm do you wanna tell me that (require 'cl) already provides support > for namespaces? No, it doesn't. emacs-cl is an implementation of Common Lisp written in emacs lisp, like ejacs is an implementation of JavaScript written in emacs lisp. > So why bother? > > Could you plz show me some code that reflects the behavior of the perl > snippet I posted? > > > --------------- > { > package Namespace; > our $var=666; > > sub tst {print $var } > > } > > package Outerspace; > > $var=42; > Namespace::tst(); # prints 666 > --------------- > > I'd like to run some tests... http://www.lisp.se/emacs-cl/ M-x load-library RET load-cl RET M-x emacs-cl RET and then in the *Emacs Common Lisp* buffer: COMMON-LISP-USER> (defpackage :namespace (:use :cl)) #<PACKAGE "NAMESPACE"> COMMON-LISP-USER> (in-package :namespace) #<PACKAGE "NAMESPACE"> NAMESPACE> (defvar *var* 888) *VAR* NAMESPACE> (defun test () (print *var*)) TEST NAMESPACE> (defpackage :outerspace (:use :cl)) #<PACKAGE "OUTERSPACE"> NAMESPACE> (in-package :outerspace) #<PACKAGE "OUTERSPACE"> OUTERSPACE> (defvar *var* 42) *VAR* OUTERSPACE> (namespace::test) 888 888 OUTERSPACE> (remove-if-not (lambda (b) (string-match ".*\.lisp" (buffer-name b))) (buffer-list)) OUTERSPACE> (list-all-packages) (#<PACKAGE "OUTERSPACE"> #<PACKAGE "NAMESPACE"> #<PACKAGE "COMMON-LISP-USER"> #<PACKAGE "COMMON-LISP"> #<PACKAGE "EMACS-COMMON-LISP-MOP"> #<PACKAGE "EMACS-COMMON-LISP"> #<PACKAGE "EMACS-LISP"> #<PACKAGE "KEYWORD">) OUTERSPACE> (remove-if-not (lambda (n) (let ((len (length n))) (when (< 3 len) (string= ".el" (subseq n (- len 3)))))) (mapcar (function emacs-lisp:|buffer-name|) (emacs-lisp:|buffer-list|))) ("cl-macs.el") OUTERSPACE> -- __Pascal Bourguignon__ http://www.informatimago.com/ ^ permalink raw reply [flat|nested] 32+ messages in thread
[parent not found: <87mxvegz12.fsf@unm.edu>]
* Re: About Emacs Modernisation Project [not found] ` <87mxvegz12.fsf@unm.edu> @ 2010-06-01 23:36 ` Pascal J. Bourguignon 2010-06-02 5:58 ` Evans Winner 0 siblings, 1 reply; 32+ messages in thread From: Pascal J. Bourguignon @ 2010-06-01 23:36 UTC (permalink / raw To: help-gnu-emacs Evans Winner <thorne@unm.edu> writes: > [...] > I say all this not because I am an expert, obviously, but > precisely the opposite. I think that it is not such a given > that Emacs ought to be re-written in Scheme or CL, and those > who want to do it may find that it's a hard sell to get some > Luddites like me using it, that's all. I mostly agree with you, (and I'm letting me being convinced that emacs lisp itself has some value for casual "programmers"), nonetheless it occured to be rather often that I had problems in my code because of collision of dynamic variable or function names. So even if we agree (and let's say we do), that we must keep and cannot do otherwise than keeping emacs lisp, for the benefit of users and existing emacs lisp code, I still think that it would be a good thing for emacs to be based on Common Lisp, and to let sophisticated programmers use CL to write emacs lisp packages. Programmers who write applications such as GNUS, or programmers who want to avoid problems such as these collisions could use Common Lisp packages. Common Lisp has compilers that produce code as efficient as C, so that indeed the whole emacs could be rewritten in CL instead of C+elisp. And this would allow the practical use of other user languages (such as JavaScript or Python) to program emacs, since they can be, and are implemented more efficiently in CL than in emacs lisp. +--------+-------------------------------+ | now | in the future ----> | +------------------------+--------+-------------------------------+ | user emacs code | elisp | elisp+CL+ejacs+clpython+... | +------------------------+--------+-------------------------------+ | emacs packages (modes) | elisp | elisp+CL+ejacs+clpython+... | +------------------------+--------+-------------------------------+ | emacs editing library | elisp | elisp ---> CL | +------------------------+--------+-------------------------------+ | emacs primitives | C | CL | +------------------------+--------+-------------------------------+ -- __Pascal Bourguignon__ http://www.informatimago.com/ ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: About Emacs Modernisation Project 2010-06-01 23:36 ` About Emacs Modernisation Project Pascal J. Bourguignon @ 2010-06-02 5:58 ` Evans Winner 0 siblings, 0 replies; 32+ messages in thread From: Evans Winner @ 2010-06-02 5:58 UTC (permalink / raw To: help-gnu-emacs pjb@informatimago.com (Pascal J. Bourguignon) writes: I mostly agree with you, (and I'm letting me being convinced that emacs lisp itself has some value for casual "programmers"), nonetheless it occured to be rather often that I had problems in my code because of collision of dynamic variable or function names. There is a great quote from Richard Stallman which you have probably read: Multics Emacs proved to be a great success -- programming new editing commands was so convenient that even the secretaries in [Greenberg's] office started learning how to use it. They used a manual someone had written which showed how to extend Emacs, but didn't say it was a programming. So the secretaries, who believed they couldn't do programming, weren't scared off. They read the manual, discovered they could do useful things and they learned to program.[1] To me this attribute seems to be the sine qua non of extension languages. If it isn't easy enough that people who either don't program for a living, or who do, but not in Lisp can pick up enough to be useful relatively quickly, then the language is not going to take off the way Emacs Lisp has. Common Lisp has compilers that produce code as efficient as C, so that indeed the whole emacs could be rewritten in CL instead of C+elisp. And this would allow the practical use of other user languages (such as JavaScript or Python) to program emacs, since they can be, and are implemented more efficiently in CL than in emacs lisp. Yes, that makes sense. Playing Devil's Advocate for a moment, though, I know Guile scheme is meant to run JavaScript and Emacs Lisp and, I think, TCL. But how much code really runs on it, and how much is written for it? And if someone wrote a major package of TCL code to run on Guile, how much support would it get from the Guile developers or community? I find myself thinking that the result is more likely just a dissipation of resources. Is it really better to have an Emacs that nominally supports ejacs and clpython and Common Lisp and TCL and Scheme and so on, but really is only serious about Common Lisp -- or an Emacs that really seriously supports one language: Emacs Lisp, which is powerful, mature, easy to write and read, and does what it is supposed to: text editing? I sympathize with the desire to have a better, stronger, lispier operating environment; perhaps a better answer is the approach that I think the Climacs developers have taken: not to put the mail reader and the chat client and so on into the text editor, but to put the editor in the Lisp, and let people write separate mail readers and such. With free, multi-threading, cross-platform Common Lisp environments this seems quite possible now. But if the goal is a large user base and all the advantages which that can give, then I still think that there will be a problem unless that environment provides something on the level of simplicity that Emacs Lisp provides; and in the case of Common Lisp, I don't think that will happen without a major cultural shift among CL hackers. Anyway, that's my sense of it. Footnotes: [1] Stallman, Richard. "My Lisp Experiences and the Development of GNU Emacs." http://www.gnu.org/gnu/rms-lisp.html ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: About Emacs Modernisation Project 2010-05-31 23:33 ` LanX 2010-06-01 10:28 ` Helmut Eller [not found] ` <87r5krh3e0.fsf@unm.edu> @ 2010-06-04 18:33 ` Joseph Brenner 2010-06-05 2:55 ` Tim X 2 siblings, 1 reply; 32+ messages in thread From: Joseph Brenner @ 2010-06-04 18:33 UTC (permalink / raw To: help-gnu-emacs LanX <lanx.perl@googlemail.com> writes: > I really enjoyed reading this blog on ejacs > > http://steve-yegge.blogspot.com/2008/11/ejacs-javascript-interpreter-for-emacs.html Thanks, I'd missed that one somehow. Steve Yegge is always... interesting. Some minor points: I get the feeling he doesn't know about the pp.el package. (I don't think he would be impressed if he did. He thinks there's something nasty about perl's Data::Dumper, too.) He doesn't understand the problem with cl.el. Using it in your own code is indeed eminently "practical", but if you expect your code to be included in the emacs core, you'll run into fears born of the lack-of-encapsulation problem he talks about. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: About Emacs Modernisation Project 2010-06-04 18:33 ` Joseph Brenner @ 2010-06-05 2:55 ` Tim X 0 siblings, 0 replies; 32+ messages in thread From: Tim X @ 2010-06-05 2:55 UTC (permalink / raw To: help-gnu-emacs Joseph Brenner <doom@kzsu.stanford.edu> writes: > LanX <lanx.perl@googlemail.com> writes: > >> I really enjoyed reading this blog on ejacs >> >> http://steve-yegge.blogspot.com/2008/11/ejacs-javascript-interpreter-for-emacs.html > > Thanks, I'd missed that one somehow. Steve Yegge is always... interesting. > > Some minor points: > > I get the feeling he doesn't know about the pp.el package. > (I don't think he would be impressed if he did. He thinks > there's something nasty about perl's Data::Dumper, too.) > > He doesn't understand the problem with cl.el. Using it in your > own code is indeed eminently "practical", but if you expect your > code to be included in the emacs core, you'll run into fears > born of the lack-of-encapsulation problem he talks about. > I have seen quite a few posts regarding the fact using 'cl will prevent you from being able to include your packages in emacs, but I'm not sure that is strictly true. I think that the actual restriction is that packages cannot be included in emacs that use 'cl at runtime. However, it seems that its OK to use them provided they are loaded at compile time and not runtime i.e. used with eval-when-compile. I just did a grep in the emacs lisp directory for (require 'cl) and got over 80 hits! It seems a number of standard emacs packages do in fact use 'cl. I didn't verify they were all only loaded at compile time and not run time. Tim P.S. this was current emacs from bzr repo -- tcross (at) rapttech dot com dot au ^ permalink raw reply [flat|nested] 32+ messages in thread
end of thread, other threads:[~2010-06-05 2:55 UTC | newest] Thread overview: 32+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <143c6d28-4423-4e43-9fc5-c0fb3340043b@c11g2000vbe.googlegroups.com> 2010-05-31 15:44 ` About Emacs Modernisation Project Pascal J. Bourguignon [not found] ` <0e994fe3-6dde-449f-879d-6701c7a195a9@e28g2000vbd.googlegroups.com> 2010-05-31 19:41 ` Alessandro Piras [not found] ` <c41c63c0-b934-442d-8385-1abff6ab9b0b@s41g2000vba.googlegroups.com> 2010-06-01 0:40 ` Alessandro Piras 2010-06-02 6:07 ` Xah Lee [not found] ` <87iq63wsvt.fsf@kuiper.lan.informatimago.com> 2010-06-01 0:06 ` LanX 2010-06-01 8:44 ` Pascal J. Bourguignon 2010-06-01 11:19 ` LanX 2010-06-01 12:56 ` Pascal J. Bourguignon 2010-06-02 6:17 ` Xah Lee [not found] ` <87ljazofkn.fsf@rapttech.com.au> 2010-05-31 23:33 ` LanX 2010-06-01 10:28 ` Helmut Eller 2010-06-01 11:27 ` LanX 2010-06-01 12:29 ` Helmut Eller 2010-06-01 12:55 ` LanX 2010-06-01 12:59 ` Pascal J. Bourguignon 2010-06-01 12:59 ` Pascal J. Bourguignon 2010-06-02 17:05 ` Xah Lee 2010-06-02 17:50 ` Helmut Eller [not found] ` <87r5krh3e0.fsf@unm.edu> 2010-06-01 8:40 ` Pascal J. Bourguignon 2010-06-01 17:34 ` rustom 2010-06-02 12:47 ` B. T. Raven 2010-06-02 17:20 ` rustom 2010-06-01 19:50 ` Stefan Monnier 2010-06-01 23:22 ` LanX [not found] ` <slrni0b8nm.9k6.bergv@u00.math.uiuc.edu> 2010-06-02 11:39 ` Pascal J. Bourguignon [not found] ` <e73e123d-3f0c-4a6f-bbac-b91fb71bf07d@f14g2000vbn.googlegroups.com> 2010-06-03 9:26 ` Emulating namespaces Pascal J. Bourguignon 2010-06-03 15:33 ` LanX 2010-06-03 17:41 ` Pascal J. Bourguignon [not found] ` <87mxvegz12.fsf@unm.edu> 2010-06-01 23:36 ` About Emacs Modernisation Project Pascal J. Bourguignon 2010-06-02 5:58 ` Evans Winner 2010-06-04 18:33 ` Joseph Brenner 2010-06-05 2:55 ` Tim X
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.