Re: [Caml-list] Function forward declaration?

[skaller <skaller@users.sourceforge.net>]

On Thu, 2004-04-08 at 00:15, Richard Jones wrote:
> On Wed, Apr 07, 2004 at 11:52:17PM +1000, skaller wrote:
> > IMHO it isn't forward calling that is broken, 
> > but global variables.
> 
> A somewhat controversial viewpoint ...  While minimising the use of
> global variables might be a theoretical desirable goal, they are very
> useful when you're actually writing real programs under the schedule
> pressure for real users..

This may be the case with a poorly designed program,
or a programmer not practiced in the techniques of
avoiding them. Since people must work with others,
one is bound to run into this problem.

However, if you write your code to be reentrant from
scratch, and do so regularly, you soon learn the
idioms required, and soon enough the benefits
of explicitly passing values around will reward you,
and everyone who works with your code.

At least, that is my experience. I allow myself
to use global variables only for debugging.
And I get a bit annoyed when system software
isn't reentrant -- for example AFAIK Ocamlyacc parsing
engine uses global data, which is very annoying
because I actually have a need for recursive parsing
and I cannot do it: I'm forced to build temporary
data structures to defer the recursion.

> The trouble seems to be that I have a perfectly practical and
> reasonable desire to see prototypes added to the language, because,
> believe it or now, it helps to solve some problems in the Real World.

I'm familiar with the Real World  :D

> Now if there's some deep reason why it's actually impossible I would
> understand, but plenty of other languages (eg. C) seem to have
> prototypes and they get along just fine.

But they don't. There is a tradeoff between static assurance
and expressivity. Ocaml errs on the side of providing stronger
guarrantees at the expense of some loss of expressivity.

I believe that a large class of 'real world' problems
where you would use prototypes can be solved in a slightly
different way, by allowing some limited form of intermodule
recursion.

The Ocaml team is working on that Right Now. The CVS version
of Ocaml supports some intermodule recursion, but only
within a single compilation unit. If that proves successful
I believe the team will start work on extending the facility
to recursion across compilation unit boundaries.

If all goes as one hopes, this should increase the expressivity
of the language: the cost will be that some error checks are
defered to initialisation time. That is a reasonable compromise
since with simple enough initialisation one would expect
a single test to find all errors immediately.

> (Same, by the way, goes for a 'return' statement which OCaml is crying
> out for).

I don't think it makes any sense in Ocaml.

I'd like to explain why, by first explaining that
Felix *does* have an explicit return statement.

In Felix, there is a syntactic distinction between
statements and expressions. There is a semantic
difference too: statements may have side effects,
expressions may not. Within a function, you can
use statements provided the side effects don't
propogate outside the function's closure.

Syntactically, because a function is made up
of imperative statements, there must be an
explicit return statement.

In Ocaml, expressions can have side effects.
So there is no need for a syntactic category
other than expressions for executable code.
So a return statement would be impossible
syntactically, it would have to be a return *expression*.

It is easy to define: here it is:

	let return x = x

and you can use it wherever you want.

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



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