Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GNU Guile 2.2.0

gnu.org

Post reply on HN
Print view View original

21–30 of 149 posts

Re: GNU Guile 2.2.0

#21

Post by ArneBab »

andrewvijay wrote: post #4

Why are those brackets there in the syntax? What's the need? It looks hard to read when the programs are bigger. Is there any super advantage to it?

The super advantage of Lisp (including Scheme): Its format for defining data is the same as for writing code, making macros a natural part of the syntax: You can change your source code just like you’d change any other list (or rather tree) data type.

However all this can be represented fully without parentheses — and this is possible with Guile using a reader extension without losing any of its power. This is realized, for example, in wisp — a language frontend for Guile: http://www.draketo.de/english/wisp

It’s a full Scheme, but without the parentheses (behind the scenes it simply infers the parentheses, adds them and hands the result to the regular Scheme frontend in Guile).

Wisp is also standardized as Scheme Request For Implementation 119: https://srfi.schemers.org/srfi-119/srfi-119.html

    display "Hello World!" ↦ (display "Hello World!")
In short: I think this question is justified. But there are many people who start preferring parentheses when they get over the initial readability barrier.

Re: GNU Guile 2.2.0

#23

Post by pmoriarty »

avar wrote: post #20

For those excited about the "Guile's Elisp implementation" in this release. The last major Guile release was 6 years ago, and much of this GuileEmacs work is still highly WIP and from my searching on emacs-devel seems to have stalled in 2015 for lack of volunteers. Just because Guile implements Elisp the language doesn't mean there isn't a ton of work to be done on Emacs itself to swap out its native VM for Guile, an…

What's left to be done?

Re: GNU Guile 2.2.0

#24

Post by davexunit »

This release has been a long time coming and I'm happy that the day has finally arrived. There's a small patch of mine in this release (my first compiler hack ever) that optimizes comparison operations for floating point numbers. If anyone is interested in hacking on compilers, I highly recommend checking out Guile as one of the easier points of entry into the space. Andy Wingo, the author, even wrote up a blog post with plenty of project ideas to improve things: http://wingolog.org/archives/2016/02/04/guile-compiler-tasks

Re: GNU Guile 2.2.0

#26

Post by clappski »

pkd wrote: post #15

For me this is the most exciting part: Complete Emacs-compatible Elisp implementation Thanks to the work of Robin Templeton, Guile's Elisp implementation is now fully Emacs-compatible, implementing all of Elisp's features and quirks in the same way as the editor we know and love. This means we can finally have a proper GuileEmacs!

This is fantastic news. Are there any other major roadblocks for GuileEmacs?

Re: GNU Guile 2.2.0

#27

Post by davexunit »

To try out Guile 2.2.0 easily from any GNU/Linux distro (from the full release notes):

    Bonus track!  This release also contains a new experiment, a binary
    installation package for the x86_64 architecture.
    
    The GNU Guix project (https://guixsd.org/) has assembled a graph of
    package definitions (for example, GCC, glibc, Guile, and so on) and is
    able to build that graph in an entirely deterministic way starting
    from only a handful of trusted bootstrap binaries.  Guix recently
    added a "guix pack" facility that can export build products from a
    Guix system, including all run-time dependencies.
    
    We have used the new "guix pack" to generate an experimental binary
    distribution for the Guile 2.2.0 release.  If you are on an x86_64
    system running GNU/Linux, begin by running the following commands:
    
      wget https://ftp.gnu.org/gnu/guile/guile-2.2.0-pack-x86_64-linux-gnu.tar.lz
      wget 
    https://ftp.gnu.org/gnu/guile/guile-2.2.0-pack-x86_64-linux-gnu.tar.lz.sig
      gpg --verify guile-2.2.0-pack-x86_64-linux-gnu.tar.lz.sig
    
    If verification fails, then see above for instructions on how to
    import the appropriate GPG key.  For reference, the pack's sha256sum
    is:
    
      c707b9cf6f97ecca3a4e3e704e62b83f95f1aec28ed1535f5d0a1d36af07a015  
    guile-2.2.0-pack-x86_64-linux-gnu.tar.lz
    
    Then in your root directory -- yes! -- do:
    
      cd /
      sudo tar xvf path/to/guile-2.2.0-pack-x86_64-linux-gnu.tar.lz
    
    This tarball will extract some paths into /gnu/store and also add a
    /opt/guile-2.2.0 symlink.  To run Guile, just invoke:
    
      /opt/guile-2.2.0/bin/guile
    
    Voilà!

Re: GNU Guile 2.2.0

#28

Post by zurn »

andrewvijay wrote: post #4

Why are those brackets there in the syntax? What's the need? It looks hard to read when the programs are bigger. Is there any super advantage to it?

Many programming languages use braces, parentheses and brackets to convey structure.

Javascript and C do it this way:

  if (foo) {
    bar(42, zonk());
  }
Guile/Clojure/etc do it this way:

  (if foo
   (bar 42 (zonk)))
If you didn't have the separators, programs would be harder to interpret for compilers and human readers, as it's harder to tell what the programmer meant from just

  if foo 
   bar 42 zonk

Re: GNU Guile 2.2.0

#29

Post by Koshkin »

andrewvijay wrote: post #4

Why are those brackets there in the syntax? What's the need? It looks hard to read when the programs are bigger. Is there any super advantage to it?

This "problem" is not unique to Lisps. Quite often, when I look at a piece of code written in C++, especially when it uses lambda functions inside calls, I can't help asking myself why there are so many brackets (and whether a Lisp would be a better alternative to C++, syntax-wise).

The syntax of the lambda itself in C++ is sort of funny: it requires to use all the bracket types at the same time!

  [](){}

Re: GNU Guile 2.2.0

#30

Post by Slackwise »

ArneBab wrote: post #21
andrewvijay wrote: post #4

Why are those brackets there in the syntax? What's the need? It looks hard to read when the programs are bigger. Is there any super advantage to it?

The super advantage of Lisp (including Scheme): Its format for defining data is the same as for writing code, making macros a natural part of the syntax: You can change your source code just like you’d change any other list (or rather tree) data type. However all this can be represented fully without parentheses — and this is possible with Guile using a reader extension without losing any of its power. This is realiz…

As a simpler solution, making brackets a lighter color so they don't stand out as much. Works really well.
Post reply on HN