Hacker News Reader

Comment by mark_l_watson | Hacker News Reader

I have written books on Common Lisp and Scheme. Their power feature to me is the combination of functional programming (functions without side effects) and how these small functions can be built bottom-up in an interactive repl. Other languages like Python and Ruby also support repl style development, but aren't sufficiently functional. A little off topic, but I am working on a commercial product (KGcreator, a tool for generating graph data for knowledge graphs) and started prototyping in both Racket and Haskell. It was a tough call but I chose Haskell. I think of Haskell as being another Lisp language that also supports repl style development.

View on HN

I love Haskell, but as far as GHC goes, its REPL story is awful: your environment doesn't even survive loading a new file! You can ask it to replay your bindings, but that's a pretty crappy solution, likely to produce unpredictable errors and, if you're doing any serious computation (such as when theorem proving), it's probably useless.

Compare this to a language like Ocaml, where I have worked at the exact same REPL, modifying the same environment, for months at a time.

This was such a standard thing to do in the Lisp and ML worlds that these languages traditionally include a save-lisp-and-die function which saves your entire runtime to disk so it can be reloaded later. (We used DMTCP in Ocaml for the same effect).

Not to moan too much. Haskell is still my favourite language. I just wish it had a decent REPL.

Isn't the lack of a stateful REPL a feature in Haskell? Don't get my wrong, I love image/state-based developing (having working knowledge with SmallTalk and just getting into emacs). But I think it is quite haskelly to introduce functions that create the state rather than create the state interactively yourself. This should be good for mocking and tests also. Yes, this is more work than in most other practical languages, but this is Haskell for you ;)

Tell us more about your books. I'm addicted to scheme books :-)

Also, what made you choose Haskell for your project? Can you share some of the reasoning?

I think the deployment story for Haskell is better than Racket. It is easy enough make standalone Racket executables but with stack and cabal it is baked in to easily build multiple executables, separate libraries, keep everything tidy.

Racket is much better to get something done and working quickly. Same comment for Common Lisp.

Haskell has great support for strongly types web services (servant) and lots of great libraries. Racket has a very rich ecosystem of libraries, custom languages (like Typed Racket). Both are great.

EDIT: It takes me longer to get to working code in Haskell but once written the code has higher value to me because it is so much faster/easier to refactor, change APIs, reuse in other projects, etc. I just did a major refactoring/code-tidying this morning, and it was very simple to do.

See Mark’s books here [1]

[1]: http://markwatson.com/books/

> functional programming (functions without side effects)

CL has mutable data structures(lists are mutable by default) and setf etc. Scheme/Clojure makes a much pleasant functional programming without side effects experience.

RxRS Scheme has mutable conses as well. One of the reasons Racket isn’t called MzScheme anymore is that its primitive conses are immutable (iirc)

Immutable cons cells also lets Racket implement a constant time `list?`, which is kind of nice.

https://docs.racket-lang.org/reference/pairs.html?q=list?#%2...

This doesn’t require immutable conses if you just update the cache whenever the cdr is mutated.

If the last cdr in a list is modified, then you need to propagate that change up to the front of the list during that modification, or check the whole list when you run `list?`. Either way, you pay linear time for it.

Only if the new value makes it no longer a list (or changes a dotted list into a real list). My hunch is that this would, in normal usages, work out to constant time (setf (cdr foo) ...) with the occasional (setf (cdr foo) atom) requiring the change in state to be propagated in linear time.

It's not only if the new cdr is an atom that the whole thing becomes a non-list. It remains a list if and only if the new cdr is a list. There are non-atom non-lists that could render it a non-list, but more disturbing is the case where the new cdr is a list until the modification is performed. If the cdr is modified to create a cycle, the the new cdr is a list right up until the point that modification is actually performed. The new cdr only ceases to be a list after the modification. So that's a really hairy situation. Note also that the cons cell being modified could belong to any number of lists or non-lists, not just one, so propagating through a change could be much worse than linear time in practice depending on what's being done. (Not to mention that propagating state the wrong direction through a chain of cons cells is itself a mess...)

Immutable cons cells eliminates all of this. If a cons cell is created with a list cdr, it will always be a list. If a cons cell is created with anything but a list as the cdr, it will never be a list. Very straight forward. You don't have to worry about linear time or worse propagations, and you don't need to anticipate what some other programmer down the line will consider "normal usage".

For a much better experience programming functionally in Common Lisp, try the FSet functional collections library: https://github.com/slburson/fset

Reply on news.ycombinator.com