Re: About Emacs Modernisation Project

Re: About Emacs Modernisation Project

[Pascal J. Bourguignon]

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

Re: About Emacs Modernisation Project

[Alessandro Piras]

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

Re: About Emacs Modernisation Project

[Alessandro Piras]

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

Re: About Emacs Modernisation Project

[Xah Lee]

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/

☄

Re: About Emacs Modernisation Project

[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.

Re: About Emacs Modernisation Project

[Pascal J. Bourguignon]

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/

Re: About Emacs Modernisation Project

[LanX]

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

Re: About Emacs Modernisation Project

[Pascal J. Bourguignon]

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

Re: About Emacs Modernisation Project

[Xah Lee]

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/

☄

Re: About Emacs Modernisation Project

[LanX]

> 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.

Re: About Emacs Modernisation Project

[Helmut Eller]

* 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

Re: About Emacs Modernisation Project

[LanX]

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)

Re: About Emacs Modernisation Project

[Helmut Eller]

* 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

Re: About Emacs Modernisation Project

[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.

Re: About Emacs Modernisation Project

[Pascal J. Bourguignon]

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

Re: About Emacs Modernisation Project

[Pascal J. Bourguignon]

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

Re: About Emacs Modernisation Project

[Xah Lee]

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/

☄

Re: About Emacs Modernisation Project

[Helmut Eller]

* 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

Re: About Emacs Modernisation Project

[Pascal J. Bourguignon]

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/

Re: About Emacs Modernisation Project

[rustom]

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...]

Re: About Emacs Modernisation Project

[B. T. Raven]

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

Re: About Emacs Modernisation Project

[rustom]

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

Re: About Emacs Modernisation Project

[Stefan Monnier]

>     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

Re: About Emacs Modernisation Project

[LanX]

> > 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?

Re: About Emacs Modernisation Project

[Pascal J. Bourguignon]

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

Re: Emulating namespaces

[Pascal J. Bourguignon]

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/

Re: Emulating namespaces

[LanX]

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...

Re: Emulating namespaces

[Pascal J. Bourguignon]

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/

Re: About Emacs Modernisation Project

[Pascal J. Bourguignon]

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/

Re: About Emacs Modernisation Project

[Evans Winner]

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

Re: About Emacs Modernisation Project

[Joseph Brenner]

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.

Re: About Emacs Modernisation Project

[Tim X]

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