Re: [Caml-list] kprintf with user formatters

[Pierre Weis <pierre.weis@inria.fr>]

[...]
> Is "match pred with true -> expr1 | false -> expr2" not
> equivalent to "if pred then expr1 else expr2"? If so, isn't pattern
> matching a fourth lazy construct?

Yes indeed, if you consider ``match'' as an operator, which is a bit
hairy, since match would be a (2n+1)-ary operator (for any given
positive integer n), taking as input 1 expression (the one to be
matched) and n (pattern, expression) pairs to match the
expression. Given that there is no notion of evaluation semantics
associated to a pattern (in the sense of the evaluation of expression)
this would be strange. However, the very match expression you
mentioned has indeed something of a lazyness behavior, since it is
indeed equivalent of an ``if ... then ... else ...'' construct, as
I know you know :)

> Just after I wrote that last post I realised that this approach
> could actually be useful in numerical contexts. As a trivial
> example, integer multiply could lazily evaluate its second argument
> (only when it is pure, if conventional semantics are to be
> preserved), not needing it if the first argument is zero.

I don't think the gain would overcome the cost of having to create
thunks in practice. On the other hand, taht would lead to evaluate the
operation 0 * expr to 0, even if the computation of expr would lead to
divergence (never terminates or fails). It's mathematically kind of
weird, I think. For instance, you would have a hard time to persuade a
matematician that

0 * ln (0)

is well-defined and evaluates to 0, ``because ln (0) has not to be
considered at all given the left operand''.

Hence, as far as I know, arithmetics operators are always considered
strict in lazy languages.

> This may be useful in more complicated settings, i.e. when dealing
> with data structures rather than primitive types and when predicates
> over the data structure can be evaluated much more quickly than the
> corresponding expression.

I'm a bit lost here. Could you explain a bit ?

> Such functionality can, of course, be implemented in vanilla
> OCaml. But I'd like to see a language which allowed mathematics to
> be expressed in a notation as close to conventional written form as
> possible (although I prefer type distinctions, like "+" vs "+.")
> whilst retaining efficiency (I'd also like to see deforesting,
> e.g. in vector expressions without having to resort to maps, folds
> etc.).

Yes, we all want such a language. Caml is the best approximation I
know, wrt a perfect match between efficiency and notational facility.

> Perhaps an OCaml -> OCaml optimising compiler would be a good
> project for someone? That way implementation details and their
> benefits can be examined without having to touch the OCaml
> compilers. I think it could be quite fun to play with such a
> thing...
>
> Cheers,
> Jon.

Yes, many people have dreamed upon (or even have planned to do) such a
tool in the past. These days, the availability of the camlp4 tools
would help a lot to perform such a goal...

Best regards,

Pierre Weis

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

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners