5 ms·

I hate to be "that guy," but what happened to the Guile-Emacs project? Guile performs way better than Elisp too, but (perhaps more importantly) raises the possi

I hate to be "that guy," but what happened to the Guile-Emacs project? Guile performs way better than Elisp too, but (perhaps more importantly) raises the possibility of writing configuration and extensions in Lua and Scheme.

rurban 8y ago
Too slow strings still
avar 8y ago
I wrote a comment here over a year ago summarizing some of the state of it, it seems like there's been no changes since then: https://news.ycombinator.com/item?id=13885682 https://news.ycombinator.com/item?id=13885682
rauhl 8y ago
IMHO switching to Guile from C is moving in the wrong direction: rather than going from a poor-but-performant systems programming language like C to a pedagogic language like Scheme, it’d be a better idea to move to an rich-and-performant language meant for industrial systems programming like Common Lisp. Scheme’s a pretty little language, but it’s not meant for building large applications. Indeed, elisp’s weaknesses are IMHO mainly where it’s most akin to Scheme (e.g. its flat namespace). I also think it’d be a bad idea to make it too easy to write emacs extensions in anything but a Lisp, because that would fragment the ecosystem. If we’re going to replace elisp, it should be with a better Lisp, not with a lesser language (e.g. Lua, Python, Ruby … whatever). The great thing about a JIT is that we get a speedup without changing the actual implementation language or fragmenting the ecosystem.
- fusiongyro 8y ago
  The idea was to replace Emacs's embedded Elisp interpreter with Guile's, not to rewrite Emacs in Guile Scheme.
  - eadmund 8y ago
    Why not just replace Emacs's embedded elisp interpreter with one written in Common Lisp? CLOCC has a basic elisp interpreter already: https://sourceforge.net/p/clocc/hg/ci/default/tree/src/cllib/elisp.lisp https://sourceforge.net/p/clocc/hg/ci/default/tree/src/cllib... Take that, put a little work into it and one could presumably replace the C core of Emacs with Common Lisp.
    - melling 8y ago
      Stallman hates Common Lisp. https://www.gnu.org/gnu/rms-lisp.en.html https://www.gnu.org/gnu/rms-lisp.en.html
      - messe 8y ago
        > I implemented Common Lisp once on the Lisp machine, and I'm not all that happy with it. One thing I don't like terribly much is keyword arguments (8). They don't seem quite Lispy to me; I'll do it sometimes but I minimize the times when I do that. > [...] > So we started to make Scheme the standard extensibility language for GNU. Not Common Lisp, because it was too large. I'd hardly say he hates it based solely on that essay.
        kazinator 8y ago
        Wow, I so agree with that and the (8) footnote: "I don't mind if a very complex and heavyweight function takes keyword arguments. What bothers me is making simple basic functions such as “member” use them." I kept keyword arguments out of TXR Lisp. That is, out of the function call mechanism. It doesn't seem like a good idea to deal with a dictionary like mechanism in function calls. I invented something called "parameter list macros". A parameter list macro can be written which adds keyword argument ability to a function (and such a macro is provided). You can do (lambda (:key a b c -- x y) ...) and now you have keyword parameters x and y. They support the (sym dfl-val present-p) syntax and all. The :key parameter macro implements them via a source transformation. :key is able to rewrite both the parameter list and the body of the function to make this work. One reason Common Lisp programmers use keyword macros is that there is no way to invoke the default value of an optional parameter which precedes another optional parameter to which an argument is being specified. If a function has optional arguments X and Y, the caller cannot default X if it specifies Y. I fixed that in TXR Lisp: the symbol : (colon) can be passed to an optional parameter to activate its default value. So if a binary function f has two optional parameters we can invoke (f : 3) to default the first optional, and specify the second one as 3. This special feature is only supported in function calls, not in macro/destructuring parameter lists. That : symbol also serves as the &optional keyword, separating the required parameters from the optionals. It harmonizes with the consing dot that demarcates the &rest parameter: (lambda (x y : z w . r) ...): x y required, z w optional, r rest. The : symbol is nothing more than the symbol named "" (empty string) in the keyword package. It's provides a very useful third value to the nil and t duo. Common Lisps have this symbol! Unfortunately, they tend to print it funny back at you like :||, and neglect to get any mileage out of its notational convenience. As for those member functions, I provide a memq, memql and memqual that use the three different equalities. The more general member function takes a key and test function, but not as keyword arguments but positional optional parameters. If you want the default test, but custom key: [member foo bar : mykey].
- fasquoika 8y ago
  The Guile VM was deliberately designed to support multiple languages. Guile Emacs was an attempt to run Elisp on Guile's VM, not rewrite Emacs in Scheme. Guile's VM is also written in C FWIW
- codygman 8y ago
  > rather than going from a poor-but-performant systems programming language like C to a pedagogic language like Scheme, it’d be a better idea to move to an rich-and-performant language meant for industrial systems programming like Common Lisp.> Scheme’s a pretty little language, but it’s not meant for building large applications. Weren't people saying the same about python and Java long ago? How do you arrive at that conclusion? > Indeed, elisp’s weaknesses are IMHO mainly where it’s most akin to Scheme (e.g. its flat namespace) Racket at least wasnt flat iirc, is guile scheme? > The great thing about a JIT is that we get a speedup without changing the actual implementation language or fragmenting the ecosystem. Agreed.
  - rauhl 8y ago
    > > Scheme’s a pretty little language, but it’s not meant for building large applications. > Weren't people saying the same about python and Java long ago? I spent roughly a decade as a professional Python developer, and in retrospect I’d probably agree that it’s not well-suited to large applications. Why, exactly, is for another discussion. As for Java — it’s certainly not meant for building small ones! > How do you arrive at that conclusion? The same way that the Scheme committee did, when they came up with R6RS: by trying to use Scheme for large systems. It lacks features which aid building large systems (e.g. namespaces); it lacks features which enable building industrial-strength systems (e.g. the Lisp condition system or CLOS); it has features which make code more complex and tend to hinder performance (e.g. call/cc); and it even has a broken feature (dynamic-wind). Then there are things like: conflating functions, variables & all other names; breaking NIL into NIL, () & #f. Those are partly a matter of taste, but I think also an indication of Lisp’s pragmatic nature: in practice, doing things the Lisp way is better, even though in theory doing them the Scheme way is. > Racket at least wasnt flat iirc, is guile scheme? Racket isn’t Scheme anymore. That’s not a bad thing, and indeed Racket is pretty amazing. I wish that the same amount of effort had been expended making Lisp better, but everyone’s gotta scratch his own itch.
    - bjoli 8y ago
      Well, in guile you get goops which is pretty much a clone of clos, call/cc is being phased out in guile since delimited continuations are the new black, unwind-protect is not enough in a language where you have first class continuations so the complexity of dynimic-wind is needed. For your escape continuation needs you can implement unwind-protect and very easily abstract away the parts of dynamic-wind you don't need. The only thing missing is really the condition system, but that could be bolted on (that is the correct term) using continuations (preferably delimited). There is even a suggestion for r7rs-large to include them. I hope it gets voted in.
- bjoli 8y ago
  Guile Scheme is a pretty nice language. It is a superset of r6rs and probably provides att bigger stdlib than ansi CL (with a proper module system with all the introspection you are used to from CL) The reason for guile Emacs is that guile is the official extension language of the GNU project. It is a very capable implementation, and the elisp implementation is a lot cleaner than the one in Emacs. You would also gain a lot of features not available in elisp. proper threading (with both pthreads and fibers, delimited continuations, and much more). Not only that, you would get a runtime for elisp that works outside Emacs. Imagine being able to write programs and just load guile-org-mode and be able to script the org process without invoking Emacs.
josteink 8y ago
> I hate to be "that guy," but what happened to the Guile-Emacs project? Guile performs way better than Elisp too I’m sorry to be that guy, but did you ever try it out for yourself? Just starting Emacs took as long as a full regular Emacs elc-build, if not longer. So not exactly faster by a universal standard.
- fusiongyro 8y ago
  Guile being faster at running Elisp doesn't necessarily mean that Emacs + Guile is faster than Emacs. Is that why the project stalled out?
  - josteink 8y ago
    I think it was issues improving startup performance + largely that it was a one man show. It doesn’t take much to terminally derail an effort driven by only a single contributor.
- deleted 8y ago
  [deleted]
- nerdponx 8y ago
  How did swapping out the Elisp interpreter for a Guile interpreter hurt performance so bad? Seems like it should be a pretty benign change.
  - messe 8y ago
    Emacs pre-compiles byte code, I'd imagine that the guile version didn't do that by default.
  - tame73_binds 8y ago
    The work isn't finished, it runs but that's it. Comparisons aren't meaningful in the current state. Besides the bytecode thing, there was also an issue with string conversions that afair wasn't solved.
- jpfr 8y ago
fantispug 8y ago
I think the primary contributor stopped work on it, no one else took over, and most users don't perceive its benefits outweigh its switching costs.
tame73_binds 8y ago
Lack of volunteers.

rurban 8y ago

Too slow strings still

avar 8y ago

I wrote a comment here over a year ago summarizing some of the state of it, it seems like there's been no changes since then: https://news.ycombinator.com/item?id=13885682 https://news.ycombinator.com/item?id=13885682

rauhl 8y ago

IMHO switching to Guile from C is moving in the wrong direction: rather than going from a poor-but-performant systems programming language like C to a pedagogic language like Scheme, it’d be a better idea to move to an rich-and-performant language meant for industrial systems programming like Common Lisp. Scheme’s a pretty little language, but it’s not meant for building large applications. Indeed, elisp’s weaknesses are IMHO mainly where it’s most akin to Scheme (e.g. its flat namespace). I also think it’d be a bad idea to make it too easy to write emacs extensions in anything but a Lisp, because that would fragment the ecosystem. If we’re going to replace elisp, it should be with a better Lisp, not with a lesser language (e.g. Lua, Python, Ruby … whatever). The great thing about a JIT is that we get a speedup without changing the actual implementation language or fragmenting the ecosystem.

fusiongyro 8y ago
The idea was to replace Emacs's embedded Elisp interpreter with Guile's, not to rewrite Emacs in Guile Scheme.
- eadmund 8y ago
  Why not just replace Emacs's embedded elisp interpreter with one written in Common Lisp? CLOCC has a basic elisp interpreter already: https://sourceforge.net/p/clocc/hg/ci/default/tree/src/cllib/elisp.lisp https://sourceforge.net/p/clocc/hg/ci/default/tree/src/cllib... Take that, put a little work into it and one could presumably replace the C core of Emacs with Common Lisp.
  - melling 8y ago
    Stallman hates Common Lisp. https://www.gnu.org/gnu/rms-lisp.en.html https://www.gnu.org/gnu/rms-lisp.en.html
    - messe 8y ago
      > I implemented Common Lisp once on the Lisp machine, and I'm not all that happy with it. One thing I don't like terribly much is keyword arguments (8). They don't seem quite Lispy to me; I'll do it sometimes but I minimize the times when I do that. > [...] > So we started to make Scheme the standard extensibility language for GNU. Not Common Lisp, because it was too large. I'd hardly say he hates it based solely on that essay.
      - kazinator 8y ago
        Wow, I so agree with that and the (8) footnote: "I don't mind if a very complex and heavyweight function takes keyword arguments. What bothers me is making simple basic functions such as “member” use them." I kept keyword arguments out of TXR Lisp. That is, out of the function call mechanism. It doesn't seem like a good idea to deal with a dictionary like mechanism in function calls. I invented something called "parameter list macros". A parameter list macro can be written which adds keyword argument ability to a function (and such a macro is provided). You can do (lambda (:key a b c -- x y) ...) and now you have keyword parameters x and y. They support the (sym dfl-val present-p) syntax and all. The :key parameter macro implements them via a source transformation. :key is able to rewrite both the parameter list and the body of the function to make this work. One reason Common Lisp programmers use keyword macros is that there is no way to invoke the default value of an optional parameter which precedes another optional parameter to which an argument is being specified. If a function has optional arguments X and Y, the caller cannot default X if it specifies Y. I fixed that in TXR Lisp: the symbol : (colon) can be passed to an optional parameter to activate its default value. So if a binary function f has two optional parameters we can invoke (f : 3) to default the first optional, and specify the second one as 3. This special feature is only supported in function calls, not in macro/destructuring parameter lists. That : symbol also serves as the &optional keyword, separating the required parameters from the optionals. It harmonizes with the consing dot that demarcates the &rest parameter: (lambda (x y : z w . r) ...): x y required, z w optional, r rest. The : symbol is nothing more than the symbol named "" (empty string) in the keyword package. It's provides a very useful third value to the nil and t duo. Common Lisps have this symbol! Unfortunately, they tend to print it funny back at you like :||, and neglect to get any mileage out of its notational convenience. As for those member functions, I provide a memq, memql and memqual that use the three different equalities. The more general member function takes a key and test function, but not as keyword arguments but positional optional parameters. If you want the default test, but custom key: [member foo bar : mykey].
fasquoika 8y ago
The Guile VM was deliberately designed to support multiple languages. Guile Emacs was an attempt to run Elisp on Guile's VM, not rewrite Emacs in Scheme. Guile's VM is also written in C FWIW
codygman 8y ago
> rather than going from a poor-but-performant systems programming language like C to a pedagogic language like Scheme, it’d be a better idea to move to an rich-and-performant language meant for industrial systems programming like Common Lisp.> Scheme’s a pretty little language, but it’s not meant for building large applications. Weren't people saying the same about python and Java long ago? How do you arrive at that conclusion? > Indeed, elisp’s weaknesses are IMHO mainly where it’s most akin to Scheme (e.g. its flat namespace) Racket at least wasnt flat iirc, is guile scheme? > The great thing about a JIT is that we get a speedup without changing the actual implementation language or fragmenting the ecosystem. Agreed.
- rauhl 8y ago
  > > Scheme’s a pretty little language, but it’s not meant for building large applications. > Weren't people saying the same about python and Java long ago? I spent roughly a decade as a professional Python developer, and in retrospect I’d probably agree that it’s not well-suited to large applications. Why, exactly, is for another discussion. As for Java — it’s certainly not meant for building small ones! > How do you arrive at that conclusion? The same way that the Scheme committee did, when they came up with R6RS: by trying to use Scheme for large systems. It lacks features which aid building large systems (e.g. namespaces); it lacks features which enable building industrial-strength systems (e.g. the Lisp condition system or CLOS); it has features which make code more complex and tend to hinder performance (e.g. call/cc); and it even has a broken feature (dynamic-wind). Then there are things like: conflating functions, variables & all other names; breaking NIL into NIL, () & #f. Those are partly a matter of taste, but I think also an indication of Lisp’s pragmatic nature: in practice, doing things the Lisp way is better, even though in theory doing them the Scheme way is. > Racket at least wasnt flat iirc, is guile scheme? Racket isn’t Scheme anymore. That’s not a bad thing, and indeed Racket is pretty amazing. I wish that the same amount of effort had been expended making Lisp better, but everyone’s gotta scratch his own itch.
  - bjoli 8y ago
    Well, in guile you get goops which is pretty much a clone of clos, call/cc is being phased out in guile since delimited continuations are the new black, unwind-protect is not enough in a language where you have first class continuations so the complexity of dynimic-wind is needed. For your escape continuation needs you can implement unwind-protect and very easily abstract away the parts of dynamic-wind you don't need. The only thing missing is really the condition system, but that could be bolted on (that is the correct term) using continuations (preferably delimited). There is even a suggestion for r7rs-large to include them. I hope it gets voted in.
bjoli 8y ago
Guile Scheme is a pretty nice language. It is a superset of r6rs and probably provides att bigger stdlib than ansi CL (with a proper module system with all the introspection you are used to from CL) The reason for guile Emacs is that guile is the official extension language of the GNU project. It is a very capable implementation, and the elisp implementation is a lot cleaner than the one in Emacs. You would also gain a lot of features not available in elisp. proper threading (with both pthreads and fibers, delimited continuations, and much more). Not only that, you would get a runtime for elisp that works outside Emacs. Imagine being able to write programs and just load guile-org-mode and be able to script the org process without invoking Emacs.

josteink 8y ago

> I hate to be "that guy," but what happened to the Guile-Emacs project? Guile performs way better than Elisp too I’m sorry to be that guy, but did you ever try it out for yourself? Just starting Emacs took as long as a full regular Emacs elc-build, if not longer. So not exactly faster by a universal standard.

fusiongyro 8y ago
Guile being faster at running Elisp doesn't necessarily mean that Emacs + Guile is faster than Emacs. Is that why the project stalled out?
- josteink 8y ago
  I think it was issues improving startup performance + largely that it was a one man show. It doesn’t take much to terminally derail an effort driven by only a single contributor.
deleted 8y ago
[deleted]
nerdponx 8y ago
How did swapping out the Elisp interpreter for a Guile interpreter hurt performance so bad? Seems like it should be a pretty benign change.
- messe 8y ago
  Emacs pre-compiles byte code, I'd imagine that the guile version didn't do that by default.
- tame73_binds 8y ago
  The work isn't finished, it runs but that's it. Comparisons aren't meaningful in the current state. Besides the bytecode thing, there was also an issue with string conversions that afair wasn't solved.
jpfr 8y ago

fantispug 8y ago

I think the primary contributor stopped work on it, no one else took over, and most users don't perceive its benefits outweigh its switching costs.

tame73_binds 8y ago

Lack of volunteers.