On bashing the OCaml-car...

On bashing the OCaml-car...

[Oliver Bandel]

Hello,

a while ago, there was the "If OCaml were a car"-thread.

Sorry for not answering directly (I'm using a webmailer
and the mail I'm answering to, is already saved somewhere else,
so I start a new thread on it).

I'm answerung to
  [
    Subject: Re: [Caml-list] If OCaml were a car
    From: skaller <skaller@users.sourceforge.net>
    Date: Mon, 20 Aug 2007 07:45:41 +1000
    Message-Id: <1187559941.6987.40.camel@rosella.wigram>
   ]


>
> On Sun, 2007-08-19 at 22:30 +0200, Tom wrote:
> > On 19/08/07, John Carr <jfc@mit.edu> wrote:
> >
> >         OCaml has a badly designed syntax processed by a badly
> >         implemented
> >         parser feeding into a backend that generates poor error
> >         messages.
> >         All this makes the language hard to use.
> >
> > I would just like to know, what exactly do you think is badly
> > designed, and what would be a better alternative? Mind that I am not
> > defending OCaml's syntax here (I have grown accustumed to it, but I do
> > not find it superb... probably...), I just think that all criticism
> > should be constructive (that is, shut up unless you've got a better
> > idea).
>
> I disagree with that: Most analysis is
> and should be destructive. Understanding problems is the
> precursor to constructing better solutions.
>
> Ocaml has lots of syntactic issues. It has too many operators,
> so that it is hard to remember their 'precedence'.


Learn it once, and then there will be no problem anymore.

> Some are
> very un-natural, for example:
>
>       if e then e1 else e2

I find this very natural.


>
> The thing is that 'else' has a different 'precedence' than 'then'.
> So you can write:
>
>       if e then e1 else a; b; c
>
> and a,b,c are all executed if the condition is false, but you
> cannot write:
>
>       if e then a; b; c else ...
>


This is completely logical.

In a if-then/if-then-else construct you have ONE expression
for the condition, ONE for the then-part and ONE for the else-part.

If you can remember the value ONE (one means: 1, type: int),
then this is completely logical and very fine.

  expr1; expr2; expr3

are NOT ONE expression; they are a sequence of expressions.


Using these if-then-else constructs can make it very easy to add new
if-then-else
constructs, when coding this way:

   if e then e1 else a;
   b;
   c


it's easy to add new lines (copy/paste; in vi/vim: yy p)

   if e then e1 else a;
   if e then e1 else a;
   if e then e1 else a;
   if e then e1 else a;
   b;
   c


and then reedit the expressions "e", "e1", "a" to new vlaues

   if e then e1 else a;
   if expr1 then e2 else foo;
   if expr2 then e3 else bar;
   if expr3 then e4 else baz;
   b;
   c


This makes editing fast (adding new if-then-else constructs,
without changing the rest of the code/behaviour).




And when you can remember "ONE" (1) this should be easy.

(To be detailed: maximum is ONE, when unit-value is used,
it's ZERO, nut maximum is ONE nevertheless; look below.)



> and similarly for let/in. So you need parentheses in the 'then' branch
> to write a 'larger' expression, but you need parentheses around the
> whole if/else to write a 'smaller' expression in the else
> branch ..

Yes.
And the reason is, that one expression will be used in
the if-then-else and not a sequence of expressions, so you have to
use paranthesis' or better: begin-else.

If it would be done differently, the number of expressions
will be different, and THAT would be a mess, IMHO.
Where to stop? Possibly you would nevertheless need
something that tells you, which code would be used,
and in C this would be { and }.




>
> Furthermore, because of the decision that procedures
> return unit, you can write:
>
>       if e then p;
>
> without the else, but only if p has type unit: the syntax is so
> confused it doesn't know if it is functional/expression based


Not the syntax is confused. YOU are confused!



There is one simple reason, why the else can be omitted,
if the type of the expressions is unit: If it's unit type,
it's ALWAYS unit type. There is only ONE possibility of unit-values!

But if it's of type int, the else-expression can't be forseen.

Would the else clause be 0, 1, 2, 3, 4, ... or any other
value, that would be of type int?
There is no way to find it out, and that's the reason,
why you have to use else in any other case than that
of using the unit type.
if you have unit, there will be only unit, and not unit(1), unit(2),
unit.(9) or  (3 *. unit)  something like that.

So, you can ignore the else-expression in this case,
because the resulting "value" is obvous.
( For unit-type the type and the value are "the same",
  possibly one could say for unit-type/unit-value,
  the value is the fixpoint of the type ).



If you are confused by it, you nevretheless can write

   if e then p else ();


Then all is, as you like it.




> (in which case the else expression should be mandatory)
> or procedural (in which case procedure calls should return void
> to prevent the call being used as an argument to an application).
>
> Felix procedures return void, and it provides
>
>       if e then e1 else e2 endif  // an expression
>       if e do
>               s1; s2; s3;
>       elif e1 then                // optional
>               s4; s5; s6;
>       else                        // optional
>               s7; s8; s9;
>       done;                       // a statement
>


This kind of C-ish style IMHO is much more confusing.
to know if "s7; s8; s9;" will be evaluated, I have
to translate this folded stuff into something plain.

If you have bigger constructs, where the conditions are
nested, it is not that easy to find out, which conditional
really is used. (But even the above one needs some time to
decypher.)

In OCaml I know that I have to use begin-end in the
else-expression and inside it could code more stuff.


But instead of such things I would rather use pattern matching like this way:


match (a,b,c,d,e) with
    true,  "hello", 47, None,      true   -> something()
    false, "world", 11, Some foo , true   -> something()
  | false,  _,      0,  _,         false  -> something_possibly_different()
  | false,  _,      _,  _,         _      -> something_completely_different()



IMHO that's much better to understand and to change,
than using nested if-then-elif-else-...-...-.-...-.-.-.-.-.-.-.----...-

When using the nested if-then-else-elif stuff, the whole
conditional stuff is folded geometrically.
This makes it less good to comprehend and unfold.
This is one major reason of semantical errors in
C-like languages.

OCaml is very clear here: in if-then or if-then-else you have
ONE expression, not any possible number of expressions, that
will be used.
This makes programming much clearer, IMHO.

And not to have elif or elsif or how you woud name it,
makes programming much clearer. :)

Use pattern matching, instead of the nested chaos of if-then-else-elif.


> and in both cases the text of the branches can be
> transparently swapped around.

Which it makes harder to follow the logic.
One has to unswap the code, when trying to comprehend it.
It's NOT obvious, which code will be evaluated!


> The cost is additional syntax
> and the mandatory terminator.

I thought you want to have LESS additional syntax?
So, your argumentation is not clear here.
You want less syntactiy issues, and with more you are happy?!




[...]
> Well it is NOT clear that all these alternatives are actually
> a good idea,


Maybe thinking about what I wrote above could make  it clear now?!


> just as it is NOT clear that excess use of camlp4 is
> a good idea. In my experience, using the language's raw syntax,
> even if it has warts, is more or less mandatory if you want
> other people to be able to read your code.
>
> Can Ocaml syntax be improved? Yes, but not much. Felix has:
>
>       print$ "Hello" + " World";
>
> which is stolen from Haskell and gets used a lot. Even if I can
> implement that with camplp4 I wouldn't. I'd like to see $ in
> the standard language: then I'd use it.


You want more syntactic issues?

I thought you asked for less!



[...]
> so I can add just one line without touching the rest
> of the code .. this is really cool!! .. so maybe the
> weird if/then/else isn't so bad after all ... :)


Yes. So, why do you bothering?!

Please, no more OCaml-bashing.

First read the manual and ask people,
what they think about something that you do not understand,
instead of blaming/bashing OCaml on that.

Thanks.

Ciao,
   Oliver


P.S.: For sequences of expressions and if-then-else,
      please look at section 6.7.2 in
        http://caml.inria.fr/pub/docs/manual-ocaml/expr.html

Re: [Caml-list] On bashing the OCaml-car...

[skaller]

On Mon, 2007-08-27 at 12:41 +0200, Oliver Bandel wrote:

> If you can remember the value ONE (one means: 1, type: int),
> then this is completely logical and very fine.
> 
>   expr1; expr2; expr3
> 
> are NOT ONE expression; they are a sequence of expressions.

Unfortunately no, this is indeed one expression.

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

Re: [Caml-list] On bashing the OCaml-car...

[skaller]

On Mon, 2007-08-27 at 12:41 +0200, Oliver Bandel wrote:

> Yes. So, why do you bothering?!
> Please, no more OCaml-bashing.

I am not Ocaml bashing: I'm analysing the consequences
of certain choices. I can write a lot of different
languages, Ocaml is only one. I also designed my own,
similar in some respects to Ocaml, and made some different
choices with different consequences.

My point is simply that the OP is right: Ocaml has a rather
convoluted and complex syntax that is hard to grasp.

Many people think functional programming is hard to learn,
contrarily, I think it is quite easy and takes about 1 hour,
since any programmer already knows it (though perhaps not
indepth techniques). When I first started using Ocaml I had
no problem with the functional programming aspect .. it was the
syntax I had problems with .. and clearly still do.

For example functors are a simple idea I understand from basic
category theory .. but simple math I can use to express the relations
between various algebraic data structures totally elude me in Ocaml.

I'm not the only one .. only the true masters even come close to
understanding why, in fact, it doesn't work without considerable
extra trickery (I have seen some of these solutions .. there
is no way in the world I could have come up with them).


-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

Re: [Caml-list] On bashing the OCaml-car...

[Oliver Bandel]

Zitat von skaller <skaller@users.sourceforge.net>:

> On Mon, 2007-08-27 at 12:41 +0200, Oliver Bandel wrote:
>
> > If you can remember the value ONE (one means: 1, type: int),
> > then this is completely logical and very fine.
> >
> >   expr1; expr2; expr3
> >
> > are NOT ONE expression; they are a sequence of expressions.
>
> Unfortunately no, this is indeed one expression.

In the manual they call it a sequence of expressions.
I think the reason why they called it this way, is to express something.

And, btw, if the whole functional programming paradigm is correct
(and if I understand it correct), a whole program can be seen as one
expression. (And *any* program can be expressed as *one* expression...
...possibly by rearanging it.)

So, this means: thie argument (that expr1; exprr2; expr 3  is one
expression) does not help here, if the whole program can be seen
as an expression.
If the whole program can be an expression, will a whole
program be possible in the if-then-else construct?

This would make no sense, IMHO.
So you would either need delimiters like { and }
or "elif" and "endif" or you say, only one basic expression
will be seen as an expression.

But if you think this would make sense, you can please explain me this.

If all can be expressed in lambda-calculus (which you might be
very fluently in), then languages like lisp or scheme would fit your
needs better? Then the whole program will be *obviously* one
expression.
But then there would be no need for any other syntax like the lambda calculus.

But OCaml is a multiparadigm language, so it has some additional syntax.
It's not your taste, but the taste of others.

Maybe it's only a kind of taste, but I like the OCaml style.

If you don't like the way it is, and like the C-ish/Perlish style more,
than this is your taste, and nothing where OCaml can be considered
badly designed. I don't say OCaml is perfect, but IMHO your arguments
were based on what you expected to be a good style of syntax
(if-then-else-stuff).

I have a different opinion on that and like OCaml the way it is.
I have used C and Perl a lot and really were annoyed from the
syntax of them. OCaml IMHO is much clearer here!

But you as a computer scientist / lambda calculus person,
(what I assume you are) may find OCaml's syntax unclear.
But I don't see, why C-ish/Perl-ish/Felix-ish style would be better.
IMHO it's worse.

It's a point of view, IMHO. I think the if-then-else-elif-endif-stuff
as you would prefer it, is best suited to make programs very clumsy.


Ciao,
   Oliver

Re: [Caml-list] On bashing the OCaml-car...

[Oliver Bandel]

Zitat von skaller <skaller@users.sourceforge.net>:

> On Mon, 2007-08-27 at 12:41 +0200, Oliver Bandel wrote:
>
> > Yes. So, why do you bothering?!
> > Please, no more OCaml-bashing.
>
> I am not Ocaml bashing: I'm analysing the consequences
> of certain choices. I can write a lot of different
> languages, Ocaml is only one. I also designed my own,
> similar in some respects to Ocaml, and made some different
> choices with different consequences.

Fine.
My appreciation for this.

>
> My point is simply that the OP is right: Ocaml has a rather
> convoluted and complex syntax that is hard to grasp.

It has a steep learning curve, yes.
At least for non-FP-programmers.

But the most things in OCaml have their advantages,
which sometimes - from a certain perspective - will not be seen!

Some people say, it's ugly, because it's not purely functional.
Other people appreciate that it is not dogmatic and offers
many paradigms. You and others dislike the if-then-else way of OCaml,
but I like it.

Before I had seen that only one single expression
is allowed in the if-then-else I also was somehow confused.
But in the manual it's mentioned. And after I was used to it,
I also have seen the advantages. So, what I mean here, is: something that
might look evil or stupid, from a different viewpoint is excellent!
And OCaml as a multiparadigm language offers many ways to look at things
differently.
For example OOP: OO sometimes is a good choice, sometimes it's annoying,
if you onyl want to have one object and not use  more objects of a certain kind.
So defining a class for one object? OCaml offers immediate objects.
Others might argue this is nonsense, or is not compatible with
"the correct way of <your_favourite_paradigm_or_style>".
But it brings good possibilities.

And that's what I mean: if you have a different taste,
and insist on your viewpoint you will have to look at some
properties in the same way, and in a certain way.

If you have found your absolutely perfect language
(you are the founder / have found it /created it),
then felix might be perfect?
Or would you write it differently today?


>
> Many people think functional programming is hard to learn,
> contrarily, I think it is quite easy and takes about 1 hour,
> since any programmer already knows it (though perhaps not
> indepth techniques). When I first started using Ocaml I had
> no problem with the functional programming aspect .. it was the
> syntax I had problems with .. and clearly still do.

I'm not quite sure, if it was the syntax also,
but as far as I remember, as FP was new to me, this
also was not so easy. I didn't found scheme much easier
to learn, even if the syntax was easier.

But maybe I have a different view, coming from mostly C and Perl.
(But compared to Haskell, I found some aspects of OCaml much easier!)



>
> For example functors are a simple idea I understand from basic
> category theory ..

Fine if you know this.
My appreciation for what you know.

But the syntax is a kind of taste (and perspective).


> but simple math I can use to express the relations
> between various algebraic data structures totally elude me in Ocaml.

??

There are other languages, which would fit your needs better, I would think.


>
> I'm not the only one .. only the true masters even come close to
> understanding why,


Possibly you can explain it.
Maybe there are already languages that make it possible
the way you like it.


> in fact, it doesn't work without considerable
> extra trickery (I have seen some of these solutions .. there
> is no way in the world I could have come up with them).

? explain this, please.



What I can say is: if you like a language, use it.
If you dislike the language: don't use it.
You should never use a language that you use
voluntarily, and at the sanme moment complain about it's
uglyness.

I don't like Java, so I don't use it.
There was a time, when I preferred Perl for nearly everything,
so I used it. Now I would prefer OCaml, so it's my first choice.
when I needed C, I have used it (or when I need it today, I will use it),
but don't complain about it's deficiencies.

Sometimes things I find out might be not so good.
It's OK to mention it. But if it's too bad, it would be time to leave it
alone. The maybe it would be time to write a new language.

But using a language and always read mails about the uglyness odes not make
sense IMHO.

And it make sense to ask for features of OCaml,
but to insist that OCaml should be rewritten by the OCaml-core team
is overconfident. They make their job, we ours.
So, we can ask for features, but we don't give the core-team the commands.

Sometimes, when I read the mails here, I think, people would
like to be the chief of the OCaml core-team.

IMHO we can be happy tho have such a good language like OCaml.
Look at M$. A company that I really dislike, but look,
what they have done: they didn't complained about OCaml,
they created F#.
So, appreciation for M$, the company I dislike, because they
made it in a very constructive way.

Ciao,
   Oliver

P.S.: If the Extlib-developers as the next project would write a
      language that is so much better than OCaml?
      I think, so many people who are complaining about OCaml so often,
      should then start such a project. And if the languge would be better
      for me, I would use it. But I don't see anything that goes into this
      direction.

Re: [Caml-list] On bashing the OCaml-car...

[Adrien]

> > My point is simply that the OP is right: Ocaml has a rather
> > convoluted and complex syntax that is hard to grasp.
>
> It has a steep learning curve, yes.
> At least for non-FP-programmers.

I have to say that French student in Mathematics are learning OCaml
(in fact caml light but it is somehow ... the same). Of course there
is the mathematical aspect but also that its syntax is simple and the
rules are precise. That makes it easier to learn but as you
mentionned, "At least for non-FP-programmers", though in fact I
personnaly started with C but I'm not the only person out there.


> > Many people think functional programming is hard to learn,
> > contrarily, I think it is quite easy and takes about 1 hour,
> > since any programmer already knows it (though perhaps not
> > indepth techniques). When I first started using Ocaml I had
> > no problem with the functional programming aspect .. it was the
> > syntax I had problems with .. and clearly still do.
>
> I'm not quite sure, if it was the syntax also,
> but as far as I remember, as FP was new to me, this
> also was not so easy. I didn't found scheme much easier
> to learn, even if the syntax was easier.
>
> But maybe I have a different view, coming from mostly C and Perl.
> (But compared to Haskell, I found some aspects of OCaml much easier!)

OCaml and FP in general is probably easy only for people with a
mathematical background even if pointers and not being able to pass a
function as a parameter just like one passes a value can actually slow
courses as it needs more explanations.
In fact I think I'll force some friends to follow an ocaml course by
me to check that. =P

And for the rest, I'd say I'm not qualified. =P