PRE-SIP: using directives

[julienrf]

Here is a summary of the main points that have been raised so far. I suggest taking them into account before submitting an actual SIP.

Motivation

@julienrf

About the motivation part, I would like to highlight something that I think is not really visible in your post: currently, distributing a Scala program as a source file (to be executed by scala my-program.scala) relies on a global installation of a Scala interpreter that has to match exactly the version used by the program (or, at least, be compatible with it). That makes it very fragile to distribute Scala programs as source files.

Do you (@romanowski) plan to update the motivation part to include that point?

Alternative Solution: Comments

@som-snytt

Both compiler test suites leverage magic leading comments

@julienrf

The fact Scala compilers will have to implement support for parsing them just to ignore them feels odd to me:

@romanowski

From the compiler’s point of view, using directives will be treated just like a comment with a fixed syntax.

I wonder if special comments (e.g. //>) would be more appropriate for that, then.

@lihaoyi

The fact that it looks similar to Scala expressions at all is misleading. Can I import stuff? What’s the evaluation order? Can I define vals/defs/classes and so on? I assume not, and that this stuff would get statically inspected as metadata, rather than evaluated as code. This means the syntax is actively misleading people into thinking it’s Scala expressions, when it’s not

Could you please expand on why you think “using directives” is the best solution vs comments?

Alternative Solution: Annotations

@lihaoyi

TBH, if we want a way to associate metadata with Scala files, that sounds a lot like the existing way to associate metadata with pieces of Scala code: an annotation. I think some annotation-like syntax using @ would be a lot better than the using syntax proposed above. We’d need to finesse the syntax in order to make it unambiguous and ergonomic, but I think it can be done and result in a much more familiar user experience. This applies to people coming from any language, as most languages have some sort of annotation-like syntax for associating metadata with code, and that’s exactly what we want to do here.

Probably, a discussion on a solution based on annotations should be included. An argument against annotation has been made here already:

@som-snytt

I think annotations suffer from the problem that they require processing (typing). By the time you’ve typechecked, you already needed the metadata, which may include compile time or run time directives.

Alternative Solution: Language Imports

@rjolly

Conversely, we could use import for general settings:

import scala "3.1.2"

It would address the objection that using already has its (different) purpose.

@rssh

Or without breaking scala syntax:

import language.version.`3.1.2`

Maybe consider including language imports in the alternative solutions. There is already an argument against reusing imports:

@Katrix

It would from what I understand not supercede language imports, as those can be locally scoped, while these can not.

Re-purposing the using keyword vs introducing a new keyword

@lihaoyi

It’s re-purposing an existing keyword in a weird way. using is kinda-sorta tangentially related to one particular use case of what we’re trying to do here, just like import $ is kinda-sorta tangentially related to one particular use case of what Ammonite does. But it’s different enough that it seems like it would cause confusion, not unlike how we used to use underscore _ for a bunch of scenarios that were kinda-sorta related

Would you mind elaborating on why you think re-purposing using is the best solution? Should we introduce another keyword instead? E.g. “pragma”?

@amsayk

I think pragma would fit perfectly as a keyword for this. It is well known for this kind of feature in other programming languages.

Syntax does not look like usual Scala

@lihaoyi

It doesn’t look like Scala. scala "3.1.2" does not look like valid Scala syntax at all. someSettings { setting1 value 1; setting2; } is technically valid Scala syntax, but is in the style of odd DSLs. It looks like Kotlin or Groovy with their convention of builder DSLs, but those aren’t ubiquitous in the Scala ecosystem.