[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ 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/