About Emacs Modernisation Project
Bernardo Barros
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? :-)
Cheers,
Bernardo
Pascal J. Bourguignon
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
LanX
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.
(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 Piras
> 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
Tim X
Emacs lisp is not what I'd consider one of my favorite lisp dialects,
but it is well suited to the task. A few things which maybe worth
considering -
* There is a difference between modernizing and
popularizing. Its important to recognize this and remember
that popularity is a transient thing and you never
become popular by trying to be popular.
* How big an issue is elisp in reality? How many users
actually write any code other htan trivial configuration
settings in elisp? Unless it is a majority, changing to
something else may be a huge cost with only minimal
benefits. Ask why the pymacs project seems still so
immature after so long.
* One of the huge benefits of elisp is that it has stayed
pretty stable for a long long time. I'm still able to run
code that is 20 years old with no or only minimal
modification. There is a hell of a lot of code out there
that does things I find important. Who is going to
re-write all of this code in another language? I would not
accept a performance downgrade as the packages I use
become second class citizens because the elisp interpreter
has been sidelined for something like python, perl, ruby,
guile etc....
* There have been other editors that have used more
mainstream style languages for extensions. None of them
seem to have lasted long or have only provided very
limited power. The question that needs to be answered is
why they haven't succeeded and why they seemed to be
limited compared to elisp.
* If you have not programmed in elisp, how can you judge
whether it is any good, what would be a reasonable
replacement and how much effort it would take. However, it
seems that most people, once they actually become familiar
with the language, decide its actually quite good at what
it does, provides lots of specialised functiaonlity that
would also need to be implemented in any other language
used for the same purpose and they realise the effort
required to change is far greater than any benefits.
* Finally, how much does it really matter whether emacs is
used by lots of people. Maybe as long as it is used by
enough people that we have sufficient maintainers, that is
sufficient? I find it odd how frequently someone new to
emacs starts posting about how fantastic it is and how we
just need to change it by doing X in order to make
everyone realise how great it is. I don't get the mindset
that discovers something that they find wonderful and
their initial thoughts are about how they can change it to
something else.
My personal feeling is that changing to something else will never happen
and is the wrong direction to go anyway. If enough feel strong enough
about the issue, their best bet would likely be to start from scratch
and develop a new editor that takes all the best ideas from emacs, adds
what they feel is important and develops it all on a new modern clean
code base. If they get it right, it will become the great editor of the
next 30 years - if they don't it will just join the pile of other failed
editor projects. Whatever the outcome, it will probably add to our
knowledge and understanding and is therefore worthwhile.
Tim
--
tcross (at) rapttech dot com dot au
Pascal J. Bourguignon
> LanX <lanx...@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".
--
__Pascal Bourguignon__ http://www.informatimago.com/
LanX
> 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.
LanX
> 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.
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.
LanX
> 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.
Alessandro Piras
>> 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
Evans Winner
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. 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.
If what you want to implement requires industrial-strength
language features, why do you want to implement it in a text
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.
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.
Pascal J. Bourguignon
> LanX <lanx...@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 J. Bourguignon
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!
Helmut Eller
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
LanX
> 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
LanX
> 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)
Helmut Eller
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
LanX
> 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.
Pascal J. Bourguignon
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 J. Bourguignon
"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 J. Bourguignon
Uday S Reddy
> 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.
There _are_ large, complex systems implemented in Elisp: mail clients, news readers, programming environments, word processors, spread sheets, personal organizers, the world's most sophisticated calendar program, ... The list goes on. ELisp's limitations do show up when we do these things.
On a positive note, there is no reason why the Emacs virtual machine cannot be extended and used for supporting other sophisticated languages. In fact, there is a move to replace the Emacs VM by a Guile VM, which might happen sooner rather than later.
I don't believe that the choice of programming language in software development is a trivial issue. I am disappointed by some of the flippant responses to the question posed here.
Cheers,
Uday Reddy
rustom
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...]
Stefan Monnier
> 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
Evans Winner
But [Emacs] has a lot of legacy which is a large part of
its popularity and longevity.
Emacs isn't just something I put up with because it has a
lot of legacy. I would argue that it has that legacy
precisely because it was the right tool for the job; that
job is editing text. It's nice that some people have
managed to engineer large systems to run in the extension
language of a text editor, but I'm not sure it's then fair
to conclude that therefore the editor should be re-written
in some other language that is designed for large complex
systems.
In any case, a distinction must be made (I think) between
Emacs Lisp and core Emacs, written in C. To me, re-writing
the core of Emacs in Common Lisp sounds like it might be a
great idea, but it's well out of my depth.
Indeed. But lexical scoping and name spaces wouldn't
make any difference in this respect.
Perhaps not. What I can say is that if Emacs Lisp were
Common Lisp, I would never have gotten serious about using
Emacs. I know that I am not alone in this. Emacs is a text
editor used by many people, and not all of them are CL
hackers -- not all of them are even programmers. Some are
just writers -- text editors are good for writing text,
actually, not just code. I would bet that there are a great
many writers and other non-programmers out there who in fact
do write useful Emacs Lisp code because Emacs Lisp is the
kind of language that they can understand well enough to use
to write useful code. It is certainly not correct to
characterize non-professional programmers as needing or
wanting only to setq a few variables. The dichotomy is not
that clear, and Emacs Lisp was, as I understand it, designed
precisely in recognition that computer users are
programmers, fundamentally, and deserve the power of a real
programming language, but editing text does not require the
complex overhead of an industrial-strength language.
Granted, one can always program in a simple subset of Common
Lisp if one wants to, or as Pascal mentioned, write a DSL --
and the real issue is a cultural one. I can look at
reasonably straight-forward Emacs Lisp and often tell what
is going on and where to make changes if I need to; the same
is not true of Common Lisp. Part of the reason is cultural
-- the coding standards for Emacs, the liberal use of doc
strings, for instance, have "trickled down" to a great deal
of third-party code written for Emacs. The Common Lisp
culture doesn't appear to me to have caught that wave. So
perhaps it would not be so bad. But if the Common Lisp
culture is an example, the result of an Emacs written in
Common Lisp would not be lots of libraries that users could
look at and easily modify, but a small amount of
tightly-written, totally inscrutable code that only a
die-hard CL hacker could love -- or even understand. I know
it would be technically possible to make an Emacs in Common
Lisp that was as useful to non-experts as current Emacs is,
but I don't believe that it would actually happen -- that it
is culturally likely. CL Emacs would become a specialty toy
that only a few would know enough about to use productively.
As for Emacs in Python et al, the same, only more so.
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.
LanX
> > 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?
Pascal J. Bourguignon
> [...]
> 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 |
+------------------------+--------+-------------------------------+
Maarten Bergvelt
>> > 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.
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.
> 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?
--
Maarten Bergvelt
Evans Winner
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
Xah Lee
> > 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/
☄
Xah Lee
wrote:
> Alessandro Piras <lay...@gmail.com> writes:
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:
Pascal J. Bourguignon
> On 2010-06-01, LanX <lanx...@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.
Xah Lee
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/
☄
Xah Lee
> 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? :-)
Yeah, i think having multiple language support is a good thing, but i
think practically that's just not feasible, for emacs being started in
the 1980s.
Note that the PyMacs guy switched to vi, and wrote a big article about
it.
here's the pymacs home page:
http://pymacs.progiciels-bpi.ca/
here's his rant, i think it used to be named something like “why i
switched to vi”
http://pinard.progiciels-bpi.ca/notes/Thoughts_on_editors.html
note the date there 2003.
Xah
∑ http://xahlee.org/
☄
rustom
>
> 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
Helmut Eller
> 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
LanX
I was meditating about how namespaces are realized in perl and now I'm
wondering if this behaviour could be mimicked in elisp.
Let's give a simplified example:
In perl the following code binds the variable $var and the function
tst() to the package Namespace, effectively they are (at compiletime!)
aliases to $Namespace::var and Namespace::tst.
---------------
{
package Namespace;
our $var=666;
sub tst {print $var }
}
package Outerspace;
$var=42;
Namespace::tst(); # prints 666
---------------
I was thinking of reproducing this behaviour in elisp with defalias
and defvaralias, to make "var" an alias of "Namespace-var", but this
effects the runtime and not the copiletime...
i.e. the above code in elisp would print 42 because at execution time
"var" would be bound to "Outerspace-var".
Question: does elisp know any mechanisms to bind/alias a symbol at
compile-time only?
Such that var will be replace by namespace-var when reading until
there is a new binding?
Pascal J. Bourguignon
> 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...
LanX
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...
Pascal J. Bourguignon
> 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...
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>
Uday S Reddy
> 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]
Even without eval, translating dynamic binding to lexical is equivalent to solving the halting problem. It is "dynamic" binding that we are talking about!\\
Most static analysis techniques try to solve the halting problem. They don't, of course. They do as good a job as they can. The last sentence of the abstract gives it away: "... has been applied to realistic Emacs Lisp code, and is *highly accurate* and reasonably efficient in practice." (Emphasis added.)
Cheers,
Uday
Joseph Brenner
LanX <lanx...@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.
Tim X
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
Stefan Monnier
> 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.
Yes, using CL macros (or even CL functions, but at the condition that
they come with a compiler-macro that expands them at compile-time) is
perfectly fine.
Stefan
Jean-Baptiste Bourgoin
The future of Emacs seems to be ... guile 2.0. Guile 2.0 run on a VM who
manage already Elisp (of course) and Javascript in addition to scheme.