Re: [Caml-list] Calling a function with a self-defined type as argument

[Markus Mottl <markus@oefai.at>]

Oliver Bandel schrieb am Thursday, den 22. August 2002:
> But the Line ("text")-argument is only complete as a Line(),
> if Line() has a higher priority than the function-call.
> I have *one* argument, which is complete if given EMPTY,
> and complete if given Line ("argument").

The parser attempts to parse arguments of a function call, all of
which must be expressions. "Line" is not an expression, it's just a
data constructor. To disambiguate things, you have to use parentheses.
Note that your proposal that the compiler should use type definitions
to see how many arguments constructors take would make sources really
unreadable for humans.  Things are perfect as they are.

> Shouldn't be types have a higher priority than calls
> in this case?

"Line" is not a type but a data constructor. It just allows you to
discriminate between values.

> Is Line() in this example handled like an ordinary function?

Even if it were a function, you'd still need parentheses, otherwise you'd
get into troubles with partial function applications, which sometimes
need disambiguation, because the semantics wouldn't be necessarily clear.

> But I want here a complete picture, and I thought
> the compiler would put the parts together: How to
> put them together is clear: I have said it him in the
> type-declaration.

It may be clear here but not always. Even if things can be tractably
analyzed by an intelligent compiler, you still need to enforce readability
of sources. It would be absolute hell to let people parse such programs,
because they'd constantly have to look up type definitions in other
places to parse things correctly. Not a problem for a compiler - huge
problem for humans!

LG,
Markus

-- 
Markus Mottl                                             markus@oefai.at
Austrian Research Institute
for Artificial Intelligence                  http://www.oefai.at/~markus
-------------------
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