Home     About     Download     Resources     Contact us

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at ocaml.org.

Browse thread
Interactive technical computing
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
 Date: 2007-03-08 (20:34) From: Christophe TROESTLER Subject: Re: [Caml-list] Interactive technical computing
```On Thu, 8 Mar 2007, Jon Harrop <jon@ffconsultancy.com> wrote:
>
> I can't justify the time unless I get to sell something. :-)

I understand that, that why I put Gerd's quote first.

> I don't think you can obtain F#'s brevity/clarity that way because
> you need to affect type inference and macros can't do that.

No but macros can locally change what '+' means.  With some Camlp4
hackery and using the Vec.t type of Lacaml (which is a shorthand for
(float, Bigarray.float64_elt, Bigarray.fortran_layout)
Bigarray.Array1.t), your F# example could look :

# let a = {| 1.; 2.; 3. |} and b = {| 2.; 3.; 4. |};;
val a : Vec.t = {| 1.; 2.; 3. |}
val b : Vec.t = {| 2.; 3.; 4. |}
# Vec.(a + b);;
- : Vec.t = {| 3.; 5.; 7. |}

Of course, when mixing vectors and matrices, we will not be able to
stay with only + and * but I am not sure that having to put type
annotations will compare favorably to put the expression in Mat.(...)
and inventing a _few_ additional operators.

Moreover I think that, in some respects, it is even better than
overloading!  For example if you write

# Vec.(a + b + c)

then Camlp4 could generate code that only needs to create 1 temporary
vector to hold the result instead of 2 (as is the case in F#).

Cheers,
ChriS

```