REPL semantics

aliak something at something.com
Thu Jul 12 21:51:18 UTC 2018


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





More information about the Digitalmars-d mailing list