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

[Chris Hecker <checker@d6.com>]

>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'm trying to write a 
real shipping application in ocaml (currently 13kloc and will probably be 
4x that at ship, not the largest app ever written to be sure, but certainly 
not a test app).  Not allowing recursion makes it harder to refactor and 
improve compile times, which is not a good thing for process (especially 
since the native compiler is a bit pokey (6x slower than a C++ compiler for 
same LOC last time I checked), and my app can't run bytecode because the 
framerate is too low).  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.

I've already committed to using caml for this project and will see my 
experiment through to ship, so these things are just "annoyances" that just 
go in the "cons" column in the article I'm going to write at the end.  For 
somebody not as committed to trying it as me, they're probably showstoppers 
and they'll decide not to use caml.

> > 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?  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, and there are order of initialization 
issues (which there aren't if you just allow functions to be called, and 
not arbitrary values) if I undertstand it correctly.  Basically, this 
workaround is not making a professional programmer looking at ocaml feel 
better about using it for large projects, in my opinion.

>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.  I think this is a 
case of good old "you don't need that" syndrome, which computer people fall 
prey to all the time.  Somebody's favorite thing doesn't support X, so many 
bytes will be sacrificed convincing the other person that they don't need 
X.  It's a pretty big waste of time, in my opinion.  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.  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.

>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".  You have to decide when the workaround is doing more 
damage to the cause of making ocaml viable/more popular/whatever your goal 
is.  If it reduces pressure for a real solution, but you still have to 
explain the workaround with a straight face to every person who asks why 
their 4 line a.ml+b.ml example won't link with this fancy new "high level 
language" but their crappy C compiler can do it, then it's not clear to me 
that it's a win.

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.

Chris


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