Yes, if you confine yourself to Miller's "pattern fragment" (Meta variables
may appear in the head of an application, but then the arguments may only
be *distinct* bound variables) then you might be fine.
Thanks for giving it a try!
Am Mo., 14. Nov. 2022 um 14:27 Uhr schrieb J. Reinders <
jaro.r
I think higher order pattern unification is different from higher order
matching because the unification means both sides are allowed to be patterns
that may contain meta variables, while matching works on only one pattern and
one concrete term.
The example pattern ‘forall a. someFunction (\x -
> I believe the reason that this is easier than higher order matching in
general because it is restricted to applications of unification variables
to locally bound variables.
Indeed, it is easier to confine oneself to the pattern fragment. I think
that's entirely the point of pattern unification:
Thank you both for the quick responses.
> Can you say precisely what you mean by "using stream fusion instead of
> foldr/build fusion in base"? For example, do you have a prototype library
> that demonstrates what you intend, all except concatMap?
I believe the stream-fusion library [1] and
Jaro
1. Is the ‘concatMap’ problem really the only problem left on the way to
> using stream fusion instead of foldr/build fusion in base?
>
Can you say precisely what you mean by "using stream fusion instead of
foldr/build fusion in base"? For example, do you have a prototype library
that demo
Hi Jaro,
I'm very glad that you are interested in picking up the pieces I left
behind!
Re: SpecConstr: Yes, that pass is already moderately complicated and gets
much more complicated when you start specialisation for non-bound lambdas,
because that would need higher-order pattern unification in R
