REPL semantics

[Luís Marques]

On Thursday, 12 July 2018 at 21:51:18 UTC, aliak wrote:
> Cool, is there on going work to sprucing up the D repl in the 
> dlang-community repo or is this a new attempt? Either way if 
> something is happening here then awesome!

Ah, that explains why my clone of drepl didn't compile: it was 
the Martin Novak's repo, not the D community one. Although on 
macOS it still doesn't compile, because of the lack of 
_rt_loadLibrary.

Regarding your question: I was investigating this as part of my 
own D-related compiler efforts (DHDL stuff), but it won't 
materialize into a D repl anytime soon. I actually never tried 
the existing REPLs, what are your issues with them?

> As for your question, hard to say me thinks. On the one hand, 
> being able to do this is nice:
>
> const int i = 3;
> const int j = 4;
> void complexCalculation() { use i and j }
> complexCalculation() // uses 3 and 4
> const int j = 5;
> complexCalculation // uses the new j
>
> On the other hand being able to redefine the name "j" as some 
> other type to use in some other computation without having 
> `complexCalculation` get messed up is also nice :)

I hadn't even considered *redefining* symbols, only overloading. 
cling doesn't support redefining. Mmmm...

> Which is how the swift repl works:
>
>   1> func f(_ a: Float) { print("f") }
>   2> f(3)
> f
>   3> func f(_ a: Int) { print("i") }
>   4> f(3)
> i
>   5> func foo(_ a: Float) { print("f") }
>   6> func bar() { print(foo(3)) }
>   7> bar()
> f
>   8> func foo(_ a: Int) { print("i") }
>   9> bar()
> f

Yeah, I had tried basically the same Swift example. But my point 
stands: I think that behavior can be explained by ease of 
implementation. Finding an example of the alternative would be 
much more interesting. Lacking that we are going to have to 
actually *think* about the problem ;-)

The examples with the dynamic languages are less relevant.