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

[brogoff@speakeasy.net]

On Mon, 17 Mar 2003, Chris Hecker wrote:
> >I think any disagreement was more one of degree, in that my "pet 
> >problem(s)" are not prioritized the same way yours are.
> 
> I actually don't see this as a "pet problem" thing. 

I also use OCaml in my job. By "pet problem", I meant that set of language 
quirks that annoy you. If you work with even one other OCaml programmer, I'll 
bet you find that what annoys you may not annoy the other guy as much, and vice 
versa. 

> It's also something that just flabbergasts 
> professional C++ programmers when they look a caml...the concept that you 
> can't break up a compilation unit any way you want to save compile time or 
> to make it more readable is crazy to them, and they're right.

C++ has explicit pointers, and allows them to be uninitialized, so it shouldn't 
be surprising that it can allow more of this kind of thing. 
 
> > > 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 "id" thing he showed?  That's just the same as doing a ref option and 
> then stuffing the functions, isn't it?

Sort of, but it allows polymorphism by using the higher order polymorphism 
features, like polymorphic methods, but for record fields instead.

> Anyway, it's an ugly hack, it  spreads knowledge of what one module needs 
> from another explicitly into the interface, you have to explicitly type the 
> forward functions, it requires an error-prone manual stuffing step, 

Yes, I agree, it's a workaround. 

> and there are order of initialization issues (which there aren't if you just 
> allow functions to be called, and not arbitrary values) 

Are you sure? I think the order of initialization issues still occur even if you 
just allow functions. 

> Basically, this workaround is not making a professional programmer looking at 
> ocaml feel better about using it for large projects, in my opinion.

Again, I agree, but every language has annoying flaws. 

> >I think that two records that refer to each other belong in the same 
> >module :-)
> 
> The reason I didn't bother giving an example is that out of context any 
> example can be "redesigned by the list" to not need it, or the list can 
> claim that you can just shove things in the same module. 

Well, of course we can redesign everything down to assembly code, but if you use 
this as a reason then you'll have to assume all discussion is pointless. I found 
Fergus Henderson's Mercury code size statistics pretty convincing as an argument 
that cross module functions should have more direct support. 

> The ability to have two types refer to each other is a totally reasonable 
> thing to do, and if you agree that it's reasonable (which you seem to), then 
> the ability to have them in different files is also reasonable by extension.  

I don't follow your logic here. 

> The limitation that they have to be in the same file is just that, a 
> limitation.  It's not a feature leading to better design, or any other 
> rationalization like that.

Actually, I've read some SML programmers arguing exactly that, that it is a 
limitation leading to better designs, and that allowing the types and functions 
to be spread out will lead to more bad designs. Good SML programmers too. My 
opinion is closer to yours than theirs wrt functions, but I wouldn't just 
discount that opinion as nonsense. I'd have to hear more from a range of ML 
programmers on various sized projects, before changing my mind on types. 

> >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.
> 
> Define "for now".  

Until a generally better language and implementation for the sort of programming 
I do comes along, that has this feature. I'm not optimistic. 

> The other thing is that something crazy like the mixin modules thing will 
> incur runtime overhead to do the module creation at init time, where you 
> just don't need that to call functions, so there are arguments for adding 
> this even if you plan to do mixins in the long run.  But anyway, I doubt 
> I've convinced anybody on the other side of the fence.

I'm on your side for functions, though I have another axe to grind that annoys 
me even more, but still on the other side for types. If my pet problem (couldn't 
resist ;) were solved, it might allow better workarounds for spreading types 
across modules too, by functorizing the parts, and allowing you to instantiate 
the parts into a new type declaration.

-- 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