Autoscoping of constructors

[JaroslavTulach]

Do you remember how ugly it is to always prefix a constructor of a type with its type name? Always write something like:

table.aggregate Aggregate_Column.Count

Enso should do better! Let's discuss how to do it!

[JaroslavTulach]

One idea is to reuse .symbol syntax. It does seem to work for

from Standard.Base import all

type X
    A
    B x

cons x:X = x.to_text

main = cons .A

but it doesn't work for cons .B 3. Opinions, ideas?

[wdanilo]

Radek proposed ..C and its even better than ...C. I think the best bets are ..C and auto.C. I like them both. I agree with Radek that ..C is so much shorter and nicer in the code, that probably its the way to go.

[JaroslavTulach]

Looks like we really need new syntax. Trying to fit into .A (even if we differentiate between lowercase and upper case as @radeusgd suggests) is probably not good idea. ... isn't bad, but it is long. My favorite would be ~:

main = cons ~A

~ is already used for suspended executions. Using it for suspended resolution might not be that bad idea.

-1 on using auto. - the goal is to shorten the syntax and auto. prefix is too long.

[wdanilo]

So, we had discussion yesterday. The ~ operator can't be used there because of a meaning clash. Enso was always designed in such a way, that type-level expressions can be processed on value-level, and vice versa. For example, you should be able to write in the future something along the lines of:

extract a = case a of 
    \Vector x -> x
    \List x -> x

my_fn: _a -> extract _a
my_fn = ...

It means, that you should be able to process types on value level, being able to pattern match and construct them. We had already problem with the -> operator here and that's why there is another ticket to change the lambda expression from a -> b to \a -> b. For example, imagine that you want to pattern match on the provided function type:

extract_second_arg fn = case fn of
    \(a -> b -> c) -> b
    \_ -> Nothing

Please note, that the expression in parentheses (a -> b -> c) does not use \, so it is a pattern match on a function type constructor, not a lambda expression. Exactly the same applies to the proposed ~ syntax. It means laziness on type level. So Imagine we have a function:

fn: Vector ~_a -> Int 
fn = ...

And we want to extract its type to another function that will be called on type level, so we will refactor the above code to:

foo = Vector ~_a -> Int 

fn: foo
fn = ...

Now, the foo expression will be invalid, as ~ will mean auto-scoping, not a lazy arg constructor.

[JaroslavTulach]

• Tracking issue is Prefix autoscoped constructors with .. #9275

[JaroslavTulach]

• Use .. to identify autoscoped constructors #9285 has just been integrated

[JaroslavTulach]

Pull request

• Autoscoped constructors #9190

is ready for your consideration.

[JaroslavTulach]

Case Constructor Patterns

Will there be any change to case constructor patterns? For example here one might be tempted to write:

case f of
           ~Item p next -> if n % p == 0 then False else
                if p * p > n then True else @Tail_Call iterate next
            ~Empty -> True

but I guess that's not really feasible - we need exact identification of the constructor before matching anything and that wouldn't be possible. All we could match would be the name and arity of the constructor and that doesn't seem to be enough.

[radeusgd]

Interesting feature, it gives me vague Lisp-like vibes.

It's pretty orthogonal to the original use-case though. In matching I think we are fine with the FQN and indeed we want to know the full type. In the future maybe we could infer this in the type system (if I know that f : My_Type then I could assume that ~Item refers to My_Type.Item). But I don't think it adds any value for us now so I'd leave this until we find any use cases for that.

[JaroslavTulach]

@farmaazon wrote:

when exactly can we use it?
I guess on typed function arguments;
but can I also use it as argument to non-typed function assuming, that the constructor will be resolved somewhere inside?

[JaroslavTulach]

That's a very good question! I think that we can begin using it in dynamic drop downs - then the decision to use the ~ form is in the hands of the libraries team. Probably there is no need for a work on the IDE side.

[JaroslavTulach]

It'd be good if the ~ form worked in static drop downs as well. I believe we need some co-operation with suggestion database in such cases, CCing @4e6. When there is a following Counting type:

type Counting
    Zero
    One
    Two 
    Many n:Integer

then a method with signature defined inline like

next c:Counting = case c of
   Counting.Zero -> Counting.One
   Counting.Two -> Counting.Many 3
   Counting.Many n -> Counting.Many n+1

is guaranteed to accept short form of ~Zero, ~One or ~Many 5. The suggestion database shall indicate this to the IDE.

On the other hand a method with no signature or signature defined on a separate line (see #6884 (comment) for details) like

prev : Counting -> Counting 
prev c = ...

doesn't guarantee to accept the short form. Again suggestion database shall provide such information to the IDE. What do you think, Dmitry?

[4e6]

Could you explain in more details how the suggestions database is involved here?

[JaroslavTulach]

It'd be good if the ~ form worked in static drop downs. I believe we need some co-operation with suggestion database to provide the IDE information whether it is possible to use autoscoped constructors or not for a given function argument.

[JaroslavTulach]

Dmitry reported

• Use autoscoping when constructing tag values of suggestion arguments #9259

as a followup issue.

[kazcw]

How does this relate to the current Tree.AutoScope syntax, e.g. here:

enso/distribution/lib/Standard/Base/0.0.0-dev/src/Meta.enso

Lines 138 to 140 in e98306f

	fields self =
	c = self.value ...
	Vector.from_polyglot_array (get_constructor_fields c)

[radeusgd]

The syntax is wrongly named, ... is used for suspending default arguments, so it should be called something else, e.g. Tree.SuspendedDefaultArguments.