Re: GSoC projects related to Emacs

Re: GSoC projects related to Emacs

[Leo]

On 2012-04-10 06:28 +0800, Bastien wrote:
> ,----[ Guile-Emacs ]
> | 
> | Use libguile as the basis for Emacs's Lisp implementation and begin
> | replacing the Elisp interpreter with Guile
> | 
> | http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/bpt/23002
> `----

I am looking forward to this ;)

Leo

GSoC projects related to Emacs

[Bastien]

Here are the current GSoC projects related to Emacs:

,----[ Guile-Emacs ]
| 
| Use libguile as the basis for Emacs's Lisp implementation and begin
| replacing the Elisp interpreter with Guile
| 
| http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/bpt/23002
`----

,----[ GNU Emacs Native Profiler ]
| The goal of this project is to provide a native profiler to GNU Emacs,
| which helps developers to optimize their code and also helps users to
| find hot-spots of their environments.
| 
| http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/m2ym/1
`----

,----[ Bugpile ]
| A bugtracker for GNU Emacs Org-mode written in Org-mode and PicoLisp
| 
| http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/tj64/1
`----

,----[ Emacs-Orgmode Git merge tool for Org Files ]
| The purpose of the project is to create a specialized Git merge driver
| for plain text Org-Mode formatted files.
| 
| http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/pwyl/1
`----

,----[ Org Sync ]
| Let Org-mode synchronize with online bug-tracking and todo-list
| services.
| 
| http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/aaptel/5002
`----

Selected students will be known on April 23rd.

If you have any questions/comments on the projects, please feel free to
ask.  I can give more details about the Org projects.  I'm curious about 
your feedback about the two others.

-- 
 Bastien

Re: GSoC projects related to Emacs

[Stefan Monnier]

> Here are the current GSoC projects related to Emacs:
> ,----[ Guile-Emacs ]
> |
> | Use libguile as the basis for Emacs's Lisp implementation and begin
> | replacing the Elisp interpreter with Guile
> |
> | http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/bpt/23002
> `----

This is a very interesting long-term project.

While I don't think moving away from Elisp is very high priority for
Emacs right now, I do hope we can "subcontract" the interpreter/compiler
implementation to some other project such as Guile.  So this project is
very useful in this context.  Getting rid of the current interpreter
will probably require a lot of work, so the hard part of this GSoC will
be to come up with good intermediate steps.

> ,----[ GNU Emacs Native Profiler ]
> | The goal of this project is to provide a native profiler to GNU Emacs,
> | which helps developers to optimize their code and also helps users to
> | find hot-spots of their environments.
> |
> | http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/m2ym/1
> `----

This is a very interesting short-term project that I'd be happy to supervise.
It's easy to divide it into steps, each one of them simple and useful,
and it's easy to add more steps if time permits (time-based sampling,
malloc-based sampling, different kinds and amounts of data being
sampled, different ways to start/stop the sampling, different ways to
analyze&display the resulting data, ...).


        Stefan

Re: Emacs and Guile (was: GSoC projects related to Emacs)

[Eli Zaretskii]

> From: Leo <sdl.web@gmail.com>
> Date: Tue, 03 Apr 2012 11:36:05 +0800
> 
> On 2012-04-10 06:28 +0800, Bastien wrote:
> > ,----[ Guile-Emacs ]
> > | 
> > | Use libguile as the basis for Emacs's Lisp implementation and begin
> > | replacing the Elisp interpreter with Guile
> > | 
> > | http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/bpt/23002
> > `----
> 
> I am looking forward to this ;)

I don't.

FWIW, my (admittedly short) experience with Guile is that it is not
reliable or stable on anything but GNU/Linux, and even there it has
much to catch up.  It has a lot to gain in terms of portability before
it can be considered seriously as an alternative to ELisp, or even its
sibling on equal rights.

As an example, look at the series of reports from my (eventually
successful) attempt to build Guile natively on MS-Windows.  The series
starts here:

  https://lists.gnu.org/archive/html/bug-guile/2012-01/msg00034.html

Please read the diffs and the analysis I posted, and you will see that
very important core features will simply not exist if some library
function or API are not supported by the underlying environment.  So
much so that some .scm files that are part of Guile itself will simply
fail to compile (and break the entire build of Guile), when one of
these features is missing.  To me, the failure to build in these cases
is a clear sign of a package that is not ready for prime time.  I
think simply nobody tried to build or work with it seriously on any
system except latest versions of GNU/Linux (and a couple of others),
see this thread:

  http://lists.gnu.org/archive/html/guile-user/2011-09/msg00064.html

Or consider Guile's support of non-ASCII characters, which relies on
libiconv with no additional features -- we cannot possibly consider
this complete enough to replace what we have in Emacs now.

And before you consider the above FUD and nothing else: GNU Make
recently added Guile support (available only from the Make CVS
repository for now), and even though Make's needs are much simpler
than Emacs's, you can get the feeling about the problems in this
thread:

  http://lists.gnu.org/archive/html/guile-user/2012-01/msg00130.html

Etc., etc.  I would suggest some serious analysis of Guile as it
stands today by someone who knows much more about it than I do, in
comparison with ELisp and the related Emacs infrastructure, and then
some serious discussions with Guile developers about the gaps, before
we can regard Guile as a contender.  I invite anyone with sufficiently
good knowledge of Emacs internals to look at the Guile equivalents and
see the significant differences, gaps, etc. (or maybe my prejudice and
misunderstandings, who knows?).  If we want to seriously talk about
Guile, let's first invest some effort in understanding what we are
talking about.

Re: GSoC projects related to Emacs

[Bastien]

Hi Stefan,

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> This is a very interesting short-term project that I'd be happy to
> supervise.

There is an official way of supervising ("mentoring") such projects: 

1. register on http://www.google-melange.com
2. apply as a "mentor"
3. apply to be a mentor for the GNU project
4. go to the Emacs Native profiler page (the URL I sent)
5. from there, tell you want to mentor this project

The project doesn't have mentor yet, having one will give it more
chances to be accepted and sponsored by Google.

If you don't want to get involved this way, and if the project get
sponsored, it's always possible to supervise it informally.

HTH,

-- 
 Bastien

Re: Emacs and Guile

[Werner LEMBERG]

> FWIW, my (admittedly short) experience with Guile is that it is not
> reliable or stable on anything but GNU/Linux, and even there it has
> much to catch up.  It has a lot to gain in terms of portability
> before it can be considered seriously as an alternative to ELisp, or
> even its sibling on equal rights.  [...]

We use it quite successfully in LilyPond which runs on Macs, Windows
boxes, and various UNIX flavours.  Right now, we have about 1.3MByte
of Scheme code.  This is Guile 1.8.x, but we are already in the
process of migrating to 2.x.

> As an example, look at the series of reports from my (eventually
> successful) attempt to build Guile natively on MS-Windows.

OK, this is a different issue.  LilyPond binaries for Mac and Windows
are cross-compiled on a GNU/Linux box.

So people working on a forthcoming Scheme support in Emacs might have
a look at LilyPond.


    Werner

Re: Emacs and Guile

[Eli Zaretskii]

> Date: Tue, 10 Apr 2012 10:26:11 +0200 (CEST)
> Cc: sdl.web@gmail.com, emacs-devel@gnu.org
> From: Werner LEMBERG <wl@gnu.org>
> 
> 
> > FWIW, my (admittedly short) experience with Guile is that it is not
> > reliable or stable on anything but GNU/Linux, and even there it has
> > much to catch up.  It has a lot to gain in terms of portability
> > before it can be considered seriously as an alternative to ELisp, or
> > even its sibling on equal rights.  [...]
> 
> We use it quite successfully in LilyPond which runs on Macs, Windows
> boxes, and various UNIX flavours.  Right now, we have about 1.3MByte
> of Scheme code.  This is Guile 1.8.x, but we are already in the
> process of migrating to 2.x.

2.x is quite different, I'm told.  My experience is with 2.x only.

> LilyPond binaries for Mac and Windows are cross-compiled on a
> GNU/Linux box.

I don't think this matters.  The problems I had were not with the
configury and the build procedure -- that worked pretty much
seamlessly.  The problem was with missing features on that are needed
for running the binaries on MS-Window.  Cross-compilation cannot fix
that.

> So people working on a forthcoming Scheme support in Emacs might have
> a look at LilyPond.

Yes, by all means.  Any experience should be carefully studied.

Re: Emacs and Guile

[Werner LEMBERG]

> The problems I had were not with the configury and the build
> procedure -- that worked pretty much seamlessly.  The problem was
> with missing features on that are needed for running the binaries on
> MS-Window.  Cross-compilation cannot fix that.

Interesting.  IIRC, we don't have major problems of running the Scheme
code on MS Windows.  The main trouble was the location of the SCM
files not being found at run time, but besides this I can't remember a
major issue.  But admittedly I haven't followed this very closely
because I don't use Windows.


    Werner

Re: Emacs and Guile

[Leo]

On 2012-04-10 15:09 +0800, Eli Zaretskii wrote:
> FWIW, my (admittedly short) experience with Guile is that it is not
> reliable or stable on anything but GNU/Linux, and even there it has
> much to catch up.  It has a lot to gain in terms of portability before
> it can be considered seriously as an alternative to ELisp, or even its
> sibling on equal rights.
>
> As an example, look at the series of reports from my (eventually
> successful) attempt to build Guile natively on MS-Windows.  The series
> starts here:
>
>   https://lists.gnu.org/archive/html/bug-guile/2012-01/msg00034.html

Indeed, these are some disheartening signs. But I hope they will
improve/mature once guile is used in more places.

Leo

Re: Emacs and Guile

[BT Templeton]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Leo <sdl.web@gmail.com>
>> Date: Tue, 03 Apr 2012 11:36:05 +0800
>> 
>> On 2012-04-10 06:28 +0800, Bastien wrote:
>> > ,----[ Guile-Emacs ]
>> > | 
>> > | Use libguile as the basis for Emacs's Lisp implementation and begin
>> > | replacing the Elisp interpreter with Guile
>> > | 
>> > | http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/bpt/23002
>> > `----
>> 
>> I am looking forward to this ;)
>
> I don't.
>
> FWIW, my (admittedly short) experience with Guile is that it is not
> reliable or stable on anything but GNU/Linux, and even there it has
> much to catch up.  It has a lot to gain in terms of portability before
> it can be considered seriously as an alternative to ELisp, or even its
> sibling on equal rights.

Guile would need better Microsoft Windows and MS-DOS support before
using Guile as the default Elisp implementation. But that's not a reason
to delay work on Guile-Emacs for free systems.

In what respect does Guile need to catch up on GNU/Linux?

> To me, the failure to build in these cases is a clear sign of a
> package that is not ready for prime time.

...on non-free, non-POSIX platforms, yes.

> Or consider Guile's support of non-ASCII characters, which relies on
> libiconv with no additional features -- we cannot possibly consider
> this complete enough to replace what we have in Emacs now.

Fortunately, Guile doesn't need to immediately replace what Emacs has
now. It's less elegant to make Elisp strings a separate type, and would
make interaction with Scheme less pleasant, but for an experimental
version it would be acceptable.

> And before you consider the above FUD and nothing else: GNU Make
> recently added Guile support (available only from the Make CVS
> repository for now), and even though Make's needs are much simpler
> than Emacs's, you can get the feeling about the problems in this
> thread:
>
>   http://lists.gnu.org/archive/html/guile-user/2012-01/msg00130.html

I don't see the significance of this particular thread; it's a trivial
problem that was quickly resolved. And it's at most a minor bug in Guile
(the return value of `define' is unspecified in R5RS).

-- 
Inteligenta persono lernas la lingvon Esperanton rapide kaj facile.
Esperanto estas moderna, kultura lingvo por la mondo. Simpla, fleksebla,
belsona, Esperanto estas la praktika solvo de la problemo de universala
interkompreno. Lernu la interlingvon Esperanton!

Re: Emacs and Guile

[Eli Zaretskii]

> From: Leo <sdl.web@gmail.com>
> Date: Wed, 11 Apr 2012 07:06:19 +0800
> 
> >   https://lists.gnu.org/archive/html/bug-guile/2012-01/msg00034.html
> 
> Indeed, these are some disheartening signs. But I hope they will
> improve/mature once guile is used in more places.

Me too.  I did that to be able to build GNU Make with Guile support,
so I hope it will get better RSN.  At least my comments and patches
were accepted by the Guile developers.

Re: Emacs and Guile

[Eli Zaretskii]

> From: BT Templeton <bpt@hcoop.net>
> Date: Tue, 10 Apr 2012 19:57:15 -0400
> 
> Guile would need better Microsoft Windows and MS-DOS support before
> using Guile as the default Elisp implementation. But that's not a reason
> to delay work on Guile-Emacs for free systems.

Please don't make this a free vs non-free systems argument; it's not.
Please try to read the threads I pointed to as a sign of immaturity of
Guile on _any_ platform.  Otherwise, I will regret I ever spoke,
because nothing but flames will come out of this thread.

> In what respect does Guile need to catch up on GNU/Linux?

I gave one example: support for non-ASCII characters.  I have bad
feelings about a few others, but I think someone who knows Guile
better should look into this.  One area I'd love expert opinion is how
will Guile GC interact with Emacs memory management.

Anyway, I hope you are not saying that just GNU/Linux is enough for
serious use of Guile in Emacs.

> > To me, the failure to build in these cases is a clear sign of a
> > package that is not ready for prime time.
> 
> ...on non-free, non-POSIX platforms, yes.

Not just.  One of the threads I pointed to clearly says that Guile is
being tested on 2 or 3 platforms.  That's way too few, IMO, and I
think it goes a long way towards explaining the problems.

> > Or consider Guile's support of non-ASCII characters, which relies on
> > libiconv with no additional features -- we cannot possibly consider
> > this complete enough to replace what we have in Emacs now.
> 
> Fortunately, Guile doesn't need to immediately replace what Emacs has
> now. It's less elegant to make Elisp strings a separate type, and would
> make interaction with Scheme less pleasant, but for an experimental
> version it would be acceptable.

I disagree.  Strings are very fundamental to Emacs.  I don't see how
Guile can be basis for any significant feature in Emacs without
supporting the emacs-internal encoding of characters.  If I cannot
safely pass a string from Emacs to Guile and back, then the range of
possible Guile-based applications in Emacs is quite narrow, I'd say.

> >   http://lists.gnu.org/archive/html/guile-user/2012-01/msg00130.html
> 
> I don't see the significance of this particular thread; it's a trivial
> problem that was quickly resolved.

The fact that this trivial problem was present is telltale, IMO.

There's some history behind it.  I was the one who bumped into that
problem as soon as I built Make with Guile on MS-Windows.  My first
thought was that something is wrong with the way I invoked Guile from
Make.  So I asked Paul Smith about this, and he said he didn't see
this problem, but the way I called a Guile function was correct.  I
next thought that my Guile build is botched in some fundamental way.
But then Paul tried Guile 2.x and hit the same problem.  So not only
there is a "trivial problem", but also there are still significant
changes between Guile 1.8 and 2.0.  These are all signs of immaturity
IMO.

Re: Emacs and Guile

[Thien-Thi Nguyen]

() Eli Zaretskii <eliz@gnu.org>
() Wed, 11 Apr 2012 10:29:26 +0300

   So not only there is a "trivial problem", but also there are
   still significant changes between Guile 1.8 and 2.0.  These are
   all signs of immaturity IMO.

I think it's more a sign of the prevalent development culture.
More time will not bring less differences as the primary Guile
hackers do not focus on bridging those differences, so maturity
in that sense can never arrive.

What Guile 2.0 needs (especially for a realistic shot at Emacs
integration), is for Someone apart from the primary Guile hackers
to curate the 1.8 branch, applying bugfixes, doc upgrades, and
design shims, all to increase the sense of continuity perceived
by client code.  By side effect of the design shims, quirks in
both 1.8 and 2.0, as well as regressions in 2.0, will be easily
identified and (perhaps less easily) abstracted.  This is the
process that will help bring maturity.

Absent that, i would agree that jumping directly to a rebase of
Emacs onto Guile 2.0 is fraught w/ the wrong kind of excitement.

Re: Emacs and Guile

[Eli Zaretskii]

> From: Thien-Thi Nguyen <ttn@gnuvola.org>
> Date: Wed, 11 Apr 2012 13:31:33 +0200
> 
> () Eli Zaretskii <eliz@gnu.org>
> () Wed, 11 Apr 2012 10:29:26 +0300
> 
>    So not only there is a "trivial problem", but also there are
>    still significant changes between Guile 1.8 and 2.0.  These are
>    all signs of immaturity IMO.
> 
> I think it's more a sign of the prevalent development culture.

Well, yeah, that's another way of putting it ;-)

> What Guile 2.0 needs (especially for a realistic shot at Emacs
> integration), is for Someone apart from the primary Guile hackers
> to curate the 1.8 branch, applying bugfixes, doc upgrades, and
> design shims, all to increase the sense of continuity perceived
> by client code.  By side effect of the design shims, quirks in
> both 1.8 and 2.0, as well as regressions in 2.0, will be easily
> identified and (perhaps less easily) abstracted.  This is the
> process that will help bring maturity.

I don't know enough to voice an opinion on that, but it certainly
sounds right to me.

One other annoyance I know of wrt the differences between these
branches is the fact that you must explicitly ask pkg-config about one
branch or the other (as in "pkg-config guile-2.0"), which is -- how
should I put that? -- suboptimal.  Maybe this nit could be fixed as
well at some point.

Re: Emacs and Guile

[Andy Wingo]

On Tue 10 Apr 2012 00:09, Eli Zaretskii <eliz@gnu.org> writes:

> FWIW, my (admittedly short) experience with Guile is that it is not
> reliable or stable on anything but GNU/Linux, and even there it has
> much to catch up.  It has a lot to gain in terms of portability before
> it can be considered seriously as an alternative to ELisp, or even its
> sibling on equal rights.

There is certainly much room for improvement.  I really appreciated your
bug reports and patches, especially since the main Guile hackers all use
GNU systems for development.  We haven't merged them all in yet, but
it's more due to a lack of time than anything else.

Portability is an ongoing challenge, as we write new code, but it's
something we can reach with help and persistence.

I'm pretty excited about BT's proposal.  BT has the right mix of care
for detail and audacity that seems necessary for a hack of this size :)

Andy
-- 
http://wingolog.org/

RE: Emacs and Guile

[Drew Adams]

I do not want to get into this discussion in detail (and don't bother flaming).
Just count me as one voice who is not in favor of "basing" Emacs on Guile or any
other Scheme dialect or implementation.

I might not object to "basing" Emacs on Common Lisp.  I think that Common Lisp,
like Emacs Lisp, is a much better fit for the kind of programming, including
customization and UI, that Emacs users and developers do.

I am content with Emacs being Emacs Lisp.  (Yes, I said "being", and not just
"being based on", because I view Emacs Lisp as part and parcel of Emacs, not
just as its implementation language.)  But I would not mind Emacs Lisp moving
more toward some of what Common Lisp offers.  (I also generally appreciate it
when we move some stuff from C to Lisp.)

I am strongly in favor of both lexical and dynamic binding/scope, for the usual
reasons given for each.

I have been in favor of lexical binding for Lisp since the original Lambda
papers back in the 70s & 80s (http://library.readscheme.org/page1.html).  But
that does not mean that I am in favor of a Scheme-based Emacs.

[I am a functional (and logic, and constraint) programming fan too, but I am not
in favor of a Haskell-based Emacs.  (I am not opposed to experimentation.  I
just do not want to see Emacs lose its Lisp development/base.)]

In the case of Emacs and its Lisp use cases, RMS's description of the advantages
of dynamic binding is right on
(http://www.gnu.org/software/emacs/emacs-paper.html#SEC17,
http://www.gnu.org/software/emacs/emacs-paper.html#SEC18), and too often missed
or under-appreciated, I think.

Steve Yegge, for example, gives as his only example of dynamic-scope advantage
setting a free variable in a called function to affect the caller's stack frame
(http://steve-yegge.blogspot.com/2008/01/emergency-elisp.html).  The advantage
to be emphasized is instead the one RMS points out: binding/setting in a caller
to affect callee behavior.

It would be misguided, IMHO, to move to a Lisp that did not enjoy both lexical
and dynamic binding/scope as first-class features.

That's all I want to say on the matter.  No, I did not provide much in the way
of reasons - I'm not really interested in the discussion.  Just count me as one
vote against a Guilemacs.  I want a "real" Lisp for Emacs ;-).  (Sorry, couldn't
resist.)

Re: Emacs and Guile

[BT Templeton]

"Drew Adams" <drew.adams@oracle.com> writes:

> I do not want to get into this discussion in detail (and don't bother flaming).
> Just count me as one voice who is not in favor of "basing" Emacs on Guile or any
> other Scheme dialect or implementation.

The plan is not to replace Elisp with Scheme, but rather to replace
Emacs's Elisp implementation with Guile's Elisp implementation.

-- 
Inteligenta persono lernas la lingvon Esperanton rapide kaj facile.
Esperanto estas moderna, kultura lingvo por la mondo. Simpla, fleksebla,
belsona, Esperanto estas la praktika solvo de la problemo de universala
interkompreno. Lernu la interlingvon Esperanton!

RE: Emacs and Guile

[Drew Adams]

> The plan is not to replace Elisp with Scheme, but rather to replace
> Emacs's Elisp implementation with Guile's Elisp implementation.

I see.  Yes, I did not understand that, so my reaction might well be off the
mark.  But perhaps it depends on what you mean by "implementation".  Do you mean
to replace only what is done now using C code by Guile (Scheme?) code?

If it's essentially one-to-one C-for-Guile/Scheme then I might not have a
problem with it.  But I would not want to see the new "implementation" extend
beyond what we currently use C for.  (And in fact I would like to see more of
what is currently implemented in C be moved to Emacs Lisp.)

Admittedly, I am ignorant of just what is being proposed.  I did indeed think
that the proposal was to in some way "base" Emacs on Scheme instead of on Emacs
Lisp.  I saw statements like these, which probably gave me the wrong impression:

*  "[Guile] has a lot to gain in terms of portability before it can be
considered seriously as an alternative to ELisp, or even its sibling on equal
rights."

*  "...[Guile]...in comparison with ELisp"

*  "I don't think moving away from Elisp is very high priority for Emacs right
now."

*  "the range of Guile-based applications in Emacs is quite narrow."

Such statements gave me the impression that Guile is being proposed "as an
alternative to Elisp", and that it was being proposed, at least in part, to
"move away from Elisp".

It is true, however, that you refer to "using Guile as the default Elisp
implementation."  I took a quick look at your summary here:
http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/bpt/23002.

The first part of your summary refers to using Guile "as the basis for Emacs's
Lisp implementation".  And that's what you're repeating now.

But there is some ambiguity in the second part of your summary: the phrase
"begin replacing the Elisp interpreter with Guile".  That could be understood as
replacing the Elisp interpreter (which interprets Elisp) with a Guile
interpreter (which interprets Guile? Scheme?).

Similarly, "implement a basic form of interaction with Guile."

So it sounded to me like you were proposing both to (a) reimplement Elisp using
Guile and (b) replace Elisp by Guile as Emacs's user/developer interpreter
language.

Re: Emacs and Guile (was: GSoC projects related to Emacs)

[Ken Raeburn]

On Apr 10, 2012, at 03:09, Eli Zaretskii wrote:
>> From: Leo <sdl.web@gmail.com>
>> Date: Tue, 03 Apr 2012 11:36:05 +0800
>> 
>> On 2012-04-10 06:28 +0800, Bastien wrote:
>>> ,----[ Guile-Emacs ]
>>> | 
>>> | Use libguile as the basis for Emacs's Lisp implementation and begin
>>> | replacing the Elisp interpreter with Guile
>>> | 
>>> | http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/bpt/23002
>>> `----
>> 
>> I am looking forward to this ;)
> 
> I don't.
> 
> FWIW, my (admittedly short) experience with Guile is that it is not
> reliable or stable on anything but GNU/Linux, and even there it has
> much to catch up.  It has a lot to gain in terms of portability before
> it can be considered seriously as an alternative to ELisp, or even its
> sibling on equal rights.

My position (when I had time to work on Guilemacs) was always that the work should be done to make this plugging together *possible*, and then we should see where things stand.  Emacs would bring a *huge* audience to Guile, for better or worse, and would possibly shine lights on various areas where Guile might not have the support that a (certain, high-profile) real-world application with particular demands might need.  That doesn't mean it can't be added… though, that circles back to concerns the maturity and stability of Guile and its interfaces.  I don't think I ever saw it as less than a multi-year project overall (even assuming I kept working on the Emacs bits and Guile folks worked on the related Guile aspects all that time).  Which is why I also figured on aiming for an Emacs code base that could be configured to use Guile or to run standalone as a transitional phase -- something that could be at least partly kept merged with upstream Emacs to keep the divergence manageable.

I also figured getting Guile to actually do ELisp interpretation would come late if at all, but some pretty exciting work has been done in that area already.

I do think something can be gotten up and running in a few months time.  I did it, many years ago, though it was pretty hackish and limped more than it ran, but I identified a few bits of low-level abstraction that would help in the process and pushed them into the Emacs source base.  So hopefully the second time around it's a little easier.  But that's only the start of getting some possible future release of Emacs to be Guile-based.  There's portability, performance, packaging and installation, transition issues, figuring out how to handle the new Guile features (threads!), licensing arguments perhaps -- and, of course, convincing various people on this list that maybe it's an okay idea after all. :-)

In any case, I'm excited to see how this project goes.

Ken

Re: Emacs and Guile

[Richard Stallman]

    What Guile 2.0 needs (especially for a realistic shot at Emacs
    integration), is for Someone apart from the primary Guile hackers
    to curate the 1.8 branch, applying bugfixes, doc upgrades, and
    design shims, all to increase the sense of continuity perceived
    by client code.

I agree it would be good if Guile worked on non-GNU systems.
At the same time, we should be careful not to define support
for non-GNU systems as part of our primary goal.
That would be drifting in the direction of downgrading our real goal.


--
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

Re: Emacs and Guile

[Thien-Thi Nguyen]

() Richard Stallman <rms@gnu.org>
() Fri, 13 Apr 2012 00:06:42 -0400

   I agree it would be good if Guile worked on non-GNU systems.
   At the same time, we should be careful not to define support
   for non-GNU systems as part of our primary goal.
   That would be drifting in the direction of downgrading our real goal.

I completely agree, and should clarify that my comments were made
w/ only GNU in mind; difficult (or, depending on one's pov, dis-)
continuity exists even there, between Guile versions.

What happens in The Wild is that j.r.hacker discovers Guile 1.x,
uses it, discovers Guile 2.0, stumbles trying to get Working Code
to behave nicely under both, fails to find a sanctioned path, and
ultimately loses interest, in the process spreading disrespect
(for Guile and sometimes GNU) among peers.

The efforts i espouse are aimed at making the sanctioned path
easier to find (i am such a j.r.hacker personally struggling to
still the creeping disrespect).  IMO, to spread software freedom
necessarily involves internal bulwarking; the edge's advance is
mooted if the center falls.

Re: Emacs and Guile

[Miles Bader]

Thien-Thi Nguyen <ttn@gnuvola.org> writes:
> What happens in The Wild is that j.r.hacker discovers Guile 1.x,
> uses it, discovers Guile 2.0, stumbles trying to get Working Code
> to behave nicely under both, fails to find a sanctioned path, and
> ultimately loses interest, in the process spreading disrespect

What does "fails to find a sanctioned path" mean?

-miles

-- 
魔力を持った謎の石仏
苔地蔵様に近づいて

Re: Emacs and Guile

[Thien-Thi Nguyen]

() Miles Bader <miles@gnu.org>
() Fri, 13 Apr 2012 16:43:23 +0900

   What does "fails to find a sanctioned path" mean?

One tries to get from point A (working code on 1.8) to point B
(same code working on both 1.8 and 2.0), by modifying the code.
There are many ways to change.  What's the best, for some set of
criteria (elegance, maintainability, minimal disturbance to the
force, ...)?  If one can attain neither the best nor the middling
way, but must resort to the worst, i.e., top-level:

  (cond ((version=? "1.8") ORIGINAL-WORKING-CODE)
        ((version=? "2.0") COMPLETELY-DIFFERENT-CODE)
        (else (error "NOT YET IMPLEMENTED")))

then, yes, that is a path, valid and functional, but no, it is not
sanctionable because ORIGINAL-WORKING-CODE was merely set aside and
now must compete for attention w/ COMPLETELY-DIFFERENT-CODE.  You
might as well have taken the advice "use another implementation /
language / platform / licensing model".  You might as well have
operated w/o awareness of GNU or its ideals in the first place.

Luckily (IMHO), such a situation only occurs when features are
completely dropped, which is rare to start and increasingly rare as
the Guile hackers learn to heed their users' needs.

Unluckily, not everyone who follows Guile development can take the
travails of the Lilypond transition (in which critical features
were discovered to have gone missing in Guile 2.0 and required to
be added back, after much exhausting "discussion") so sanguinely.
That's why Someone should put energy into mending what was rent.

Anyway, this is no longer about Emacs, so i'll shut up now.