Comprehensions are just syntactic sugar, so I don't really understand the
objection, you simply translate the syntax into the underlying syntax
before compilation.
In general collections need to be mutable to be 'pushed' into. Only the
special case of a singly linked list (or some trees with no backlinks) is
this possible. For more general handling of collections I was thinking of
something more like this (illustrated with a list):
{-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies,
FlexibleInstances, FlexibleContexts #-}
import Control.Monad.State.Lazy
class Extensible e a m | e -> a where
push :: MonadState e m => a -> m ()
instance MonadState [a] m => Extensible [a] a m where
push x = do
xs <- get
put (x:xs)
comp1 x [] = return ()
comp1 x (y:ys) = do
comp1 x ys
push (x, y)
comp2 [] ys = return ()
comp2 (x:xs) ys = do
comp2 xs ys
comp1 x ys
main :: IO ()
main = do
s <- execStateT (comp2 xs ys) []
putStrLn $ show s
where
xs = [1, 2, 3]
ys = [4, 5, 6]
At the moment you would need a pre-processor to output the 'correct'
Haskell for generic comprehensions. I haven't included using type classes
to read the 'Nth' value from the input collections as that would
over-complicate the example. In this case the type of collection is
determined by the empty collection you provide (to execStateT), and the
contents inferred from the contents. Note the only type annotations needed
are in the type class definition which is what you want. The aim should be
to infer all types not specifically defined in an interface (type-class)
definition.
Keean.
On 9 February 2015 at 23:17, Jonathan S. Shapiro <[email protected]> wrote:
> On Mon, Feb 9, 2015 at 3:01 PM, Jonathan S. Shapiro <[email protected]>
> wrote:
>
>> I see two possible ways to look at this. The first is that we have a
>> productions that looks like:
>>
>> expr := expr '|' generator
>> expr := '[' expr ']'
>>
>>
>> The other option is that we have a production somewhere that looks like:
>>
>> expr := '[' expr '|' generator ']'
>>
>>
>> But that would appear to lead to the conclusion that we are only able to
>> use comprehensions to produce a limited number of types that are
>> syntactically known to the parser.
>>
>
> Full disclosure: I can see a third way that accounts entirely for how we
> get the behavior we want out of [ expr ], but it seems unspeakably ugly to
> me and I think there must surely be a cleaner way.
>
> The third way is to define [ expr ] to buildAList(expr), and then use
> overlapping instance resolution on buildAList(expr) to alter the behavior
> in the event that the input expression satisfies Iterable 'a 'elemType
>
> But that seems like a pretty damned dirty abuse of ad hoc overloading.
> There has to be a way that doesn't require us to build support into the
> grammar!
>
>
> shap
>
>
> _______________________________________________
> bitc-dev mailing list
> [email protected]
> http://www.coyotos.org/mailman/listinfo/bitc-dev
>
>
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
