non-symbol infix functions

non-symbol infix functions

[Chris Hecker]

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).  

There's no way to define an arbitrarily named infix function, right?  The BNF in the manual implies you can't do it.  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 )).  Yet, pervasives.mli has "external (lsl)..." in it.

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)?

Perhaps this should be added to the FAQ?

Chris

Re: non-symbol infix functions

[Pierre Weis]

> 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/

Re: non-symbol infix functions

[Chris Hecker]

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

Right, I meant for an arbitrary identifier.

Anyway, is there a rationale for this?  Was it just not worth the effort, or did it lead to ambiguities or something?

Chris

Re: non-symbol infix functions

[Pierre Weis]

> >But, no, you can ``do it internally'', if you wanted to write the
> >corresponding Caml code. 
> 
> Right, I meant for an arbitrary identifier.
> 
> Anyway, is there a rationale for this?  Was it just not worth the
> effort, or did it lead to ambiguities or something?
> 
> Chris

Problem is that the parsing of the language becomes highly context
dependant, since interpretation of expression depends on the infix
declaration context. This is rather unfortunate when you want to have
separate compilation.

Now we may have decided to remove all the infix alphanumeric
identifiers, but we failed to find good infix symbols for all the
operations.

Best regards,

Pierre Weis

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