On Thursday, 12 July 2018 at 22:17:29 UTC, Luís Marques wrote:
>
> I actually never tried the existing REPLs, what are your issues with them?

No Windows support.

For drepl:
"Works on any OS with full shared library support by DMD (currently linux, OSX, and FreeBSD)."

On Friday, 13 July 2018 at 02:26:28 UTC, jmh530 wrote:

> No Windows support.
>
> For drepl:
> "Works on any OS with full shared library support by DMD (currently linux, OSX, and FreeBSD)."

For macOS that means using LDC.

--
/Jacob Carlborg

On Thursday, 12 July 2018 at 22:17:29 UTC, Luís Marques wrote:

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

Have you considered using LDC and JIT? [1] [2]. Found this [3] snippet as well, not sure what it is.

[1] https://github.com/ldc-developers/ldc/pull/2293
[2] https://github.com/ldc-developers/ldc/releases/tag/v1.8.0 (mentions something called EasyJIT)
[3] https://gist.github.com/eldar/2294388

--
/Jacob Carlborg

On Friday, 13 July 2018 at 06:22:41 UTC, Jacob Carlborg wrote:
> On Friday, 13 July 2018 at 02:26:28 UTC, jmh530 wrote:
>
>> No Windows support.
>>
>> For drepl:
>> "Works on any OS with full shared library support by DMD (currently linux, OSX, and FreeBSD)."
>
> For macOS that means using LDC.

It doesn't seem to work with LDC on macOS either:

$ dub --compiler=ldc2
(...)
Undefined symbols for architecture x86_64:
  "_rt_loadLibrary", referenced from:
      __D4core7runtime7Runtime__T11loadLibraryZQoFxAaZPv in drepl.o
ld: symbol(s) not found for architecture x86_64

On Friday, 13 July 2018 at 06:27:08 UTC, Jacob Carlborg wrote:
> Have you considered using LDC and JIT? [1] [2]. Found this [3] snippet as well, not sure what it is.
>
> [1] https://github.com/ldc-developers/ldc/pull/2293
> [2] https://github.com/ldc-developers/ldc/releases/tag/v1.8.0 (mentions something called EasyJIT)
> [3] https://gist.github.com/eldar/2294388

I just wanted to know what the REPL semantics were, not so much actually use the REPL day to day. For my DHDL stuff I don't think the LDC JIT particularly applies, it's more source code translation stuff.

On Friday, 13 July 2018 at 16:20:03 UTC, Luís Marques wrote:
> On Friday, 13 July 2018 at 06:22:41 UTC, Jacob Carlborg wrote:
>> On Friday, 13 July 2018 at 02:26:28 UTC, jmh530 wrote:
>>
>>> No Windows support.
>>>
>>> For drepl:
>>> "Works on any OS with full shared library support by DMD (currently linux, OSX, and FreeBSD)."
>>
>> For macOS that means using LDC.
>
> It doesn't seem to work with LDC on macOS either:
>
> $ dub --compiler=ldc2
> (...)
> Undefined symbols for architecture x86_64:
>   "_rt_loadLibrary", referenced from:
>       __D4core7runtime7Runtime__T11loadLibraryZQoFxAaZPv in drepl.o
> ld: symbol(s) not found for architecture x86_64

Did you try the Docker image?

On Friday, 13 July 2018 at 16:55:27 UTC, Seb wrote:
> Did you try the Docker image?

No, I just ran it on my Ubuntu VM. Is it important that I try? I was just providing feedback that it doesn't seem to run with LDC either.

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