I seem to have run into an instance of the expression problem [1], or
something very similar, when experimenting with ``finally tagless''
EDSLs, and don't see a good way to work around it.
I have been experimenting with embedded DSLs, using the techniques
described in a couple recent papers [2,3].
On Wed, Sep 23, 2009 at 7:59 PM, Brad Larsen wrote:
> The trouble comes in when defining a more general arithmetic
> expression type class. Suppose we want polymorphic arithmetic
> expressions:
>
>> class PolyArithExpr exp where
>> constant :: a -> exp a
>> addP :: exp a -> exp a -> e
Luke,
On Wed, Sep 23, 2009 at 11:12 PM, Luke Palmer wrote:
> On Wed, Sep 23, 2009 at 7:59 PM, Brad Larsen wrote:
>> The trouble comes in when defining a more general arithmetic
>> expression type class. Suppose we want polymorphic arithmetic
>> expressions:
>>
>>> class PolyArithExpr exp where
Brad:
On 24/09/2009, at 11:59 AM, excerpts of what Brad Larsen wrote:
We then try to define an evaluator:
-- instance PolyArithExpr E where
-- constant = E
-- addP e1 e2 = E (eval e1 + eval e2) -- bzzt!
The instance definition for `addP' is not type correct:
Could not deduce (Num
Luke,
On Wed, Sep 23, 2009 at 11:12 PM, Luke Palmer wrote:
> On Wed, Sep 23, 2009 at 7:59 PM, Brad Larsen wrote:
>> The trouble comes in when defining a more general arithmetic
>> expression type class. Suppose we want polymorphic arithmetic
>> expressions:
>>
>>> class PolyArithExpr exp where
Peter,
On Thu, Sep 24, 2009 at 12:22 AM, Peter Gammie wrote:
[...]
> Ambiguity is IMHO best handled with a judicious application of type (or
> data) families, but you can get surprisingly far by simply requiring that
> every class member mention all type variables in the class head. YMMV of
> co
Brad,
On 24/09/2009, at 2:45 PM, Brad Larsen wrote:
On Thu, Sep 24, 2009 at 12:22 AM, Peter Gammie
wrote:
[...]
Ambiguity is IMHO best handled with a judicious application of type
(or
data) families, but you can get surprisingly far by simply
requiring that
every class member mention al
On Wed, Sep 23, 2009 at 10:24 PM, Brad Larsen wrote:
> On Wed, Sep 23, 2009 at 11:12 PM, Luke Palmer wrote:
>> I would like to see an example of this unmodularity, making use of the
>> polymorphism, so I can understand what you're asking better.
>>
>> Luke
>
> [...]
>
> A simple test case, combin
The modularity problem I speak of is that to add a new interpretation of the
DSL, I will likely have to modify the EDSL definition to add additional
constraints. Ideally, I would like to be able to define the EDSL once, in a
module, and be able to write arbitrary interpretations of it in other
mod
Brad Larsen wrote:
The modularity problem I speak of is that to add a new interpretation of the
DSL, I will likely have to modify the EDSL definition to add additional
constraints. Ideally, I would like to be able to define the EDSL once, in a
module, and be able to write arbitrary interpretatio
Bruno,
On Thu, Sep 24, 2009 at 1:20 AM, Bruno Oliveira wrote:
> Hello Brad,
>
> I believe that the problem you encountered is not quite the expression
> problem (which is about adding new constructors and functions modularly),
> but rather about refining *existing* constructs with more specific t
Wren,
On Thu, Sep 24, 2009 at 8:36 PM, wren ng thornton wrote:
> Brad Larsen wrote:
>>
>> The modularity problem I speak of is that to add a new interpretation of
>> the
>> DSL, I will likely have to modify the EDSL definition to add additional
>> constraints. Ideally, I would like to be able to
Brad Larsen wrote:
On Thu, Sep 24, 2009 at 8:36 PM, wren ng thornton wrote:
The reason this is unsatisfying is [...] if you need to lift
more than one variable in the same class then it can be tricky to do the
encoding right. For instance, when converting Monad into this form (e.g. so
we can de
Edward,
On Sat, Sep 26, 2009 at 11:41 AM, Edward Kmett wrote:
> I would just like to add that Oleg and Chung-chieh made sure in their
> finally tagless paper to use monomorphic lifting of literals explicitly to
> avoid this sort of ambiguity. Using Num or another typeclass is fine as long
> as al
I would just like to add that Oleg and Chung-chieh made sure in their
finally tagless paper to use monomorphic lifting of literals explicitly to
avoid this sort of ambiguity. Using Num or another typeclass is fine as long
as all you want to do is evaluate your EDSL. But what about partial
evaluatio
15 matches
Mail list logo
