[WIP/feedbacks] Add magic constants

[minirop]

Disclaimer: it's more to have feedbacks/tweaks (e.g. on the syntax) or ideas (e.g. of new constants) than actually get this PR merged "as-is".

Hello there,

Many languages have a way to print the current filename or the current line (like the C preprocessor with __FILE__ and __LINE__). So I told to myself "why not add them to wren?" and went with the same syntax.

Since the filename is not known from the VM, I chose to print the module name. So now you have __LINE__ and __MODULE__.

Here's some code with what is printed when you do wren test.wren:

mymod.wren:

var func = Fn.new {
	System.print("inside module: " + __MODULE__ + " on line " + __LINE__.toString)
}

test.wren:

var x = __LINE__
System.print(x.toString + " => " + __LINE__.toString) // print: "1 => 2"

System.print(__MODULE__) // print: "main"

import "mymod" for func

func.call() // print: "inside module: mymod on line 2"
func.call() // print: "inside module: mymod on line 2"
func.call() // print: "inside module: mymod on line 2"

minirop

[acook]

Wouldn't it be better to nest them under a single top level constant instead of adding several?

[minirop]

What kind of "single"? __MODULE_LINE__ or Magic.line + Magic.module?

I chose "several" because it's the easiest, it's just a "detect and replace" idiom like the keywords.

[KyleCharters]

I believe it would be best to place it under the existing optional "Meta" class.

[ruby0x1]

Another note, in the context of scripting a line/file can be variable. For instance if a "script" is just a loose file, but is merged with several loose files into one wren module, this would report incorrect line numbers. This is a common issue for languages that are like this, see for instance #line directive in glsl.

I'd also note that it would make more sense to me in meta since the module/line is available for a callstack usually, it should be fairly easily available as a regular function. This too has the same concern about module/line.

[minirop]

I've tried to put module and line as getter inside a class called "Location" (because why not?).
Location.module: super easy to implement.
Location.line: impossible? (see below).

The line number of each bytecode is inside FnDebug.sourcelines so it's accessible, but the bytecode "index", which is frame->ip - fn->code.data - 1, is not valid for the current frame (the current frame->ip is only updated just before a new callframe is pushed, see STORE_FRAME() in runInterpreter()).

Also, the reason I chose variables is because it's a simple "replace" at compile time, while a function call has cost at runtime.

And what to do with that kind of code? Will it print 1 or 2? (Both can be considered valid, and everybody has a different opinion)

System.print(Location.
             line)

[IngwiePhoenix]

It would be nice having such a feature! But this kind of makes me wonder where the error-callback, which can be supplied to a VM config, is getting it's line from? Couldn't you use a similiar method to how that stack trace is being built to fill `LINE``?

I can see how this could become a problem with concatenated files, actually. However, it should at least be an optional thing people can include if they would like to. That is at least my opinion. Therefore I support the idea of adding this to Meta or making it an own little module that can be compiled in, if wanted. Or, at least enabled either during compilation or through VM configuration.

config.provideLineVariable = true/false;
config.provideModuleNameVariable = true/false;

[mhermier]

Maybe this could also be augmented with a 'FUNCTION' variable (or what ever the name) to inform about the current function/method name.

[ChayimFriedman2]

The one thing that I learned from these macros, and similar things in other languages, is that they useful for one thing: tracking the location of an error. For that, we have #868, which will display you the full stack trace.

If for some strange reason you still need that, you can parse the stack trace. This is the worst idea ever because the stack trace isn't guaranteed to be stable to parse but just easy for humans to read.