Re: Module recursion (Was Re: [Caml-list] Re: Haskell-like syntax)

[brogoff@speakeasy.net]

On Sun, 16 Mar 2003, Chris Hecker wrote:
> >Are you sure you agree?
> 
> I agree with what I thought you were saying.  :)  I thought we had the same 
> high-concept, which is just that you can apply the 80/20 rule here and do 
> _something_ to alleviate the DAG module problem without doing some totally 
> general thing like Tom's mixin modules thing. 

Yes, we have the same high level concept, namely, that we can look for solutions 
to specific problems that result from not being able to call modules recursively, 
without solving the whole thing, as with mixin modules. 

I think any disagreement was more one of degree, in that my "pet problem(s)" are 
not prioritized the same way yours are. I won't give percentages, since I don't 
know what they mean in this context. I find that the inability to have type 
declarations recursive with functor instantiation reduces the value of functors, 
and the workaround (the parameterization trick) forces you to introduce 
polymorphism just to do this. I agree that the lack of cross module function 
recursion is also a significant problem. Jacques Garrigue showed how you can use 
the newish explicit polymorphism to alleviate the problem I mentioned with the 
well known reference to function workaround for this problem. That's an 
improvement, but we still end up using mutation directly (a bit ugly, to me) and 
abusing the first class polymorphism a bit, just like when we use dictionary 
records to simulate polymorphic recursion. I'd still prefer an explict "forward" 
construct to handle both of these. 

> I think 80% of the problem for me would be solved by allowing recursive function calls.  

The workaround Jacques provided should satisfy this need for now. What do you 
think? 

> The next 15% would be solved by allowing types to recurse (the example you asked for is 
> two records that refer to each other). 

I think that two records that refer to each other belong in the same module :-)

Seriously, I *know* that's what allowing types to recurse across modules is an 
example of allowing types to recurse across modules. I was searching for a 
compelling example of when that is necessary. In a previous incarnation of this 
discussion, Fergus Henderson cited some example from the Mercury compiler where 
the *functions* were getting huge (on the order of 10KLOC) before being split 
up. So that's part of a good argument for directly supporting cross module 
function recursion. I don't mind types getting big, partly because, IMO, a 
good factoring in OCaml often involves pulling type declarations into their own 
separate .mli file. 

> The next 5% is everything 
> else.  But, I'd happily take just functions calling recursively across 
> modules, because that would just be huge, and allow me to refactor into 
> smaller modules, increasing compile speed, decoupling, etc.
> 
> I would even be happy with this in as a temporary feature and I'd have to 
> rewrite code when the real thing came along.

I think the reference to function trick, augmented by a naming convention (say, 
prefixing the funs with fwd_<funname>) and using higher order polymorphism, as 
JG just showed, is an acceptable workaround for now. But it doesn't seem as 
elegant as a forward construct. 

-- Brian


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners