search

Feldspar / feldspar-language

The goal of the Feldspar project is to define a high-level language that allows description of high-performance digital signal processing algorithms.
Other
45 stars 3 forks source link

Generalize types of polymorphic functions #9

Open emilaxelsson opened 11 years ago

emilaxelsson commented 11 years ago

For example:

getIx :: Syntax a => Data [Internal a] -> Data Index -> a
setIx :: Syntax a => Data [Internal a] -> Data Index -> a -> Data [Internal a]

Is this a good idea?

emwap commented 11 years ago

That would make the following valid:

{-# LANGUAGE FlexibleContexts #-}

import Feldspar
import Feldspar.Vector

ex1 :: Syntax a => Data [Internal (Vector a)] -> Data Index -> Vector a
ex1 = getIx

ex2 :: Syntax (M a) => Data [Internal (M a)] -> Data Index -> M a
ex2 = getIx

While 'ex1' might be useful, I'm not sure we want to allow 'ex2'. Do you have a use case?

emilaxelsson commented 11 years ago

No M a doesn't have a Syntax instance so ex2 would not be allowed.

I'm just assuming it might be useful to do things like setIx a i (1,2). Of course it's not much more typing to say setIx a i (resugar (1,2)), but it seems quite natural to make such functions as general as possible. The idea would be to generalize all polymorphic types Data a in the core language (but not e.g. Data [a] or Data Bool). The downside is that for functions like getIx, we lose some type inference (since a cannot be inferred from Internal a).

Currently, e.g. condition and forLoop are generalized to Syntax types, but their types don't mention Internal, so no type inference is lost.

Now that I think about it, the loss of type inference seems to kill this proposal. Maybe the rule-of-thumb should be to keep the core language interface free from type functions?