Hello Markus,

On Thu, 22 Aug 2002, Markus Mottl wrote:

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

OK, I believe it you.
I'm the beginner in Ocaml, not you. ;-)

I have to program more in Ocaml, then I will see
how it works.

After looking again on my sources (the one I mailed to the list)
I found some other things, I could do better, e.g. not use
Empty_Line for Line "", because it does not help much, but
yields some problems.

All in all I see, that I have some problems with Ocaml,
because I have not used it very often.

But even after this short time of using functional programming
(I looked a littlebid into it and then made a pause, looked
again in and made a pause) I'm very annoyed, when I use imperative
programming.
E.G. the reading of the lines and comparing them with my
ad-hoc parsing is really annoying, especially, when I
want to put the read text into an array of strings or
array of objects...

...when programming in the usual C-like style, I'm now
constantly annoyed.

I will try some more functional ideas and use recursion
instead of loops. I hope that helps.



[...]
> 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!

OK.

I maybe one day will see the advantages. ;-)

Ciao,
   Oliver

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