Re: [Caml-list] productivity improvement

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] Rule based language [was: productivity improvement]

[Alessandro Baretta]

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

Here is the specification of the language:

<program> -> <ruleset> <dataset> <goals>

<ruleset> -> ruleset: <rules>
<rules>   -> <rule> <rules> | <epsilon>
<rule>    -> <rule_name> is <preconditions> =>
                  <postconditions>;
<rule_name> -> <token>
<preconditions> -> <conditions>
<postconditions> -> <conditions>
<conditions>    -> <datum> | <datum> and <conditions>
<datum>   -> <token>

<dataset> -> data_set: <data_list>
<data_list> -> <datum>; <data_list> | <epsilon>

<goals>  -> goals: <goal_list>
<goal_list> -> <goal> <goal_list> | <epsilon>
<goal>   -> <simple>? <goal_name> is <conditions>;
<simple> -> simple
<epsilon> ->

I hope this grammar is complete. I cannot find the original 
specifications for this language.

The interpreter takes a program written in the language 
specified above and for each goal it attempts to find a 
sequence of rule activations that lead to the conditions of 
goal being present contemporarily in the dataset. Since 
preconditions are removed from the dataset upon rule 
activation, the logic determined by this language is non 
monotonous, and backtracking is required to solve the 
problem. Goals marked simple are tested with out 
backtracking: the first rule whose preconditions are 
verified is activated at each step.

Goals are all verified from the initial dataset--that is, 
execution order or goals does not matter.

Here's a thirty second test case I cooked up. We'll want 
something more complete and complex for verification and 
benchmarking.
<rules.program>
--------------------------------------------------------
ruleset:

1 is x => y;
2 is x and pippo => z;

dataset:

foo
x;

goals:

foo is x;
simple x is foo;
simple sz is z;

--------------------------------------------------------
The following is the output the interpreter is supposed to 
generate.

[alex@athlon ocaml]$ ./rules < rules.program
Goal pippo: found
Goal x: found
Goal sz: not found
Goal z: found


Code on and have fun!

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

[Caml-list] compact.c

[Julie Farago]

Hello,

Is there a paper on the compaction code (compact.c) of the garbage
collector (in byterun/)? Even though the documentation in this file is
really exceptional, I am a little confused by how the inversion of
pointers is used to compact the heap. Is there an algorithm I should
lookup?

Thanks a lot!
-Julie

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

[Caml-list] Re: Camlp4 optimizations (was: productivity improvement)

[Christophe TROESTLER]

On Thu, 17 Oct 2002, Jeffrey Palmer <jeffrey.palmer@acm.org> wrote:
> 
> [...]  I need to do things similar to Blitz, which I suppose dooms
> me to template hell. ;)

I was thinking: could camlp4 help in such endavours?  One could even
imagine that for numerical intensive applications, some Camplp4
routines produce C (say) code that is (transparently for the user)
callable from the main program...  All that in a safe way...  Am I
dreaming here about the possibilities of camlp4 or is it possible?

Cheers,
ChriS
-------------------
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] Re: Camlp4 optimizations (was: productivity improvement)

[Chris Hecker]

>I was thinking: could camlp4 help in such endavours?  One could even
>imagine that for numerical intensive applications, some Camplp4
>routines produce C (say) code that is (transparently for the user)
>callable from the main program...  All that in a safe way...  Am I
>dreaming here about the possibilities of camlp4 or is it possible?

camlp4 can generate C with no problem (although I don't know if it can 
create another file, but I don't see why not, it can run arbitrary caml 
code during parsing).

The biggest problem with making ocaml look nice and pretty for numerical 
code is that there is no overloading (of functions or operators), and 
camlp4 doesn't have access to types, so you can't have both:

s*a (scalar times matrix)
a*b (matrix times matrix)

What code would the * operator generate in camlp4?  This needs to be fixed 
at a deeper level than syntax (which is where camlp4 operates...and 
operates well! :).  Althought hopefully it's fixed in a way that doesn't 
require a runtime type-check if the information is available at compile time.

Or, maybe I'm missing something...it would be awesome if I was and this was 
possible!

Chris


-------------------
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] Re: Camlp4 optimizations (was: productivity improvement)

[Shivkumar Chandrasekaran]

On Thursday, October 17, 2002, at 11:32 AM, Chris Hecker wrote:

> The biggest problem with making ocaml look nice and pretty for 
> numerical code is that there is no overloading (of functions or 
> operators),

I have written thousands of lines of numerical linear algebra code in 
Clean (where such overloading is possible) and in OCaml. I don't miss 
it one bit. (Let me concentrate on matrix multiplication since that was 
what the post talked about.)

The reason for not missing overloading is that in coding *efficient* 
matrix algorithms, matrix multiplications usually have a well-defined 
end-place for the result. This end-place is usually a sub-matrix of an 
existing matrix (canonical examples are classical factorizations: LU, 
QR). Hence I don't just need "a * b", I really need to say "c = a * b, 
but don't generate new space for a * b, just use the space allocated 
for c instead".

Luckily in OCaml and Clean we can solve this by making a HOF of type

( |*| ) : matrix * matrix -> (matrix -> unit)

Then I can say (a |*| b) c, or, with one more definition,

c =$ a |*| b

Note, that even Clean will not allow you to replace |*| with *, since 
the only way to overload * in Clean is as (matrix matrix -> matrix) 
which is not what I want.

Secondly I also need to say, in Matlab notation, a' * b. One cumbersome 
way around is to define a function called transpose that just flags its 
argument to be transposed without actually doing it. This creates its 
own nightmare. A better solution for me (in Clean and OCaml) has been 
to define a ~* b to mean a' * b, and variations thereof.

However, for casual coding a la Matlab style, the lack of overloading 
could be seen as a problem. Of course one must then be prepared to live 
with unnecessary copying and memory accesses.

--shiv--

-------------------
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] Re: Camlp4 optimizations (was: productivity improvement)

[Chris Hecker]

>However, for casual coding a la Matlab style, the lack of overloading 
>could be seen as a problem. Of course one must then be prepared to live 
>with unnecessary copying and memory accesses.

Of course, that's why I said "look nice and pretty for numerical code" not 
"be efficient".  There are times when you want blas-style functions for 
efficiency, and times when you want to write d = (a + b) * (c - b).  Caml 
can't do the latter [very cleanly].  That was my point.

Saying the latter isn't necessary or desired is the same type of argument 
people use against other high-level language features (gc, etc.).  When 
programming, most of my time is spent figuring out what I want to do and 
how, it is not spent optimizing (and I write games, which are notoriously 
prematurely optimized).  Once I figure something out, then I'll optimize it 
if necessary.  Blas-style functions inhibit rapid prototyping and 
experimentation, while expression-syntax-style operators inhibit 
efficiency.  I want to be able to use both, each at the appropriate time.

That's why I wish Ocaml supported the latter better.

Chris


-------------------
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] Re: Camlp4 optimizations (was: productivity improvement)

[Daniel de Rauglaudre]

Hi,

On Thu, Oct 17, 2002 at 11:32:31AM -0700, Chris Hecker wrote:
> 
> camlp4 can generate C with no problem (although I don't know if it can 
> create another file, but I don't see why not, it can run arbitrary caml 
> code during parsing).

Camlp4, in its standard usage, does not generate C: Camlp4, in its
standard usage, just converts source code (in any syntax) into normal
OCaml source code (by abstract syntax tree).

But of course, Camlp4 is a normal OCaml program, and therefore can
create, as side effects, intermediate files, C files, why not, and can
transmit to OCaml some code defining the good "external" definitions,
and so on. But it would not be what Camlp4 is created for.

And Camlp4 does not know the types of the things in the file its
treats. If you want types, you must do typing!!! And I am sorry,
typing a program is a rather complicated job...

When you write "let x = 3 in x + 2", Camlp4 does not even make the
relation between the first "x" and the second "x". For it, they are
just some pattern and some expression, that's all.

  ---

To know if Camlp4 can help: take your source program, add any syntax
extension that you would like to have, and write what you want that
Camlp4 generates for you in *normal OCaml syntax*: if you cannot write
your thing in normal OCaml syntax, it means that Camlp4 cannot help
you.

Since you cannot write C code in normal OCaml syntax, you cannot use
Camlp4 to generate C code.

-- 
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] Re: Camlp4 optimizations (was: productivity improvement)

[Brian Hurt]

On Thu, 17 Oct 2002, Chris Hecker wrote:

> The biggest problem with making ocaml look nice and pretty for numerical 
> code is that there is no overloading (of functions or operators), and 
> camlp4 doesn't have access to types, so you can't have both:
> 
> s*a (scalar times matrix)
> a*b (matrix times matrix)
> 
> What code would the * operator generate in camlp4?  This needs to be fixed 
> at a deeper level than syntax (which is where camlp4 operates...and 
> operates well! :).  Althought hopefully it's fixed in a way that doesn't 
> require a runtime type-check if the information is available at compile time.
> 
> Or, maybe I'm missing something...it would be awesome if I was and this was 
> possible!
> 

I'd like to ask a stupid question here: how important is operator 
overloading?  Remember, before you answer, that FORTRAN managed to be 
crowned king of numerical languages for decades (and may still hold the 
crown depending upon who you talk to), with no operator or function 
overloading.  You had to call functions with names like cgbmv() (pop quiz- 
what does that function do?) and dgesvd().

I'm still an ocaml newbie, so I don't know how ocaml handles operator 
overloading.  I do know how C++ handles operator overloading.  Consider 
the 'innocent' statement:
    a = b + c + d;
What you want is for the compiler to produce code like:
    a = b;
    a += c;
    a += d;
Instead, what the compiler instead does is:
    t1 = b + c;
    t2 = t1 + d;
    a = t2;
generating two unnessecary temporaries.  If your objects are complex 
variables (2 floats) or even short 3D vectors (3 floats) this isn't too 
bad.  If your objects are 10,000 element vectors or matricies, creating 
two unnecessary temporaries (or even 1 unnecessary temporary) is bad.

So why not just code it as:
    a = b;
    a += c;
    a += d;
?  Well, I ask- is that code all that much more understandable then:

    matrix.assign a b ;
    matrix.addto a c;
    matrix.addto a d;
?  The advantage of operator overloading is the ability to express complex 
equations "obviously"-
    a = b + c + d;
is way more understandable than the two examples above or:
    matrix.assign a (matrix.add (matrix.add b c) d)
which is the equivelent.  But if you can't optimize it, you're just asking 
to produce bad code.

The other cent I'd like to throw into this discussion is a pointer at the 
OoLaLa project- which is attempting to build a whole new linear algebra 
library in Java with an OO design (instead of the thin wrappers around 
FORTRAN-era BLAS libraries and various operator overloading proposals):
http://citeseer.nj.nec.com/luj00oolala.html
Yes, I know this isn't a functional design.  But I'm throwing it out there 
as a springboard for ideas.

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] Re: Camlp4 optimizations (was: productivity improvement)

[Chris Hecker]

>how important is operator overloading?

I'm amazed that people who are interested in high level languages are 
asking these questions (not to attack you personally, just the overall 
attitude)!

I replied to most of this issue in my previous post, but come on people, 
the job of a language is to make the programmer's life easier.  Software 
quality is horrible, for the most part, and we don't even get this horrible 
software on time.  Why?  Hint:  it's not because correct programs are 
running too slow and developers are spending that time optimizing.  It's 
because complex software is hard to write correctly.  The language should 
help with this.  Ocaml helps in a lot of ways with this problem, but when 
writing numerical code it doesn't help very much, or as much as it 
could.  That is what I'm complaining about.

If I could write matlab-style syntax in ocaml, hundreds of lines of code in 
my game would just disappear.  That would be wonderful!  It would mean it 
was easier and faster to write, to debug, and that when I realize I didn't 
actually want to do a certain operation, I could change it quickly.  When I 
finally figure out what I want to do and how I want to do it, I'll optimize it.

And besides, the entire idea behind a garbage collector is that it's fast 
at handling tons of small allocations!  I use tons of matrix -> matrix -> 
matrix operations (like add, mult, etc. in and attempt to make more 
readable code) and the performance is perfectly acceptable for 
development.  I will optimize things later, but LATER, and only if I need to.

Frustrated,
Chris


-------------------
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] Re: Camlp4 optimizations (was: productivity improvement)

[Brian Hurt]

On Thu, 17 Oct 2002, Chris Hecker wrote:

> 
> >how important is operator overloading?
> 
> I'm amazed that people who are interested in high level languages are 
> asking these questions (not to attack you personally, just the overall 
> attitude)!

Developers won't learn a new language with a reputation of inefficiency
(by which they mean how fast the program will run, not how easy is it to
develop in).  And I agree with you that this is wrong, but I admit- one of
the reasons I was attracted to Ocaml instead of other functional
programming languages was the performance.  I now like it enough that I'll
stick with it despite inefficiencies.  Wander up to your local java bigot 
and mention "I hear Java is slow" and watch him jump down your throat. 

And this does not necessarily mean that the performance isn't illusory.  
Notice that I used C++ as my "bad example", a language that has (IMHO an 
unjustified) reputation for performance.

Yes, this is marketing and not logical- so what?

I will say- there is a way to get both the ease of development of operator 
overloading *and* the performance of BLAS.  Make matricies first class 
types known to the compiler, like ints, floats, and strings (vectors can 
be considered m-by-1 matricies).  Now the compiler knows what 
substitutions are legal or not- it can easily replace a = b + c + d; with 
a = b; a += c; a += d;, or even a = d; a += c; a += b; if it feels like 
it.  

The compiler would then produce code which would call out to a 
library which would have to be linked in (rather like you have to add -lm 
to your command line to use sin() in C).  So programs which don't use 
matricies don't have to suffer the "code bloat" associated with them.

The only problem with adding matricies to the language is where do you
stop?  Matricies and vectors (as mx1 matricies), OK.  Complexs?  
Matricies (and vectors) of complexes?  Quaternions?  Directed rounding?  
Single and double precision FP?  Quad precision FP?  Matricies and vectors
of all of the above?  Arbitrary precision FP (with matricies)?  Interval
arithmetic (with matricies)?  Etc.

All of these and more have been proposed (for other languages).  Take some 
time to explore:
http://www.cs.berkeley.edu/~wkahan/
for examples (Prof. Kahan is one of the people being the IEEE FP spec).

Barring adding matricies to the language, your two options are operator 
overloads and/or functions of some sort (the two are not necessarily 
incompatible- a single library could supply both of them, with warnings to 
use the functions for best performance).

By the way, there's evidence that garbage collection *increases* 
performance.  See:
ftp://ftp.nj.nec.com/pub/pls/pldi94.ps.Z
if you don't already beleive me (or have already seen that paper).

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] Re: Camlp4 optimizations (was: productivity improvement)

[Jeffrey Palmer]

On Thursday 17 October 2002 4:19 pm, Brian Hurt wrote:
> I will say- there is a way to get both the ease of development of
> operator overloading *and* the performance of BLAS.  Make matrices
> first class types known to the compiler, like ints, floats, and
> strings (vectors can be considered m-by-1 matrices).  Now the
> compiler knows what substitutions are legal or not- it can easily
> replace a = b + c + d; with a = b; a += c; a += d;, or even a = d; a
> += c; a += b; if it feels like it.
>

There are alternatives to adding these as primitive types to the 
language. In the case of C++, the concept of template metaprogramming 
(basically a weakened macro system) has shown that it's possible to 
generate numeric code on par with Fortran by rewriting expressions to 
avoid pairwise evaluation. See:

http://osl.iu.edu/~tveldhui/papers/iscope97/index.html
http://osl.iu.edu/~tveldhui/papers/Expression-Templates/exprtmpl.html
http://osl.iu.edu/~tveldhui/papers/Template-Metaprograms/meta-art.html

for the background and some examples of this approach.

However, the (obvious) problem with this approach, from a C++ 
perspective, is that it is not supported by the language. This stuff 
was basically "discovered", rather than designed, and if you've ever 
tried to use these techniques, this becomes VERY clear. The syntax is a 
disaster. An in-language mechanism for this type of macro expansion (a 
la lisp/scheme macros) would simplify this immensely.

Is this approach implementable in ocaml? The C++ template mechanism has 
complete access to the C++ type system, which makes it significantly 
more useful than the standard preprocessor. I seem to remember an 
earlier posting (today) indicating that this type information isn't 
available in ocamlp4.

Does anyone know of any strongly-typed languages where this type of 
macro expansion/partial evaluation is available?  (I seem to remember 
GHC providing a hook mechanism for term rewriting during optimization, 
but I don't think that's quite the same...)

Cheers,

	- j

(Actually, now that I think about it, I recall someone on one of the C++ 
newsgroups discussing the possibility of using a functional language 
for the template language, since it seems like most of the interesting 
things you can do with templates are functional in nature.)


-- 
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] Re: Camlp4 optimizations (was: productivity improvement)

[Alessandro Baretta]

Jeffrey Palmer wrote:

> However, the (obvious) problem with this approach, from a C++ 
> perspective, is that it is not supported by the language. This stuff 
> was basically "discovered", rather than designed, and if you've ever 
> tried to use these techniques, this becomes VERY clear. The syntax is a 
> disaster. An in-language mechanism for this type of macro expansion (a 
> la lisp/scheme macros) would simplify this immensely.
> 
> Is this approach implementable in ocaml? The C++ template mechanism has 
> complete access to the C++ type system, which makes it significantly 
> more useful than the standard preprocessor. I seem to remember an 
> earlier posting (today) indicating that this type information isn't 
> available in ocamlp4.

I'm sorry to have to point out that this is false. The 
template rewriting mechanism knows absolutely nothing about 
typing. You can give the C++ compiler a template it will 
placidly accept, while at the same time giving you all sorts 
or typing errors at template instantiation time. This means 
that if you write a template library in C++ you'll know if 
it is type-correct (with respect to C++ *very weak* typing 
rules) only when you try to use it in some other project. 
This is equivalent to the non-typing of assembly language, 
which yields all sorts of runtime errors to the users. As 
far as C++ templates go, you have to consider as users the 
programmers who will use the template library. Template 
instantiation plays the part of running an assembled program.

Besides, what kind of access to the type system can a 
*generic* program have? If it depended on specific features 
of specific types it would no longer be generic, would it not?

The golden rule of C : Use functions, not macros.
The golden rule of C++: Use classes, not templates.

The Java developers knew both rules. They made a mess anyway.

> Does anyone know of any strongly-typed languages where this type of 
> macro expansion/partial evaluation is available?  (I seem to remember 
> GHC providing a hook mechanism for term rewriting during optimization, 
> but I don't think that's quite the same...)

Ocaml. Macro expansion == Syntax extension.
Macro processor == Camlp4.

Keep in mind that Camlp4 builds the complete abstract syntax 
tree of an ocaml program you parse with it. It later feeds 
the tree to the compiler. Once Camlp4 has built the syntax 
tree you can apply any program transformation you care to, 
in order to optimize your program. Of course, before 
applying such "program-rewriting-at-compile-time" 
techniques, you should prove them to be correct.

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] Re: Camlp4 optimizations (was: productivity improvement)

[Jeffrey Palmer]

On Thursday 17 October 2002 6:55 pm, Alessandro Baretta wrote:
> I'm sorry to have to point out that this is false. The
> template rewriting mechanism knows absolutely nothing about
> typing. You can give the C++ compiler a template it will
> placidly accept, while at the same time giving you all sorts
> or typing errors at template instantiation time. This means
> that if you write a template library in C++ you'll know if
> it is type-correct (with respect to C++ *very weak* typing
> rules) only when you try to use it in some other project.
> This is equivalent to the non-typing of assembly language,
> which yields all sorts of runtime errors to the users. As
> far as C++ templates go, you have to consider as users the
> programmers who will use the template library. Template
> instantiation plays the part of running an assembled program.
>

Hmm. I have two observations:

1) You can't "use" templates without instantiating them, so although 
you're right - template type checking is deferred to instantiation, 
this is by design (a pain, I agree).

2) Template code, during instantiation, has access to the type system. 
You can write conditional template code that will be instantiated only 
if A is a subclass of B, etc. Although the mechanisms used to do this 
are obtuse, it is possible.

> The golden rule of C++: Use classes, not templates.

Interesting. I'd say the opinion has shifted from not using templates to 
using them for almost everything. It seems that, since the introduction 
of the C++ standard library, everyone is building template libraries. 
It's almost as though people have decided that "virtual" is a dirty 
word. ;)

> Once Camlp4 has built the syntax
> tree you can apply any program transformation you care to,
> in order to optimize your program.

I really have to make some time to play with that thing - it really 
sounds amazing.

Oh, and in response to my own earlier question regarding partial 
evaluation and strongly-typed languages, I noticed a post elsewhere on 
the list to a very interesting site:

http://www.cs.rice.edu/~taha/MetaOCaml/

Enjoy!

	- 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] Re: Camlp4 optimizations (was: productivity improvement)

[Alessandro Baretta]

Jeffrey Palmer wrote:
> On Thursday 17 October 2002 6:55 pm, Alessandro Baretta wrote:
> 
> 
> Hmm. I have two observations:
> 
> 1) You can't "use" templates without instantiating them, so although 
> you're right - template type checking is deferred to instantiation, 
> this is by design (a pain, I agree).

It's more than a pain. John Max Skaller acutely pointed out 
that templates have "no semantics". The semantics of a 
template depends on the parameter(s) with which it is 
instantiated, and in a very bizzarre way. Code which 
compiles and is correct with well-behaved parameters--the 
STL, for example--becomes incorrect, won't compile, or will 
miserably die at runtime with a segfault, if it is 
instantiated with a parameter class redefining the basic 
operations--equality, assignment, copy constructor, etc--in 
a such a way as to violate the assumptions explicitly or 
implicitly made by the template designer. Such errors are 
not revealed when the template is written and "compiled". 
They are revealed at best at template instantiation time, 
and possibly at runtime.

Caml functors, on the other hand, are statically type 
checked at compile time. Once and for all. If they compile, 
they're correct. And that's it.

> 2) Template code, during instantiation, has access to the type system. 
> You can write conditional template code that will be instantiated only 
> if A is a subclass of B, etc. Although the mechanisms used to do this 
> are obtuse, it is possible.

I did not know such constructs exist. I knew about RTTI. Now 
I discover C++ has a TITI--Template Instantiation Type Id. I 
take it to mean that the compiler allows you to write 
manually the checks that it ought to perform by himself: 
namely, that the type parameter has the methods that you 
need to invoke on it. Can you point me to any reference I 
could look into on his point?

>>The golden rule of C++: Use classes, not templates.
> 
> 
> Interesting. I'd say the opinion has shifted from not using templates to 
> using them for almost everything. It seems that, since the introduction 
> of the C++ standard library, everyone is building template libraries. 
> It's almost as though people have decided that "virtual" is a dirty 
> word. ;)

It's just a matter of taste, like any golden rule. The 
predominant trend seems to be embodied by Java: subtyping 
polymorphism and RTTI, which in Java goes with the name 
"reflection".

>>Once Camlp4 has built the syntax
>>tree you can apply any program transformation you care to,
>>in order to optimize your program.
> 
> 
> I really have to make some time to play with that thing - it really 
> sounds amazing.

Not really. TANSTAAFL. You want to optimize your 
code--explicitly unroll loops, rewrite matrix manipulation 
code, and whatnot. Go on, but you better prove that what 
you're doing is correct. I am not a big fan of Hoare's 
method, but I'd definitely use it to make sure the resulting 
compiler is semantically equivalent to the vanilla ocamlc. 
Besides, it's not miraculous, what you end up with is always 
ocaml code, albeit in an abstract form. As DdR pointed out, 
Camlp4 can generate nothing that you cannot code by hand.

> Oh, and in response to my own earlier question regarding partial 
> evaluation and strongly-typed languages, I noticed a post elsewhere on 
> the list to a very interesting site:
> 
> http://www.cs.rice.edu/~taha/MetaOCaml/
> 
> Enjoy!
> 
> 	- j
> 

You too!

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] Re: Camlp4 optimizations (was: productivity improvement)

[Remi VANICAT]

Alessandro Baretta <alex@baretta.com> writes:

> Jeffrey Palmer wrote:
>> On Thursday 17 October 2002 6:55 pm, Alessandro Baretta wrote:
>> Hmm. I have two observations:
>> 1) You can't "use" templates without instantiating them, so although
>> you're right - template type checking is deferred to instantiation,
>> this is by design (a pain, I agree).
>
> It's more than a pain. John Max Skaller acutely pointed out that
> templates have "no semantics". The semantics of a template depends on
> the parameter(s) with which it is instantiated, and in a very bizzarre
> way. Code which compiles and is correct with well-behaved
> parameters--the STL, for example--becomes incorrect, won't compile, or
> will miserably die at runtime with a segfault, if it is instantiated
> with a parameter class redefining the basic operations--equality,
> assignment, copy constructor, etc--in a such a way as to violate the
> assumptions explicitly or implicitly made by the template
> designer. Such errors are not revealed when the template is written
> and "compiled". They are revealed at best at template instantiation
> time, and possibly at runtime.
>
> Caml functors, on the other hand, are statically type checked at
> compile time. Once and for all. If they compile, they're correct. And
> that's it.


Well, the Set.Make and Map.Make functor to the stdlib want the compare
function of their argument to be a comparison function. This in not
checked at compile time (this can't be verify). and if this not the
case, you can difficultly predict the comportment of those functor.
(well it won't segfault, but it may not do what you want).

SO it is not so simple.

>> Oh, and in response to my own earlier question regarding partial
>> evaluation and strongly-typed languages, I noticed a post elsewhere
>> on the list to a very interesting site:
>> http://www.cs.rice.edu/~taha/MetaOCaml/

There is also dml (http://oops.tercom.ru/dml/) that don't need a
patched version of ocaml...
-- 
Rémi Vanicat
vanicat@labri.u-bordeaux.fr
http://dept-info.labri.u-bordeaux.fr/~vanicat
-------------------
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] Re: Camlp4 optimizations (was: productivity improvement)

[Sven Luther]

On Fri, Oct 18, 2002 at 10:23:32AM +0200, Remi VANICAT wrote:
> Alessandro Baretta <alex@baretta.com> writes:
> 
> > Jeffrey Palmer wrote:
> >> On Thursday 17 October 2002 6:55 pm, Alessandro Baretta wrote:
> >> Hmm. I have two observations:
> >> 1) You can't "use" templates without instantiating them, so although
> >> you're right - template type checking is deferred to instantiation,
> >> this is by design (a pain, I agree).
> >
> > It's more than a pain. John Max Skaller acutely pointed out that
> > templates have "no semantics". The semantics of a template depends on
> > the parameter(s) with which it is instantiated, and in a very bizzarre
> > way. Code which compiles and is correct with well-behaved
> > parameters--the STL, for example--becomes incorrect, won't compile, or
> > will miserably die at runtime with a segfault, if it is instantiated
> > with a parameter class redefining the basic operations--equality,
> > assignment, copy constructor, etc--in a such a way as to violate the
> > assumptions explicitly or implicitly made by the template
> > designer. Such errors are not revealed when the template is written
> > and "compiled". They are revealed at best at template instantiation
> > time, and possibly at runtime.
> >
> > Caml functors, on the other hand, are statically type checked at
> > compile time. Once and for all. If they compile, they're correct. And
> > that's it.
> 
> 
> Well, the Set.Make and Map.Make functor to the stdlib want the compare
> function of their argument to be a comparison function. This in not
> checked at compile time (this can't be verify). and if this not the
> case, you can difficultly predict the comportment of those functor.
> (well it won't segfault, but it may not do what you want).

It will just do what you tell it to do, which is a feature, not a bug :)))

Friendly,

Sven Luther
-------------------
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] Re: Camlp4 optimizations (was: productivity improvement)

[Brian Hurt]

One thing that occurs to me in this discussion is that there seems to be 
two types of LinAlg library users:

- Those who work on lots of "small" matricies (4x4 or smaller).  
The classic example of this is doing 3D rendering.

- Those who work on a few "large" matricies- weather modeling, cad/cam 
solvers, etc.

There are lots of differences between the two categories of problems.  
For example- large matricies benefit enormously (both in terms of
computation required and memory required) from "specialized" forms having
special representations, while small matricies don't.  Consider banded,
symmetic, triangluar forms.  

A matrix-matrix multiply for 4x4 matricies is only 128 FLOPs- easily
inlinable and unrollable, and worthwhile to do both. A matrix-matrix
multiply for matricies of 1,000 x 1,000 elements would be two billion
(10**9) FLOPs- if the compiler tried to inline such a function, it'd
choke.  If it didn't choke, it'd produce a binary with a size measured in
gigabytes.  What the 1Kx1K matrix multiply wants is good blocking and
copying to take full advantage of cache- code which is worthless in the
4x4 case.

The 4x4 matrix is only 128 bytes in size (dense, full)- while we don't 
want to create lots of spurious copies, some copies aren't a problem.  
That 1Kx1K matrix weighs in at almost 8 meg- we don't want to create 
spurious copies if we can at all avoid it.  Etc.

The solution, I think, is to provide two interfaces- one optimized (and 
strictly constrained) to small matricies- 3x3, 4x4 at most.  We implement 
operator overloading here.  Small matricies only have one form (dense, 
full, not complex, same precision as float).  Then other people could 
write the "big" matrix library- with special forms, multiple precisions, 
comples numbers, etc.

Brian  

On Thu, 17 Oct 2002, Jeffrey Palmer wrote:

> On Thursday 17 October 2002 4:19 pm, Brian Hurt wrote:
> > I will say- there is a way to get both the ease of development of
> > operator overloading *and* the performance of BLAS.  Make matrices
> > first class types known to the compiler, like ints, floats, and
> > strings (vectors can be considered m-by-1 matrices).  Now the
> > compiler knows what substitutions are legal or not- it can easily
> > replace a = b + c + d; with a = b; a += c; a += d;, or even a = d; a
> > += c; a += b; if it feels like it.
> >
> 
> There are alternatives to adding these as primitive types to the 
> language. In the case of C++, the concept of template metaprogramming 
> (basically a weakened macro system) has shown that it's possible to 
> generate numeric code on par with Fortran by rewriting expressions to 
> avoid pairwise evaluation. See:
> 
> http://osl.iu.edu/~tveldhui/papers/iscope97/index.html
> http://osl.iu.edu/~tveldhui/papers/Expression-Templates/exprtmpl.html
> http://osl.iu.edu/~tveldhui/papers/Template-Metaprograms/meta-art.html
> 
> for the background and some examples of this approach.
> 
> However, the (obvious) problem with this approach, from a C++ 
> perspective, is that it is not supported by the language. This stuff 
> was basically "discovered", rather than designed, and if you've ever 
> tried to use these techniques, this becomes VERY clear. The syntax is a 
> disaster. An in-language mechanism for this type of macro expansion (a 
> la lisp/scheme macros) would simplify this immensely.
> 
> Is this approach implementable in ocaml? The C++ template mechanism has 
> complete access to the C++ type system, which makes it significantly 
> more useful than the standard preprocessor. I seem to remember an 
> earlier posting (today) indicating that this type information isn't 
> available in ocamlp4.
> 
> Does anyone know of any strongly-typed languages where this type of 
> macro expansion/partial evaluation is available?  (I seem to remember 
> GHC providing a hook mechanism for term rewriting during optimization, 
> but I don't think that's quite the same...)
> 
> Cheers,
> 
> 	- j
> 
> (Actually, now that I think about it, I recall someone on one of the C++ 
> newsgroups discussing the possibility of using a functional language 
> for the template language, since it seems like most of the interesting 
> things you can do with templates are functional in nature.)
> 
> 
> 


-------------------
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] Re: Camlp4 optimizations (was: productivity improvement)

[Chris Hecker]

> > I'm amazed that people who are interested in high level languages are
> > asking these questions (not to attack you personally, just the overall
> > attitude)!
>Developers won't learn a new language with a reputation of inefficiency...
>Yes, this is marketing and not logical- so what?

Huh?

1. We were never discussing taking the blas-style syntax out of the 
language (you couldn't, it's just function calls).  We were discussing 
adding a feature that would allow the expression-style syntax.  If you're 
saying that there shouldn't be any features in a language which can be 
misused to write slow code or something else of that nature, then every 
real language fails on that front.

2. This mailing list is not for marketing caml to each other (although the 
latest thread resurrection about C++ might belie that statement).  I have 
already chosen to use caml, as have most of the people on this list.  I was 
pointing out a way in which caml could be better to that audience, and was 
surprised at the response.

Anyway, this is getting silly.  Overloading (operators and functions) would 
help when writing certain kinds of programs, and I hope it gets added to 
the language.  Allowing infix function specification (instead of just 
operators) would be nice as well for these same kinds of programs, but it 
is not nearly as important (and it can be handled by camlp4 just fine).

Is there any news on the GCaml experiment from last year?

Chris
-------------------
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] Re: Camlp4 optimizations (was: productivity improvement)

[brogoff]

On Thu, 17 Oct 2002, Chris Hecker wrote:
[...snip...]
> Overloading (operators and functions) would 
> help when writing certain kinds of programs, and I hope it gets added to 
> the language. 

I agree, and me too. 

Another related wish that comes up every so often would be the ability to 
have records in the same module which can share field names. Since we have 
polymorphic variants it seems that it isn't such a stretch to have more 
polymorphic records. Going to classes means you give up pattern matching, 
and pattern matching is one of the most attractive features of ML. I realize 
that some people will argue that the omission of overloading is a good thing 
from the standpoint of readability (I don't agree, but I understand this 
argument) but I have yet to see anyone make a similar claim about OCaml 
records. 

> Allowing infix function specification (instead of just 
> operators) would be nice as well for these same kinds of programs, but it 
> is not nearly as important (and it can be handled by camlp4 just fine).
> 
> Is there any news on the GCaml experiment from last year?

The online code hasn't changed for more than a year, and that old version 
doesn't really work with the module system. From playing with the system, 
I thought it was fine for the kind of overloading I wanted but but some people 
may have problems with the explicitness. I also wonder if there is an 
efficiency penalty. Consider that if you are interested in overloading + 
on integers, floats, and complex, no penalty is acceptable. 

There has, of course, been a lot more work on overloading in the Haskell 
world, with constraint handling rules, and systems O and CT and such. I 
doubt we'll see overloading in Caml anytime soon...

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

Re: [Caml-list] Rule based language [was: productivity improvement]

[Alessandro Baretta]

Oleg wrote:
> Alex,
> 
> This looks pretty simple. What makes you think the program is a compelling 
> evidence of O'Caml superior productivity?

197 lines of code, including whitespace and commments. I 
think it is a pretty clear example of how you can write cool 
software in O'Caml in a very short time. If you had not been 
"lazy", as you said, and had tried implementing the same 
language in C++, I strongly doubt you could have written a 
more compact source.

> Is the idea to make a maximally efficient program? In that case, what kind of
> a) number of different tokens
> b) dataset size
> c) ruleset size
> d) rules size
> are we looking at?
>
> Regards
> Oleg

 From the standpoint of benchmarking, we'll need to write 
several test cases to see how the execution times scale with 
  program size. We might actually want to write an automatic 
testcase generator. I do no expect a C++ compiler to be able 
to beat ocamlopt by a significant amount, unless you use an 
optimized algorithm, different form the one I implemented. 
Anyhow, we shall take up the quest for benchmarking after 
your C++ clone of my "rules" program will be available.

BTW, if you wish to extend the language with other 
constructs, such as pattern matching rules, I'm willing to 
do this. Such constructs would probably increase the 
"lines-of-code" ratio of the C++ vs. O'Caml versions.

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] Rule based language [was: productivity improvement]

[Oleg]

[-- Attachment #1: Type: text/plain, Size: 1790 bytes --]

On Sunday 21 July 2002 09:00 am, Alessandro Baretta wrote:
> Oleg wrote:
> > Alex,
> >
> > This looks pretty simple. What makes you think the program is a
> > compelling evidence of O'Caml superior productivity?
>
> 197 lines of code, including whitespace and commments. I
> think it is a pretty clear example of how you can write cool
> software in O'Caml in a very short time. If you had not been
> "lazy", as you said, and had tried implementing the same
> language in C++, I strongly doubt you could have written a
> more compact source.


109 LOC in C++ counting blank lines and lines containing a single '}'. See 
atttached files.

A few notes about the differences between your O'Caml program and my C++ 
program: 

1) I'm not using Yacc or Lex for parsing, because I'm not familiar with these 
tools, so ugly parsing takes up most of those 109 LOC (Parsing things is 
peripheral to my professional interests right now. I don't write compilers)

2) I decided not to implement the "simple" keyword, because I did not 
understand what it was supposed to mean (a depth limit on deduction, I'm 
guessing, but what for?)

3) Your program fails to imlement multi-token post-conditions in rules and 
mutli-token goals (as described in your formal language specification)

4) The algorithms are different I think, resulting in, for example, about 
200x speed improvement for the attached test.input file on my P3-800MHz 
(g++-3.0 vs ocamlopt) (The output is identical).  The O'Caml program 
convergence seems to be quite unstable.  Sometimes it is as fast or even 
faster than the C++ program. 

I can see how the same algorithm can be implemented in ~100 LOC of O'Caml 
too. However, IMO as this and the previous examples show, reports about 
extreme LOC ratios are premature.

Cheers,
Oleg

[-- Attachment #2: test.input.gz --]
[-- Type: application/x-gzip, Size: 13749 bytes --]

[-- Attachment #3: rules.cpp.gz --]
[-- Type: application/x-gzip, Size: 1098 bytes --]

Re: [Caml-list] Rule based language [was: productivity improvement]

[Alessandro Baretta]

Oleg wrote:
>>197 lines of code, including whitespace and commments. I
>>think it is a pretty clear example of how you can write cool
>>software in O'Caml in a very short time. If you had not been
>>"lazy", as you said, and had tried implementing the same
>>language in C++, I strongly doubt you could have written a
>>more compact source.
>
 >
> 
> 109 LOC in C++ counting blank lines and lines containing a single '}'. See 
> atttached files.

Cool job Oleg! Hats off to you.

> A few notes about the differences between your O'Caml program and my C++ 
> program: 
> 
> 1) I'm not using Yacc or Lex for parsing, because I'm not familiar with these 
> tools, so ugly parsing takes up most of those 109 LOC (Parsing things is 
> peripheral to my professional interests right now. I don't write compilers)

I expected it to be so.

> 2) I decided not to implement the "simple" keyword, because I did not 
> understand what it was supposed to mean (a depth limit on deduction, I'm 
> guessing, but what for?)

Not a big deal.

> 3) Your program fails to imlement multi-token post-conditions in rules and 
> mutli-token goals (as described in your formal language specification)

I don't remember. I lost the original specs and I finished 
working on that program more than a year ago. I look at it 
again today if I have time. Otherwise I'll, think intensely 
about parsing and backtracking, under the Salentinian sun, 
on the white sand of the beaches of Alimini.

> 4) The algorithms are different I think, resulting in, for example, about 
> 200x speed improvement for the attached test.input file on my P3-800MHz 
> (g++-3.0 vs ocamlopt) (The output is identical).  The O'Caml program 
> convergence seems to be quite unstable.  Sometimes it is as fast or even 
> faster than the C++ program. 

I take this to mean you are challenging me, huh? You are, 
huh? Ok... Ok, you'll see... ;-)

> I can see how the same algorithm can be implemented in ~100 LOC of O'Caml 
> too. However, IMO as this and the previous examples show, reports about 
> extreme LOC ratios are premature.
> 
> Cheers,
> Oleg

I had only a modest O'Caml experience 14 months ago, when I 
wrote the code you have seen. On the other hand, you are an 
expert C++ programmer now, at the time of the "challenge". 
I'll pick up your challenge and try to cook up something by 
tonight. After that, we'll have to pick up our challenge 
again in late august.

Have a lot of fun!
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] compact.c

[Damien Doligez]

>From: Julie Farago <farago@eecs.harvard.edu>
>
>Is there a paper on the compaction code (compact.c) of the garbage
>collector (in byterun/)? Even though the documentation in this file is
>really exceptional, I am a little confused by how the inversion of
>pointers is used to compact the heap. Is there an algorithm I should
>lookup?

There is no paper on compact.c itself, but the algorithm is not
original.  If I remember correctly, it is from this paper:

F. Lockwood Morris, A time- and space-efficient garbage compaction
algorithm, Communications of the ACM, v.21 n.8, p.662-665, Aug. 1978

The only tricky part is the double inversion of pointers to infix
headers.  If you really need it, I'll write up a short description and
put it on my web page.

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