Re: [stack] sweetening concatenative syntax

On Mar 6, 2008, at 3:41 PM, Daniel Ehrenberg wrote:

>> Anyway, saying that "all your doing is pattern matching" gets more
>> complicated when types are involved. For example, when I eventually
>> introduce GADTs, sum deconstructors like 'unlist' will need to
>> introduce equality constraints. It also isn't clear how a macro could
>> be able to inform you if you've not covered all of the possible cases
>> when matching. Therefore, any sort of general pattern matching
>> facility would need to be implemented into the language proper, and
>> ideally I'd like to avoid that as it complicates things.
>>
>> - John
>
> Pattern matching only has to be built into a language when its type
> system or syntax extension system is insufficiently expressive.
> There's no good reason why a complicated, library-based pattern
> matching macro couldn't cooperate with a type system or completeness
> constraints.

This seems incredibly difficult in practice. Would the macro system be  
able to to query the type system? Would it be able to find out all  
constructors of a given data type? Would it be able to check if a  
given data type requires that equality constraints be introduced when  
matching? How would it generate code that handles such a thing anyway?  
Would it need to be smart enough to translate to a pre-defined  
deconstructor? How would it be able to give errors as intelligible as  
a built-in system for subtle matters like this? If the macro were to  
introduce variables, would the specification not have to indicate how  
this interacts with linearity? Does the macro not then need to be in  
the core anyway?

> Factor has two pattern matching libraries implemented, which take  
> different tactics but are both fairly general and implemented  
> without the help of the core.

Yes, it's all very easy when types aren't involved.

- John