Live data from Hacker News

What makes a good REPL?

vvvvalvalval.github.io

161–170 of 177 posts

Re: What makes a good REPL?

#161

Earlier quoted context omitted.

I think there may be some confusion here, immutability is about the stability of values (e.g. I have a string, list, map etc and I want to pass it to others, view its value, make changes without affecting the original value). Immutability is not the same as rebinding a name (in clojure at least) e.g. the following is perfectly valid (global and local binding of the same name repeatedly) (def a 1) (def a 2) (def a 3)…

For a global def to be a "rebinding" rather than assignment is crippling. It means that previous references to a still see the old thing, which is wrong if you want them to see the new thing.

Clojure does not rebind the reference, it just changes it to point to something else. So it does not suffer from what you describe. Previous references will see the new thing as you'd hope.

So def on an existing binding does assignment. That's what is meant by "re-binding".

Re: What makes a good REPL?

#162
post #138

Earlier quoted context omitted.

Yes that's me :) >> 2. Tests can only ever answer close-ended questions: "does this work?", but not "how does this work?", "what does this look like?" etc. > I fail to understand this point. I mean you can obviously write tests that just run stuff and not throw an exception or error. Furthermore you can share how you set stuff up with other developers.... and again you can just delete it if its obnoxious. Yes, but th…

> It's not that the environment is custom, is that it's real. Do you call your payment service or your mail sending service from your tests? This is exactly the kind of thing you want to experiment with in a supervised, non-repeatable way. The irony you mentioning that is I have actually written "tests" that call braintree and stripe... Just to clarify when I say "test" I don't mean some precise definition of "unit t…

> I think in large part of what your saying is good about REPLs is that they allow hot code swapping but that is only IMO really one part of the REPL. The key to really good REPL should be human input (think Excel) and human output (think images and graphs).

I definitely could have spent more time on this part in the article. You may want to have a look at Proto-REPL (https://atom.io/packages/proto-repl), which is one of Clojure's REPLs (for the Atom editor)

Re: What makes a good REPL?

#163
post #160

Earlier quoted context omitted.

For a global def to be a "rebinding" rather than assignment is crippling. It means that previous references to a still see the old thing, which is wrong if you want them to see the new thing.

If you want others to see the new thing automatically, you need something much more powerful than plain old assignment anyway: something which will let you pick a synchronization strategy. "Changes at any arbitrary time, including when you are halfway through reading it" is not in any way a sound synchronization strategy and the only thing you get with assignment. You seem to understand the important difference betwe…

[deleted]

Re: What makes a good REPL?

#164
post #135

Earlier quoted context omitted.

That's the converse of my point. The article claimed immutable data is important for a good REPL and I said that the claim was an overstatement. I didn't say that immutable data makes a REPL impossible. I quite like immutable datastructures, as it happens.

I was replying that LISP doesn't have immutable data structures.

Common Lisp has some immutable data structure such as, oh, numbers. If you arithmetically encode a record of data into a bignum integer, that is immutable.

Re: What makes a good REPL?

#165
post #160

Earlier quoted context omitted.

For a global def to be a "rebinding" rather than assignment is crippling. It means that previous references to a still see the old thing, which is wrong if you want them to see the new thing.

If you want others to see the new thing automatically, you need something much more powerful than plain old assignment anyway: something which will let you pick a synchronization strategy. "Changes at any arbitrary time, including when you are halfway through reading it" is not in any way a sound synchronization strategy and the only thing you get with assignment. You seem to understand the important difference betwe…

> you need something much more powerful than plain old assignment anyway: something which will let you pick a synchronization strategy.

Right, just like the king's subjects don't actually need a toaster, but rather breakfast food cooker.

Re: What makes a good REPL?

#166

Earlier quoted context omitted.

For a global def to be a "rebinding" rather than assignment is crippling. It means that previous references to a still see the old thing, which is wrong if you want them to see the new thing.

Clojure does not rebind the reference, it just changes it to point to something else. So it does not suffer from what you describe. Previous references will see the new thing as you'd hope. So def on an existing binding does assignment. That's what is meant by "re-binding".

[deleted]

Re: What makes a good REPL?

#167
post #102

Earlier quoted context omitted.

Some languages have immutable bindings too, where you only shadow previous bindings.

If you can shadow previous bindings then that would also cause no problem for repl re-usage, unless the shadowing syntax is different to the binding syntax. Either way, unrelated to the point in the article about the advantage of immutable values for repl, not immutable bindings. I would certainly agree that truly immutable bindings would be at best quite a stumbling block for repls, but so far no one was advocating…

> so far no one was advocating for them as a good repl feature

GHCi has this feature, if you explicitly turn it on (-fwarn-name-shadowning with -Werror). I agree that it's not a terribly useful way to run a REPL.

Re: What makes a good REPL?

#168
post #130
post #126

Earlier quoted context omitted.

I wonder how do that. I'm building a language that truly will benefit for a REPL (is for database development) but also do it compiled simplified other things. Is done on .NET/F#. I wonder how architect the thing so I can have a good repl yet compiled... but how?

Since more than a few language implementations already do things like that, I'm inclined to say that's more or less a solved problem.

Yeah, but I have not find a resource that explain how is done.

Re: What makes a good REPL?

#169

Take a look at Smalltalk's environment and take a look a t Common Lisp's REPL. They have all the features that make for a good 'REPL'. (As noted before, REPL is a Lisp term that stands for: read - from keyboard input, parse the input string into the syntactic structure of the language eval - eval the expression, this includes binding variables or defining new functions, also re-defining functions, even if such functi…

> Common Lisp's REPL The SBCL and CCL REPLs do not support readline-style editing. This actually makes them infuriating to use outside of Emacs or some other IDE-like environment. There is definitely a market for a high-quality, implementation-independent Lisp REPL.

> The SBCL and CCL REPLs do not support readline-style editing. This actually makes them infuriating to use outside of Emacs

TL;DR: I fail to see how this can be a problem.

Yes, but they do work fine inside Emacs (or perhaps inside other IDEs), and if i was using the SBCL command-line and needed readline-style-editing, then it was because I'm developing or debugging, so I'd be inside Emacs (or other IDE) in the first place...

Re: What makes a good REPL?

#170
post #114

Earlier quoted context omitted.

> in Lisp all expressions evaluate to something Minor nitpick, but note that if you define: (defun foo () (values)) Then (foo) does not return a value and accordingly, the REPL prints nothing. But in a context where you need a value, that value would be NIL: if A evaluates to 3, then after (setf a (foo)) it will evaluate to NIL.

According to a famous epigram by Alan Perlis, Lisp programmers know "the value of everything, but the cost of nothing". It reflects the expectation that a language which calls itself Lisp is expected to produce a value out of any expression which evaluates. Though Common Lisp adds the nuance of multiple values, the behavior you describe is how it conforms to this general expectation. Code written in an everything-rea…

> Scheme, a Lisp-like language, allows some evaluable expressions to have an "undefined" or "unspecified" result value.

That's why they are heretics !!

(Just joking of course... Scheme is the other great Lisp dialect.)

Post reply on HN