Add something like __MODULE__ and __FUNCTION__ and __LINE__

[inoas]

in foo.gleam:

pub fn bar() {
  "called foo.bar()"
  // Having __MODULE__ and __FUNCTION__ and __LINE__ would be useful here
}

I would use this in production for things like Sentry.io logging.

[lpil]

Could be a good idea! I'd be interested in seeing what other languages use for this syntax wise. I recall NodeJS uses a __ prefix, and Erlang uses ?MODULE etc

[inoas]

I'd be interested in seeing what other languages use for this syntax wise

Elixir

Has __MODULE__ but makes it hard to get the others:

"Called #{__MODULE__}.#{__ENV__.function |> elem(0)}() in #{__ENV__.file}:#{__ENV__.line}"
# Called Elixir.Foo.bar() in /abs/path/to/test.exs:5

PHP

Has these:

Magic Constant Name	Usage
__LINE__	The current line number of the file.
__FILE__	The full path and filename of the file with symlinks resolved. If used inside an include, the name of the included file is returned.
__DIR__	The directory of the file. If used inside an include, the directory of the included file is returned. This is equivalent to dirname(__FILE__). This directory name does not have a trailing slash unless it is the root directory.
__FUNCTION__	The function name, or {closure} for anonymous functions.
__CLASS__	The class name. The class name includes the namespace it was declared in (e.g. Foo\Bar). When used in a trait method, __CLASS__ is the name of the class the trait is used in.
__TRAIT__	The trait name. The trait name includes the namespace it was declared in (e.g. Foo\Bar).
__METHOD__	The class method name.
__NAMESPACE__	The name of the current namespace.
ClassName::class	The fully qualified class name.

Source: https://www.php.net/manual/en/language.constants.magic.php

Ruby

Has __FILE__ and __LINE__

See: https://ruby-doc.org/core-2.5.0/doc/keywords_rdoc.html

C++

Seem to have __FILE__, __LINE__ and _func_ or __FUNCTION__
See: https://stackoverflow.com/a/597081

Python

Predefined (writable) attributes:

    [__name__](https://docs.python.org/3/reference/import.html#name__)

        The module’s name.

    __doc__

        The module’s documentation string, or None if unavailable.

    [__file__](https://docs.python.org/3/reference/import.html#file__)

        The pathname of the file from which the module was loaded, if it was loaded from a file. The [__file__](https://docs.python.org/3/reference/import.html#file__) attribute may be missing for certain types of modules, such as C modules that are statically linked into the interpreter. For extension modules loaded dynamically from a shared library, it’s the pathname of the shared library file.

    __annotations__

        A dictionary containing [variable annotations](https://docs.python.org/3/glossary.html#term-variable-annotation) collected during module body execution. For best practices on

Source: https://docs.python.org/3/reference/datamodel.html#the-standard-type-hierarchy => Sub header modules (scoll down)

Java

Seems to lack them, but allows to fetch values from the Stack Trace: https://www.recitalsoftware.com/blogs/152-howto-use-file-and-line-in-java-programs

Dart

Seems to lack them, but allows to fetch similar values via Stack Trace: https://stackoverflow.com/a/65742207

Swift

Has them: https://docs.swift.org/swift-book/ReferenceManual/Expressions.html#ID390

As of note swift also supports fetching of a __COLUMN__, together with __LINE__ that is a great pointer to source code.

NodeJS

Seems to have __dirname but lacks others which need to be retreived via the stack:
https://github.com/gavinengel/magic-globals/blob/master/magic-globals.js

Perl

At least has __FILE__ and __LINE__:

• https://perldoc.perl.org/functions/__FILE__
• https://perldoc.perl.org/functions/__LINE__

C#

Not directly available, have to go through stacktrace or CallerInformation
https://stackoverflow.com/a/44139163

[inoas]

After going through a languages the C-inherited __FILE__ and __LINE__ etc are very prevalent.

I'd suggest to add these, if possible:

__FILE__
__LINE__
__COLUMN__
__MODULE__
__FUNCTION__

[lpil]

Looks like it's overwhelmingly __THING__, let's go for that syntax. Thank you

[inoas]

Would these inject these values:

• __FILE__ => String
• __DIR__ => List(String) (base would be ./src/ dir?, [] if directly in ./src/?)
• __LINE__ => Int
• __COLUMN__ => Int
• __MODULE__ => String
• __FUNCTION__ => Result(String, nil) (In case FUNCTION is being used in const declarations. We could also just not allow it to be used there? Also I assume function only returns the name of the named function not any anon function reference/variable binding?)

I feel like keeping file and dir separated may be helpful, also for cross platform compat? Else FILE could be a unix path (String) or a List(String)?

[lpil]

String sounds good. I could imagine __PACKAGE__ being useful too.

__FILE__ and __DIR__ could be misleading as the source file may not exist after the program has been compiled.

[inoas]

Maybe a keyword could be added that yields a well structured Tuple to be consumed by custom logging/tracing/reporting tools such as stdout logging or sentry.

// here `trace` would be an assumed keyword
// replacing `trace` with a truple of the constants above, resolved at compile time.
// `sentry.log` would be some userland module/function.
sentry.log(trace, "my_msg")`

[inoas]

__FILE__ and __DIR__ could be misleading as the source file may not exist after the program has been compiled.

I still think __FILE__ or __SOURCE_FILE__ would be very benificial for things to lookup on crashes such as on sentry. There could also be an __VM_FILE__ or __RUNTIME_FILE__ but then we need twice the line and column number constants?

[xhh]

Since every Gleam source file is a module, we could just use __MODULE__.

[lpil]

I still think FILE or SOURCE_FILE would be very benificial for things to lookup on crashes such as on sentry.

Crashes come with a stacktrace so that's already covered 👍

[rockwotj]

I would recommend against anything platform specific here as it could break caching across platforms. Similarly goes for adding stuff like __DATE__ or a non deterministic value