Version française
Home     About     Download     Resources     Contact us    
Browse thread
non-symbol infix functions
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Pierre Weis <Pierre.Weis@i...>
Subject: Re: non-symbol infix functions
> This simply has to be an FAQ, but I can't find a single reference to
> it in the FAQ or the manual (except the BNF, which is wrong, I
> think).

Right: I should add an answer to this question in the FAQ.

The wrong parts of the BNF of the manual must also be corrected (feel
free to suggest the correct BNF please: we will be glad to insert it
in place of the current BNF).

> There's no way to define an arbitrarily named infix function, right?

Yes.

> The BNF in the manual implies you can't do it.

Yes.

> But at the same time, that BNF implies you can't have "external"
> infix operators that aren't value-names (which have to be either
> lowercase-ident or ( operator-name )).

Yes.

> Yet, pervasives.mli has "external (lsl)..." in it. 

Yes. No contradiction with your points above: lsl is effectively a
lowercase-ident.

In fact, the ident lsl is defined as a reserved keyword with lexical
class INFIXOP4, hence it can be used as an infix.

The same is true for a limited list of infix identifiers
or, mod (INFIXOP3), land (INFIXOP3), lor (INFIXOP3), lxor (INFIXOP3),
lsl (INFIXOP4), lsr (INFIXOP4), asr (INFIXOP4).

Note also that true, false, and [] are reserved keywords.

Also note that reserved keywords are indeed reserved, hence the user
cannot suppress keywords or define new ones.

> So, why can there be an external (lsl) but not a let (lsl) x y =
> ...?  If it's true that you can't do it internally, why did you guys
> bother hacking lsl and the other bit ops to be infix, since it
> breaks consistency (and taunts the programmer with a non-symbol
> infix operator the likes of which he can't make himself)? 

The external status of a value is not a syntactic matter but a
semantic property: it means that the definition is not written in
Caml, but elsewhere. Very often the definition is a C function, or
more directly an instruction of the byte-code interpreter (or some
assember instructions for the native code compiler). This external
status is decided for efficiency considerations (e.g. low-level string
manipulation functions), or to avoid useless reimplementation effort
(e.g. arithmetic operators, Yacc parser generator engine).

So, yes, lsl is defined as an external primitive (for efficiency
reasons, since it is a processor instruction on most platforms).

But, no, you can ``do it internally'', if you wanted to write the
corresponding Caml code. For instance:

# let (lsl) x y = x + y (* Write appropriate code here *);;
val ( lsl ) : int -> int -> int = <fun>

> Perhaps this should be added to the FAQ?
> Chris

Yes. But it is a bit complex, since the FAQ is for both the Objective
Caml and Caml Light systems. Unfortunately this post is irrelevant for
Caml Light, since Caml Light features arbitrary user's defined infixes
identifiers.

May be the Caml list archives, can be considered as a ``super'' FAQ ?

Pierre Weis

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