Re: [Caml-list] productivity improvement

Re: [Caml-list] productivity improvement

[Oleg]

On Tuesday 09 July 2002 04:04 pm, John Carr wrote:
> > [1] cat source | sed "s/ //" | wc -c
>
> You need a 'g' at the end of the sed command, or use the simpler:
>
> tr -d ' ' < source | wc -c

cat source | sed "s/[[:space:]]//g" | wc -c

to catch '\t' too, while we are at it.

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

Re: [Caml-list] productivity improvement

[Oleg]

On Tuesday 16 July 2002 01:29 pm, Shannon --jj Behrens wrote:

> Wow, that's an impressive piece of C++!!!  C++ never
> seems to stop surprising me!  Nonetheless, I feel the
> OCAML version is infinitely more readable.
>
> Best Regards,
> -jj
[...]

I'd say, to a person equally familiar with O'Caml and C++, the readability 
ratio is less than 2 [1] The readability of compiler messages is a whole 
different story: G++ gives horrible messages when templates, or, god forbid, 
STL errors are present [2]

However, the C++ version looks more "extensible" to me: Suppose that in a 
while, you decide that you want your "node" to be not only Leaf or Unop or 
Binop, but also Triop:

type 'a node = Leaf of 'a | Unop of ('a->'a) * 'a node | Binop of ('a * 'a -> 
'a) * 'a node * 'a node | Triop of ('a * 'a * 'a -> 'a) * 'a node * 'a node * 
'a node;;

You will need to modify the original node type and function "eval" by adding 
an extra pattern to "match" statement, and then recompile everying that 
depends on it. At the same time, with C++ the type of node remains the same. 
You just need to derive a new class  from it:

template<class T>
struct triop : public node<T> {
      T (*fun)(T, T, T);
      node<T> &n1;
      node<T> &n2;
      node<T> &n3
      T eval() { return fun(n1.eval(), n2.eval(), n3.eval); }
      triop (T (*f)(T, T, T), node<T>& N1, node<T>& N2, node<T>& N3) : 
fun(f), n1(N1),  n2(N2), n3(N3) {}  
};

Recompiling isn't necessary. In fact, "old code" may call "new code" if you 
happen to pass it a node that happens to be a triop.

Oleg

P.S. Having read the CalTech tutorial and chapters 1-4 & 14 of the O'Reilly 
book, and having gotten some experience with O'Caml, I'm running low on 
motivation right now. Please give me examples of what's 
hard/awkward/impossible in C++, but relatively easy in O'Caml, if any (I have 
only finite time, so 50 KLOC Coq is not a good example :)

P.P.S. My primary interest is statistical AI (artificial neural networks). I 
haven't found any relevant libraries or applications in SML or O'Caml. That 
is a bit discouraging.

[1] And the example was hand-picked!
[2] If one doesn't want "ad hoc" genericity, templates aren't necessary, of 
course.
-------------------
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

Re: [Caml-list] productivity improvement

[Brian Smith]

Oleg wrote:
> You will need to modify the original node type and function "eval" by adding 
> an extra pattern to "match" statement, and then recompile everying that 
> depends on it. At the same time, with C++ the type of node remains the same. 
> You just need to derive a new class  from it:

I am wondering about this point too. But, perhaps you can use O'Caml 
classes to do the same thing as the C++ template classes?

Anway, I think that the above "problem" can also be an asset. If you are 
building an interpreter, and you add a new construct to the interpreted 
language, then all code that claims to know about every construct will 
become erroneous, and so you will know right away what new code needs to 
be added. There doesn't seem to be anything like that in an 
inheritance-based model.

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

Re: [Caml-list] productivity improvement

[William Lovas]

On Thu, Jul 18, 2002 at 07:14:06PM -0400, Oleg wrote:
> However, the C++ version looks more "extensible" to me: Suppose that in a 
> while, you decide that you want your "node" to be not only Leaf or Unop or 
> Binop, but also Triop:
> 
> type 'a node = Leaf of 'a | Unop of ('a->'a) * 'a node | Binop of ('a * 'a -> 
> 'a) * 'a node * 'a node | Triop of ('a * 'a * 'a -> 'a) * 'a node * 'a node * 
> 'a node;;
> 
> You will need to modify the original node type and function "eval" by adding 
> an extra pattern to "match" statement, and then recompile everying that 
> depends on it. At the same time, with C++ the type of node remains the same. 
> You just need to derive a new class  from it:
> 
> [snip]
>
> Recompiling isn't necessary. In fact, "old code" may call "new code" if you 
> happen to pass it a node that happens to be a triop.

Yes, but what if you decide to add a new function on nodes?  Like say,
typecheck, or eval2, with slightly different semantics?  In the O'Caml
version, it's as simple as that -- add a new function and run with it.
With the C++ version, though, now you have to modify *every* *single*
*class* that inherits from node, and recompile them all.  

So it really seems that it's just a question of what's most important for
your own particular purpose.  Someone looking to extend the definition of
node indefinitely would prefer an object-oriented version, while someone
focused on providing new functionality over nodes would prefer the
functional version.

> Oleg
> 
> P.S. Having read the CalTech tutorial and chapters 1-4 & 14 of the O'Reilly 
> book, and having gotten some experience with O'Caml, I'm running low on 
> motivation right now. Please give me examples of what's 
> hard/awkward/impossible in C++, but relatively easy in O'Caml, if any (I have 
> only finite time, so 50 KLOC Coq is not a good example :)

It strikes me that although you were able to quite easily translate this
toy evaluator example into C++, this may not have been the case with a
larger, more complex example.  It's something that scales exponentially, so
you're probably not going to find very many small, concise examples that 
show conclusively how much easier O'Caml is.  (And, of course, you have to 
take into account the style question mentioned above.  One style does not
necessarily fit all.)

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

Re: [Caml-list] productivity improvement

[Oleg]

On Thursday 18 July 2002 07:54 pm, William Lovas wrote:
> On Thu, Jul 18, 2002 at 07:14:06PM -0400, Oleg wrote:
> > However, the C++ version looks more "extensible" to me: Suppose that in a
> > while, you decide that you want your "node" to be not only Leaf or Unop
> > or Binop, but also Triop:
> >
> > type 'a node = Leaf of 'a | Unop of ('a->'a) * 'a node | Binop of ('a *
> > 'a -> 'a) * 'a node * 'a node | Triop of ('a * 'a * 'a -> 'a) * 'a node *
> > 'a node * 'a node;;
> >
> > You will need to modify the original node type and function "eval" by
> > adding an extra pattern to "match" statement, and then recompile everying
> > that depends on it. At the same time, with C++ the type of node remains
> > the same. You just need to derive a new class  from it:
> >
> > [snip]
> >
> > Recompiling isn't necessary. In fact, "old code" may call "new code" if
> > you happen to pass it a node that happens to be a triop.
>
> Yes, but what if you decide to add a new function on nodes?  Like say,
> typecheck, or eval2, with slightly different semantics?  In the O'Caml
> version, it's as simple as that -- add a new function and run with it.
> With the C++ version, though, now you have to modify *every* *single*
> *class* that inherits from node, and recompile them all.
[...]

Not really. Run-time type identification (RTTI) and a "switch" statement 
should work in a free (non-member) function just like O'Caml's "match" AFAIK.

Regards,
Oleg
-------------------
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

Re: [Caml-list] productivity improvement

[Oleg]

On Friday 19 July 2002 03:03 am, Issac Trotts wrote:
> Right, so how is your C++ compiler going to remind you when you forget to
> include a needed case in the switch statement (assuming there is something
> in the typeinfo to switch on; you can't switch on a string in C++.)  OCaml
> will remind you, but I don't see how a C++ compiler could.

Correct. Since C++ compiler can not possibly know of all existent sub-types, 
there is no way it can warn you. This is why virtual member functions are 
still preferred. 

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

Re: [Caml-list] productivity improvement

[Andreas Rossberg]

Oleg wrote:
> 
> On Friday 19 July 2002 03:03 am, Issac Trotts wrote:
> > Right, so how is your C++ compiler going to remind you when you forget to
> > include a needed case in the switch statement (assuming there is something
> > in the typeinfo to switch on; you can't switch on a string in C++.)  OCaml
> > will remind you, but I don't see how a C++ compiler could.
> 
> Correct. Since C++ compiler can not possibly know of all existent sub-types,
> there is no way it can warn you. This is why virtual member functions are
> still preferred.

And how would you do more complex case analysis, corresponding to nested
patterns? This is more than cumbersome and error-prone in C++ - with
RTTI, and even more so with method dispatch, where your single algorithm
will have to be scattered over tons of distant functions. A maintenance
nightmare.

BTW, as Issac noted, you cannot even use switch statements to perform
RTTI in C++. You have to program if cascades.

-- 
Andreas Rossberg, rossberg@ps.uni-sb.de

"Computer games don't affect kids; I mean if Pac Man affected us
 as kids, we would all be running around in darkened rooms, munching
 magic pills, and listening to repetitive electronic music."
 - Kristian Wilson, Nintendo Inc.
-------------------
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

Re: [Caml-list] productivity improvement

[Alessandro Baretta]

Andreas Rossberg wrote:
> Oleg wrote:
>>
>>Correct. Since C++ compiler can not possibly know of all existent sub-types,
>>there is no way it can warn you. This is why virtual member functions are
>>still preferred.
> 
> And how would you do more complex case analysis, corresponding to nested
> patterns? This is more than cumbersome and error-prone in C++ - with
> RTTI, and even more so with method dispatch, where your single algorithm
> will have to be scattered over tons of distant functions. A maintenance
> nightmare.
> 
> BTW, as Issac noted, you cannot even use switch statements to perform
> RTTI in C++. You have to program if cascades.
> 

Yes, but RTTI is a hack. Nobody would seriously "plan" to 
use RTTI during the design stage of a software system. You 
just "happen" to need RTTI when most of the code is already 
there and you realize there is a bug in the specification 
which would require to redesign the inheritance hieararchy. 
In such cases you go with RTTI. Otherwise, you'd stick to 
simple OO polymorphism, which is the "Right Way(TM)" to use 
case/pattern matching constructs in C++. In C++ all you have 
to encapsulate runtime types is the class construct. Because 
of its native polymorphism, one could argue that RTTI and 
case statements are never really needed. The only arise out 
of design errors. Of course, the latter seem to be fairly 
frequent in a language that does not enforce sensible coding 
conventions. Consider <reinterpret_cast> ...

Alex

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

Re: [Caml-list] productivity improvement

[John Max Skaller]

Alessandro Baretta wrote:

>
> Yes, but RTTI is a hack. 


Matches on ocaml unions _also_ use run time checks.

> Nobody would seriously "plan" to use RTTI during the design stage of a 
> software system. 

Sure they do.

> You just "happen" to need RTTI when most of the code is already there 
> and you realize there is a bug in the specification which would 
> require to redesign the inheritance hieararchy. In such cases you go 
> with RTTI. Otherwise, you'd stick to simple OO polymorphism, which is 
> the "Right Way(TM)" to use 


No. (class based) object orientation is utterly flawed as a paradigm, as 
can be seen
by posing the trivial problem of representing any type with a binary 
operator.
It just can't be done, the problem is called 'covariance problem'.

I find it hard to state what the problem is here, but I'll try:
the problem is you can write an unimplementable interface
and not get a type error:

    struct X { virtual bool binop(X const&)const=0; };

No (realistic) instances of this class can be constructed
because no derived class can implement the method binop.
[That is a fact not to be debated] The problem then is that
you can reasonably expect to write this interface for
say a 'number' type.

In commerical applications, almost ALL data is relational,
and so cannot be abstracted. The OO paradigm is not just
useless here, but downright destructive.

Example:

    class Transaction { ..
    class Invoice { ...

Well, suppose you wanted more than one kind of transaction,
and more than one kind of invoice .. some ignorant designer
would think polymorpism would work here.

I doesn't though. You you end up using RTTI hacks,
NOT because of a design error .. but because the very paradigm
is faulty.

Not I'm not saying objects/classes etc are useless. I'm saying
they're just a tool with some limited uses: they perform well
when restricted to those uses. If no covariant methods are needed,
abstraction works. For example: device drivers typically have
methods with invariant arguments.

-- 
John Max Skaller, mailto:skaller@ozemail.com.au
snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia.
voice:61-2-9660-0850




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

Re: [Caml-list] productivity improvement

[Brian Smith]

John Max Skaller wrote:
> Alessandro Baretta wrote:
> No. (class based) object orientation is utterly flawed as a paradigm, as 
> can be seen by posing the trivial problem of representing any type
 > with a binary operator.
> It just can't be done, the problem is called 'covariance problem'.
> 
> I find it hard to state what the problem is here, but I'll try:
> the problem is you can write an unimplementable interface
> and not get a type error:
> 
>    struct X { virtual bool binop(X const&)const=0; };

Do you really mean _all_ class-based object orientation? Don't 
multimethods and/or overloading help in this case?

bool equals(x : 'a,      y : 'b)      = false ;
bool equals(x : Integer, y : Integer) = x.intValue() = y.intValue() ;
bool equals(x : String,  y : String)  = (* compare all the chars *) ;
bool equals(x : String,  y : Integer) = equals(x, y.toString()) ;

This seems to be what Nice does. Nice is based on the 
ML(less-than-or-equal) type system.

Perhaps, your comments only apply to a certain subset of class-based 
object-orietned languages?

- Brian



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

Re: [Caml-list] productivity improvement

[John Max Skaller]

Brian Smith wrote:

> John Max Skaller wrote:
>
>> Alessandro Baretta wrote:
>> No. (class based) object orientation is utterly flawed as a paradigm, 
>> as can be seen by posing the trivial problem of representing any type
>
> > with a binary operator.
>
>> It just can't be done, the problem is called 'covariance problem'.
>>
>> I find it hard to state what the problem is here, but I'll try:
>> the problem is you can write an unimplementable interface
>> and not get a type error:
>>
>>    struct X { virtual bool binop(X const&)const=0; };
>
>
> Do you really mean _all_ class-based object orientation? Don't 
> multimethods and/or overloading help in this case? 


I don't understand really. The requirment is for an interface specification
and (the possibility of) multiple representations.

Multimethods are just a slightly more sophisticated dispatch technique,
they necessarily break object encapsulation, and there is still
no way to represent n squared functions any way other
than with n squared functions. :-)

Does overloading help? Sure. It is the only solution.
More precisely,  a convenient syntax for naming
the n squared functions.

>
>
> bool equals(x : 'a,      y : 'b)      = false ; 


> bool equals(x : Integer, y : Integer) = x.intValue() = y.intValue() ;
> bool equals(x : String,  y : String)  = (* compare all the chars *) ; 

Both these cases show a common representation.

What is the type of x.intValue()?
Obviously this is bogus. There is a total loss of abstraction.
Clearly, the only type of Integer of any use at all is 'int'.
Obviously won't work for 'long long int'. ;-)

The second case is more interesting, since the String
contents are concrete, but the representation of the
sequencing of them internally is abstracted.

In other words, different implementations can
exist of the *same* type String.  This is a good use
of class based object orientation (providing
one level of representation independence).

Q: Why does it work?
A: because the characteristic methods of the abstraction

    x.get(i) // get nth char
    x.set(i,c) // set ith char to c

have *invariant* arguments. In particular,
i and c are specific concrete types.

> bool equals(x : String,  y : Integer) = equals(x, y.toString()) ; 

Urg :-)

>
> This seems to be what Nice does. Nice is based on the 
> ML(less-than-or-equal) type system.
>
> Perhaps, your comments only apply to a certain subset of class-based 
> object-orietned languages?

My comment applies to considering object orientation as a *paradigm*.
It is language independent, entailing mutable objects, encapsulation,
and subtyping (possibly via inheritance).

Ocaml and C++  are both object oriented languages, and they are both better
than pure ones precisely because classes are only one available
technique.  Classes are useful, dynamic *linear* dispatch is not to be
sneered at. (and multimethod research is useful, to find
'almost linear' dispatch techniques). [linear dispatch uses
an indexed table lookup, and so is constant time]


-- 
John Max Skaller, mailto:skaller@ozemail.com.au
snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia.
voice:61-2-9660-0850




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

Re: [Caml-list] productivity improvement

[Alessandro Baretta]

John Max Skaller wrote:
> Alessandro Baretta wrote:
> 
>>
>> Yes, but RTTI is a hack. 
> 
> 
> 
> Matches on ocaml unions _also_ use run time checks.

Sure. Pattern matching is not a problem when it's idiomatic 
and safe. You can say that pattern matching is the most 
basic construct in O'Caml--even let x = 1 is a pattern 
matching. C++, on the other hand, has *no* pattern matching 
construct. RTTI is a kludge, retrofitted on a badly flawed 
language, because there were situations where OO 
polymorphism could not be used.

>> Nobody would seriously "plan" to use RTTI during the design stage of a 
>> software system. 
> 
> Sure they do.

Some people even go bungee jumping o sky diving. You just 
wouldn't beleive how crazy people can get.

>> You just "happen" to need RTTI when most of the code is already there 
>> and you realize there is a bug in the specification which would 
>> require to redesign the inheritance hieararchy. In such cases you go 
>> with RTTI. Otherwise, you'd stick to simple OO polymorphism, which is 
>> the "Right Way(TM)" to use 
> 
> No. (class based) object orientation is utterly flawed as a paradigm, as 
> can be seen
> by posing the trivial problem of representing any type with a binary 
> operator.
> It just can't be done, the problem is called 'covariance problem'.

I searched Google for a covariance problem related to 
unimplementable interfaces but with no luck. Could you point 
me to some literature?

>    struct X { virtual bool binop(X const&)const=0; };

Tell me if I got this straight: OO polymorphism requires 
that inheriting classes wishing to override methods of 
parents must use covariant return types and contravariant 
parameter types, so as to guarantee that inheritance implies 
subtyping. In this case, it would be meaning less to 
implement interface X because, applying the contravariance 
principle to the formal parameter of binop, you'd end up 
with a class whose binop will accept as rhs parameters any 
instance of any subtype of X. Therefore a class Integer will 
have a greater_than_binop accepting instances of class 
Rational, Real, Complex, Quaternion ... This is meaningless, 
of course, so we conclude that establishing an identity 
between inheritance and subtyping relations is paradoxical. 
Correct?

> In commerical applications, almost ALL data is relational,
> and so cannot be abstracted. The OO paradigm is not just
> useless here, but downright destructive.

Slow... What? I don't follow you here.

> Example:
> 
>    class Transaction { ..
>    class Invoice { ...
> 
> Well, suppose you wanted more than one kind of transaction,
> and more than one kind of invoice .. some ignorant designer
> would think polymorpism would work here.
> 
> I doesn't though. You you end up using RTTI hacks,
> NOT because of a design error .. but because the very paradigm
> is faulty.

I can't say. All the literature I read on OO languages 
(_Teach_yourself_C++_in_21_days_/_Java_for_Dummies_ :-) ) 
seems to indicate that RTTI is "intracardiac adrenaline" of 
fibrillating software systems. You try RTTI, then, if it 
dies all the same, you type "rpm --install 
ocaml-3.04.<your_arch>.rpm" and start a new life.

> Not I'm not saying objects/classes etc are useless. I'm saying
> they're just a tool with some limited uses: they perform well
> when restricted to those uses. If no covariant methods are needed,
> abstraction works. For example: device drivers typically have
> methods with invariant arguments.

That's why Linux is coded in C as opposed to C++. I wonder 
about the possibility of writing a functional kernel...

Anyway, it is now appropriate to conclude with: Long live 
the Caml!

Alex



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

Re: [Caml-list] productivity improvement

[John Max Skaller]

Alessandro Baretta wrote:

>
>>    struct X { virtual bool binop(X const&)const=0; };
>
>
> Tell me if I got this straight: OO polymorphism requires that 
> inheriting classes wishing to override methods of parents must use 
> covariant return types and contravariant parameter types, so as to 
> guarantee that inheritance implies subtyping. In this case, it would 
> be meaning less to implement interface X because, applying the 
> contravariance principle to the formal parameter of binop, you'd end 
> up with a class whose binop will accept as rhs parameters any instance 
> of any subtype of X. Therefore a class Integer will have a 
> greater_than_binop accepting instances of class Rational, Real, 
> Complex, Quaternion ... This is meaningless, of course, so we conclude 
> that establishing an identity between inheritance and subtyping 
> relations is paradoxical. Correct? 


The problem is that for arbitrary implementations of the abstractionX,
you clearly cannot encode the primitive binop without knowing
the representation of 'this' and the argument. This is a precise
assertion compared to saying it is 'meaningless': often there
is a good meaning (sure you can add Rationals and quaternions .. :-)

Note that the assertion is not a theorem: it is an *assumption*.
So it cannot be questioned.

>
>
>> In commerical applications, almost ALL data is relational,
>> and so cannot be abstracted. The OO paradigm is not just
>> useless here, but downright destructive.
>
>
> Slow... What? I don't follow you here. 


A relational database is just an encoding of
functions like

    'a ~b'

by making a table of a and b columns.
But ~ is a binary operator.


-- 
John Max Skaller, mailto:skaller@ozemail.com.au
snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia.
voice:61-2-9660-0850




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

Re: [Caml-list] productivity improvement

[Oleg]

On Friday 19 July 2002 04:57 am, Andreas Rossberg wrote:
> And how would you do more complex case analysis, corresponding to nested
> patterns? 

I think I know what nested patterns are (something like 
Node (x, y, Bla(1, _)) -> ...), but I don't see where any extra difficulty 
will come from while using virtual functions. Could you give specific 
examples please?

> This is more than cumbersome and error-prone in C++ - with
> RTTI, and even more so with method dispatch, where your single algorithm
> will have to be scattered over tons of distant functions. A maintenance
> nightmare.

Why would maintaining code organized by data type be harder? Isn't it what 
encapsulation is all about?

> BTW, as Issac noted, you cannot even use switch statements to perform
> RTTI in C++. You have to program if cascades.

That is correct. I never actually had to use RTTI, so I thought typeid could 
be converted into int.

Regards,
Oleg
-------------------
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

Re: [Caml-list] productivity improvement

[Andreas Rossberg]

Oleg wrote:
> 
> > And how would you do more complex case analysis, corresponding to nested
> > patterns?
> 
> I think I know what nested patterns are (something like
> Node (x, y, Bla(1, _)) -> ...), but I don't see where any extra difficulty
> will come from while using virtual functions. Could you give specific
> examples please?

Consider a simple expression language again. This time extended with
variables and function expressions:

  type 'a expr = Const of 'a | Var of string
               | Unop of 'a -> 'a
               | Binop of 'a -> 'a -> 'a
               | Lambda of string * 'a expr
               | Apply of 'a expr * 'a expr

Evaluation has to rely on (one-step) reduction (sketch only):

 let rec reduce1 env = function
 | Var x -> List.assoc x env
 | Apply (Lambda (x, e), v) -> eval ((x,v)::env) e
 | Apply (Unop f,  Const x) -> Const (f x)
 | Apply (Binop f, Const x) -> Unop (f x)
 | Apply  _ -> raise Error
 | e -> e

Doing this with method dispatch requires serious amounts of object
spaghetti. I believe you are imaginative enough to see that this is
absolutely hopeless for realistic examples with a large number of more
complex cases - the number of additional helper methods polluting all
your classes will grow exponentially. (And note that even multiple
dispatch isn't expressive enough to avoid that.)

> > This is more than cumbersome and error-prone in C++ - with
> > RTTI, and even more so with method dispatch, where your single algorithm
> > will have to be scattered over tons of distant functions. A maintenance
> > nightmare.
> 
> Why would maintaining code organized by data type be harder? Isn't it what
> encapsulation is all about?

No. That's one of the things OO ideology gets wrong. Making the type the
unit of encapsulation is much too inflexible. Often you want to
encapsulate several types simultanously, e.g. when you have functions
operating on a group of closely related types, which cannot sensibly be
implemented knowing only one of the types' internals. Thus
orthogonalising types and modules is a definite plus.

-- 
Andreas Rossberg, rossberg@ps.uni-sb.de

"Computer games don't affect kids; I mean if Pac Man affected us
 as kids, we would all be running around in darkened rooms, munching
 magic pills, and listening to repetitive electronic music."
 - Kristian Wilson, Nintendo Inc.
-------------------
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

Re: [Caml-list] productivity improvement

[John Max Skaller]

Andreas Rossberg wrote:

>
>No. That's one of the things OO ideology gets wrong. Making the type the
>unit of encapsulation is much too inflexible. Often you want to
>encapsulate several types simultanously, e.g. when you have functions
>operating on a group of closely related types, which cannot sensibly be
>implemented knowing only one of the types' internals. Thus
>orthogonalising types and modules is a definite plus.
>
Yes. When I read OOSC (Meyer), I thought it was pretty good science.
I still do, because one can pinpoint the error to the decision to map
both modules and types onto the class construction.

 From a category viewpoint, however,
it is obvious OO is limited and gets a fundamental idea completely wrong:
in OO, methods are used to abstract a type from its representation,
and the coding is *intrinsic*, that is, 'inside the object' which is called
encapsulation.

But in the categorical model, the types are simple points
with no properties at all: the 'type' structure is *extrinsic*.
The beauty of the categorical model is that the semantics
of the 'types' can be determined entirely without
specifying any encoding of the functions!
It is necessary only to specify how they compose.

Anyhow, this is why I think OO is a waste of time as a 'paradigm':
it get the fundamental answer to the question completely wrong.
The question, of course is:

    how do we represent abstractions?

Ocaml modules are not right either, but they're much
better answer in general.

-- 
John Max Skaller, mailto:skaller@ozemail.com.au
snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia.
voice:61-2-9660-0850




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

Re: [Caml-list] productivity improvement

[Brian Rogoff]

William Lovas writes:
> It strikes me that although you were able to quite easily translate this
> toy evaluator example into C++, this may not have been the case with a
> larger, more complex example. 

Even this toy example was not really translated into C++. Translating OCaml 
functions, which can be closures, to C style function pointers, is a cheat. 
To be accurate, you need to model these as C++ functors (yes, I hate that 
terminology but that's what Stroustrup uses) to simulate closures. This is 
inevitably a pain, because simulating nested functions in a lexically
scoped language means that the object constructor has to have the variables 
that the "execute" function uses explicitly passed in. 

> It's something that scales exponentially, so you're probably not going to 
> find very many small, concise examples that show conclusively how much 
> easier O'Caml is. 

Actually, I think that there are quite a few.

Anyways, if you're interested in pursuing the extensibility question raised
here further, Jacques Garrigue wrote a nice little paper comparing sum types,
polymorphic variants, and classes on a simple evaluator example. 

http://wwwfun.kurims.kyoto-u.ac.jp/~garrigue/papers/fose2000.html

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

Re: [Caml-list] productivity improvement

[Eray Ozkural]

On Friday 19 July 2002 19:35, Brian Rogoff wrote:
> To be accurate, you need to model these as C++ functors (yes, I hate that
> terminology but that's what Stroustrup uses) to simulate closures. This is

You can just say "function object" instead. "Functor" in STL is abuse of 
terminology. The "functor" in caml makes mathematical sense since a functor 
goes from one category to another as we all know. :P

-- 
Eray Ozkural <erayo@cs.bilkent.edu.tr>
Comp. Sci. Dept., Bilkent University, Ankara
www: http://www.cs.bilkent.edu.tr/~erayo
GPG public key fingerprint: 360C 852F 88B0 A745 F31B  EA0F 7C07 AE16 874D 539C
-------------------
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

Re: [Caml-list] productivity improvement

[Alessandro Baretta]

Oleg wrote:

> P.S. Having read the CalTech tutorial and chapters 1-4 & 14 of the O'Reilly 
> book, and having gotten some experience with O'Caml, I'm running low on 
> motivation right now. Please give me examples of what's 
> hard/awkward/impossible in C++, but relatively easy in O'Caml, if any (I have 
> only finite time, so 50 KLOC Coq is not a good example :)

I am in the process of finishing up a simple XML stylesheet 
processor which formats ascii data for a line printer. Very 
simple. About 1000 odd lines of code in O'Caml. Would a 
project of this kind and size suit your interest? You might 
try to code a processor for the same dtd, so that we can 
measure di difference in "semantic density" of O'Caml and 
C++, within the limits of our respective abilities with the 
two languages (I'm not an O'Caml guru--yet...)

> P.P.S. My primary interest is statistical AI (artificial neural networks). I 
> haven't found any relevant libraries or applications in SML or O'Caml. That 
> is a bit discouraging.

I have a feeling that O'Caml was born out INRIA's need for a 
language to use in symbolic AI projects. The two worlds seem 
to be very difficult to reconcile.

> [1] And the example was hand-picked!
> [2] If one doesn't want "ad hoc" genericity, templates aren't necessary, of 
> course.

Ah! Wait a minute. I have another toy project I could 
propose to you: an interpreter for rule based language, à la 
CLIPS. 197 lines of code in ocaml, including comments. This 
is probably the kind of compelling example you are looking 
for. I coded it in 24 h, including time for sleep, nutrition 
and general self care.

Let me know if you are interested.

Alex

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

Re: [Caml-list] productivity improvement

[Oleg]

On Thursday 18 July 2002 09:25 pm, Alessandro Baretta wrote:

[...]

> Ah! Wait a minute. I have another toy project I could
> propose to you: an interpreter for rule based language, à la
> CLIPS. 197 lines of code in ocaml, including comments. This
> is probably the kind of compelling example you are looking
> for. I coded it in 24 h, including time for sleep, nutrition
> and general self care.
>
> Let me know if you are interested.

Sure, if it's really compelling, and if I won't have to guess the language 
specifications.

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

Re: [Caml-list] productivity improvement

[Eray Ozkural]

On Friday 19 July 2002 04:25, Alessandro Baretta wrote:
>
> > P.P.S. My primary interest is statistical AI (artificial neural
> > networks). I haven't found any relevant libraries or applications in SML
> > or O'Caml. That is a bit discouraging.
>
> I have a feeling that O'Caml was born out INRIA's need for a
> language to use in symbolic AI projects. The two worlds seem
> to be very difficult to reconcile.
>

Interesting, but I still think ocaml maintains its superiority not only in 
traditional string and list processing but algorithmic prowess as well.

I have a feeling I can beat any ANN implementation written in C++ for that 
matter ;) I was writing a generic ANN library in C++ and found it to be quite 
difficult to put together different kinds of networks and algorithms in the 
same basket. It would really benefit from a well designed generic graph 
library which I can imagine would be possible only in a functional language.

Cheers,

-- 
Eray Ozkural <erayo@cs.bilkent.edu.tr>
Comp. Sci. Dept., Bilkent University, Ankara
www: http://www.cs.bilkent.edu.tr/~erayo
GPG public key fingerprint: 360C 852F 88B0 A745 F31B  EA0F 7C07 AE16 874D 539C
-------------------
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

Re: [Caml-list] productivity improvement

[Oleg]

On Tuesday 15 October 2002 05:31 am, Eray Ozkural wrote:

> I have a feeling I can beat any ANN implementation written in C++ for that
> matter ;) I was writing a generic ANN library in C++ and found it to be
> quite difficult to put together different kinds of networks and algorithms
> in the same basket. It would really benefit from a well designed generic
> graph library which I can imagine would be possible only in a functional
> language.

"Beat" in what sense? Should you decide to write an O'Caml ANN library that 
learns better or faster than PDP++, SNNS and Torch, I can't imagine anyone 
trying to keep you from doing it.

BTW BOOST has some sort of template graph library by Jeremy Siek.

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

Re: [Caml-list] productivity improvement

[Eray Ozkural]

On Tuesday 15 October 2002 15:34, Oleg wrote:
> On Tuesday 15 October 2002 05:31 am, Eray Ozkural wrote:
> > I have a feeling I can beat any ANN implementation written in C++ for
> > that matter ;) I was writing a generic ANN library in C++ and found it to
> > be quite difficult to put together different kinds of networks and
> > algorithms in the same basket. It would really benefit from a well
> > designed generic graph library which I can imagine would be possible only
> > in a functional language.
>
> "Beat" in what sense? Should you decide to write an O'Caml ANN library that
> learns better or faster than PDP++, SNNS and Torch, I can't imagine anyone
> trying to keep you from doing it.
>

I think better in the sense of extensibility, it could be made to allow more 
sophisticated learning algorithms or ANN models. It could be made just as 
efficient as any C code, or even faster who knows. Actually, what I have in 
mind is a general purpose machine learning library which has all the standard 
networks under the "ANN" module: single layer, multi layer feed forward 
(together with BP), hopfield and kohonen nets... I wrote all that in C++ for 
a grad course but I think it has its shortcomings, so I intend to rewrite it 
in ocaml so that I can have a convenient machine learning shell.

Nevertheless, it's an awful lot of work if you want to have your interfaces 
tidy.

> BTW BOOST has some sort of template graph library by Jeremy Siek.

Yes I know, but I prefer to use my own stuff. Even though that library is 
supposed to go into C++ standard some time in the future ;) I think C++ will 
be obsolete by then ;)


Here is some C++ client code for character recognition to give you a feel of 
the approach I have in mind. I would like to have an ANN library that is more 
generic than the one I crafted in C++ ;) Any ideas welcome.

  typedef Neuron< Bipolar_Sigmoidal_Custom > Neuron;
  typedef Sqr_Matrix<double,5> Matrix;
  typedef Matrix_Source< Matrix > Source;
  typedef pair<Source *, vector<double> > Training_Pair;

  // use a multi layered neural network
  Feed_Forward_Net<Neuron, Raw_Input_Neuron, Neuron> ff_net;

  // add hidden neurons initialized at small random values.
  for (int i=0; i<11; i++)
    ff_net.add_hidden(Neuron(Rand::rand_double(-0.005, 0.005), 0));
  // initialize with random values
  ff_net.init_random();

  // a square 5x5 matrix
  Matrix Amtx;

  // we now configure our network for ebp

  Source source(Amtx);
  ff_net.connect_input(source);
  ff_net.connect_output(10); // our coding requires ten outputs

  // the net has been put to required topology

  // read the training sets into this training pairs list
  vector< Training_Pair > pairs;

  // this is all hardwired, not much config
  // is required.

  list< Matrix* > matrices;
//   list< auto_ptr<Matrix> > matrices;
  list< Source > sources;
  for (int character = 0; character < 10; character++) {
    ostrstream name_stream;
    name_stream << "data/char-" << character  << ".txt" << ends;
    ifstream file_in( name_stream.str()  );
    // 4 patterns each
    for (int i = 0; i<4; i++) {
      Matrix *Amtx = new Matrix;
      matrices.push_back( Amtx );
      sources.push_back( Source(*Amtx) );
      vector<double> desired = cons_max(10, character);
      pairs.push_back( Training_Pair(&sources.back(), desired) );
      file_in >> *Amtx;
    }
  }

  // train the network with this data
  // the learning coefficient is 0.02
  CPU_Time start_time;
  ff_net.train(pairs, 0.02, 0.00002, 100000);
  cout << "Trained in " << CPU_Time() - start_time << endl;

  // voila
  nlog << ff_net << endl;

  // now testing with the original training set
  list< Source >::iterator source_it = sources.begin();
  int correct_results = 0;
  for (int character = 0; character < 10; character++) {
    cout << "testing character " << character << endl;
    for (int i = 0; i<4; i++) {
      ff_net.compute(*source_it++);
      vector<double> result_vec(10);
      for (int res=0; res<10; res++)
        result_vec[res] = ff_net.output_layer[res].read();
      double result =select_max(result_vec);
      cout << "  pattern " << i
           << " : " << result << endl;
      if (result == character)
        correct_results++;
    }
  }
  double train_success = double(correct_results) / 40 * 100;
  cout << "Training success is " << train_success << "%" << endl;

and so forth...

-- 
Eray Ozkural (exa) <erayo@cs.bilkent.edu.tr>
Comp. Sci. Dept., Bilkent University, Ankara
www: http://www.cs.bilkent.edu.tr/~erayo  Malfunction: http://mp3.com/ariza
GPG public key fingerprint: 360C 852F 88B0 A745 F31B  EA0F 7C07 AE16 874D 539C
-------------------
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

Re: [Caml-list] productivity improvement

[Emmanuel Renieris]

On Thu, Jul 18, 2002 at 07:14:06PM -0400, Oleg wrote:
> Please give me examples of what's 
> hard/awkward/impossible in C++, but relatively easy in O'Caml, if any (I have 
> only finite time, so 50 KLOC Coq is not a good example :)

I can tell you what I found problematic with C++ but those would be
_my_ problems, not yours. (Remember in the Hitch Hiker's Guide To The
Galaxy, where  pretending you are somebody else's problem makes you
invisible?)

Back at the beginning of this thread, you said that you ported some
small personal utilities, and that you saw no productivity improvement.
You postulated some reasons:
1) You were using the same imperative style
2) your knowledge of O'Caml is rudimental
3) there is no productivity enhancement
4) there is no productivity enhancement the programs you were 
   translating
5) there is no productivity enhancement for small programs in general.

Based on your posted C++ code, I will add a sixth one: you know C++
so well that few things seem hard in it.

I see two ways to weed through this list: 
Tell us what _you_ find hard/awkward/impossible in C++. Maybe somebody
will be able to point out how they are easier in Ocaml (if indeed they
are).
Show us some of your ocaml code. Maybe there is some idiom you don't 
have yet, and that would make a difference.

> P.P.S. My primary interest is statistical AI (artificial neural networks). I 
> haven't found any relevant libraries or applications in SML or O'Caml. That 
> is a bit discouraging.

If the FFI is not enough for you, then this comes into the productivity 
equation. There is also a section of the humps where you can state your wishes.
The language-libraries issue is a chicken and egg problem, but things
should get better with time. I'm not so sure that it's possible to reach the 
size of the C-syntaxed languages, but Python (and, I hear, Perl) did it,
so there is a chance.

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

Re: [Caml-list] productivity improvement

[Oleg]

On Friday 19 July 2002 12:42 am, Emmanuel Renieris wrote:
> I see two ways to weed through this list:
> Tell us what _you_ find hard/awkward/impossible in C++. Maybe somebody
> will be able to point out how they are easier in Ocaml (if indeed they
> are).

The first thing that comes to mind: a program that would read, write, listen, 
look, speak, comprehend and pass the Turing test seems to be hard to create 
in C++. So hard, I've never tried[1] I'm not sure if it's the language 
though, although it could be.

> Show us some of your ocaml code. Maybe there is some idiom you don't
> have yet, and that would make a difference.

Since this is the second time I'm asked, I will have to do that, even though 
the program is really straight-forward, silly and uninstructive. Description 
first, code at the end: Sometimes, when I feel like being organized and 
productive[2], which happens no more than thrice per fortnight, I plan things 
to do in advance and estimate time it will take me to do them: I edit a file 
containing a list of tasks and time in minutes, e.g.

<stdin>
finish reading chapter 13 of ocaml book 30
Determine Dr. Leroy's involvement in JFK assassination 180
call dad 20
have supper 20
Go through T&R level in Halo in Legendary mode 30000
</stdin>

The program reads it from STDIN, calculates completion times and formats 
everything into a neat HTML table in STDOUT. I have a bash alias that glues 
VIM, this program and browser together, of course.

Oleg

[1] I'm not kidding. It really is hard.
[2] And I actually am much more productive when I do that

-------------------------------------------------------
let print_aux hours minutes = 
    if hours < 10 then print_char ' ';
    print_int hours;
    print_char ':';
    if minutes < 10 then print_char '0';
    print_int minutes;;

let print_time m =
    let m = m mod (60*24) in
    let hours = m / 60 in
    let hours = hours mod 24 in
    let hours = if hours > 12 then hours - 12 else hours in
    let tag = if m >= 12*60 then "pm" else "am" in
    let minutes = m mod 60 in
    print_aux hours minutes;
    print_string tag;;
    
let print_duration m =
    let hours = m / 60 in
    let hours = hours mod 24 in
    let minutes = m mod 60 in
    print_aux hours minutes;;

let curr_time = 
    let tmp = Unix.localtime (Unix.time ()) in
    tmp.Unix.tm_min + 60 * tmp.Unix.tm_hour;;

let isdigit = function '0' | '1' .. '9' -> true | _ -> false;;

let split_string s = 
    let i = ref (String.length s - 1) in
    while !i >= 0 && (s.[!i] = ' ' || s.[!i] = '\t') do i := !i-1 done;
    while (!i >= 0) && (isdigit (s.[!i])) do i := !i-1 done;
    i := !i+1;
    String.sub s 0 !i, int_of_string (String.sub s !i (String.length s - 
!i));;

let print_table_entry name duration curr_time = 
    print_string ("\t<tr><td align=left>" ^ name ^ "</td><td align=right>");
    print_duration duration;
    print_string "</td><td align=right>";
    print_time (curr_time + duration);
    print_string "</td></tr>\n";;

print_string "<html>
<title> Schedule </title>
<body bgcolor=\"#773333\" text=\"#00ff00\">
<table border=\"2\">\n";;

let rec read_and_print curr_time =
    let s = input_line stdin in
    let (s, v) = split_string s in
    print_table_entry s v curr_time;
    read_and_print (curr_time + v) 
in try
    read_and_print curr_time
with
    _ -> ();;

print_string "</table>
</body>
</html>\n";;
-------------------
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

Re: [Caml-list] productivity improvement

[Alessandro Baretta]

Oleg wrote:
> On Friday 19 July 2002 12:42 am, Emmanuel Renieris wrote:
> 
>>I see two ways to weed through this list:
>>Tell us what _you_ find hard/awkward/impossible in C++. Maybe somebody
>>will be able to point out how they are easier in Ocaml (if indeed they
>>are).
> 
> 
> The first thing that comes to mind: a program that would read, write, listen, 
> look, speak, comprehend and pass the Turing test seems to be hard to create 
> in C++. So hard, I've never tried[1] I'm not sure if it's the language 
> though, although it could be.

To think of it, I never tried running the hundred meter dash 
  in 9.50s... Did anyone ever pass the Turing test anyway?

>>Show us some of your ocaml code. Maybe there is some idiom you don't
>>have yet, and that would make a difference.
> 
> 
> Since this is the second time I'm asked, I will have to do that, even though 
> the program is really straight-forward, silly and uninstructive. Description 
> first, code at the end: Sometimes, when I feel like being organized and 
> productive[2], which happens no more than thrice per fortnight, I plan things 
> to do in advance and estimate time it will take me to do them: I edit a file 
> containing a list of tasks and time in minutes, e.g.
> 
> <stdin>
> finish reading chapter 13 of ocaml book 30
> Determine Dr. Leroy's involvement in JFK assassination 180
> call dad 20
> have supper 20
> Go through T&R level in Halo in Legendary mode 30000
> </stdin>
> 
> The program reads it from STDIN, calculates completion times and formats 
> everything into a neat HTML table in STDOUT. I have a bash alias that glues 
> VIM, this program and browser together, of course.
> 
> Oleg
> 
> [1] I'm not kidding. It really is hard.
> [2] And I actually am much more productive when I do that
> 
> -------------------------------------------------------
> let print_aux hours minutes = 
>     if hours < 10 then print_char ' ';
>     print_int hours;
>     print_char ':';
>     if minutes < 10 then print_char '0';
>     print_int minutes;;

let print_aux h m = printf
   (if minutes < 10 then "%2d:0%1d" else "%2d:%2d") h m

One line vs. 5

> let print_time m =
>     let m = m mod (60*24) in
>     let hours = m / 60 in
>     let hours = hours mod 24 in
>     let hours = if hours > 12 then hours - 12 else hours in
>     let tag = if m >= 12*60 then "pm" else "am" in
>     let minutes = m mod 60 in
>     print_aux hours minutes;
>     print_string tag;;

let print_time m = print_aux
   (m mod 60) (m / (60*24) mod 12);
   print_string
     (if m mod (60*24) >= 12*60 then "pm" else "am")

3 vs. 8

If you continue to program more or less the same way you 
would in C you cannot notice any improvement. The language 
is functional. Don't think in terms of assignments. Don't 
redefine an identifier (hours). Use functions: apply them to 
expressions. You ought to think in terms of computations as 
opposed to operations.


I have no more time now. Good bye.

Alex

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

Re: [Caml-list] productivity improvement

[Daniel de Rauglaudre]

> > let print_aux hours minutes = 
> >     if hours < 10 then print_char ' ';
> >     print_int hours;
> >     print_char ':';
> >     if minutes < 10 then print_char '0';
> >     print_int minutes;;
> 
> let print_aux h m = printf
>    (if minutes < 10 then "%2d:0%1d" else "%2d:%2d") h m

let print_aux = printf "%02d:%02d"

-- 
Daniel de RAUGLAUDRE
daniel.de_rauglaudre@inria.fr
http://cristal.inria.fr/~ddr/
-------------------
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

Re: [Caml-list] productivity improvement

[Alessandro Baretta]

Daniel de Rauglaudre wrote:
>>>let print_aux hours minutes = 
>>>    if hours < 10 then print_char ' ';
>>>    print_int hours;
>>>    print_char ':';
>>>    if minutes < 10 then print_char '0';
>>>    print_int minutes;;
>>
>>let print_aux h m = printf
>>   (if minutes < 10 then "%2d:0%1d" else "%2d:%2d") h m
> 
> 
> let print_aux = printf "%02d:%02d"

You're a real O'Caml Jedi. Type inference be with you!

Alex

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

Re: [Caml-list] productivity improvement

[Xavier Leroy]

> Determine Dr. Leroy's involvement in JFK assassination 180

Should take less time than this, given that I wasn't born at that time :-)

As everyone else, I'll point out that your code can be shortened and
made more readable by judicious use of printf and regexps (see below).
But really, if this is the kind of programs you're interested in
(text-based I/O with no data structures), forget about C++ and Caml,
and use Perl.

- Xavier Leroy

open Printf

let print_time m =
  let hours = (m / 60) mod 24 and minutes = m mod 60 in
  printf "%2d:%02d%s"
         (if hours > 12 then hours - 12 else hours)
         minutes
         (if hours > 12 then "pm" else "am")

let print_duration m =
  let hours = (m / 60) mod 24 and minutes = m mod 60 in
  printf "%2d:%02d" hours minutes

let re = Str.regexp "\\(.*\\)[ \t]+\\([0-9]+\\)$"

let split_string s =
  if Str.string_match re s 0
  then (Str.matched_group 1 s, int_of_string (Str.matched_group 2 s))
  else failwith "bad line"
-------------------
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

Re: [Caml-list] productivity improvement

[Eray Ozkural]

On Friday 19 July 2002 14:10, Xavier Leroy wrote:
> > Determine Dr. Leroy's involvement in JFK assassination 180
>
> Should take less time than this, given that I wasn't born at that time :-)
>
> As everyone else, I'll point out that your code can be shortened and
> made more readable by judicious use of printf and regexps (see below).
> But really, if this is the kind of programs you're interested in
> (text-based I/O with no data structures), forget about C++ and Caml,
> and use Perl.
>

Definitely so.

Also "portage" from C/C++ cannot automatically result in a productivity 
enhancement for obvious reasons. A straightforward port will preserve
the painstaking style of those languages.

For truly enhancing the quality of code the first step I take is to design
the program to benefit from the higher level of abstraction and modularity
modern functional languages provide for.

Especially using generic data types work very well. In ocaml you can really 
write algorithms that work on generic structures, which is good for cutting 
down code size and getting to the point. Using the module system, one can 
clearly decompose the code into interfaces and implementations...

For instance in a stock market prediction code I have been working on, it took 
no more than a couple of days to rewrite a large portion of the code in 
Haskell that was previously written in C. The resulting code was 
significantly shorter and more modular; allowing me to play with new 
algorithms / metrics easily. The same would not be the case with C++. (The 
code isn't too Haskell specific and could be done as well in ocaml)

That code I think went down from about 2500 lines to 500 lines which isn't 
bad. To attain that kind of improvement, you need a change in style. The C 
program apparently used lots of text I/O to transfer and store data between
modules. The Haskell program didn't have to.

It is also true that it is not correct to expect such improvements in code 
that is too simple. If all you want to do is to sum over an array of 
integers, you can do it in C easily.

-- 
Eray Ozkural <erayo@cs.bilkent.edu.tr>
Comp. Sci. Dept., Bilkent University, Ankara
www: http://www.cs.bilkent.edu.tr/~erayo
GPG public key fingerprint: 360C 852F 88B0 A745 F31B  EA0F 7C07 AE16 874D 539C
-------------------
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

Re: [Caml-list] productivity improvement

[Pal-Kristian Engstad]

On Tuesday 15 October 2002 02:24 am, Eray Ozkural wrote:
> For instance in a stock market prediction code I have been working on, it
> took no more than a couple of days to rewrite a large portion of the code
> in Haskell that was previously written in C. The resulting code was
> significantly shorter and more modular; allowing me to play with new
> algorithms / metrics easily. The same would not be the case with C++. (The
> code isn't too Haskell specific and could be done as well in ocaml)

I've found Haskell's use of IO monads to be "interesting", but terribly 
restricting and hard to understand. I do like their operator and function 
overloading mechanisms though - I wish Ocaml would have something similar (it 
just gets tedius having to add a "." in every floating point calculation). 
I've also had problems with converting stateful programs into Haskell.

> That code I think went down from about 2500 lines to 500 lines which isn't
> bad. To attain that kind of improvement, you need a change in style. The C
> program apparently used lots of text I/O to transfer and store data between
> modules. The Haskell program didn't have to.

That's strange. How could the Haskell program not have to do IO?

> It is also true that it is not correct to expect such improvements in code
> that is too simple. If all you want to do is to sum over an array of
> integers, you can do it in C easily.

Now, that is very true.

PKE.
-- 
  _       
  \`.       Pål-Kristian Engstad, Senior Software Engineer,
   \ `|     Naughty Dog, Inc., 1315 3rd Street Promenade, 
  __\ |`.   Santa Monica, CA 90046, USA. (310) 752-1000 x799. 
    /  /o   mailto:engstad@naughtydog.com http://www.naughtydog.com
   /  '~    mailto:mrengstad@yahoo.com    http://www.engstad.com
  / ,'      Go hang-gliding!
  ~'

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

Re: [Caml-list] productivity improvement

[Eray Ozkural]

On Tuesday 15 October 2002 21:47, Pal-Kristian Engstad wrote:
>
> > That code I think went down from about 2500 lines to 500 lines which
> > isn't bad. To attain that kind of improvement, you need a change in
> > style. The C program apparently used lots of text I/O to transfer and
> > store data between modules. The Haskell program didn't have to.
>
> That's strange. How could the Haskell program not have to do IO?
>

Like many UNIX C codes, each module in the C code was a separate executable 
storing intermediate results in ASCII files. That is a good programming style 
for not so simple C codes because:
1) C is terribly hard to debug
2) C programs are easy to break
3) It's very hard to implement complex/dynamic data structures in C
And so on

However, in a functional language I can afford to implement those data 
structures to handle everything in-core. The reliability of the language 
helps me to keep it relatively bug-free, and it's very easy to write 
functions that accomplish complex tasks. I tried to do the same with C++ but 
it would result in meaningless container classes (like for each session, 
stock, stock market, etc.) and glue code.

That kind of thing is what I mean by change of style. If you do not change 
style, your program is not going to differ too much. You have to use the 
powerful features of the functional language to your advantage for gaining 
the edge.

It's pretty much like the old arguments about C vs. C++. Well you can write 
code that is just like C code in C++. There isn't much point in doing so, and 
still you can see incompetent programmers going all printf, atoi and int 
a[100] in C++.

You can even write assembly-style code in C++, but what purpose would that 
serve?

So if you're not using higher-order functions, recursive types, etc. in your 
program, your program is *not* really functional.[+] It is often quite 
*impossible* to translate a program in functional style to C++ without 
significant loss of quality and performance, ie. your code size is going to 
blow up to a factor of 2-3 at least and performance is going to suck.[|]

In addition, I shouldn't have to mention how useful an interpreter can be 
while developing complex applications like machine learning. With C++, you 
would cringe at never-ending compilations and SIGSEGVs... With your
ultra-hip functional language you don't work that way. Talk about 
productivity.

After all, we all know how the "functional paradigm" was addressed in the C++ 
standard: by a severely deficient imitation of (1st class?) functions through 
templates. Sorry, but I can't afford my code to look anywhere similar to STL. 
Using the standard lib for those data structures and algorithms may be okay, 
but writing something like STL itself is a big NO-NO.

I think to understand how futile that exercise is, every C++ programmer must 
undertake an impossible-in-C++ project.

Here is one for you: write a general purpose parallel array library with
syntax similar to that of blitz, should implement efficient parallel 
algorithms for a large class of topologies. That was the project which led me 
to conclude that C++ was *not* fitting for generic programming....

Nobody should ever write code like the following snippet, yet I suspect 
intermediate C++ programmers would be delighted by the looks of it: "Wow it 
looks just like part of the standard library" How great! What a big bunch of 
crap! Just imagine you are trying to add a new feature to this kind of code, 
you have to change like hundreds of template parameters, signatures and 
functions....

That project was a difficult piece of C++ trickery after which I concluded 
that C++ was not the right language to implement such a system. I also wrote 
that down in the report. There was simply no way it could be done without 
making it an enormous portion of spaghetti. (Supporting 
distributions/alignments a la HPF was virtually impossible)

There are many academic projects in the field of scientific computing with 
similar goals. Just try to compile them or understand a bit of the 
implementation.

-------------------------------- awful C++ code.....

template <typename _Expression> template <typename RHS_Gen_Expr>
Gen_Expr< Array_Add_Expression<_Expression,
  typename Object_Traits<RHS_Gen_Expr>::Expression> >
Gen_Expr<_Expression>::operator+ (const RHS_Gen_Expr& gen_right)
{
  typedef typename Object_Traits<RHS_Gen_Expr>::Expression RHS;
  typedef Array_Add_Expression<Expression,
    typename Object_Traits<RHS_Gen_Expr>::Expression> Add_Expression;
  typedef Gen_Expr<Add_Expression> Gen_Add;

  RHS right = Object_Traits<RHS_Gen_Expr>::reference
    (const_cast<RHS_Gen_Expr&>(gen_right));

//   nlog << node_str << *this << " + " << right << endl;
  Gen_Add return_expr(Add_Expression(expression, right));
  return return_expr;
}

--------------------------------------------------------

[+] You don't really have to use lists everywhere, that's LISP not ocaml.
[|] Don't bring up ghc's poor performance in this discussion, think ocaml

-- 
Eray Ozkural <erayo@cs.bilkent.edu.tr>
Comp. Sci. Dept., Bilkent University, Ankara
www: http://www.cs.bilkent.edu.tr/~erayo
GPG public key fingerprint: 360C 852F 88B0 A745 F31B  EA0F 7C07 AE16 874D 539C
-------------------
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

Re: [Caml-list] productivity improvement

[Diego Olivier Fernandez Pons]

    Bonjour,

I do not understand very well why are you arguing, or is there anyone
in this list who is not convinced that Caml (and functional languages)
are more suited for any complex work than C/C++ (and other imperative
languages) ?

> Sorry, but I can't afford my code to look anywhere similar to STL.
> Using the standard lib for those data structures and algorithms may
> be okay, but writing something like STL itself is a big NO-NO.

When I wrote Baire, I read a lot of data structures and algorithms
code in other languages (C, C++, Java, SML, Haskell, Lisp, Scheme).

Compared with all those libraries, Baire is :
- much more complex (more algorithms and data structures)
- cleaner
- smaller
- easier to maintain and debug

It is faster than Java, SML, Haskell, Lisp and Scheme librairies
(since Caml is faster than all these languages and Baire uses same or
better algorithms), and we have good reasons to believe that it is at
least as fast as C++ code when you choose a data structure more suited
to the data you are manipulating (which Baire offers but STL/LEDA does
not)

Moreover, I wrote it in a few month and did it alone

Finally, Baire has not yet said its last word since it is only a
pre-release

Does anyone need more evidence ?

> Here is one for you: write a general purpose parallel array library with
> syntax similar to that of blitz, should implement efficient parallel
> algorithms for a large class of topologies. That was the project which led me
> to conclude that C++ was *not* fitting for generic programming....

C++ in not fitting for any kind of programming and there is no need of
such a specific application to demostrate it.


        Diego Olivier

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

Re: [Caml-list] productivity improvement

[Jeffrey Palmer]

Hello all. I have a request.

Can we please cease the C++ flamefest? Some of us are not able to choose 
our implementation language quite as easily as others, and, frankly, 
endless discussions about language X's failings just irritate the 
people that are forced to use X daily. Making blanket statements like 
"language X clearly isn't good for anything" is just ridiculous - 
nothing is ever that clear cut. 

If we were to talk about the aspects of C++ (or Java, or ...) that we 
could apply to ocaml, that might be a different story (there might not 
be many!)

For my part, I'm under the impression that cross-module functor 
specializations (terminology?) in ocaml, akin to C++ template 
instantiation, are not optimized in the same manner as C++ templates 
(compiled away). Is this true? This is a killer for me, as I can't even 
afford the overhead of a function call (don't ask).

I would love to be able to write my product in ocaml, and plop a C++ 
wrapper on top of it, but practicalities unfortunately make this an 
impossibility. I need to do things similar to Blitz, which I suppose 
dooms me to template hell. ;)

	- j

-- 
The river is moving.
The blackbird must be flying.

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

Re: [Caml-list] productivity improvement

[brogoff]

On Thu, 17 Oct 2002, Jeffrey Palmer wrote:
> Hello all. I have a request.
> 
> Can we please cease the C++ flamefest? Some of us are not able to choose 
> our implementation language quite as easily as others, and, frankly, 
> endless discussions about language X's failings just irritate the 
> people that are forced to use X daily. Making blanket statements like 
> "language X clearly isn't good for anything" is just ridiculous - 
> nothing is ever that clear cut. 

Right, it's also kind of silly because OCaml is an imperative language, so 
flames like "imperative languages suck" belong on the Haskell, Clean, and 
Mercury mailing lists, but not here! 

> If we were to talk about the aspects of C++ (or Java, or ...) that we 
> could apply to ocaml, that might be a different story (there might not 
> be many!)

Sure, you've probably nailed the most popular one, which is doing C++ 
style compilation by monomorphizing everything. I doubt this will happen in 
OCaml because it is a research vehicle for research in language design, 
and that implementation strategy makes lots of things hard in a language like 
OCaml. This where the "Standard" in SML is somewhat meaningful, as some 
researchers in that community have focused on those kind of optimizations. 

There was a recent thread on this, here 

http://caml.inria.fr/archives/200202/msg00055.html

-- Brian


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

Re: [Caml-list] productivity improvement

[Diego Olivier Fernandez Pons]

    Bonjour,

> people that are forced to use X daily. Making blanket statements like
> "language X clearly isn't good for anything" is just ridiculous -
> nothing is ever that clear cut.

We are not responsible of the design mistakes your company may have
done.

> This is a killer for me, as I can't even afford the overhead of a
> function call (don't ask).

If what you need is real speed you should better try a 2 stages Caml/C
solution, like the FFTW (fastest fourier transformation in the west
which produces C code from a Caml function) or using CIL
(Infrastructure for C Program Analysis and Transformation).

It will be cleaner, easier to maintain, much more portable and ...
FASTER ! (you should read Matteo Frigo's papers on the subject)

- FFTW home page : www.fftw.org
- CIL home page : http://manju.cs.berkeley.edu/cil/

        Diego Olivier

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

Re: [Caml-list] productivity improvement

[Francois Pottier]

> For my part, I'm under the impression that cross-module functor 
> specializations (terminology?) in ocaml, akin to C++ template 
> instantiation, are not optimized in the same manner as C++ templates 
> (compiled away). Is this true?

It is true. However, a source-to-source transformer is being developed
at Orsay which statically unfolds functor applications, eliminating
this overhead, and suppressing the antagonism between modularity and
efficiency. As far as I have heard, it should be released `real soon
now'.

-- 
François Pottier
Francois.Pottier@inria.fr
http://pauillac.inria.fr/~fpottier/
-------------------
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

[Caml-list] productivity improvement

[Oleg]

Hi

As part of learning O'Caml I was rewriting small personal utility programs 
from C++ to O'Caml and I have not seen any productivity improvement so far. 
Possibly, this is because I essentially use the same imperative style or 
because my knowledge of O'Caml is rudimental or because there is no 
productivity enhancement, at least for the programs I was translating or for 
small programs in general.

What are the _simplest_ examples that demonstrate considerable (> 2:1) O'Caml 
vs C++ productivity improvement (in terms of program size) and where can I 
find them?

Thanks
Oleg

P.S. Just trying to stay motivated.
-------------------
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

Re: [Caml-list] productivity improvement

[Michael Vanier]

Imperative code in ocaml is not going to be massively different than
imperative code in any other (garbage-collected) language.  You need to
learn the functional style.  Why not post some of the personal utility
programs to the list and see if we can make them more idiomatic?

Personally, I think one of the big issues wrt C++ vs. ocaml is simply the
presence of a garbage collector and real strong static type checking.  The
productivity increases are as much in the form of reduced debugging time as
they are in the form of fewer lines of code.  However, higher-order
functions can give you a substantial savings in code size.

Mike


> From: Oleg <oleg_inconnu@myrealbox.com>
> Date: Mon, 8 Jul 2002 15:53:26 -0400
> 
> Hi
> 
> As part of learning O'Caml I was rewriting small personal utility programs 
> from C++ to O'Caml and I have not seen any productivity improvement so far. 
> Possibly, this is because I essentially use the same imperative style or 
> because my knowledge of O'Caml is rudimental or because there is no 
> productivity enhancement, at least for the programs I was translating or for 
> small programs in general.
> 
> What are the _simplest_ examples that demonstrate considerable (> 2:1) O'Caml 
> vs C++ productivity improvement (in terms of program size) and where can I 
> find them?
> 
> Thanks
> Oleg
> 
> P.S. Just trying to stay motivated.
-------------------
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

Re: [Caml-list] productivity improvement

[John Max Skaller]

Michael Vanier wrote:

>Imperative code in ocaml is not going to be massively different than
>imperative code in any other (garbage-collected) language.  
>
I don't agree.

All imperative languages -- including ocaml -- contain functional parts,
usually known as 'expressions'. The ability to write clear and simple
imperative code is greatly enhanced by a powerful functional system
precisely because it allows the imperative part of the language to
be used just for imperative things. In a language like C the
functional system is so weak, that one must use the imperative
features just to implement purely functional constructions.

For example, you cannot initialise a structure in C except
with an imperative statement:

    X x = {1,2,3,4};

For example, you cannot encode a switch (other than
over a bool) in an expression: you have a to use a statement,
although you can wrap it in a function and call that ..
although of course you lose your environment and so you need
to pass them ... argggrgrgrg. Perhaps you can do better with:

    int x = expr;
    result =
        x==1 ? blah1() :
        x==2 ? blah2():
        x==3 ? blah3():
        ...

As someone said recently "ocaml forever" :-))

-- 
John Max Skaller, mailto:skaller@ozemail.com.au
snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia.
voice:61-2-9660-0850




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

Re: [Caml-list] productivity improvement

[Alessandro Baretta]

John Max Skaller wrote:
> 
> As someone said recently "ocaml forever" :-))
> 

Just today I have found a counterexample where C does a 
better job than O'Caml--at least within the context of my 
understanding of and ability with the two languages.

This is the problem: I have a text file containing a fairly 
long table extracted from a database (approximately 73000 
lines). I had to write a program to parse each line, extract 
only the relevant fields and reformat dates and times 
according to some sensible format (such as dd/mm/yyyy 
hh:mm:ss as opposed to yyyymmdd hhmmss00). This is how I 
solved the problem in C:


#include <stdio.h>

int main ( int argc , char *argv[]) {

#define ALF " %*s"
#define ISIN " %*s"
#define DATE " %4s%2s%2s"
#define TIME " %2s%2s%2s%*2s"
#define PRICE "%s"
#define QN     "%s"
#define CNTVL  "%*s"


   char scanner[] = ALF ISIN DATE TIME PRICE QN CNTVL;
   char printer[] = "%s/%s/%s\t%s:%s:%s\t%s\t%s\n";

   char year[8], month[8], day[8];
   char hh[4], mm[4], ss[4];
   char price[64], qn[64];

   int n;

   while (1) {
     n=scanf(scanner, year, month, day,
	hh, mm, ss, price, qn);
     if (n==EOF) break;
     printf(printer, day, month, year,
	hh, mm, ss, price, qn);
   }
}


I was not able to figure out an easy way to do this in 
O'Caml. Of course, I could have used ocamllex and ocamlyacc 
to define a lexer and a parser, but what I really needed was 
a scanf function.

My intuition is that we badly need a *functional* scanf. Of 
course, I despise the idea of a format string. I had to use 
7 #defines in order to make some sense of the scanf format, 
and I might have done the same for printf, where the format 
not a little simpler.

Of course, my understanding of O'Caml is incomplete, and I'm 
sure someone will be good enough to teach how I could have 
done the same in O'Caml with only a fraction of the lines of 
code.

Alex

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

Re: [Caml-list] productivity improvement

[Jun P.FURUSE]

Hello,

> Just today I have found a counterexample where C does a 
> better job than O'Caml--at least within the context of my 
> understanding of and ability with the two languages.
[..]
> I was not able to figure out an easy way to do this in 
> O'Caml. Of course, I could have used ocamllex and ocamlyacc 
> to define a lexer and a parser, but what I really needed was 
> a scanf function.

Ah, you should have waited for few days.
The module Scanf is available in the next O'Caml version 3.05, 
which will be distributed soon...

-
Jun

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

Re: [Caml-list] productivity improvement

[Pierre Weis]

> Hello,
> 
> > Just today I have found a counterexample where C does a 
> > better job than O'Caml--at least within the context of my 
> > understanding of and ability with the two languages.
> [..]
> > I was not able to figure out an easy way to do this in 
> > O'Caml. Of course, I could have used ocamllex and ocamlyacc 
> > to define a lexer and a parser, but what I really needed was 
> > a scanf function.
> 
> Ah, you should have waited for few days.
> The module Scanf is available in the next O'Caml version 3.05, 
> which will be distributed soon...
> 
> -
> Jun
> 
> -------------------
> 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

As Jun said, a scanf facility will be introduce in the next version of
Objective Caml. Consider this feature as experimental, and fill free
to send us comments, if you can test it, have remarks or additions to
suggest, or more importantly, if you find bugs before the release!

With this new (functional) scanf facility, your program sounds like
this in Caml:

try
  while true do
    Scanf.scanf " %s %s %4s%2s%2s %2s%2s%2s%2s %s %s %s"
      (fun _ _ year month day hh mm ss _ price qn _ ->
         Printf.printf "%s/%s/%s\t%s:%s:%s\t%s\t%s\n" 
           day month year hh mm ss price qn)
  done
with End_of_file -> ();;

We can now compare with your C version of the program:

Conciseness and elegance: well, I'm not too unhappy of the Caml code,
but yes, it can be considered as a bit cryptic ...

Readability: in this example, we certainly lack the ability to skip an
argument as in the %*s of the C version; also, and once again, we lack
a format concatenation primitive to cleanly express the decomposition
of the scanf format at hand (which means that we still lack the fourth
type variable argument in the type of format strings that would permit
the sound implementation of this feature).

Performance: compared to the ggc-O2 compiled C version, this program
is about twice slowlier, which is a performance of the Objective Caml
compiler, given the highly readable and simple-minded source code of
the Scanf module.

Anyway, thanks a lot for your interesting example that forced me to
review the code of the Scanf module, and to slightly modify its
functionalities in order to accomodate your program more elegantly!

Pierre Weis

INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://pauillac.inria.fr/~weis/


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

[Caml-list] productivity improvement

[Basile STARYNKEVITCH]

>>>>> "Oleg" == Oleg  <oleg_inconnu@myrealbox.com> writes:


    Oleg> What are the _simplest_ examples that demonstrate
    Oleg> considerable (> 2:1) O'Caml vs C++ productivity improvement
    Oleg> (in terms of program size) and where can I find them?

I am not sure the question does make any real sense. You might ask an
Ocaml vs Java comparaison, or an Ocaml vs Python compraison ....

1. Try coding the Ocaml compiler, the ActiveDVI viewer, the Unison
   synchronizer, or the Coq proof system, ... in C++, then tell us
   about your findings. If possible, publish your working C++ code :-)

2. The simplest example I can think of is the hello world program. In
   Ocaml it is just a single line:
      print_endline "hello world";;

   but in C++ you'll need at least an #include, then a main function,
   containing a out << "hello world" << endl statement perhaps a
   simplest even example is the empty program: (a 0 byte file in
   Ocaml, but in C++ you need a main function. the size improvement is
   infinite in favor of Ocaml)


Ok, my answer is silly, but I feel the question a bit silly too. More
convincing examples are the many existing (and publicised) code in
Ocaml. See the ocaml hump for instance, and more generally try ocaml
in a Web search engine. Also the Oreilly book (originally in French,
but translated in english) on Ocaml will help. There are lots of stuff
from http://www.ocaml.org/ too.

Both Ocaml and C++ requires a significant learning effort, however
(you might compare the volume of the language reference manuals; the
core language of C++ is much heavier than the core language of
Ocaml). Try coding some stuff in Ocaml and you will learn by
yourself. The type inference system is really a big plus.

Ocaml does have some minor weaknesses: the syntax is sometimes painful
(you could look into the Revised syntax proposal of D.deRanglaudre in
camlp4); mixing datatypes (eg records) and classes is painful; there
are much less libraries in Ocaml than in C or C++; metaprogramming is
not really easy; runtime information is almost inexistant; Ocaml has
no overloading, etc...

The real convincing examples would be projects which failed in C++ but
were resurrected and worked in Ocaml (I heard there are some such
projects but I cannot name them) but I am not sure you'll find public
references to failed projects.


N.B. Any opinions expressed here are only mine, and not of my organization.
N.B. Les opinions exprimees ici me sont personnelles et n engagent pas le CEA.

---------------------------------------------------------------------
Basile STARYNKEVITCH   ----  Commissariat à l Energie Atomique * France
DRT/LIST/DTSI/SLA * CEA/Saclay b.528 (p111f) * 91191 GIF/YVETTE CEDEX 
phone:+33 1,6908.6055; fax: 1,6908.8395 home: 1,4665.4553; mobile: 6,8501.2359
work email: Basile point Starynkevitch at cea point fr 
home email: Basile at Starynkevitch point 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

Re: [Caml-list] productivity improvement

[Shannon --jj Behrens]

>     Oleg> What are the _simplest_ examples that
> demonstrate
>     Oleg> considerable (> 2:1) O'Caml vs C++
> productivity improvement
>     Oleg> (in terms of program size) and where can I
> find them?

I wrote a bunch of programs comparing several
languages using two different algorithms ("Simple" and
"Modcount") for finding primes.  Eventually, I hope to
throw these up on a Web page, but here is a summary of
the results:

Simple:
  C:
    Source: 76 lines
    Binary: 5833 bytes
    Sample Run: 1.56 seconds
  Cyclone:
    Source: 63 lines
    Binary: 127264 bytes
    Sample Run: 1.63 seconds
  Ocaml:
    Source: 35 lines
    Binary: 138726 bytes
    Sample Run: 3.57 seconds
  Python:
    Source: 28 lines
    Binary: 1629 bytes
    Sample Run: 13.6 seconds

ModCount:
  C:
    Source: 95 lines
    Binary: 6020 bytes
    Sample Run: 1.08 seconds
  Cyclone:
    Source: 83 lines
    Binary: 127391 bytes
    Sample Run: 1.35 seconds
  Ocaml:
    Source: 54 lines
    Binary: 139091 bytes
    Sample Run: 3.66 seconds
  Python:
    Source: 44 lines
    Binary: 4054 bytes
    Sample Run: 91.8 seconds

Line counts do not include blank lines or comments.
Sample runs were calculated using "time ./executable
5000".  Ocaml programs where compiled using the native
compiler.  Python binary sizes were taken from .pyo's
which still require the Python interpretter.  My
friend did a Java version.  It required more lines of
code that OCAML, and was slightly slower.  I don't
have the exact numbers, so I haven't written them
here. :(

Here are some of the things that I learned:

1) C is the fastest (of course).
2) Python requires the fewest lines of code.
3) Ocaml provides (in my mind) the best ratio of
execution speed per lines of code.
4) I don't agree that having a higher level language
will often result in using better algorithms, which
compensate for the language overhead.

I have the code of the programs, if you wish.

Best Regards,
-jj

__________________________________________________
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com
-------------------
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

Re: [Caml-list] productivity improvement

[Oleg]

On Tuesday 09 July 2002 02:20 pm, Shannon --jj Behrens wrote:

> I wrote a bunch of programs comparing several
> languages using two different algorithms ("Simple" and
> "Modcount") for finding primes.  Eventually, I hope to
> throw these up on a Web page, but here is a summary of
> the results:
>
> Simple:
>   C:
>     Source: 76 lines
>     Binary: 5833 bytes
>     Sample Run: 1.56 seconds
>   Cyclone:
>     Source: 63 lines
>     Binary: 127264 bytes
>     Sample Run: 1.63 seconds
>   Ocaml:
>     Source: 35 lines
>     Binary: 138726 bytes
>     Sample Run: 3.57 seconds
>   Python:
>     Source: 28 lines
>     Binary: 1629 bytes
>     Sample Run: 13.6 seconds
>
> ModCount:
>   C:
>     Source: 95 lines
>     Binary: 6020 bytes
>     Sample Run: 1.08 seconds
>   Cyclone:
>     Source: 83 lines
>     Binary: 127391 bytes
>     Sample Run: 1.35 seconds
>   Ocaml:
>     Source: 54 lines
>     Binary: 139091 bytes
>     Sample Run: 3.66 seconds
>   Python:
>     Source: 44 lines
>     Binary: 4054 bytes
>     Sample Run: 91.8 seconds
>
> Line counts do not include blank lines or comments.

Hi

I intensionally used "program size" and not LOC, because C/C++ programmers 
like to use short lines and very short lines (containing a single "{" or 
"}"). How do the program sizes compare in terms of the number of non-blank 
characters, for example? [1]

Thanks

Oleg
[1] cat source | sed "s/ //" | wc -c
-------------------
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

Re: [Caml-list] productivity improvement

[Shannon --jj Behrens]

> Hi
> 
> I intensionally used "program size" and not LOC,
> because C/C++ programmers 
> like to use short lines and very short lines
> (containing a single "{" or 
> "}"). How do the program sizes compare in terms of
> the number of non-blank 
> characters, for example? [1]
> 
> Thanks
> 
> Oleg
> [1] cat source | sed "s/ //" | wc -c

Hmm, that's not really a reasonable comparison,
because even the commenting style will mess it up. 
I'll post the code, and you can compare.  If anyone
has any comments on my usage (or lack thereof) of
OCAML idioms, I'd be quite happy to hear them:

<http://ironorchid.com/jjinux/patches/findprimes.tar.gz>

Best Regards,
-jj

__________________________________________________
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com
-------------------
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

Re: [Caml-list] productivity improvement

[sebastien FURIC]

 Hello,

 I've tested your O'Caml program on my PC:

time ./findprimes_modcount 10000

real    1m26.089s
user    0m0.010s
sys     0m0.040s

 To my surprise, this naive lazy version in Clean (5 lines of code!)
outperforms your version:

<clean>

   module sieve

   import StdEnv

   primes =: sieve [2, 3 ..]
   where sieve [p : xs] = [p : sieve [x \\ x <- xs | x mod p <> 0]]

   Start = take 10000 primes

</clean>

time ./sieve

real    1m17.460s
user    0m0.010s
sys     0m0.020s

 The corresponding version in O'Caml (using a lazy list module) is far
from being as efficient:

<caml>

   type 'a stream = Empty | Cons of 'a * 'a stream Lazy.t

   let rec iter f = function
       | Empty -> ()
       | Cons (x, xs) -> f x; iter f (Lazy.force xs)

   let rec filter p = function
       | Empty -> Empty
       | Cons (x, xs) ->
           if (p x) then Cons (x, lazy (filter p (Lazy.force xs))) else
filter p (Lazy.force xs)

   let rec take n s = match (n, s) with
       | _, Empty -> Empty
       | 0, _ -> Empty
       | n, Cons (x, xs) -> Cons (x, lazy (take (n - 1) (Lazy.force
xs)))


   let rec from n = Cons (n, lazy (from (n + 1)))

   let print_int_stream = iter (function x -> print_int x; print_string
"; ")

   let primes =
       let rec sieve = function
           | Empty -> Empty
           | Cons (p, xs) -> Cons (p, lazy (sieve (filter (function n ->
n mod p <> 0) (Lazy.force xs))))
       in sieve (from 2);;

   print_int_stream (take 10000 primes)

</caml>

real    11m9.021s
user    0m0.020s
sys     0m0.030s

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

Re: [Caml-list] productivity improvement

[Dave Mason]

Further to my comment on benchmarking...

I just ran your ocaml lazy version, and got:

real	14m15.124s
user	13m26.769s
sys	0m2.510s

This on a 533MHz Alpha with 3/4GB of RAM.  There is no swapping.

Even when I compile it with the optimizing compiler, I get:

real	9m8.763s
user	8m51.626s
sys	0m1.667s

Based on the (small) differences between the byte-code version and the
optimized version, I hypothesize that a large amount of that time is spent
in garbage collection.  This looks like a perfect garbage-collector
stress test!

My guess for why Clean does well suggests a garbage collector better
tuned to the problem, but more importantly, a much more efficient
handling of laziness.  I suspect you'd see similar results for this
problem in Haskell.  Of course that doesn't mean Clean or Haskell will
beat OCaml at most, or even many, other benchmarks.  But when laziness
is inherent in a solution, expect lazy languages to do much better
than eager languages.

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

Re: [Caml-list] productivity improvement

[sebastien FURIC]

Dave Mason a écrit :
> 
> Further to my comment on benchmarking...
> 
> I just ran your ocaml lazy version, and got:
> 
> real    14m15.124s
> user    13m26.769s
> sys     0m2.510s
> 
> This on a 533MHz Alpha with 3/4GB of RAM.  There is no swapping.
> 
> Even when I compile it with the optimizing compiler, I get:
> 
> real    9m8.763s
> user    8m51.626s
> sys     0m1.667s
> 
> Based on the (small) differences between the byte-code version and the
> optimized version, I hypothesize that a large amount of that time is spent
> in garbage collection.  This looks like a perfect garbage-collector
> stress test!
> 
> My guess for why Clean does well suggests a garbage collector better
> tuned to the problem, but more importantly, a much more efficient
> handling of laziness.  I suspect you'd see similar results for this
> problem in Haskell.  Of course that doesn't mean Clean or Haskell will
> beat OCaml at most, or even many, other benchmarks.  But when laziness
> is inherent in a solution, expect lazy languages to do much better
> than eager languages.
> 
> ../Dave

 Dave,

 My strange user times are obtained under Cygwin. I forgot to mention I
did the test under Windows NT 4.0 (Intel 200 MHz, 128 MB RAM) using the
last version of Cygwin (hence the last version of time.exe!) and
Objective Caml 3.04. There was no swapping, so sys time is a good
approximation of the time spent by the program to solve the problem.
 It is not very surprising to beat O'Caml using a language that is tuned
to perform lazy computations natively when the problem to solve is lazy!
 More surprising is the fact that the lazy program outperforms a strict
one (written in an imperative style).

 Cheers,

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

Re: [Caml-list] productivity improvement

[nadji]

sebastien FURIC wrote:

> Dave Mason a écrit :
> >
> > Further to my comment on benchmarking...
> >
> > I just ran your ocaml lazy version, and got:
> >
> > real    14m15.124s
> > user    13m26.769s
> > sys     0m2.510s
> >
>

...

> > in garbage collection.  This looks like a perfect garbage-collector
> > stress test!
>

I did some tests and it seems a lot of time is being spent on garbage collection.

> >
> > My guess for why Clean does well suggests a garbage collector better
> > tuned to the problem, but more importantly, a much more efficient
> > handling of laziness.  I suspect you'd see similar results for this
> > problem in Haskell.  Of course that doesn't mean Clean or Haskell will
> > beat OCaml at most, or even many, other benchmarks.  But when laziness
> > is inherent in a solution, expect lazy languages to do much better
> > than eager languages.
> >

... with a lazy style of programming. I ran your test with my computer, and it
took
it around 5mn to complete. I programmed the same test in a functional way
(and with DDR's syntactic sugar), and it now completes in 21s. Moreover,
the program is nearly as short as your Clean one. See below.

>  It is not very surprising to beat O'Caml using a language that is tuned
> to perform lazy computations natively when the problem to solve is lazy!

I don't agree with you when you say that the problem to solve is lazy. The
_algorithm_ you use is lazy. There are certainly lots of ways to solve it
with imperative style, and lots of optimisations (I think of multiprocessor
ones) that you can't implement with your algorithm.


file erat.ml :
(* defines 2 streams : the first one is the functional that I have written,
and the second is Sébastien Furic's one *)
let primes1 =
  let rec erat isprime n =
    if isprime n then [< 'n; erat (fun k -> isprime k && k mod n <> 0) (n + 1) >]

    else erat isprime (n + 1)
  in erat (fun _ -> true) 2

let primes2 =
  let rec filter f = parser
      [< 'n; xs >] -> if f n then [< 'n; filter f xs >] else filter f xs
  in let rec sieve = parser
      [< 'p; xs >] -> [< 'p; sieve (filter (fun x -> x mod p <> 0) xs) >]
  in let rec from k = [< 'k; from (k + 1) >]
  in sieve (from 2)

let _ =
  let primes = match Sys.argv.(1) with "1" -> primes1 | "2" -> primes2
  | _ -> failwith "syntax: erat (1|2) n" in
  let rec print_stream = function
    | 0 -> Printf.printf "\n"
    | n -> Printf.printf "%d " (Stream.next primes); print_stream (n - 1)
  in print_stream (int_of_string (Sys.argv.(2)))

compile it with :
    ocamlopt -o erat -pp camlp4o erat.ml
on my computer,
    time ./erat 1 10000 ->  0:21.74
    time ./erat 2 10000 -> 5:15.87

Cheers,
Nadji

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

Re: [Caml-list] productivity improvement

[John Max Skaller]

Oleg wrote:

>What are the _simplest_ examples that demonstrate considerable (> 2:1) O'Caml 
>vs C++ productivity improvement (in terms of program size) and where can I 
>find them?
>
Try doing this in C++:

    type 'a node = Leaf of 'a | Unop of ('a->'a) * node | Binop of ('a * 
'a -> 'a)
    let rec eval n = match n with
    | Leaf  i -> i
    | Unop (f,n) -> f (eval n)
    | Binop (f,n1,n2) -> f ((eval n1), (eval n2))

[Hint: it cannot be done without one of:
    a) casts, or
    b) serious difficulties wth memory management
]


-- 
John Max Skaller, mailto:skaller@ozemail.com.au
snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia.
voice:61-2-9660-0850




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

Re: [Caml-list] productivity improvement

[Nicolas barnier]

John Max Skaller wrote:
> 
> Try doing this in C++:
> 
>     type 'a node = Leaf of 'a | Unop of ('a->'a) * node | Binop of ('a *
> 'a -> 'a)
>     let rec eval n = match n with
>     | Leaf  i -> i
>     | Unop (f,n) -> f (eval n)
>     | Binop (f,n1,n2) -> f ((eval n1), (eval n2))

Just if some newbie wants to copy and paste this piece of code,
there is a small mistake in the type:

type 'a node =
   Leaf of 'a
 | Unop of ('a->'a) * 'a  node
 | Binop of ('a * 'a -> 'a)  * 'a  node * 'a  node;;

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

Re: [Caml-list] productivity improvement

[Oleg]

On Wednesday 10 July 2002 11:39 am, John Max Skaller wrote:
> Oleg wrote:
> >What are the _simplest_ examples that demonstrate considerable (> 2:1)
> > O'Caml vs C++ productivity improvement (in terms of program size) and
> > where can I find them?
>
> Try doing this in C++:
>
>     type 'a node = Leaf of 'a | Unop of ('a->'a) * node | Binop of ('a *
> 'a -> 'a)
>     let rec eval n = match n with
>
>     | Leaf  i -> i
>     | Unop (f,n) -> f (eval n)
>     | Binop (f,n1,n2) -> f ((eval n1), (eval n2))
>
> [Hint: it cannot be done without one of:
>     a) casts, or
>     b) serious difficulties wth memory management
> ]

Shame on you! I hear you are on the C++ standardization committee :)
Code first [1], comments below.

<C++>
    1   #include <iostream>
    2   #include <cmath>
    3
    4   template<class T>
    5   struct node { 
    6       virtual T eval() = 0;
    7   };
    8
    9   template<class T>
   10   struct leaf : public node<T> {
   11       T i;
   12       T eval() { return i; }
   13       leaf(const T& t) : i(t) {};
   14   };
   15
   16   template<class T>
   17   struct unop : public node<T> {
   18       T (*fun)(T);
   19       node<T>& n;
   20       T eval() { return fun(n.eval()); }
   21       unop(T (*f)(T), node<T>& N) : fun(f), n(N) {}
   22   };
   23
   24   template<class T>
   25   struct binop : public node<T> {
   26       T (*fun)(T, T);
   27       node<T> &n1;
   28       node<T> &n2;
   29       T eval() { return fun(n1.eval(), n2.eval()); }
   30       binop(T (*f)(T, T), node<T>& N1, node<T>& N2) : fun(f), n1(N1), 
n2(N2) {}
   31   };
   32
   33   int main() {
   34       typedef node<double> N;
   35       typedef leaf<double> L;
   36       typedef unop<double> U;
   37       typedef binop<double> B;
   38       L a(4);
   39       U b(std::sin, a);
   39       U b(std::sin, a);
   40       U c(std::cos, a);
   41       B d(std::atan2, b, c);
   42       std::cout << d.eval() << '\n';
   43   }
</C++>

As one can see, the code is reasonably idiomatic C++, there are no casts or 
explicit memory management. Templates are used only for genericity. If one 
looks past the superficial syntax differences, the C++ code is not even much 
more verbal than the O'Caml example, namely:

1) one needs to define the abstract (interface) class instead of O'Caml's 
succinct "type 'a node = ".
2) writing "template<class T>", "struct", ": public node<T>", "};" adds to 
program size, while decreasing readability and compilation speed. But writing 
these really happens without much thinking.
3) constructors do have to be written manually, but that's only 3 LOC total 
(1 per each derived class / variant), and they are very simple and idiomatic.
4) as used in "main()", the C++ code will not take any "abstraction" [2]
performance pentalty

John's example was still very interesting [3], thanks: we've learned that 
O'Caml variant types translate into C++ single inheritance from abstract 
classes, not unions. Give me more! 

Best regards,
Oleg

P.S. What I do like about C++, is that even though the language claims to be 
multi-paradigm, good design is really class-based (structs are classes), 
while in O'Caml one has to decide on using classes vs records + HOFs, and 
lists vs arrays vs bigarrays. IMHO maybe O'Caml needs fewer types.

[1] I'm no language lawyer, but I think this is 100% ANSI/ISO C++. BTW, it 
compiled with "g++-3.0 -pedantic" without warnings or errors.

[2] In C terms, "calling function through a pointer" in node<double>'s 
virtual table. There will be no penalty, because the C++ compiler is required 
to infer types at compile time here. How about O'Caml? Will it do "match" at 
compile time, if possible?

[3] Special Simpsons quote today:
KITENGE: This is the earliest known fossil of a human being. It's over two 
million years old. 
HOMER: Pff, I've got more bones than that guy. If you're trying to impress 
me, you've failed.
KITENGE: It's not the number of bones, sir, it's the...
HOMER: You have failed!
-------------------
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

Re: [Caml-list] productivity improvement

[Eray Ozkural]

On Tuesday 16 July 2002 06:34, Oleg wrote:
>
> As one can see, the code is reasonably idiomatic C++, there are no casts or
> explicit memory management. Templates are used only for genericity. If one
> looks past the superficial syntax differences, the C++ code is not even
> much more verbal than the O'Caml example, namely:

Are you nuts? That code you've written is outlandish. It's typical C++ 
verbooooosity without a point. Did you notice how many lines that is?

It's just the kind of code that I said "should never be written". I can't 
afford programming non-sense like that.

If that looks pretty to you, you ought to revise your sense of aesthetics. 

-- 
Eray Ozkural <erayo@cs.bilkent.edu.tr>
Comp. Sci. Dept., Bilkent University, Ankara
www: http://www.cs.bilkent.edu.tr/~erayo
GPG public key fingerprint: 360C 852F 88B0 A745 F31B  EA0F 7C07 AE16 874D 539C
-------------------
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