[Caml-list] failwith, raise and type inference

[Caml-list] failwith, raise and type inference

[Paul Guyot]

Hello,

My students came up with a behavior of ocaml I couldn't explain.
I have exactly the same result with 3.07pl2 and a fresh copy checked 
out from CVS.

>let rec f1 key dict =
>	match dict with
>		[] -> failwith "The key " ^ key ^ " could not be found"
>		| (aKey, aValue)::tail ->
>			if (aKey = key)
>			then aValue
>			else f1 key tail;;

is of type:

val f1 : string -> (string * string) list -> string = <fun>

while:

>exception SomeException of string;;
>
>let rec f2 key dict =
>	match dict with
>		[] -> raise (SomeException key)
>		| (aKey, aValue)::tail ->
>			if (aKey = key)
>			then aValue
>			else f2 key tail;;

is of type:

val f2 : string -> (string * 'a) list -> 'a = <fun>

Considering that failwith is of type string -> 'a and raise of type 
exn -> 'a, I couldn't figure out why the correct type for f is only 
infered with raise.

Any idea?

Paul
-- 
Philosophie de baignoire - consultations sur rendez-vous.

NPDS/NewtonOS: http://newton.kallisys.net:8080/
Apache/FreeBSD: http://www.kallisys.com/

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

Re: [Caml-list] failwith, raise and type inference

[Frederic van der Plancke]

Just a small precedence bug.

failwith "The key " ^ key ^ " could not be found"

is equivalent to:

(failwith "The key ") ^ key ^ " could not be found"

and not to:

failwith ("The key " ^ key ^ " could not be found")

F.

Paul Guyot wrote:
> 
> Hello,
> 
> My students came up with a behavior of ocaml I couldn't explain.
> I have exactly the same result with 3.07pl2 and a fresh copy checked
> out from CVS.
> 
> >let rec f1 key dict =
> >       match dict with
> >               [] -> failwith "The key " ^ key ^ " could not be found"
> >               | (aKey, aValue)::tail ->
> >                       if (aKey = key)
> >                       then aValue
> >                       else f1 key tail;;
> 
> is of type:
> 
> val f1 : string -> (string * string) list -> string = <fun>
> 
> while:
> 
> >exception SomeException of string;;
> >
> >let rec f2 key dict =
> >       match dict with
> >               [] -> raise (SomeException key)
> >               | (aKey, aValue)::tail ->
> >                       if (aKey = key)
> >                       then aValue
> >                       else f2 key tail;;
> 
> is of type:
> 
> val f2 : string -> (string * 'a) list -> 'a = <fun>
> 
> Considering that failwith is of type string -> 'a and raise of type
> exn -> 'a, I couldn't figure out why the correct type for f is only
> infered with raise.
> 
> Any idea?
> 
> Paul
> --
> Philosophie de baignoire - consultations sur rendez-vous.
> 
> NPDS/NewtonOS: http://newton.kallisys.net:8080/
> Apache/FreeBSD: http://www.kallisys.com/
> 
> -------------------
> To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
> Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

-------------------
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] failwith, raise and type inference

[Paul Guyot]

À (At) 13:49 +0000 2/04/04, Frederic van der Plancke écrivait (wrote) :
>Just a small precedence bug.
>
>failwith "The key " ^ key ^ " could not be found"
>
>is equivalent to:
>
>(failwith "The key ") ^ key ^ " could not be found"
>
>and not to:
>
>failwith ("The key " ^ key ^ " could not be found")

Oh yeah, that's obviously that. :)
Thanks for all the replies.

Paul
-- 
Philosophie de baignoire - consultations sur rendez-vous.

NPDS/NewtonOS: http://newton.kallisys.net:8080/
Apache/FreeBSD: http://www.kallisys.com/

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

Re: [Caml-list] failwith, raise and type inference

[Nicolas Cannasse]

> >let rec f1 key dict =
> > match dict with
> > [] -> failwith "The key " ^ key ^ " could not be found"
> > | (aKey, aValue)::tail ->
> > if (aKey = key)
> > then aValue
> > else f1 key tail;;

The tip is here :

failwith "The key " ^ key ^ " could not be found"

is actually equivalent to :

(failwith "The key ") ^ key ^ " could not be found"

and different from (what you were thinking) :

failwith ("The key " ^ key ^ " could not be found")

Regards,
Nicolas Cannasse

-------------------
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] failwith, raise and type inference

[Correnson Loïc]

Bad priority between operators and function call:
(failwith a ^ b) must be understood as (failwith a)^b.
    L.

-------------------
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] failwith, raise and type inference

[Luc Maranget]

> Hello,
> 
> My students came up with a behavior of ocaml I couldn't explain.
> I have exactly the same result with 3.07pl2 and a fresh copy checked 
> out from CVS.
> 
> >let rec f1 key dict =
> >	match dict with
> >		[] -> failwith "The key " ^ key ^ " could not be found"
> >		| (aKey, aValue)::tail ->
> >			if (aKey = key)
> >			then aValue
> >			else f1 key tail;;
> 
> is of type:
> 
> val f1 : string -> (string * string) list -> string = <fun>
> 

> Any idea?

I think I have a clue :

failwith "The key " ^ key ^ " could not be found"

is parsed as

(failwith "The key ") ^ key ^ " could not be found"

Hence the overall type of this expression is string.


The other result of the pattern matching matching has the same type
as aValue

Finally, you get that the type of aValue (second component of
your pairs is string).

I think you can check my interpretation by issuing

>f1 "bonga" []
>;;
Exception: Failure "The key ".


Of course, the intended coding is
failwith ("The key " ^ key ^ " could not be found")


Admitedly caml syntax is not very  beginner friendly.
But the observed parsing has some internal logics.

On usualy understand that  f x + y is in fact  (f x) + y
But here, with failwith being a ``special'' function and ^ a ``special''
operator, well...


Cheers,

--Luc Maranget

-------------------
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] weird floating poing behavior on windows

[Zeno Lee]

Can anyone tell me what's going on here?  Is this a known issue on windows? 

C:\>ocaml
        Objective Caml version 3.07+2
# 0.2 *. 0.26;;
- : float = 0.052000000000000005
# 0.8 *. 0.7 *. 0.8;;
- : float = 0.44799999999999995


-------------------
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] weird floating poing behavior on windows

[Greg Bacon]

In message <008101c418ea$3ff43780$6401a8c0@xp>,
    "Zeno Lee" writes:

: Can anyone tell me what's going on here?  Is this a known issue on
: windows? 
: 
: C:\>ocaml
:         Objective Caml version 3.07+2
: # 0.2 *. 0.26;;
: - : float = 0.052000000000000005
: # 0.8 *. 0.7 *. 0.8;;
: - : float = 0.44799999999999995

It's a known issue on digital computers, i.e., with finite-precision
arithmetic.  See "What Every Computer Scientist Should Know About
Floating-Point Arithmetic":

    http://www.validlab.com/goldberg/paper.pdf

Greg

-------------------
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] weird floating poing behavior on windows

[David Brown]

On Fri, Apr 02, 2004 at 02:39:43PM -0500, Zeno Lee wrote:
> Can anyone tell me what's going on here?  Is this a known issue on windows? 
> 
> C:\>ocaml
>         Objective Caml version 3.07+2
> # 0.2 *. 0.26;;
> - : float = 0.052000000000000005
> # 0.8 *. 0.7 *. 0.8;;
> - : float = 0.44799999999999995

Nothing unusual.  Floats only have a certain amount of precision.  The
toplevel prints floats out with more precision than they contain.  It
does the same thing on Linux.

For example, in C:

        #include <stdio.h>

        int
        main (int argc, char **argv)
        {
          printf ("%.17g\n", 0.2 * 0.26);
          printf ("%.17g\n", 0.8 * 0.7 * 0.8);
          return 0;
        }

prints:
        0.052000000000000005
        0.44799999999999995

Now the real question is why does the toplevel do this (and where, in
the code is it coming from).  string_of_float only uses 12 digits.

Dave Brown

-------------------
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] weird floating poing behavior on windows

[Zeno Lee]

This does not happen to me on Solaris from which I do all my ocaml work, but
I happened to be using the toplevel on windows as a quick and dirty
calculator when I noticed the different behavior.

solaris$ ocaml
        Objective Caml version 3.06

#  0.8 *. 0.7 *. 0.8;;
- : float = 0.448

however, when I use your example c program on the same solaris machine it
prints out

0.44799999999999995


----- Original Message ----- 
From: "David Brown" <caml-list@davidb.org>
To: "Zeno Lee" <zeno.lee@earthlink.net>
Cc: <caml-list@inria.fr>
Sent: Friday, April 02, 2004 3:07 PM
Subject: Re: [Caml-list] weird floating poing behavior on windows


> On Fri, Apr 02, 2004 at 02:39:43PM -0500, Zeno Lee wrote:
> > Can anyone tell me what's going on here?  Is this a known issue on
windows?
> >
> > C:\>ocaml
> >         Objective Caml version 3.07+2
> > # 0.2 *. 0.26;;
> > - : float = 0.052000000000000005
                        052000000000000005

> > # 0.8 *. 0.7 *. 0.8;;
> > - : float = 0.44799999999999995
>
> Nothing unusual.  Floats only have a certain amount of precision.  The
> toplevel prints floats out with more precision than they contain.  It
> does the same thing on Linux.
>
> For example, in C:
>
>         #include <stdio.h>
>
>         int
>         main (int argc, char **argv)
>         {
>           printf ("%.17g\n", 0.2 * 0.26);
>           printf ("%.17g\n", 0.8 * 0.7 * 0.8);
>           return 0;
>         }
>
> prints:
>         0.052000000000000005
>         0.44799999999999995
>
> Now the real question is why does the toplevel do this (and where, in
> the code is it coming from).  string_of_float only uses 12 digits.
>
> Dave Brown

-------------------
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] weird floating poing behavior on windows

[Pierre Weis]

> This does not happen to me on Solaris from which I do all my ocaml work, but
> I happened to be using the toplevel on windows as a quick and dirty
> calculator when I noticed the different behavior.
> 
> solaris$ ocaml
>         Objective Caml version 3.06
                                    ^
You are using version 3.06 on Solaris and 3.07 on Windows: the way
the top-level prints floats has changed in version 3.07.

Regards,

Pierre Weis

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


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

Re: [Caml-list] weird floating poing behavior on windows

[Brian Hurt]

On Fri, 2 Apr 2004, Zeno Lee wrote:

> This does not happen to me on Solaris from which I do all my ocaml work, but
> I happened to be using the toplevel on windows as a quick and dirty
> calculator when I noticed the different behavior.

Gnu Libc has special hacks in it so that it will want to print out 2.0 
instead of 1.9999999997824 etc.  Which masks the error, it doesn't 
eliminate it.

-- 
"Usenet is like a herd of performing elephants with diarrhea -- massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it."
                                - Gene Spafford 
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] weird floating poing behavior on windows

[Brian Hurt]

On Fri, 2 Apr 2004, Zeno Lee wrote:

> Can anyone tell me what's going on here?  Is this a known issue on windows? 

This is a known issue with floating point numbers.  Take a class or get a 
book on numerical analysis is my recommendation.

Here's the basic problem: let's assume our machine works in base 10 
instead of base 2, and that floating point numbers only hold 4 decimal 
digits.  So how does the machine represent 1.0/3.0?  It can't, not 
exactly.  It's instead represented as 0.3333.  Four digits of accuracy, 
remember?  So we take this number, and multiply it by 3.0, we get not the 
expected answer of 1.0, but instead 0.3333*3, or 0.9999.  Opps.  

Now, in finite precision binary fp, we can't exactly represent 1/5th, just
like we can't exactly represent 1/3 in finite precision decimal.  The
system gets "close", but can't do it exactly, so every once in a while you
get an answer a little larger or smaller than expected.  Even worse, these
small errors can accumulate, snowballing into huge errors.  A lot of very
intelligent people spend years making algorithms in which these errors
tend to cancel each other out instead of accumulating- so that if this 
calculation comes out a little high, the next calculation will likely come 
out a little low.  You can get a PhD and spend your life doing this, and a 
lot of people have.  My recommendation is to simply get a book, and do 
things the way they tell you to.

-- 
"Usenet is like a herd of performing elephants with diarrhea -- massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it."
                                - Gene Spafford 
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] failwith, raise and type inference

[Pierre Weis]

[...]
> Admitedly caml syntax is not very  beginner friendly.
> But the observed parsing has some internal logics.
> 
> On usualy understand that  f x + y is in fact  (f x) + y
> But here, with failwith being a ``special'' function and ^ a ``special''
> operator, well...

That could be part of the problem: failwith is not ``special'' nor is ^,
hence the regular treatment of f x ^ y as (f x) ^ y and failwith x ^ y
as (failwith x) ^ y.

Operator precedence in Caml has been carefully crafted, you should
have a look at the programming guide lines that gives some hints on the
internal logics of some parts of the parsing, in the section

   When to use parentheses within an expression

Best regards,

Pierre Weis

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


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

Re: [Caml-list] failwith, raise and type inference

[Ker Lutyn]

I wonder if we could have Haskell's $ operator added to OCaml. It would make
this idiom and a lot of my code nicer.

    failwith $ "foo" ^ "bar"

Defining it myself as

    let ($) f x = f x

doesn't work because of precedence and associativity. The caml sources
frequently define

    let (++) x f = f x

which is a similar idea - but lots of times Haskell's $ is what you want.



--- Pierre Weis <pierre.weis@inria.fr> wrote:
> [...]
> > Admitedly caml syntax is not very  beginner friendly.
> > But the observed parsing has some internal logics.
> > 
> > On usualy understand that  f x + y is in fact  (f x) + y
> > But here, with failwith being a ``special'' function and ^ a ``special''
> > operator, well...
> 
> That could be part of the problem: failwith is not ``special'' nor is ^,
> hence the regular treatment of f x ^ y as (f x) ^ y and failwith x ^ y
> as (failwith x) ^ y.
> 
> Operator precedence in Caml has been carefully crafted, you should
> have a look at the programming guide lines that gives some hints on the
> internal logics of some parts of the parsing, in the section
> 
>    When to use parentheses within an expression
> 
> Best regards,
> 
> Pierre Weis
> 
> INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://pauillac.inria.fr/~weis/
> 
> 
> -------------------
> To unsubscribe, mail caml-list-request@inria.fr Archives:
> http://caml.inria.fr
> Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ:
> http://caml.inria.fr/FAQ/
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners


__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway 
http://promotions.yahoo.com/design_giveaway/

-------------------
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] failwith, raise and type inference

[Jacques Garrigue]

From: Ker Lutyn <ker527mail@yahoo.com>
> I wonder if we could have Haskell's $ operator added to OCaml. It would make
> this idiom and a lot of my code nicer.
> 
>     failwith $ "foo" ^ "bar"
> 
> Defining it myself as
> 
>     let ($) f x = f x
> 
> doesn't work because of precedence and associativity. The caml sources
> frequently define
> 
>     let (++) x f = f x
> 
> which is a similar idea - but lots of times Haskell's $ is what you want.

This doesn't look very much related to the original thread.
But you just have to find an operator with the right associativity.

    let (@<) f x = f x ;;
    print_string @< String.capitalize  @< "foo" ^ "bar" ;;

Since the first character decides the associativity, you might also
choose @@, @>, or anything you like. ^^, ^@, ... would have the same
associativity and precedence also.
Look at section 6.7 of the manual for infix operators and their
precedences.

Jacques Garrigue

-------------------
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] failwith, raise and type inference

[Issac Trotts]

> This doesn't look very much related to the original thread.
> But you just have to find an operator with the right associativity.
> 
>     let (@<) f x = f x ;;
>     print_string @< String.capitalize  @< "foo" ^ "bar" ;;
> 
> Since the first character decides the associativity, you might also
> choose @@, @>, or anything you like. ^^, ^@, ... would have the same
> associativity and precedence also.
> Look at section 6.7 of the manual for infix operators and their
> precedences.

Why not just use parens?

-- 
Issac Trotts
http://mallorn.ucdavis.edu/~ijtrotts
(w) 530-757-8789

-------------------
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] failwith, raise and type inference

[skaller]

On Tue, 2004-04-06 at 15:23, Issac Trotts wrote:
> > This doesn't look very much related to the original thread.
> > But you just have to find an operator with the right associativity.

> Why not just use parens?

.. because we want to write Ocaml not Lisp? <j/k>

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



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

Re: [Caml-list] failwith, raise and type inference

[Christophe TROESTLER]

> --- Pierre Weis <pierre.weis@inria.fr> wrote:
> > [...]
> > Operator precedence in Caml has been carefully crafted, you should

Well I have a little question on this.  The guide says "Arithmetic
operators: the same rules as in mathematics." but

-. 3.**2.

returns 9. while in math -x^2 means -(x^2) and not (-x)^2 !  I am
curious why such an oddity.

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] failwith, raise and type inference

[skaller]

On Tue, 2004-04-06 at 11:15, Christophe TROESTLER wrote:

> Well I have a little question on this.  The guide says "Arithmetic
> operators: the same rules as in mathematics." but
> 
> -. 3.**2.
> 
> returns 9. while in math -x^2 means -(x^2) and not (-x)^2 !  I am
> curious why such an oddity.

The correct grammar here is rather nasty.
I use it in Felix, but i'm not at all sure it's
a good idea. The problem comes with:

	-x^2, x^-2, x^2^3

which are

	-(x^2), x^(-2), x^(2^3)

I use this grammar (which I hope delivers the above),
and is supposed to be the same as FORTRAN:
the nastiness is the 'uplink' from power to 
prefixed.

term:
  ...
  prefixed { $1 }

prefixed:
  | PLUS power  { apl $1 "pos" $2 }
  | MINUS power { apl $1 "neg" $2 }
  | TILDE power { apl $1 "compl" $2 }
  | power       { $1 }

/* exponentiation is right associative */
power:
  | superscript STARSTAR prefixed      { apl2 $2 "pow" [$1; $3] }
  | superscript { $1 }

superscript:
 ...

Knuth found this whole idea so distasteful that
in TeX the rule is that ^ and _ (super and subscript
operators) are unassociative and require explicit
bracketing.

Consider also:

	fgx
which usually means f(g(x)) but can also mean (fg)x ... 
I'm not sure there *are* any 'usual' rules in maths.

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



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

Re: [Caml-list] failwith, raise and type inference

[Eric C. Cooper]

On Tue, Apr 06, 2004 at 05:05:44PM +1000, skaller wrote:
> I'm not sure there *are* any 'usual' rules in maths.

Yes, traditional math notation needs human disambiguation:
consider sin^2 (x) versus sin^{-1} (x)

I don't think we want to require AI in the ocaml parser ...

-- 
Eric C. Cooper          e c c @ c m u . e d u

-------------------
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] failwith, raise and type inference

[Christophe TROESTLER]

On 06 Apr 2004, skaller <skaller@users.sourceforge.net> wrote:
> 
> On Tue, 2004-04-06 at 11:15, Christophe TROESTLER wrote:
> 
> > -. 3.**2.
> > 
> > returns 9. while in math -x^2 means -(x^2) and not (-x)^2 !
>
> I'm not sure there *are* any 'usual' rules in maths.

Well -x^2 as meaning -(x^2) *is* a usual rule -- no mathematician will
ever understand  it as (-x)^2.   Still my question remains  as whether
the above is intended by the  OCaml developpers or is just a case that
"slipped through" (and an oddity that has bitten me once).

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] failwith, raise and type inference

[Xavier Leroy]

> > > -. 3.**2.
> > > 
> > > returns 9. while in math -x^2 means -(x^2) and not (-x)^2 !
> >
> > I'm not sure there *are* any 'usual' rules in maths.
> 
> Well -x^2 as meaning -(x^2) *is* a usual rule -- no mathematician will
> ever understand  it as (-x)^2.   Still my question remains  as whether
> the above is intended by the  OCaml developpers or is just a case that
> "slipped through" (and an oddity that has bitten me once).

Off the top of my head, I'd say this behavior wasn't intentional and
is probably a mistake.  I haven't checked with the Yacc grammar, though
(Yacc is somewhat cranky with the precedences, and it happens that
expressing the right precedences isn't obvious.)

- Xavier Leroy

-------------------
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] failwith, raise and type inference

[skaller]

On Fri, 2004-04-09 at 17:32, Xavier Leroy wrote:

> Off the top of my head, I'd say this behavior wasn't intentional and
> is probably a mistake.  I haven't checked with the Yacc grammar, though
> (Yacc is somewhat cranky with the precedences, and it happens that
> expressing the right precedences isn't obvious.)

I tried and couldn't get it to work. Why use it anyhow?

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



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