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

[Chris Hecker <checker@d6.com>]

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

Sure, I was just indicating that there are some things that go beyond "pet 
problems" and get into "real problems", and I think this is one of 
them.    The question is just whether programming is enough of an 
engineering discipline to be able to say "this is a quantifiably bad thing 
for implementing large programs".  I guess it's not since things like this 
are still very subjective, but if it was then I'd say this function thing 
falls into that category because you want to enable decoupling.  It's also 
gray because compile times and coupling aren't going to kill a project, 
they're just going to make the process more painful than it needs to 
be.  So, the rationalizers always can point to success and say, "see, it 
wasn't needed", which misses the subtlety of the situation.

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

Hmm.  There are no "0th order" initialization order problems, since a 
function is always just callable (as opposed to trying to call through an 
uninitialized value).  I guess there are 1st order problems in that if A 
calls into B.f and B hasn't been initialized and B.f uses a global in B 
then you'll be in trouble.  I don't think there's a problem if you do not 
reference any globals, though.  I think it's still a valuable tool in that 
case, but yeah, I guess it's not totally safe.  That's probably why this 
hasn't been implemented.  I wonder what that patch did in this case, if 
anything.  Ah, here's Fabrice's original post, and it looks like you have 
to enforce the constraint manually:

http://groups.google.com/groups?selm=fa.hlh6e5v.1fmkppq%40ifi.uio.no
(related post by Xavier, replying to me complaing about this limitation in 
2001 when I learned about it :)
http://groups.google.com/groups?selm=fa.dks4ugv.1a6iho7%40ifi.uio.no

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

Sure, but again, there has to be some metric for when something is more 
than just an annoying flaw.  I guess large programs get written in caml, so 
by some measure it "works".  Maybe that is the only metric available at 
this point.  However, given that metric, large programs got written in asm, 
but that didn't stop people from trying to fix the "annoying flaws" and 
finding value in fixing them.  :)

>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 don't discount it as nonsense, I just trust professional programmers 
more.  We're so far away from a language that actually helps design 
programs for you, that any steps in that direction right now are usually 
naive and more limiting than useful, in my opinion.  Caml needs Obj.magic, 
for example.  It would be a less viable language without it, even though 
every argument for its use could be called "bad design".

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