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