redefine named arg lists in terms of let

[CeylonMigrationBot]

[@gavinking] We've occasionally discussed introducing some kind of let construct (though we might actually use the keyword given). It might be possible to define named argument lists in terms of positional arguments and this new let construct, at least at the specification level. That is:

Button {
    size = Size(50,10); 
    label = "Say Hello";
    void onClick() {
        say("Hello!");
    }
}

Would mean:

let (size = Size(50,10), 
     label = "Say Hello", 
     onClick = void() {say("Hello!");})
Button(label,size,onClick)

This would further help us conceptualize "id" in UIs and build scripts:

Panel {
    value label = Label { size = Size(50,10); };
    value button = Button {
        label = "Click me";
        size = Size(50,10); 
        onClick() => label.text="Hello!"; 
    };
}

Would mean something like:

let (label = Label { size = Size(50,10); },
     button = Button { label = "Click me";
                       size = Size(50,10); 
         onClick() => label.text="Hello!"; })
Panel(label,button)

(Thanks to @loicrouchon having part of this idea.)

[Migrated from ceylon/ceylon-spec#744]

[CeylonMigrationBot]

[@gavinking] Note: this idea kinda depends on #3604.

[CeylonMigrationBot]

[@FroMage] See the differences between let and letrec.

Also, I don't see this nearly useful enough without if/else expressions.

[CeylonMigrationBot]

[@gavinking]

See the differences between let and letrec.

Do we need letrec for some reason? In all the examples I'm thinking about, let is sufficient.

Also, I don't see this nearly useful enough without if/else expressions.

WDYM, that's a key feature #3609 of 1.1, already promised in §6.7.1 of the language spec.

[CeylonMigrationBot]

[@quintesse] In this code:

Panel {
    value label = Label { size = Size(50,10); };

isn't there a problem that you can't choose your own name for label? There seems to be a "conflict" between having to specify the name of the parameter and the wish to be able to choose your own.

[CeylonMigrationBot]

[@gavinking] huh? In that example we are choosing our own name...

[CeylonMigrationBot]

[@gavinking]

huh? In that example we are choosing our own name...

(See the Note in §6.6.8 of the latest spec and the recent mailing list discussion with @loicrouchon.)

[CeylonMigrationBot]

[@quintesse] Ok, so what if I want to refer to the value of a named argument? How would that work?

For example:

Panel {
    value label = Label { size = Size(50,10); };
    value button = Button {
        label = "Click me";
        size = Size(50,10); 
        onClick() => label.text="Hello!";  // How do I refer to the button's label?
    };
}

[CeylonMigrationBot]

[@gavinking]

Ok, so what if I want to refer to the value of a named argument?

Probably just use the parameter name.

[CeylonMigrationBot]

[@quintesse]

Probably just use the parameter name

Ok, so we'd need some way to refer to elements in enclosing scopes and such.

[CeylonMigrationBot]

[@gavinking]
@quintesse As usual with named arg lists, we conceptualize it as something a bit like inheritance.

In this case, the "inheriting" scope, i.e. the named arg list inherits names from the "inherited" scope, in this case the parameter list, and also adds its own local names.

[CeylonMigrationBot]

[@quintesse] Sure, but there could be several layers of those, with local names hiding outer scopes etc. We'd probably want some way to access those, right? Or would you expect people to go FQN starting from the outermost object in those cases?

[CeylonMigrationBot]

[@gavinking]

See the differences between let and letrec.

Do we need letrec for some reason? In all the examples I'm thinking about, let is sufficient.

Hrm, perhaps that's wrong. If we want to support freely-form cross-references within argument bodies (rather than just to previous arguments, we would need something a bit like letrec I guess. We also run into evaluation-ordering problems, of course, but we could resolve them either using the approach we use for class bodies or the approach we use for toplevels.

[CeylonMigrationBot]

[@gavinking]

Sure, but there could be several layers of those, with local names hiding outer scopes etc.

Sure, and exactly the same is true of inheritance.

We'd probably want some way to access those, right?

Well with the case of classes we let you use this and outer to resolve ambiguities, though that's obviously only a partial solution. I think it's unlikely that this is an enormous problem in practice. Normally you will be referencing things within the listed arguments, which have their own names.

Or would you expect people to go FQN starting from the outermost object in those cases?

I have no idea what the FQN of an argument would be.

[CeylonMigrationBot]

[@gavinking] OK, I mean, I suppose your point, @quintesse, is that you're going to typically get a lot more nesting in a UI definition than you get in regular class definition. This is true. I still think it's going to turn out OK because in a UI definition most args are in the ordinary list of arguments of §6.6.8, and they get their own names, according to #3855.

[CeylonMigrationBot]

[@quintesse]
@gavinking Yes, that was what I meant.

And by FQN I tried to refer to some way of going from the toplevel element (for example Panel in the code above) "downwards". Almost as if the object was already created and you could just do panel.elements[1].label but in this case panel.button.label.