Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Programming GNU is Not Unix

Two Years of GNU Guile Scheme 2.0 107

Posted by Unknown Lamer from the better-lisp-for-a-better-tomorrow dept.
Two years ago Guile Scheme, the official extension language of the GNU project, released version 2.0, a major upgrade to the implementation. As part of the two year anniversary, the maintainers organized a challenge to hack a small project using Guile in 30 days as part of a birthday software potluck. The two coolest dishes appear to be OpenGL support using the FFI, and XCB bindings built using the XML specification for XCB: "guile-xcb is a language implemented in the Guile VM that parses the XML files used by the xcb project to specify the X protocol and compiles them into Guile modules containing all the methods and data needed to send requests to the X server and receive replies/events back. If new X extensions are added to the xcb library, guile-xcb can compile and add them with no additional work. " See the release announcement for details on the other dishes.
This discussion has been archived. No new comments can be posted.

Two Years of GNU Guile Scheme 2.0 More

Two Years of GNU Guile Scheme 2.0

Comments Filter:

  • Guile supports curly-infix, too! (Score:5, Interesting)

    by dwheeler ( 321049 ) on Wednesday February 20, 2013 @11:27AM (#42955677) Homepage Journal
    Another cool thing about GNU guile is that the most recent version supports SRFI-105, "curly-infix-expressions" [schemers.org], as developed by the Readable Lisp S-expressions Project [sourceforge.net]. Curly-infix expressions let you write stuff like {a + b} instead of (+ a b), which is a big improvement in readability.

    • Re: (Score:2, Insightful)

      by Anonymous Coward

      Correct me if I'm wrong, but wouldn't that break the fact that in Lisp everything is supposed to be a list? In (+ a b) it's clear to both user and interpreter what the first member of the list is, but with {a + b} the interpreter may know what is what, but the user no longer sees firsthand that the s-expression is a list like any other. The key to groking Lisp is to learn to think recursively like the interpreter, and I would think that this change in notation unhealthily forces thinking patterns derived fr

      • Re:Guile supports curly-infix, too! (Score:4, Insightful)

        by cduffy ( 652 ) <charles+slashdot@dyfis.net> on Wednesday February 20, 2013 @11:52AM (#42955935)

        Correct me if I'm wrong, but wouldn't that break the fact that in Lisp everything is supposed to be a list?

        Plenty of LISPs break that "rule", and usually for the better. Clojure wouldn't be the tremendously practical and useful language it is if it didn't have vectors, maps, queues, and the like.

        What's important is that the language retains isomorphism (and thus, LISP's full measure of metaprogramming power) -- as long as your parse tree and your code map 1:1, adding some additional types does no harm and a world of good.

        • Curly-infix-expressions (as well as sweet-expressions, which are a superset) are just additional abbreviations. In curly-infix, the surrounding "{...}" indicate that it's a list, but that parameters are written in a different order than they are actually stored. So {a + b + c} is just (+ a b c). We're now wrapping up sweet-expression notation, which is a superset that uses syntactically-relevant indentation (like Python). Check out http://readable.sourceforge.net/ [sourceforge.net] for more info, and in particular, pleas

          • Re: (Score:1)

            by Anonymous Coward

            From that page I see that they make the same error as Python, to allow both spaces and tabs for indentation (however I don't see any specification how tabs are treated). That's a great recipe for hard to find bugs (because you literally don't see the difference between spaces and tabs). Especially given the fact that different people tend to use different tab sizes (while traditionally a tab goes to the next multiple of 8 characters, nowadays it is usually configurable, and people do configure it).

            • There's no problem. You can use spaces or tabs, but you HAVE to be consistent when you use one or the other. So if you indent a line with a tab, all sibling and child lines MUST start with a tab... multiple spaces don't count. You can even mix, but you still have to be consistent, so if you use tab space space, all later siblings and child lines must start with tab space space.

              • There's no problem. You can use spaces or tabs, but you HAVE to be consistent when you use one or the other. So if you indent a line with a tab, all sibling and child lines MUST start with a tab... multiple spaces don't count. You can even mix, but you still have to be consistent, so if you use tab space space, all later siblings and child lines must start with tab space space.

                So what happens if I start the next line with spaces?

              • This fails in practice. I don't do Python so I don't know how they solve it, but when I used Occam it was a major hassle. Problem one was that youc ould not visually see the difference between spaces and tabs and very few editors enable this (no fair using language specific editors. Additionally once you have multiple programmers touching the same file it all goes to hell, because everyone has a different notion about spaces vs tabs and tab width. Similarly, it's a pain in the ass in Makefiles, it's a

                • Actually, it turns out there's no problem.

                  The tools require consistency, and report an error where it's not. Then if you are a tab-only person, you can use tabs. If you are a spaces-only person, you can use spaces. If you try to use them inconsistently (tab on one line, where space was used on the previous line), then it reports an error.

                  Notice that this is COMPLETELY DIFFERENT from Makefiles. The problem with Makefiles is that there are cases where you can't tell where an error is, and so it quiet

                  • Actually, it turns out there's no problem.

                    Actually, it turns out that there is a big problem.

                    The tools require consistency, and report an error where it's not. Then if you are a tab-only person, you can use tabs. If you are a spaces-only person, you can use spaces.

                    That's nice, but not everyone is a lone coder working on toy projects of no relevance which never get maintained by other devs. Here in the real world it's rare to find a single source file for even tiny (but real, not toy) projects that hasn't been touched upon by at least three different people over the course of three years.

                    Hell, in one system I worked on, the original comments in the source code dated from 1992 when the code was written for some 8-bit

              • Re: (Score:2)

                by Raenex ( 947668 )

                You can even mix, but you still have to be consistent, so if you use tab space space, all later siblings and child lines must start with tab space space.

                Speaking from experience on development teams, this still leads to problems when you have to look at the code and your editor treats the tabs differently. Allowing mixing of tabs and spaces is a really horrible idea.

      • The curly syntax can be purely lexically transformed to normal s-expressions. E.g. {x + y} turns directly into (+ x y) as soon as it's read in, before it's even evaluated as code. So homoiconicity is retained and there is absolutely no problem. You can read SRFI-105 or look at the "Sweet Expressions" project yourself to see the details of how exactly things work, and what the limitations are. (Hint: It does NOT save you from learning the true underlying prefix-notation, it's merely a convenience for when yo

      • Re: (Score:2)

        by Hentes ( 2461350 )

        As long as the braces are implemented with a macro, that's not a problem.

        • Actually, the braces are implemented in the reader. In Common Lisp terminology, they can be implemented as a "reader macro", but this is a completely different step than the Lisp "macros" usually refer to. This means that you can use {...} with data or code, and you can even use them as inputs to macros (in the usual sense). Thus, you can combine Scheme's "define-syntax" with {...} without problems. The SRFI-105 spec has some examples you might want to look at.

      • You should read John McCarthy's original lisp paper sometime. He used m(eta)-expressions -- eg, +[a, b] -- rather than s-expressions. S-expression evaluation was implemented first and now you're stuck with it.

      • Re: (Score:2)

        by tibit ( 1762298 )

        Lists are general but poorly performing data structures. Modern Lisps aren't all about lists at all. They have multiple data types.

    • RPN is scarey! (Score:1)

      by Anonymous Coward

      RPN has always scared people. It's why HP calculators don't dominate the market.

      • RPN has always scared people. It's why HP calculators don't dominate the market.

        Scheme (and Lisp) uses prefix notation, i.e. the operation symbol + comes first, (+2 2). Reverse polish notation, also known as postfix notation, the operation symbol comes last, (2 2 +).

    • Re: (Score:1)

      by Anonymous Coward

      (is
      (about 'GNU guile' (another 'cool thing'))
      (support 'most recent version' (clarification (clarify 'SRFI-105'

      • Re: (Score:1)

        by semios ( 146723 )

        {{(another 'cool thing') about 'GNU guile' } is
        {'most recent version' supports
        (clarification (clarify 'SRFI-105'
        (developed 'Readable Lisp S-expressions Project')

    • Re: (Score:3)

      by rmstar ( 114746 )

      For Common Lisp there is the "infix" package, which you can just load as part of your program. You can write infix using a #i() reader macro. Thus, #i(1+1) is equivalent to (+ 1 1), etc.

      Programmers that use Lisp or Scheme for a while end up using plain prefix. The percieved inconvenience of prefix notation is due to not being used to it. After a while you realize that prefix notation is a lot more readable and less error-prone than infix.

      • "Programmers that use Lisp or Scheme for a while end up using plain prefix."

        Sure, for those few programmers who keep using (Common) Lisp or Scheme. But almost all developers say, "what, no infix?", and ignore or stop using Lisps. And those who stick around find that it's hard to use infix in most Lisps today because there's no standard mechanism for using it. We're working to fix that, while keeping Lisp homoiconic and general.

        The percieved inconvenience of prefix notation is due to not being used to i

        • Re: (Score:2)

          by jbolden ( 176878 )

          I use Haskell which has infix and prefix and does a pretty good job of letting your pass between the two

          i.e. you can take infix star and write ((*) 2 3) for (2*3)
          and you can take prefix f (a `f` b) for (f a b)

          That being said what makes LISP, LISP is the complete lack of syntactic structures that parsing is trivial. The fact that you can write in a LISP evaluator in a few hundred lines and thus whip up a DSL inside of anything is what makes LISP. I don't mind curly braces. I don't mind Clojures additions

    • A real lisper would find (+ a b) to be easier to read and less ambiguous. This is similar to someone going to the HP calculator fans and telling them that you have a patch to allow it to work like a TI calculator, they're just not going to be impressed. The real reason perhaps is that people want to get rid of what they mistakenly think are redundant parentheses, however in order to do that you dont need infix what you really need is operator precedence, and that's an ugly bag of worms with no business ap

  • Emacs and Guile need each other (Score:3, Interesting)

    by Anonymous Coward on Wednesday February 20, 2013 @11:28AM (#42955683)
    I've wanted to get into Lisp, but it's frustrating that my everyday GNU environment is split between Guile and Emacs Lisp. I wish that the project, talked about for years, to rewrite Emacs and base it on Guile would take off. It would save Guile, in a sense, because in spite of Scheme's status as the official GNU extension language it tends to be overlooked, and Emacs would benefit greatly from the bindings already developed for Guile.

    • Re:Emacs and Guile need each other (Score:5, Informative)

      by Unknown Lamer ( 78415 ) Works for Slashdot <clinton@nOSPAm.unknownlamer.org> on Wednesday February 20, 2013 @11:36AM (#42955763) Homepage Journal

      It's close to being reality [hcoop.net]. Guile has an Emacs-Lisp compiler to its VM that can run actual elisp programs, but lacks... the emacs part. And last summer's GSoC (perhaps this summer, finishing it?) saw emacs's lisp interpreter ported to guile... as in, the C representations of Emacs's internal data types and control structures are done using libguile. The code is currently being rebased on the latest emacs trunk; hopefully it'll see public release sooner than later.

      Now the two pieces just have to meet in the middle.

      So that's the first 95%. Now just for the other 95%!

    • I dunno, I still prefer Lisps with good old fashioned dynamic scoping (aka, special variables). Scheme is statically scoped and thus can be a very different style of programiming. Not that there's a whole lot of stuff in Emacs still that uses dynamic scoping, it would just feel wrong to kill off the last bastion of that style. I haven't used Guile much but I always got the impression that it was bulkier than Emacs Lisp (but then most FSF projects seem to bulk up fast, ala GNU Hello World).

      • Guile has fluids, which give you similar behavior as dynamic scoping without forcing the costs of dynamic scoping on all code. Emacs Lisp actually has optional lexical scope now, and a lot of stuff is converting to use it because it's proven to reduce code errors and runtime overhead. That, and you can't use dynamically scoped bindings to pass information between threads (a serious limitation in Emacs's implementation).

        Obviously, fluids have their place in something like Emacs where the cost of breaking abs

        • So Guile isn't as tiny a scheme as the stereotype. There used to be two ends of the spectrum; pure simple scheme that's trimmed down versus all-the-features Common Lisp (which has special variables).

    • One goal does not need to interfere with the other. Emacs Lisp and Scheme are trivial to learn. Scheme is a more of a general purpose programming language. It's trivial to learn (see HERE [neu.edu])It's also worth learning simply because one of the best CS books, the SICP [mit.edu], is using Scheme. As for Emacs Lisp, I don't see a need to get very deeply into. Scheme is nicer and more simple. Emacs Lisp is the language much of emacs is written in as well as its modules. Unless you have in mind writing Emacs modules, picking

      • Re: (Score:2)

        by jbolden ( 176878 )

        If by mainstream you mean professional. Common Lisp stagnated and until Clojure there really wasn't a LISP with professional libraries. The LISP community all during the 1980s and 1990s simply didn't want to make the compromises needed to have a mainstream language. I think that in many ways Haskell has taken the role that LISP used to play in terms of language of the future.

        If by mainstream you mean educational. It is a pity. Racket is fantastic for educational scheme. The AP exam is based on Java, b

        • Common Lisp only had a few years of stagnation... It more suffered from being a decade ahead of its time so folks took "you can still run code from 1995 in the aughts" as a sign of decay instead of stability. Of course, it never really did regain the GUI capabilities (except for Clozure on OS X) the proprietary stuff had since the whole compiler/tools industry just collapsed suddenly.

          I've used CL professionally, and I'd put it on par with C++ for that... powerful, well supported, without the annoyances of J

          • Re: (Score:2)

            by jbolden ( 176878 )

            I don't know about that. QuickLisp may have solved so of this but the situation was bad for many years. Have you gone through something like Perl or Java library collections to see what a full set of libraries looks like? It isn't just GUI is it everything.

            A far as IDEs, yeah it is a problem for most non static languages. The static Algol based languages have the best IDEs. Clojure has fairly good support because of its ties to the Java community, you might want to check that out. I keep my eye on htt [leksah.org]

    • > I wish that the project, talked about for years, to rewrite Emacs and base it on Guile would take off. It would save Guile

      Exactly, and this is exactly its problem. It is not the Emacs people who are pushing this rewrite, but the guile people. in order to get a "killer app" as a vehicle to advertize Guile, because nobody else wants to write a killer app in guile from scratch.

      Of course, Emacs would benefit from an vastly improved Elisp engine too, but my feeling is that the usual Emacs users actually do

  • Scheme rocks, but lost the race (Score:3)

    by WaywardGeek ( 1480513 ) on Wednesday February 20, 2013 @11:31AM (#42955715) Journal

    I love Scheme. I even wrote my own scheme interpreter way back and used it as the embedded control language in QuickLogic's P&R tools. However, only software geeks like Scheme, making it a terrible language for tool control for anything but software dev tools. TCL beat the heck out of Scheme in terms of popularity for this purpose. Python beat the heck out of Scheme as well. Perl got adopted by the text mashing crowd. Also, Guile, at least in the 1.0 version had issues. For example, it really wanted to have main in it's code, while your entire application was something it called. TCL has a better architecture for embedding. Anyway, this is nice, but I don't personally see a significant future for Scheme.

    • Re: (Score:1)

      by Anonymous Coward

      I've seen a lot of higher-order and first-class written in Python, but I've always been able to model semantic flows in LISP and Scheme faster. Half of what people need in that kind of model could be done in Prolog, and the rest could be done in OCaml or Haskell; however, how many commercial shops have more than a token programmer who might have a dusty tome of such arcane knowledge?

      Different OSes, programming languages, methodologies, techniques for different problem domains.

      Diversity is good. Monocultur

      • Monoculture is pervasive. Sometimes it shows up just with all the currently popular language following the same old style with just minor variants in syntax. You get a batch of developers all used to Java or C++ or Python and so every new language they create just can't help but resemble that style. There just aren't that many programmers any more who have used languages that are radically different from that style, much less many programmers who are experts in those languages. We need more devs who are

        • I'm just guessing that you and I are of a similar age (I'm 49). Ken McElvain said that Lisp ruined me. Even when coding in C, I program in Lisp. I love Prolog, and wrote a tiny version of it at one point. I never learned Smalltalk, and suspect I missed out on something huge, but I love Forth and of course had to write my own version. As for Fortran, my first programming job was in Fortran IV. Some of the most brilliant people I've ever known are physicists who continue to program in Fortran to this da

    • I think TCL really broke things. I was used to ARexx when it came out and it was vastly simpler to embed than TCL, and TCL felt always like it wanted to be in control (the thing you accuse Guile of doing).

    • Anyway, this is nice, but I don't personally see a significant future for Scheme.

      Never say never.. Back in 2000 I thought JavaScript was just an insignificant programming language for adding simple dynamics to a web page, like drop down menus, validating input, etc, a web designer's tool, not a serious coders tool, and see how things have turned out. JS is probably now one of the hottest programming languages, despite all the drawbacks. Next, who could have imagined a Lisp dialect (Scala) running on top of

      • Scala is on the bubble for being a mainstream language. I'm personally very excited about it. I wouldn't call it a Lisp dialect... just highly lisp influenced. However, I'm totally ignorant of Scala's history. Lisp lives on in many languages.

      • Duh, I just accidentally wrote Clojure instead of Scala. Those two somehow crossed in my mind, both being JVM languages, as I was writing this.

  • Lame joke alert! (Score:1)

    by Anonymous Coward

    I guess Guile Scheme...
    (puts on sunglasses)
    does go with everything.

Slashdot Top Deals

One man's constant is another man's variable. -- A.J. Perlis

Close