Live data from Hacker News

Perchance to Scheme (2016)

hardmath123.github.io

21–30 of 82 posts

Re: Perchance to Scheme (2016)

#21
> Clojurescript.... Personally, I don’t like it on a matter of principle: I don’t like things that compile to JavaScript. It doesn’t seem like anything you really need to write better code.

Maybe I don't understand what the alternative is when you want to write client side code for the browser - js?? I use Clojurescript and find clear benefits.

By way of example I often found the general setTimeout functionality to be a nightmare for scheduling delays. Most of the time it works, but periodically I find it blocks or fails (via a dependancy chain) and then have to spend time arranging code abnormally to mitigate. In clojurescipt I use core async.

  (defn timeout [ms]
    (let [c (async/chan)]
      (js/setTimeout (fn [] (async/close! c)) ms)
     c))
Never looked back. Never had a delay problem - Ever.

cljs core.async and many other features have made it so much more enjoyable to write client side code. Don't even get me started on callbacks.

> Oh, and one last thing. I feel it’s obligatory at this point for me to say, please don’t spend too much time researching Scheme dialects. Just pick Racket and start coding

I've had the opposite experience so thanks, but no thanks.

Re: Perchance to Scheme (2016)

#24
post #22
post #11

Emacs Lisp is most certainly not a Scheme.

The plan is to replace Emacs Lisp with Guile, which is a Scheme: https://www.emacswiki.org/emacs/GuileEmacs

No, that's not the plan. The plan is to replace the Emacs Lisp runtime with a Guile-based runtime.

See here: 'is a branch of GNU Emacs that replaces Emacs’s own EmacsLisp engine with the Elisp compiler of Guile.'

The word is 'ENGINE'. That's the underlying language runtime.

It's neither GNU Emacs right now, nor will Emacs Lisp be replaced.

Re: Perchance to Scheme (2016)

#25
post #16

> ClojureScript is a compiler from Clojure to JavaScript (Clojure originally targeted Java). It is not a Scheme dialect, not does it feel like one. It’s a LISP dialect. Hell no. The linked website, http://wiki.c2.com/?LispSchemeDifferences lists differences between Common Lisp and Scheme. Clojure is not a Common Lisp implementation.

Clojure(Script) is neither a Scheme nor an implementation of Common Lisp but is a LISP dialect. LISP dialect languages are simply a group of lisp-like language not just implementations of Common Lisp. https://en.m.wikipedia.org/wiki/List_of_Lisp-family_programm...

I personally can't consider Clojure as a lisp dialect. According to McCarthy, lisp is built on top of five fundamental primitives: CONS, CAR, CDR, EQ, and ATOM. Excepting for EQ, Clojure has none of these or define them differently than the other lisp dialects, breaking the inter-compatibility of the core language.

Re: Perchance to Scheme (2016)

#26
post #24
post #22

Earlier quoted context omitted.

The plan is to replace Emacs Lisp with Guile, which is a Scheme: https://www.emacswiki.org/emacs/GuileEmacs

No, that's not the plan. The plan is to replace the Emacs Lisp runtime with a Guile-based runtime. See here: 'is a branch of GNU Emacs that replaces Emacs’s own EmacsLisp engine with the Elisp compiler of Guile.' The word is 'ENGINE'. That's the underlying language runtime. It's neither GNU Emacs right now, nor will Emacs Lisp be replaced.

I thought that project is perennially under development, and at this point in time more like good thing to look at than having a real chance of getting merged with master?

Re: Perchance to Scheme (2016)

#27

A minor update: Now Chez Scheme is open source (Apache license) https://github.com/cisco/chezscheme

Racket is now integrating the best parts of Chez Scheme, for a future release.

Racket-on-Chez will be considerably slower than vanilla Chez - Racket semantics incur some overhead. Here are some rough benchmarks from a year ago:

http://blog.racket-lang.org/2018/01/racket-on-chez-status.ht...

Re: Perchance to Scheme (2016)

#28
post #12

I am guilty of writing my own Scheme (R5RS) interpreter as well, and a key takeaway from the experience was that many things calling themselves Scheme interpreters are missing core parts of Scheme. Implementing a language that resembles Scheme is quite easy. Implementing call-with-current-continuation and hygienic macros AND getting the tricky little details correct is not.[0] An analogy might be someone offering "ab…

Call/cc is pretty simple to implement depending on how you chose to represent your scheme code. Using CPS call/cc is trivial.

Hygienic macros are however never trivial. It is so many kinds of tricky, and together with the nice debugability of macros you find yourself in a nice place.

Re: Perchance to Scheme (2016)

#29
post #26
post #24

Earlier quoted context omitted.

No, that's not the plan. The plan is to replace the Emacs Lisp runtime with a Guile-based runtime. See here: 'is a branch of GNU Emacs that replaces Emacs’s own EmacsLisp engine with the Elisp compiler of Guile.' The word is 'ENGINE'. That's the underlying language runtime. It's neither GNU Emacs right now, nor will Emacs Lisp be replaced.

I thought that project is perennially under development, and at this point in time more like good thing to look at than having a real chance of getting merged with master?

Probably. ;-)

Re: Perchance to Scheme (2016)

#30
Alternatively - you can choose to program in Common Lisp - an industrial strength language that has been demonstrated in large projects like the QPX flight search engine (Google Flights).

For anyone who doesn't know - a big difference that Common Lisp brings to the table is that it has separate namespaces for variables and functions. This may not sound like much but it makes it much easier to write macros (code that writes code) and facilitates compile-time computing.

Another big difference between Scheme and Common Lisp is that the Common Lisp specification is _much_ larger and it comes with a much larger collection of standard built-in functions and macros and a standard object-oriented programming facility, among many other things.

I know this because I've spent the last six years implementing Clasp (github.com/clasp-developers/clasp) - a Common Lisp that interoperates with C++ and uses LLVM as the backend. There are several excellent implementations of Common Lisp - Steel Bank Common Lisp is a great place to start.

Post reply on HN