auto-wrap enhancement

[jurgenvinju]

When constructing or pattern matching large data types the number of names and brackets is often an impediment. People sometimes use aliases over tuple types to circumvent this problem. Aliases have their issues and we prefer everybody to use clear and simple data types, so we need something to solve the syntactic vinegar.

One idea would be to have the type checker infer constructors (probably functions in general).
Examples:

data E = add(Exp, Exp) | intcon(int i) | realcon(real r);

E e = add(1, 1.0); // would work and generate add(intcon(1), realcon(1.0))

Further support for avoid naming unambiguous constructors:

E e = <1,2>; // would lead to the same add(intcon(1), realcon(1.0))

If there is another definition for E then the checker complains:

data E = mul(Exp, Exp);

E e = <1,2>; // error: there are two binary constructors for E which can match, please disambiguate add(1,2) or mul(1,2)

[jurgenvinju]

PS: a different notation instead of tuple brackets would also be nice perhaps.

[tvdstorm]

I think the tuple thing is unneeded. The others, well, it's like the good old days of ASF+SDF! Just parse it.

[jurgenvinju]

Yes, just like ASF+SDF, although I think this feature is more like Scala's implicits than anything else.

I don't think the feature is easy to implement actually, given type inference, but we are helped with the syntax for literals which is unambiguously typed. Otherwise I am interested to hear wat @mahills thinks about this from the perspective of the type checker.

[mahills]

I'm not sure it's particularly troublesome from the type checking perspective, although the code for checking pattern matching and binding types to introduces names is already fairly complex -- we should be fine if we make tight rules about when this can be used (basically, nothing ambiguous). Then, of course, we need the checks to tell if uses are ambiguous :)

I am more worried about maintainability of programs using this feature, since you would have some constructors appearing explicitly, and some not appearing at all, making it harder to understand programs using larger data definitions that you didn't write yourself. We would probably want UI support to "desugar" this (maybe something if you hover over it) so you could see the explicit definition, or maybe even an option to expand and replace in-place if you were writing it this way just to save some typing.

[jurgenvinju]

I agree that implicit stuff makes code harder to understand and I like the
idea of adding IDE support to help out (documentation hover and
refactorings)

On Mon, Aug 4, 2014 at 10:50 PM, mahills notifications@github.com wrote:

I'm not sure it's particularly troublesome from the type checking
perspective, although the code for checking pattern matching and binding
types to introduces names is already fairly complex -- we should be fine if
we make tight rules about when this can be used (basically, nothing
ambiguous). Then, of course, we need the checks to tell if uses are
ambiguous :)

I am more worried about maintainability of programs using this feature,
since you would have some constructors appearing explicitly, and some not
appearing at all, making it harder to understand programs using larger data
definitions that you didn't write yourself. We would probably want UI
support to "desugar" this (maybe something if you hover over it) so you
could see the explicit definition, or maybe even an option to expand and
replace in-place if you were writing it this was just to save some typing.

—
Reply to this email directly or view it on GitHub
#628 (comment).

Jurgen Vinju

• Centrum Wiskunde & Informatica - SEN1

• INRIA Lille - ATEAMS

• Universiteit van Amsterdam

  www: http://jurgen.vinju.org, http://www.rascal-mpl.nl,
  http://twitter.com/jurgenvinju
  skype: jurgen.vinju

[PaulKlint]

On the one hand: yes back to good old ASF+SDF times. On the other hand our current situation is much better: in the ASF+SDF setting we were hindered by syntactic ambiguities and here we have much better control. I particularly like the possibility to write literals in AST without wrappers like intcon.

Another application: in the Figure library there are cases where you want to mix integers and strings, For instance, fontWeight=300 or fontWeight="bold" (as allowed by SVG and CSS). This can be achieved by:

data weight = intweight(int n) | strweight(str s);

Now the keyword parameter weight fontWeight="normal" will do. In an even more perfect (Rascal) world, we would be able to write (note the absence of empty parameter lists):

data weight = intweight(int n) | light | normal | bold;

and weight fontWeight=normal

[jurgenvinju]

@tvdstorm About the tuple thing, the motivation is that right now we use
aliases to tuple types to model "records" while we have the constructor
feature for this (especially with keyword parameters) We need a syntax for
multi-valued records which produce constructors. The tuple thing was an
idea in this direction, but I'd prefer a different syntax.

  data F = foo(int i, int j);

  // just not have the name of the constructor? only allowed for records
with > 1 items to avoid  ambiguity
   F x = (1,2);

  // or rather not have the brackets or the comma's? probably ambiguous and
needs a lot of thinking through
   F x = f 1 2;

  // misuse tuple syntax, has the benefit of not adding new syntax, but
tuples would need keyword parameters.
  F x = <1,2>;

@PaulKlint yes, removing the brackets is also interesting, but it involves
different aspects of the language to make that happen than the implicit
wrapping. Could you open another issue for this?

On Mon, Aug 4, 2014 at 11:53 PM, Paul Klint notifications@github.com
wrote:

On the one hand: yes back to good old ASF+SDF times. On the other hand our
current situation is much better: in the ASF+SDF setting we were hindered
by syntactic ambiguities and here we have much better control. I
particularly like the possibility to write literals in AST without wrappers
like intcon.

Another application: in the Figure library there are cases where you want
to mix integers and strings, For instance, fontWeight=300 or
fontWeight="bold" (as allowed by SVG and CSS). This can be achieved by:

data weight = intweight(int n) | strweight(str s);

Now the keyword parameter weight fontWeight="normal" will do. In an even
more perfect (Rascal) world, we would be able to write (note the absence of
empty parameter lists):

data weight = intweight(int n) | light | normal | bold;

and weight fontWeight=normal

—
Reply to this email directly or view it on GitHub
#628 (comment).

Jurgen Vinju

• Centrum Wiskunde & Informatica - SEN1

• INRIA Lille - ATEAMS

• Universiteit van Amsterdam

  www: http://jurgen.vinju.org, http://www.rascal-mpl.nl,
  http://twitter.com/jurgenvinju
  skype: jurgen.vinju