www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - REPL semantics

reply =?UTF-8?B?THXDrXM=?= Marques <luis luismarques.eu> writes:
Consider a D REPL session like this:


 void bar(long x) { writeln(x); }



 void foo() { bar(42); }


42


 void bar(int) {}


Assuming implementation complexity is not an issue, what do you 
feel is the more natural semantics for a REPL? Should foo now 
call bar(int), or should it still call bar(long)? (feel free to 
generalize the issue)

I was curious to see what the existing REPLs did, but they seem 
to have bit rotted and no longer compile.
Jul 12 2018
next sibling parent =?UTF-8?B?THXDrXM=?= Marques <luis luismarques.eu> writes:
On Thursday, 12 July 2018 at 19:07:15 UTC, Luís Marques wrote:

 Assuming implementation complexity is not an issue, what do you 
 feel is the more natural semantics for a REPL? Should foo now 
 call bar(int), or should it still call bar(long)? (feel free to 
 generalize the issue)


BTW, this succeeds:

     long foo(long x) { return x; }
     enum x = foo(42);
     mixin("int foo(int x) { return x-1; }");
     enum y = foo(7);
     static assert(x == 42);
     static assert(y == 6);

...but is it guaranteed by the spec? Alternatives: 1) 
implementation-defined ordering (of the mixin and the enums), 
possibly different than the existing frontend; 2) 
non-deterministic ordering, can change from one compiler run to 
another.
Jul 12 2018
prev sibling next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Thursday, 12 July 2018 at 19:07:15 UTC, Luís Marques wrote:

 Consider a D REPL session like this:


 void bar(long x) { writeln(x); }



 void foo() { bar(42); }


 42


 void bar(int) {}


 Assuming implementation complexity is not an issue, what do you 
 feel is the more natural semantics for a REPL? Should foo now 
 call bar(int), or should it still call bar(long)? (feel free to 
 generalize the issue)

 I was curious to see what the existing REPLs did, but they seem 
 to have bit rotted and no longer compile.


Most REPLs I've used are for languages with dynamic typing. 
Perhaps take a look at a C REPL and see what it does?
Jul 12 2018
parent reply =?UTF-8?B?THXDrXM=?= Marques <luis luismarques.eu> writes:
On Thursday, 12 July 2018 at 20:33:04 UTC, jmh530 wrote:

 On Thursday, 12 July 2018 at 19:07:15 UTC, Luís Marques wrote:
 Most REPLs I've used are for languages with dynamic typing. 
 Perhaps take a look at a C REPL and see what it does?


Well, cling calls the original function:

[cling]$ #import <stdio.h>
[cling]$ void foo(long x) { printf("long\n"); }
[cling]$ void bar() { foo(42); }
[cling]$ void foo(int x) { printf("int\n"); }
[cling]$ bar()
long

...but to me that doesn't mean much. If it was the other way 
around (bar was updated to call foo(int)) I think I could safely 
conclude that it was an intended consequence. But the actual 
behavior can easily be explained by the fact that that's the most 
straightforward implementation (especially for a REPL that uses 
an existing C++ frontend, like clang). I was looking for a more 
fundamental answer: what would the user prefer to happen?
Jul 12 2018
next sibling parent reply aliak <something something.com> writes:
On Thursday, 12 July 2018 at 21:15:46 UTC, Luís Marques wrote:

 On Thursday, 12 July 2018 at 20:33:04 UTC, jmh530 wrote:

 On Thursday, 12 July 2018 at 19:07:15 UTC, Luís Marques wrote:
 Most REPLs I've used are for languages with dynamic typing. 
 Perhaps take a look at a C REPL and see what it does?


 Well, cling calls the original function:

 [cling]$ #import <stdio.h>
 [cling]$ void foo(long x) { printf("long\n"); }
 [cling]$ void bar() { foo(42); }
 [cling]$ void foo(int x) { printf("int\n"); }
 [cling]$ bar()
 long

 ...but to me that doesn't mean much. If it was the other way 
 around (bar was updated to call foo(int)) I think I could 
 safely conclude that it was an intended consequence. But the 
 actual behavior can easily be explained by the fact that that's 
 the most straightforward implementation (especially for a REPL 
 that uses an existing C++ frontend, like clang). I was looking 
 for a more fundamental answer: what would the user prefer to 
 happen?


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!

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 :)

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

For reference, this is from node and ruby but not with overloads 
since there's no function overloading: They use the current state 
of the source it seems.


 var i = 3;


undefined

 function f() { console.log(i); }


undefined

 f()


3
undefined

 var i = 4;


undefined

 f()


4
undefined

Ruby:

2.4.0 :002 > def f0() 3 end
  => :f0
2.4.0 :003 > f0()
  => 3
2.4.0 :004 > def f1() f0() end
  => :f1
2.4.0 :005 > f1()
  => 3
2.4.0 :006 > def f0() 4 end
  => :f0
2.4.0 :007 > f1()
  => 4
2.4.0 :008 >



Cheers,
- Ali
Jul 12 2018
parent reply =?UTF-8?B?THXDrXM=?= Marques <luis luismarques.eu> writes:
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.
Jul 12 2018
next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
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)."
Jul 12 2018
parent reply Jacob Carlborg <doob me.com> writes:
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
Jul 12 2018
parent reply =?UTF-8?B?THXDrXM=?= Marques <luis luismarques.eu> writes:
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
Jul 13 2018
parent reply Seb <seb wilzba.ch> writes:
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?
Jul 13 2018
parent =?UTF-8?B?THXDrXM=?= Marques <luis luismarques.eu> writes:
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.
Jul 13 2018
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
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
Jul 12 2018
parent =?UTF-8?B?THXDrXM=?= Marques <luis luismarques.eu> writes:
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.
Jul 13 2018
prev sibling parent aliak00 <something something.com> writes:
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
Jul 16 2018
prev sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Thursday, 12 July 2018 at 21:15:46 UTC, Luís Marques wrote:

 On Thursday, 12 July 2018 at 20:33:04 UTC, jmh530 wrote:

 On Thursday, 12 July 2018 at 19:07:15 UTC, Luís Marques wrote:
 Most REPLs I've used are for languages with dynamic typing. 
 Perhaps take a look at a C REPL and see what it does?


 Well, cling calls the original function:

 [cling]$ #import <stdio.h>
 [cling]$ void foo(long x) { printf("long\n"); }
 [cling]$ void bar() { foo(42); }
 [cling]$ void foo(int x) { printf("int\n"); }
 [cling]$ bar()
 long

 ...but to me that doesn't mean much. If it was the other way 
 around (bar was updated to call foo(int)) I think I could 
 safely conclude that it was an intended consequence. But the 
 actual behavior can easily be explained by the fact that that's 
 the most straightforward implementation (especially for a REPL 
 that uses an existing C++ frontend, like clang). I was looking 
 for a more fundamental answer: what would the user prefer to 
 happen?


I think most people, at least most people who have used REPLs 
before, would think that the above should print int. But this is 
because most REPLs are used with dynamic languages. I don't doubt 
that it makes sense that it is easier to implement such that it 
prints long. You're compiling each line as it comes in, so bar 
compiles to some machine code that can only depend on the 
definition of foo at the time it is compiled.

I think the mental model of someone coming from a dynamic 
language would be as if bar is dynamically re-compiled when the 
foo(int x) is entered.
Jul 12 2018
parent reply =?UTF-8?B?THXDrXM=?= Marques <luis luismarques.eu> writes:
On Thursday, 12 July 2018 at 22:04:39 UTC, jmh530 wrote:

 I think the mental model of someone coming from a dynamic 
 language would be as if bar is dynamically re-compiled when the 
 foo(int x) is entered.


Right. Hopefully there aren't too many weird cases once that is 
generalized to other corners of the language. I also never used 
REPLs for major development, only for debugging and minor tests, 
so I don't have experience with that style of development where 
you code everything in the REPL and then save the whole state, 
which makes it harder for me to evaluate how important certain 
REPL features are.
Jul 12 2018
parent jmh530 <john.michael.hall gmail.com> writes:
On Thursday, 12 July 2018 at 22:24:19 UTC, Luís Marques wrote:

 Right. Hopefully there aren't too many weird cases once that is 
 generalized to other corners of the language. I also never used 
 REPLs for major development, only for debugging and minor 
 tests, so I don't have experience with that style of 
 development where you code everything in the REPL and then save 
 the whole state, which makes it harder for me to evaluate how 
 important certain REPL features are.


I primarily use REPL's for prototyping. It just makes some things 
much easier. So for instance, I can load up some functions and 
libraries and data and then run a bunch of different statistics 
models without needing to compile everything again. I can also 
plot everything as needed without needed to compile everything 
all over again.
Jul 12 2018
prev sibling parent =?UTF-8?B?THXDrXM=?= Marques <luis luismarques.eu> writes:
On Thursday, 12 July 2018 at 19:07:15 UTC, Luís Marques wrote:

 Consider a D REPL session like this:


Unlike cling, drepl doesn't seem to support overloading:

Welcome to D REPL.
D> import std.stdio;
std
D> void bar(long) { writeln("long"); }
bar
D> void bar(int) { writeln("int"); }
bar
D> bar(42)
`_mod2.bar` at /tmp/drepl.adse9Q/_mod2.d(3) conflicts with 
`_mod1.bar` at /tmp/drepl.adse9Q/_mod1.d(3)
template `std.stdio.write` cannot deduce function from argument 
types `!()(void)`, candidates are:
/usr/include/dmd/phobos/std/stdio.d(3669):        
`std.stdio.write(T...)(T args) if (!is(T[0] : File))`

It can envision the implementation that produces that result, and 
in terms of that implementation it makes sense, but ouch, that's 
not user friendly or in-line with regular D semantics.
Jul 12 2018