A peek at the roadmap for pattern matching and more

[John Rose]

On Aug 12, 2020, at 4:28 PM, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> 
> I know that you have consider something like this, but i prefer making the deconstructor a method returning a tuple at Java level, to be closer to the JVM level.
> So a syntax more like
>   class Point {
>     int x;
>     int y;
> 
>     (int x, int y) deconstructor {
>       return (this.x, this.y);
>     }
>   }
> 
> Conceptually, it's also more like the reverse of a constructor, a constructor takes the values from the stack to move them to the heap, a desconstructor takes the value from the heap and move them to the stack.

To be closer to the JVM level we should number our variables, not name them.
That is, if being closer to the JVM level were so important as to prefer positional
notations to name-based notations.

One reason to avoid tuples is we’d have to reify them more thoroughly in the language,
and that seems like busy-work.

The more important reason to avoid tuples is they don’t have named components,
and the stuff we are looking at these days with records, constructors, and deconstructors
is *all about names*.

— John