REPL semantics

[aliak00]

On Thursday, 12 July 2018 at 22:17:29 UTC, Luís Marques wrote:
> 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?

Ah I see. Last I remember it was just too buggy to use so it 
caused more pain than pleasure :p I don't remember the exact 
details though sorry.

>
>> 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.

We can try and think:

So if we think of adding an overload as "redefining a name" then 
is it fair to generalize the question to: "should redefining 
symbol A affect any previously defined symbol B that was 
dependent on the previous definition of A?"

And then I'd say that defining an overload of symbol A is 
technically a redefining of A - i.e. it's semantics change.

Redefinition affects:
+ Can change functionality of B without having to redefine all of 
it
- Can cause things to stop working silently (think a tree of 
hidden dependencies)

Redefinition does not affect:
+ The last defined symbol works "as expected"
- Must redefine symbols if you want them to use redefined 
dependent definitions.

I think changing the value of a variable should affect any 
dependent definitions, while redefining a variable should not 
affect dependent symbols - an appeal to predicability is what I'm 
going for.

And I think defining an overload falls under redefining a symbol.

Or you can also have the best of both worlds if you allow a 
special repl annotation before any definitinons - @dynamic on 
symbol A can mean that redefining it will affect dependent 
Symbols for e.g.

Haskell's GHCi repl does the same as swift (with redefining 
symbols at least, don't think it supports overloading in the 
imperative language sense of the term). Though I think that makes 
the most sense for haskell being a pure language.

Cheers,
- Ali