__WhereRef/WhereVal peeling, #ifdef and related experiments

[Nils Jonsson]

There is a problem with this kind of syntax anyway. It should be a semantic
failure to match on different type variables. Matching different type
variables produces cases that are racing against each other. So a syntax
similar to yours suggested is quite desirable to make semantics clear. But
anyway, it should not be possible to match cases on an any X and any Y in
the same "switch-case".

By this I suggest a syntax more related to switch-case Statements and to
allow matching only one type variable at a time. Then code refactoring
would not be much of a concern, because the related problems would not
exist.

Regards,
Nils

On Mon, Jan 19, 2015 at 2:27 AM, Thomas W <twhitmore.nz at gmail.com> wrote:

> Thanks Brian. As I noted, Maurizio's patch is not a real syntax..  just a
> hack to take experimentation further.
>
> Brian doesn't want to discuss syntaxes, nor was my intent to suggest such
> -- just to move the concepts away from preprocessors, #ifdef and
> single-dimensionality.
>
> There are many ways to slice type-casing; your example shows one (though
> > you need a "meet rule" when you get to the multiple-tvar case), but there
> > are others.
>
>
> My post specifically raised the possibility of multiple-tvar cases, and
> suggested a simple rectilinear approach in multi-dimensional space. There
> would need to be order of precedence in match rules, but no interaction
> would exist between separate clauses.
>
> I'm having difficulty Googling an exact definition for "meet rule" -- if
> you want to email a definition privately, I'd appreciate -- but apart from
> most-specific L-to-R order of precedence, no such rule would be needed.
>
> Let me know if anything is unclear.
>
> Regards,
> Thomas
>