Alias Syntax

[amitu]

We currently do not have any syntax to alias things. We can have:

-- alias foo: bar

One can argue we can also do:

-- <type-of-bar> foo: $bar

So why do we need the alias syntax at all? In fact the later is already supported and is going to be supported in the future as well. Just that <type-of-$arbitrary-symbol> is not yet defined. Eg how do write the type of a function, or a component etc?

And these are good problems to solve, and we are def going to solve. Our module way of doing thing is to treat the function/component name itself as a type, basically you saying whatever is the type of this function is the type. Which can allow:

-- bar foo: bar

This "works" if bar is a function or component, but not if bar is a record, as this is the syntax we use to create an instance of the record.

Even for component I keep thinking -- <component-name> <id>: syntax to insert the instance of component and create a variable of type ftd.ui that stores that instance, so it can be referred from other documents etc.

In light of this, I feel alias can be good addition to the language. Alias is a bit more explicit I feel, it feels a little more lightweight, you are just aliasing something.

Alias and Export Rename

@xypnox asked for export rename feature, which is a good addition. It too can be handled via alias:

-- integer x: 10 ;; by default everything is private
-- public alias the-x: x

Import Desugaring

The reason I was thinking of this syntax is because we can then desugare the import statement using aliases:

-- import: foo
exposing: bar

-- integer x: bar()

Can be desugared into:

-- alias bar: foo#bar 
-- integer x: bar()

full module name with # separator should also be allowed as discussed elsewhere.

We can de-sugar export/exposing: * by creating appropriate private or public aliases for each symbol defined in imported module.

-- import: foo
export: *

De-sugars into:

-- public alias x: foo#x
-- public alias y: foo#y

And so on.

exposed stuff are not exported, so we do not mark those aliases public.

-- import: foo
exposing: *

De-sugars into:

-- alias x: foo#x
-- alias y: foo#y

Alias Conflict

If we are doing export: * etc, and have a symbol with same name defined, is it an error, or our symbol which is technically defined later on, shadows the exported symbol, or do we follow the order of definition/import to pick the last value?

I prefer it is an error for you to explicitly expose x and define x, similarly export desugar alias conflicting with defined symbols should be an error, but if we are implicitly exposing x via de-sugaring, then shadowing is the better behaviour. This is what Rust does. By default Result is std::result::Result, so it has been "exposed", but we can still create our own Result type and overwrite it.

[amitu]

amitu.com problem - module vs symbol alias

If there is an alias:

-- alias x: amitu.com

Does x refer to index module of package amitu.com or to a symbol com defined in already imported module amitu? We do not know if alias is a module alias or symbol alias.

Solution

What if we do not yet expose alias language feature, and only do import de-sugaring:

-- import: foo as bar
exposing: x

de-sugars into:

-- internal-alias bar: foo
-- internal-alias x: foo#x

This way presence or absence of # can be used to infer if it is a module or symbol alias. Also we can be explicit:

-- module-alias bar: foo
-- symbol-alias x: foo#x

If we expose these two aliases, or maybe alias + module-alias to users, then also we do not have a problem.

[amitu]

Decision: de-sugared and user available alias + module-alias is what we are going with.