Hacker News Reader

Comment by rekado | Hacker News Reader

We have Guix as a system configuration/package manager, the GNU Shepherd as an init, and the GuixSD initrd itself, all of which are written in Guile Scheme.

With the GNU Hurd important parts of the OS could be written in Scheme as well.

The problems start with the desktop, where we don't really have anything that's well-integrated and lispy. Sure, there's StumpWM (Common Lisp), and there's Emacs, but they are separate programmes and there's no link between them.

There is McCLIM[1], a GUI toolkit which looks like a continuation of lisp machine ideas, but as far as I know it does not have an active community (unlike Guix and Guile, whose communities actively work on a Scheme-powered operating system).

[1]: https://common-lisp.net/project/mcclim/excite.html

View on HN

Sadly the GUI world seems uninterested in that kind of "interactivity". Instead they keep taking away options and in general dumbing down the UIs with the belief that this will make computers more approachable for the masses.

But at that point, why bother? Build a games console or a cable TV box with a web browser and call it a day...

I really wish the GNU project would standardise on Common Lisp rather than Scheme. Lisp-2, false NIL, full-powered macros — Common Lisp has a lot going for it.

An emacs written in Common Lisp, running in StumpWM, running atop a CL Guix, Shepherd & GuixSD would be a thing of beauty.

Stallman does not like Common Lisp.

I wonder if he really liked Lisp Machine Lisp or ZetaLisp.

That's what he has used and IIRC he claims to have implemented CL.

But if you see what was missing in elisp: object system, closures, keyword arguments, ... That stuff was also in LML.

I know, but I just don't get it. Common Lisp sure feels closer to elisp than Scheme does, and I'm constantly missing things from Common Lisp when I'm writing elisp (e.g. read macros, packages or character as a type distinct from integers).

For me, at least, elisp just feels like a primitive Common Lisp while Scheme feels like a completely different language with a similar surface syntax.

My take: he did not like the added complexity in CL compared to Maclisp or even simpler Lisps. I doubt he is a big believer in Scheme either.

> Lisp-2, false NIL, full-powered macros — Common Lisp has a lot going for it.

Heh, I find none of these things desirable :) I guess some people are just wired differently. I prefer a single namespace for all values, #F as the only false value, and (optionally) hygienic macros with syntax-case (which does not prevent traditional macros of the defmacro kind).

What's the current take of the Scheme community on syntax-case? Last I looked it was not in R7RS...

It's not in r7rs small, but t will probably find it's way into r7rs large:

http://trac.sacrideo.us/wg/wiki/YellowDocket

The thing that tends to push me into agreement is that common lisp is compiled whereas scheme/guile is bytecode. If we want to use lisp for OS purposes I think it needs to be compiled for the speed benefits. Is there any other lisp or similar language that is compiled?

Maybe I just irrationally don't trust bytecode vm's.

Scheme can be compiled. https://github.com/cisco/ChezScheme

I don't think the distinction is helpful. Guile Scheme is in fact compiled, and the resulting binary is in ELF format. It's still bytecode for the Guile VM, but this does not allow any inference on performance.

I did not know that, thank you for the correction, it certainly opens me up more to scheme. There are a handful of tools that use it that I really want to dig into (gnu mcron for example), but I've been trying to decide if its worth the time investment.

>Lisp-2, false NIL, full-powered macros — Common Lisp has a lot going for it.

I agree, however my reasons for going towards Common Lisp vs Scheme wouldn't really be those, but basically that important stuff is already standardized, proven and documented (i.e. conditions&restarts, object oriented system), while on the Scheme world they are left to "roll your own" status.

I'd say Scheme is a great language for learning and exploring, while CL is a better choice for creating production software.

I don't get the obsession with defmacro vs syntax case. Defmacro can be implemented in syntax case in about 10 lines, whereas the power of syntax-case is very much non-trivial to implement in CL.

I understand that R7RS got rid of syntax-case and standard Scheme is back to syntax-rules only (which is another thing I like about Common Lisp: the standard has been in existence for 23 years).

I'm reminded of this article (https://fare.livejournal.com/189741.html), where this Common Lisp macro:

    (defmacro nest (&rest r) (reduce (lambda (o i) `(,@o ,i)) r :from-end t))

Has to turn into this in Racket (which isn't quite Scheme):

    (define-syntax (nest stx)
      (syntax-case stx ()
        ((nest outer ... inner)
         (foldr (lambda (o i)
                  (with-syntax (((outer ...) o)
                                (inner i))
                    #'(outer ... inner)))
                #'inner (syntax->list #'(outer ...))))))

And was incredibly difficult to reason about. And that author likes Racket.

The Scheme community obsessed over macro hygiene since the 1970's. Yet as of 1997, Scheme still had no error handling mechanism. The R5RS spec spoke about situations which perpetrate an "error", without defining what an error is, how an error can be caught, how an error can be programmatically generated at will, or even whether the image can continue running when an error occurs. (Yeah, macro hygiene will somehow save your project that is confounded by hacks to work around the lack of error handling!)

I'm not going to sit here re-evaluating Scheme, year by year, to see whether it's up to snuff yet.

Someone drop me an e-mail when Scheme gets a well-defined, left-to-right evaluation order, and when its imperative forms all return a stable value like #f or whatever.

R7rs small is a language in the spirit of r5rs. R5rs large will have a specified low level macro facility, probably syntax-case in one form or the other.

The smaller standard does not specify a low level macro facility. That doesn't mean that an implementation won't have one. No scheme has syntax-rules only.

I agree that the defmacro is simpler, but nobody said otherwise. The nest macro is more or less perfect for defmacro since it doesn't need hygiene.

If defmacro is so Important, there are several schemes with it out there, and if you really need it it is trivially implemented using low level hygienic macro facilities.

How do you describe the semantics of `nest` without showing the implementation?

    (define-syntax nest
      (syntax-rules ()
        ((nest x) x)
        ((nest x ... (y ...) z) (nest x ... (y ... z)))))

That one is quadratic according to the author, but for 1050 expands of a nest with 6 levels it is less than 10% slower. Whereas in chez scheme, the difference is even less (for more than 2000 expansions)

Edit: Decided to stress test the chez scheme macro expader. for 30000 expansions, it was under 1s using the syntax-case version. I'd say that is very much good enough.

The MCCLIM community is somewhat active, but very small...

Reply on news.ycombinator.com