On Friday, 10 June 2016 at 15:35:32 UTC, jmh530 wrote:
> On Friday, 10 June 2016 at 15:14:02 UTC, ketmar wrote:
>> 1. this is heavily OT. ;-)
>
> I didn't forget to mark it! :-)

Well, yeah, we should start a new thread, but compiler programming isn't really off topic at all on a forum where we talk about programming a compiler! Knowing the idea helps reading dmd source too.

On Friday, 10 June 2016 at 15:03:30 UTC, jmh530 wrote:
> Let's say you have something simple like 1+2, you would build an AST that looks something like
>    +
>   / \
>  1   2
> What would be the next step?

https://github.com/adamdruppe/arsd/blob/master/script.d#L879

The function is pretty simple: interpret the left hand side (here it is 1, so it yields int(1)), interpret the right hand side (yields int(2)), combine them with the operator ("+") and return the result.

Notice that interpreting the left hand side is a recursive call to the interpret function - it can be arbitrarily complex, and the recursion will go all the way down, then all the way back up to get the value.

On Friday, 10 June 2016 at 15:29:01 UTC, Chris wrote:
> But seriously, would you like to work on something like DScript. Your scripting language already fulfills things that were on my wishlist (easy D interop).

I'm best when working on something that I'm actively using, since then I find the bugs myself and have some personal thing to gain (a lot of times, I can take time out of the day job to do it then, since it contributes directly back to it)...

and alas, right now, I'm not actively using it. I do have some plans for it, but no set schedule.

That said though, it is already fairly useful... if you guys use it and report bugs/feature requests, I can probably respond to that.

On Tue, 2016-06-07 at 15:15 +0000, Chris via Digitalmars-d wrote:
> 
[…]
> Java has lambdas now (since version 8, I think) and I read
> somewhere that it's not certain that Java programmers will adopt
> (i.e. use) them at all. D has the advantage that its users are
> […]

Whatever you read, the writer didn't really know what they were talking about. At least not in general, and if they were talking of the Javaverse as a whole. Java 8 features such as lambda expressions, Streams, method references, etc. are no longer even controversial. There is a world-wide activity in transforming Java 6 and Java 7 code to Java 8. Yes some of this is pull rather than push, and I am sure there are islands of intransigence (*). However the bulk of Java programmers will eventually get and use the features.

Of course many people have stopped using Java and use Kotlin, Ceylon, or Scala (**). The crucial point here is that the Javaverse is much, much more than just the Java language.


(*) Usually people who think Java 5 was a bad move and stick with Java
1.4.2.

(**) There are others but these are the main players.

-- 

Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Friday, 10 June 2016 at 15:30:19 UTC, Wyatt wrote:
>> globals.write = &(writeln!string);
>
> Woah, I never thought of using it like that!

Yeah, since writeln is a template, you need to instantiate it with some arguments. This isn't the ideal way to do it in the script btw, it'd be like:

globals.write = (var this_, var[] args) { writeln(args); };

or something like that - this signature gives a variadic function to the scripting language, whereas writeln!string just has a single argument.

But, of course, the script language cannot instantiate D templates itself, so you gotta do that before assigning it to the runtime var. But from there, the jsvar.d reflection code will handle the rest of var<->string conversions.

> I use it in my toml parser and it's very pleasant.  I figured it probably isn't very fast, but it works and that's important.

kewl! Did you use the script component for interpreting or just the jsvar part for the data?

On Friday, 10 June 2016 at 15:27:03 UTC, Jonathan M Davis wrote:
> Most developers have titles like "Software Engineer" or "Senior Softweer Engineer." They'e frequently called programmers and/or software developers when not talking about titles.

Neither academia or businesses use Computer Scientist as a job title... tough?

> Yeah. Most universities in the US have a Computer Science degree, but some have Software Engineering as a separate degree. My college had Computer Science, Software Engineer, and Computer Engineering, which is atypical. All of them took practical courses, but the SE guys didn't have to take some of the more theoretical stuff and instead took additional classes focused on working on projects in teams and whatnot.

Sounds like a good setup. At my uni we could pick freely what courses we wanted each semester, but needed a certain combination of fields and topics to get a specific degree. Like for entering computer science you would need the most feared topic, Program Verification taught by Ole-Johan Dahl (co-creator of Simula) who was very formal on the blackboard... I felt it was useless at the time, but there are some insights you have to be force-fed... only to be appreciated later in life. It is useless, but still insightful.

Not sure if those more narrow programs are doing their students a favour, as often times the hardest part is getting a good intuition for the basics of a topic, while getting the "expert" knowledge for a specific task is comparatively easier. Especially now we have the web. So, being "forced" to learning the basics of a wider field is useful.

I'm rather sceptical of choosing C++ as a language for instance. Seems like you would end up wasting a lot of time on trivia and end up students hating programming...

On Friday, 10 June 2016 at 17:10:39 UTC, Adam D. Ruppe wrote:
> On Friday, 10 June 2016 at 15:30:19 UTC, Wyatt wrote:
>> I use it in my toml parser and it's very pleasant.  I figured it probably isn't very fast, but it works and that's important.
>
> kewl! Did you use the script component for interpreting or just the jsvar part for the data?

Just the jsvar; I've got a Ppegged grammar mixin doing most of the heavy lifting.  IIRC, you actually wrote it around the time I was fighting a losing battle with nested Variant arrays and it saved me a lot of headache.

-Wyatt

On Friday, 10 June 2016 at 17:02:06 UTC, Adam D. Ruppe wrote:
>
> https://github.com/adamdruppe/arsd/blob/master/script.d#L879
>
> The function is pretty simple: interpret the left hand side (here it is 1, so it yields int(1)), interpret the right hand side (yields int(2)), combine them with the operator ("+") and return the result.
>
> Notice that interpreting the left hand side is a recursive call to the interpret function - it can be arbitrarily complex, and the recursion will go all the way down, then all the way back up to get the value.

Ah, it produces mixin("1+2") and evaluates that.

What's the PrototypeObject sc I see everywhere doing?

On Friday, 10 June 2016 at 17:36:02 UTC, jmh530 wrote:
> Ah, it produces mixin("1+2") and evaluates that.

Sort of, 1 and 2 are both runtime variables there so it really produces mixin("a+b") after setting a = 1 and b = 2 above.

But yeah, that's the idea - it just hoists that mixin to runtime for scripting.

> What's the PrototypeObject sc I see everywhere doing?

sc is short for "scope" - it refers to the chain of local variables. So consider the following:

var a = 1;
function foo() {
  var b = 4;
  var c = a + b;
}

foo();


So as this is interpreted by my thing, it is like it runs the following D code:

// this happens as part of the interpreter initialization
auto globalScope = new PrototypeObject(globals_the_d_programmer_passed);

// now it starts running
auto currentScope = globalScope;

// var a = 1;
currentScope["a"] = 1; // it holds the local variables!


call_function("foo", []); // script foo();

// when we enter the new scope inside the function, it
// creates a new object, based on the old one
currentScope = new PrototypeObject(currentScope);

// var b = 4;
currentScope["b"] = 4; // remember the scope changed above, so this is local to the function now

// var c = a + b;
currentScope["c"] = currentScope["a"] + currentScope["b"];

/*
  OK, so at this point, we get two variables: a and b. That's
  what the sc object in the script.d source represents - what
  I called currentScope here.

  The opIndex does two things: check the current scope for the
  name. If it is there, return that value. If not, go up to
  the parent scope and look there. Continue until you find it,
  of if it isn't there, throw a "no such variable" exception.

  It'd find b in the current scope and return the
  function-local variable, and it'd find a in the parent scope.
*/

// and now that the function is over, we pop off the local
// variables from the function by setting the current back
// to the old parent
currentScope = currentScope.parent;



So yeah, the sc in the interpreter is just the currentScope from the pseudocode, a chain of AAs holding the local variables.

On Friday, 10 June 2016 at 17:59:15 UTC, Adam D. Ruppe wrote:
>> What's the PrototypeObject sc I see everywhere doing?
>
> sc is short for "scope" - it refers to the chain of local variables. So consider the following:
> [snip]

Cool. Thanks.