circular module dependencies

[Geoffrey Irving]

I made a small change to the Lir, and am have trouble resolving the
resulting cyclic module dependency in a clean way. I merged ExpInt
and ExpChar in Lir.Exp into

ExpVal TypeVal Value

which allows arbitrary runtime values to be embedded in the Lir.
Unfortunately, this produces a dependency cycle

Lir -> Value -> Lir

in the pretty printing code, since Value can contained delayed
Lir.Exp's. There's no cyclic dependency outside pretty printing,
since Value by itself is an unprintable abstract datatype declared in
Memory.

Do you have suggestions as to how to resolve this? I realize it may
be impossible to answer without more information.

Thanks,
Geoffrey

[Dylan Simon]

From Geoffrey Irving <irv...@naml.us>, Sat, Apr 30, 2011 at 04:22:48PM -0700:

Yeah, I'm not sure I understand. To be more explicit, from the current
sources, that would introduce:

lir.duck -> type.duck
lir.duck -> Memory.hs

Now, I presume you've moved Value from Memory.hs to value.duck (somehow)? But
value.duck is about interpreter values, not runtime representations, right?
And Value.hs is pretty high level for its name, so its current contents and
the Value definition don't seem like they should go together.

Or are you only talking about dependencies because of Pretty instances? I'd
have no objection to moving all the Pretty instances to the same place.

[Geoffrey Irving]

On Sat, Apr 30, 2011 at 4:40 PM, Dylan Simon <dylan-...@dylex.net> wrote:
> From Geoffrey Irving <irv...@naml.us>, Sat, Apr 30, 2011 at 04:22:48PM -0700:
>> I made a small change to the Lir, and am have trouble resolving the
>> resulting cyclic module dependency in a clean way.  I merged ExpInt
>> and ExpChar in Lir.Exp into
>>
>>   ExpVal TypeVal Value
>>
>> which allows arbitrary runtime values to be embedded in the Lir.
>> Unfortunately, this produces a dependency cycle
>>
>>     Lir -> Value -> Lir
>>
>> in the pretty printing code, since Value can contained delayed
>> Lir.Exp's.  There's no cyclic dependency outside pretty printing,
>> since Value by itself is an unprintable abstract datatype declared in
>> Memory.
>>
>> Do you have suggestions as to how to resolve this?  I realize it may
>> be impossible to answer without more information.
>
> Yeah, I'm not sure I understand.  To be more explicit, from the current
> sources, that would introduce:
>
>        lir.duck -> type.duck
>        lir.duck -> Memory.hs
>
> Now, I presume you've moved Value from Memory.hs to value.duck (somehow)?  But
> value.duck is about interpreter values, not runtime representations, right?
> And Value.hs is pretty high level for its name, so its current contents and
> the Value definition don't seem like they should go together.

Value is still in Memory.hs. Value.hs imports value.duck, which
defines FunValue and IOValue, and otherwise only contains pretty
printing code.

> Or are you only talking about dependencies because of Pretty instances?  I'd
> have no objection to moving all the Pretty instances to the same place.

I suppose moving all the Pretty instances to the same place is easy
and sufficiently clean. I'll do that.

Geoffrey