Custom operators in the revised syntax

Custom operators in the revised syntax

[Nicolas Pouillard]

Hello,

Again this message is about the revised syntax and it's negative
points or useless distances with the original one.

Today it's about custom operators. In the original syntax everyone
knows that's easy to define and use custom operators like ++, -->,
>>>, +|, =?=, ... and as many as you want.

To declare them in the original syntax one needs parens:

let ( =?= ) x y = ...;;

In the revised syntax one use a backslash:

value \=?= x y = ...;

Why not... but in the revised syntax these new operators are not
automatically infix or prefix or postfix, you have to make your own
syntax extension. In practice I found it too heavy, unless you already
have a custom syntax extension local to the project or something like
that.

However there is bad things with parens:

- Not LL(1) when treating them in parsing
- Spaces must be used for the `*' character to avoids starting comments.

In fact when dealing them in the lexer that's ok.
And the space issue is not too big.

Concerning the fixity of these operators I've already changed it to
have the same thing as the original syntax.

Concerning the backslash, I want to restore the parens convention to
declare them and then free the backslash character and make it
available in the default lexer (useful for an ascii lambda for
instance).

As before, feel free to make comments on that (not really passionating) subject.

Regards,

-- 
Nicolas Pouillard

Re: [Caml-list] Custom operators in the revised syntax

[Loup Vaillant]

2007/5/10, Nicolas Pouillard <nicolas.pouillard@gmail.com>:
> Hello,
>
> Again this message is about the revised syntax and it's negative
> points or useless distances with the original one.
>
> Today it's about custom operators. In the original syntax everyone
> knows that's easy to define and use custom operators like ++, -->,
> >>>, +|, =?=, ... and as many as you want.
>
> To declare them in the original syntax one needs parens:
>
> let ( =?= ) x y = ...;;
>
> In the revised syntax one use a backslash:
>
> value \=?= x y = ...;
>
> Why not... but in the revised syntax these new operators are not
> automatically infix or prefix or postfix, you have to make your own
> syntax extension. In practice I found it too heavy, unless you already
> have a custom syntax extension local to the project or something like
> that.

I regret that a bit too. However, I can't tell I really miss it: I
find the default prefix syntax for function terse enough, so I don't
bother. The only useful usage I can think about is associative
operators, with which one can fold many arguments at once.

For example, the function composition :
(f (g (h (i x)))) becomes (f ° g ° h ° i) x
wich looks a bit better.


>
> However there is bad things with parens:
>
> - Not LL(1) when treating them in parsing
> - Spaces must be used for the `*' character to avoids starting comments.
>
> In fact when dealing them in the lexer that's ok.
> And the space issue is not too big.
>
> Concerning the fixity of these operators I've already changed it to
> have the same thing as the original syntax.

By the way, which are the fixity and associativity of custom operators
in the original syntax?


> Concerning the backslash, I want to restore the parens convention to
> declare them and then free the backslash character and make it
> available in the default lexer (useful for an ascii lambda for
> instance).

Err, I may not understand, but isn't "fun" terse enough? Or is it just
an idea from Haskell?

> As before, feel free to make comments on that (not really passionating) subject.

It should be : adding up "not really passionating" upgrades may lead
to a quiet revolution, eventually. :)

Regards,
Loup Vaillant

Re: [Caml-list] Custom operators in the revised syntax

[Nicolas Pouillard]

On 5/10/07, Loup Vaillant <loup.vaillant@gmail.com> wrote:
> 2007/5/10, Nicolas Pouillard <nicolas.pouillard@gmail.com>:
> > Hello,
> >
> > Again this message is about the revised syntax and it's negative
> > points or useless distances with the original one.
> >
> > Today it's about custom operators. In the original syntax everyone
> > knows that's easy to define and use custom operators like ++, -->,
> > >>>, +|, =?=, ... and as many as you want.
> >
> > To declare them in the original syntax one needs parens:
> >
> > let ( =?= ) x y = ...;;
> >
> > In the revised syntax one use a backslash:
> >
> > value \=?= x y = ...;
> >
> > Why not... but in the revised syntax these new operators are not
> > automatically infix or prefix or postfix, you have to make your own
> > syntax extension. In practice I found it too heavy, unless you already
> > have a custom syntax extension local to the project or something like
> > that.
>
> I regret that a bit too. However, I can't tell I really miss it: I
> find the default prefix syntax for function terse enough, so I don't
> bother. The only useful usage I can think about is associative
> operators, with which one can fold many arguments at once.
>
> For example, the function composition :
> (f (g (h (i x)))) becomes (f ° g ° h ° i) x
> wich looks a bit better.

Exactly.

> > However there is bad things with parens:
> >
> > - Not LL(1) when treating them in parsing
> > - Spaces must be used for the `*' character to avoids starting comments.
> >
> > In fact when dealing them in the lexer that's ok.
> > And the space issue is not too big.
> >
> > Concerning the fixity of these operators I've already changed it to
> > have the same thing as the original syntax.
>
> By the way, which are the fixity and associativity of custom operators
> in the original syntax?

In fact the cool thing is that the rule is really simple, long
operators have the same associativity, fixity, priority as the well
known prefix of it.

Example:

+| is like + (infix, left assoc...)

<=> is like <

!* is like ! (prefix)

**/ is like ** (infix, right assoc)

Simple no?

> > Concerning the backslash, I want to restore the parens convention to
> > declare them and then free the backslash character and make it
> > available in the default lexer (useful for an ascii lambda for
> > instance).
>
> Err, I may not understand, but isn't "fun" terse enough? Or is it just
> an idea from Haskell?

I'm not talking about the revised syntax itself but about the reusable
camlp4 lexer, in case of using the camlp4 parsing system. If one want
to parse a language with lambdas as backslashs (like Haskell and
others one can do it).

I think also about operators like \/ for OR and /\ for AND.

> > As before, feel free to make comments on that (not really passionating) subject.
>
> It should be : adding up "not really passionating" upgrades may lead
> to a quiet revolution, eventually. :)
:)

-- 
Nicolas Pouillard

Re: [Caml-list] Custom operators in the revised syntax

[Stefano Zacchiroli]

On Thu, May 10, 2007 at 10:55:02PM +0200, Nicolas Pouillard wrote:
> Today it's about custom operators. In the original syntax everyone
> knows that's easy to define and use custom operators like ++, -->,
> >>>, +|, =?=, ... and as many as you want.

Not strictly related to your RFC, but while we are at it: any chance to
broaden the set of characters accepted for the definition of custom
operators, possibly supporting UTF-8?

I understand this is a much more involved change and I do not know if
your camlp4 related changes affected the ocaml lexer support for
non-ascii characters, but someone had to ask this :-)

Cheers.

-- 
Stefano Zacchiroli -*- PhD in Computer Science ............... now what?
zack@{cs.unibo.it,debian.org,bononia.it} -%- http://www.bononia.it/zack/
(15:56:48)  Zack: e la demo dema ?    /\    All one has to do is hit the
(15:57:15)  Bac: no, la demo scema    \/    right keys at the right time

Re: [Caml-list] Custom operators in the revised syntax

[dmitry grebeniuk]

Shalom, Nicolas.

NP> Today it's about custom operators. In the original syntax everyone
NP> knows that's easy to define and use custom operators like ++, -->,
>>>>, +|, =?=, ... and as many as you want.

  As for me, the lack of custom infix operators in revised syntax
is a feature that allows to keep code clean, without any
"=?=" or "<<+".  The code "(func arg1 arg2)" is imho much
more readable than "arg1 op arg2" because: 1. function name
usually says something about the meaning of the function, 2. you
don't need to remember operator's precedence and associativity
to understand the code.

-- 
WBR,
 dmitry                          mailto:gds-mlsts@moldavcable.com

Re: [Caml-list] Custom operators in the revised syntax

[Loup Vaillant]

2007/5/11, dmitry grebeniuk <gds-mlsts@moldavcable.com>:
> Shalom, Nicolas.
>
> NP> Today it's about custom operators. In the original syntax everyone
> NP> knows that's easy to define and use custom operators like ++, -->,
> >>>>, +|, =?=, ... and as many as you want.
>
>   As for me, the lack of custom infix operators in revised syntax
> is a feature that allows to keep code clean, without any
> "=?=" or "<<+".  The code "(func arg1 arg2)" is imho much
> more readable than "arg1 op arg2" because: 1. function name
> usually says something about the meaning of the function, 2. you
> don't need to remember operator's precedence and associativity
> to understand the code.

I remember a family of languages where (func x y) is the only syntax : Lisp. :)

I tend to agree when one says custom operators are evil. However, when
the default syntax uses operators, the custom ones are a net win : a
wise programmer will use their semantic load carefully (big nums, for
example), and sparsely, so the code is more readable.  An unwise
programmer will make the code unreadable anyway, regardless of the
operators.

Regards,
Loup

Re: [Caml-list] Custom operators in the revised syntax

[Nicolas Pouillard]

On 5/11/07, dmitry grebeniuk <gds-mlsts@moldavcable.com> wrote:
> Shalom, Nicolas.
>
> NP> Today it's about custom operators. In the original syntax everyone
> NP> knows that's easy to define and use custom operators like ++, -->,
> >>>>, +|, =?=, ... and as many as you want.
>
>   As for me, the lack of custom infix operators in revised syntax
> is a feature that allows to keep code clean, without any
> "=?=" or "<<+".  The code "(func arg1 arg2)" is imho much
> more readable than "arg1 op arg2" because: 1. function name
> usually says something about the meaning of the function, 2. you
> don't need to remember operator's precedence and associativity
> to understand the code.

This seems reasonable, but that's more a guideline. The feature can be
present for that wants it. Moreover Camlp4 is about changing the
syntax, so one can buy the revised syntax without the fact of patching
syntaxes but features are here.

-- 
Nicolas Pouillard

Re: [Caml-list] Custom operators in the revised syntax

[Jon Harrop]

On Friday 11 May 2007 15:15, Loup Vaillant wrote:
> I tend to agree when one says custom operators are evil. However, when
> the default syntax uses operators, the custom ones are a net win : a
> wise programmer will use their semantic load carefully (big nums, for
> example)

Ints, nats, floats, complexes, quaternions, column and row vectors, matrices, 
tensors, inner and outer products, symbolic expressions... This is why I like 
operator overloading.

For example, Smoke has the multiplications: * (int), *. (float), *| (vector 
scaling), *|| (matrix-vector transform) and *||| (matrix-matrix multiply).

Operator overloading and template metaprogramming were the only things I 
missed moving from C++ to OCaml. :-)

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?e

Re: [Caml-list] Custom operators in the revised syntax

[Nicolas Pouillard]

On 5/11/07, Loup Vaillant <loup.vaillant@gmail.com> wrote:
> 2007/5/11, dmitry grebeniuk <gds-mlsts@moldavcable.com>:
> > Shalom, Nicolas.
> >
> > NP> Today it's about custom operators. In the original syntax everyone
> > NP> knows that's easy to define and use custom operators like ++, -->,
> > >>>>, +|, =?=, ... and as many as you want.
> >
> >   As for me, the lack of custom infix operators in revised syntax
> > is a feature that allows to keep code clean, without any
> > "=?=" or "<<+".  The code "(func arg1 arg2)" is imho much
> > more readable than "arg1 op arg2" because: 1. function name
> > usually says something about the meaning of the function, 2. you
> > don't need to remember operator's precedence and associativity
> > to understand the code.
>
> I remember a family of languages where (func x y) is the only syntax : Lisp. :)
>
> I tend to agree when one says custom operators are evil. However, when
> the default syntax uses operators, the custom ones are a net win : a
> wise programmer will use their semantic load carefully (big nums, for
> example), and sparsely, so the code is more readable.  An unwise
> programmer will make the code unreadable anyway, regardless of the
> operators.

One always can write unreadable code, no? So it's more a matter of how
much using these features than having them.

BTW the really cool thing about how custom operators are treated in
OCaml is the fact that their understanding do not depend on the
definition of them.

If you know the parsing rules of + then you know those for +|%@!^&++?@^

-- 
Nicolas Pouillard

Re: [Caml-list] Custom operators in the revised syntax

[Nicolas Pouillard]

On 5/11/07, Jon Harrop <jon@ffconsultancy.com> wrote:
> On Friday 11 May 2007 15:15, Loup Vaillant wrote:
> > I tend to agree when one says custom operators are evil. However, when
> > the default syntax uses operators, the custom ones are a net win : a
> > wise programmer will use their semantic load carefully (big nums, for
> > example)
>
> Ints, nats, floats, complexes, quaternions, column and row vectors, matrices,
> tensors, inner and outer products, symbolic expressions... This is why I like
> operator overloading.
>
> For example, Smoke has the multiplications: * (int), *. (float), *| (vector
> scaling), *|| (matrix-vector transform) and *||| (matrix-matrix multiply).
>
> Operator overloading and template metaprogramming were the only things I
> missed moving from C++ to OCaml. :-)

But having these custom operators reduce the pain, right?

-- 
Nicolas Pouillard
who also likes overloading and meta-programming....

Re: [Caml-list] Custom operators in the revised syntax

[brogoff]

On Fri, 11 May 2007, Nicolas Pouillard wrote:
> This seems reasonable, but that's more a guideline. The feature can be
> present for that wants it. Moreover Camlp4 is about changing the
> syntax, so one can buy the revised syntax without the fact of patching
> syntaxes but features are here.

Any chance we could have something like in Haskell where you easily
define new infix names?

Speaking of Haskell and Revised, one of the things I like about Revised
over Ocaml syntax (that lots of people dislike it seems) is the
additional bracketing. Most of the syntactical annoyances I have with
Ocaml are usually connected with bracketing. Someone once quipped that
all problems with ML syntax can be fixed with some parentheses, and I
have to admit that quip makes sense. So I prefer Revised as an
alternative syntax over Python/Haskell influenced approaches.

-- Brian

Re: [Caml-list] Custom operators in the revised syntax

[Nicolas Pouillard]

On 5/11/07, brogoff <brogoff@speakeasy.net> wrote:
> On Fri, 11 May 2007, Nicolas Pouillard wrote:
> > This seems reasonable, but that's more a guideline. The feature can be
> > present for that wants it. Moreover Camlp4 is about changing the
> > syntax, so one can buy the revised syntax without the fact of patching
> > syntaxes but features are here.
>
> Any chance we could have something like in Haskell where you easily
> define new infix names?

Something general like: x `foo` y ?

> Speaking of Haskell and Revised, one of the things I like about Revised
> over Ocaml syntax (that lots of people dislike it seems) is the
> additional bracketing. Most of the syntactical annoyances I have with
> Ocaml are usually connected with bracketing. Someone once quipped that
> all problems with ML syntax can be fixed with some parentheses, and I
> have to admit that quip makes sense. So I prefer Revised as an
> alternative syntax over Python/Haskell influenced approaches.

In Haskell you can put brackets and semi-colons if you dislike
significant layout.

-- 
Nicolas Pouillard

Re: [Caml-list] Custom operators in the revised syntax

[Loup Vaillant]

2007/5/11, Jon Harrop <jon@ffconsultancy.com>:
> On Friday 11 May 2007 15:15, Loup Vaillant wrote:

> Operator overloading and template metaprogramming were the only things I
> missed moving from C++ to OCaml. :-)

What exactly is more difficult (or less convinient) in Ocaml once you
quit template metaprogramming?

Re: [Caml-list] Custom operators in the revised syntax

[skaller]

On Fri, 2007-05-11 at 16:15 +0200, Loup Vaillant wrote:
> 2007/5/11, dmitry grebeniuk <gds-mlsts@moldavcable.com>:

> I tend to agree when one says custom operators are evil. However, when
> the default syntax uses operators, the custom ones are a net win : a
> wise programmer will use their semantic load carefully (big nums, for
> example), and sparsely, so the code is more readable. 

In Ocaml, there's no overloading: custom operators have 
big advantages for things like int32, int64, bignums, matrices etc,
where other languages can simply use overloading.

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

Re: [Caml-list] Custom operators in the revised syntax

[skaller]

On Fri, 2007-05-11 at 15:37 +0100, Jon Harrop wrote:

> Operator overloading and template metaprogramming were the only things I 
> missed moving from C++ to OCaml. :-)

What about the segfaults? Don't you miss them too? 

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

Re: [Caml-list] Custom operators in the revised syntax

[brogoff]

On Fri, 11 May 2007, Nicolas Pouillard wrote:
> On 5/11/07, brogoff <brogoff@speakeasy.net> wrote:
> > Any chance we could have something like in Haskell where you easily
> > define new infix names?
>
> Something general like: x `foo` y ?

Exactly.

> In Haskell you can put brackets and semi-colons if you dislike
> significant layout.

Yes, I know. I don't dislike significant layout, I'm just pointing out
that the (relatively minor) issues I have with OCaml syntax, like
try/with or if/then capturing more than I expect, are fixed in Revised,
by using more brackets.

-- Brian

Re: [Caml-list] Custom operators in the revised syntax

[skaller]

On Fri, 2007-05-11 at 16:52 +0200, Loup Vaillant wrote:

> What exactly is more difficult (or less convinient) in Ocaml once you
> quit template metaprogramming?

C++ has polyadic programming which is flakey but sort of works
reasonably well in practice some of the time even though it
is technically unsound .. <:)

For example, 'fold' is defined for all data structures,
just once (it's called accumulate).

This is miles ahead of Ocaml and Haskell, however I'll
stick with correctness, thanks.

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

Re: [Caml-list] Custom operators in the revised syntax

[Nicolas Pouillard]

On 5/11/07, brogoff <brogoff@speakeasy.net> wrote:
> On Fri, 11 May 2007, Nicolas Pouillard wrote:
> > On 5/11/07, brogoff <brogoff@speakeasy.net> wrote:
> > > Any chance we could have something like in Haskell where you easily
> > > define new infix names?
> >
> > Something general like: x `foo` y ?
>
> Exactly.

Fine, but what syntax? The backquote is already use for polymorphic
variants (and in stream parsers too).

>
> > In Haskell you can put brackets and semi-colons if you dislike
> > significant layout.
>
> Yes, I know. I don't dislike significant layout, I'm just pointing out
> that the (relatively minor) issues I have with OCaml syntax, like
> try/with or if/then capturing more than I expect, are fixed in Revised,
> by using more brackets.

Personally I would prefer just an "end" to close them.
That's what I've done in a small *experimental* extension called
Reloaded. It's usable on top of the original syntax or the revised
one.

camlp4o -parser rr -str "match x with A -> 1 | B -> 2 end"

-- 
Nicolas Pouillard

Re: [Caml-list] Custom operators in the revised syntax

[Jon Harrop]

On Friday 11 May 2007 15:46, you wrote:
> > Operator overloading and template metaprogramming were the only things I
> > missed moving from C++ to OCaml. :-)
>
> But having these custom operators reduce the pain, right?

Using, +, +., +| and +|| is better than add, add_float, add_vector, add_matrix 
but allowing + to be used to all such types ('a -> 'a -> 'a) is much better 
still. It isn't even that hard to add to the language.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?e

Re: [Caml-list] Custom operators in the revised syntax

[skaller]

On Sat, 2007-05-12 at 03:48 +0100, Jon Harrop wrote:

> Using, +, +., +| and +|| is better than add, add_float, add_vector, add_matrix 
> but allowing + to be used to all such types ('a -> 'a -> 'a) is much better 
> still. It isn't even that hard to add to the language.

Oh? It changes the way type inference works.

I have only seen one algorithm for this an it was
extremely complicated. If you know a better way I'd
sure like to know what it is.

Of course, you can use the Haskell typeclass approach,
where you make the signature predefined as:

	(+): 'a -> 'a -> 'a

and then resolve to the specific type and thus specific
function (or error) after the usual inference/checking phase,
however this *does* require a extra code in the compiler,
possibly a complete extra phase that has to be done before
type information is erased, it introduces new errors:

	let f a b = a + b

will pass type checking, then fail during instantiation,
whereas at present the signature is inferred as

	f: int * int -> int

I know F# supports overloaded operators, but I have no idea
how it can work.

Felix also allows both overloading AND typeclasses,
but it works because it does not have type inference.

The only way I can see to extend Ocaml without breaking it
would require the introduction of a new kind of type,
which would at least allow finite sets of ground types,
for example:

	int \U int16 \U int32 \U float \U bigint \U matrix

Felix actually has these things, they're not types
but nouns of sugar used for constraints:

	'a constraint 'a = int | 'a = int16 ...

and this kind of constraint, unfortunately, doesn't propagate
(i.e. the above isn't really a type). Propagating ground
type sets is actually easy, but once you have higher orders
it is probably undecidable.

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

Re: [Caml-list] Custom operators in the revised syntax

[Jon Harrop]

On Saturday 12 May 2007 05:40, you wrote:
> On Sat, 2007-05-12 at 03:48 +0100, Jon Harrop wrote:
> > Using, +, +., +| and +|| is better than add, add_float, add_vector,
> > add_matrix but allowing + to be used to all such types ('a -> 'a -> 'a)
> > is much better still. It isn't even that hard to add to the language.
>
> Oh? It changes the way type inference works.

Yes.

> I have only seen one algorithm for this an it was
> extremely complicated. If you know a better way I'd
> sure like to know what it is.

AFAIK, you just change the unify to intersect sets of types. I assume the 
implementation of polymorphic variants already does this, so take that and 
make it enforce a single type contructor at function boundaries (maybe 
defaulting in some cases). If you "polymorphic variant" has more than one 
constructor then there is an ambiguity and you flag an error asking for a 
type annotation.

> 	let f a b = a + b
>
> will pass type checking,

The F# approach is to default + to int, to maintain compatibility with OCaml.

> I know F# supports overloaded operators, but I have no idea
> how it can work.

.NET provides run-time type information so I assume the compiler specializes 
when types are static and resorts to run-time dispatch otherwise. I was 
certainly advised against using generics to implement a float/float32 FFT 
because they incur run-time tests for many simple arithmetic operations, 
killing performance.

> and this kind of constraint, unfortunately, doesn't propagate
> (i.e. the above isn't really a type). Propagating ground
> type sets is actually easy, but once you have higher orders
> it is probably undecidable.

I hadn't thought of that. I just discovered that you cannot add vectors of 
vectors in F#, so it is probably 1st order only.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?e

Re: [Caml-list] Custom operators in the revised syntax

[Jon Harrop]

On Friday 11 May 2007 15:52, Loup Vaillant wrote:
> What exactly is more difficult (or less convinient) in Ocaml once you
> quit template metaprogramming?

Lack of operator overloading makes many mathematical expressions more tedious 
to write. Lack of template metaprogramming makes it harder to write efficient 
library functions to handle low-dimensional vectors and matrices.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?e

Re: [Caml-list] Custom operators in the revised syntax

[skaller]

On Sat, 2007-05-12 at 05:47 +0100, Jon Harrop wrote:

> > I have only seen one algorithm for this an it was
> > extremely complicated. If you know a better way I'd
> > sure like to know what it is.
> 
> AFAIK, you just change the unify to intersect sets of types. 

I have no idea how to unify in the presence of (undiscriminated)
setwise union of polymorphic types. It seems a little easier
if the types are restricted to a finite set of non-polymorphic
types.

> I assume the 
> implementation of polymorphic variants already does this, so take that and 
> make it enforce a single type contructor at function boundaries (maybe 
> defaulting in some cases). If you "polymorphic variant" has more than one 
> constructor then there is an ambiguity and you flag an error asking for a 
> type annotation.

The difference is that polymorphic variants HAVE constructors.
But we're talking about types *without* constructors.

In Felix, the (Ocaml) term combinators actually support typesets.
But the unification engine just throws up when it sees them :)

During overload resolution, you CAN use typesets as constraints.
For example:

	typedef ints = typesetof(int, long);
	fun f[t in ints]: t * t -> t = "$1+$2";

	print$ f 1; // OK!
	print$ f 1L; // OK!
	print$ f 1.0; // ERROR

	fun g[t in ints](x:t)=> f x; // ERORR

The last line illustrates the lack of propagation: the type
of x is actually just 't' at the point f is applied,
and t isn't in the set ints.

The way it works is the argument is first matched against the
unconstrained type (by unification), and then the constraint
such as:

	int in typeset(int,long)

is checked: if it fails that overload candidate is rejected
(but another may still match).

In principle the correct 'subtyping' rule is to use a subset
(or superset depending on +/- position I guess) so that
it should be possible in this case to propagate and make
the function g above work.

The problem is that once you introduce polymorphism,
the type of one function can depend on the type of another,
but that type isn't known until that other is actually
instantiated.

This can not be handled 'properly' by just adding typesets to the 
type system because that would be too general: it fails to
record the dependencies. For example in the f/g case above,
the type of g is NOT

	g: ints -> ints

but rather

	g: { int -> int; long -> long }

and now consider a harder case like:

	t in ints. t * t = { int * int; long * long }

which is quite different to

	ints * ints = { int * int; int * long; long * int; long * long }

So roughly .. we're talking about a unification engine that
can propagate constraints, and a type system which would
seem to at least need to be second order. 

As I said I think this is possible for finite ground types,
but in the presence of polymorphism unification would not be
able to reduce many terms. In turn, this would make overloading
such cases impossible.

In Felix, overloading is done polymorphically, and can't
vary depending on the instantiation of type variables
(you can do that with typeclasses though).

But unless you instantiate the type variables, you can't
reduce the terms. It isn't clear it is even possible to
normalise them for equality check, let alone tell if
one is a specialisation of another.

The result, in Felix, is that overloading would have to
return a SET of functions instead of a single one,
since several functions 'might' match the argument type.
And the set could be large -- it seems exponential in
the length of a call chain. Ouch.

If ANYONE knows an algorithm that can do unification with
sets of types, that is, with a union type, I'd sure like
to know it!

> .NET provides run-time type information so I assume the compiler specializes 
> when types are static and resorts to run-time dispatch otherwise.

That seems right. I think G'Caml tried to do that was well.

> > and this kind of constraint, unfortunately, doesn't propagate
> > (i.e. the above isn't really a type). Propagating ground
> > type sets is actually easy, but once you have higher orders
> > it is probably undecidable.
> 
> I hadn't thought of that. I just discovered that you cannot add vectors of 
> vectors in F#, so it is probably 1st order only.

Hmm, that's a bit surprising if your explanation above is correct,
that is, if it resorts to dynamic typing if it can't resolve
statically.


-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

Re: [Caml-list] Custom operators in the revised syntax

[Jon Harrop]

On Saturday 12 May 2007 06:45, you wrote:
> On Sat, 2007-05-12 at 05:47 +0100, Jon Harrop wrote:
> > > I have only seen one algorithm for this an it was
> > > extremely complicated. If you know a better way I'd
> > > sure like to know what it is.
> >
> > AFAIK, you just change the unify to intersect sets of types.
>
> I have no idea how to unify in the presence of (undiscriminated)
> setwise union of polymorphic types. It seems a little easier
> if the types are restricted to a finite set of non-polymorphic
> types.

They are, aren't they? e.g. int or float.

If you write:

> let ipow3 x =
    let sqr x = x*x in
    x * sqr x;;
val ipow3 : int -> int

then F# gives the inner definition "sqr" a type like [int|float] as 'a -> 'a 
until it is resolved to int -> int. If you change the code with an outer 
annotation:

> let ipow3 x : float =
    let sqr x = x*x in
    x * sqr x
val ipow3 : float -> float

then it still works because the inner type specializes to float -> float 
rather than defaulting to int -> int. The outer definition of "ipow3" then 
becomes float -> float.

> If ANYONE knows an algorithm that can do unification with
> sets of types, that is, with a union type, I'd sure like
> to know it!

Isn't this exactly what polymorphic variants do?

> > I hadn't thought of that. I just discovered that you cannot add vectors
> > of vectors in F#, so it is probably 1st order only.
>
> Hmm, that's a bit surprising if your explanation above is correct,
> that is, if it resorts to dynamic typing if it can't resolve
> statically.

I don't think it resorts to dynamic typing. I think it just doesn't do static 
code explosion as C++ templates do. That isn't dynamic typing because the 
types are still checked statically.

I believe the F# standard library also does some run-time type based 
optimizations, like using specialized routines for vectors and matrices of 
floats. Again, this isn't really dynamic typing because it does not introduce 
any run-time errors.

So if you do:

  type 'a complex = {r: 'a; i: 'a}
  let zero_float = {r=0.; i=0.}
  let zero_float32 = {r=0.f; i=0.f}

then it doesn't generate type specialized code for float and float32 (same as 
OCaml). When you do:

  List.map ((+) 1)

OCaml does not use a version of List.map that is specialized for ints.

That isn't to say that the .NET JIT won't do the specialization itself, but I 
believe it does not currently do that.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?e

Re: [Caml-list] Custom operators in the revised syntax

[skaller]

On Sat, 2007-05-12 at 06:59 +0100, Jon Harrop wrote:

> > If ANYONE knows an algorithm that can do unification with
> > sets of types, that is, with a union type, I'd sure like
> > to know it!
> 
> Isn't this exactly what polymorphic variants do?

I don't think so, but here I need a theorist to give
a proper explanation.

I suspect part of what pm-variants do does indeed rely
on the fact that you have a finite set of discrete constructors
(variant tags).

However here, you will fail to get a unique constructor a LOT
of the time .. and that is OK, you just dispatch at run time
on the tag.

But int, float, long etc don't have tags or associated RTTI
in Felix when used as values (they do if they're boxed .. but
they're boxed by using a variant .. and that's a different type).

The point is that here, we actually need to resolve to 
a single type, equivalent to pm-variants resolving to
a single constructor. So the situation is different:

	f: [`Int of int | `Float of float] -> int

makes sense, use runtime dispatch but:

	f: [int | float] -> int

is nonsense -- unless the argument is ignored --
because you *cannot* dispatch. In Felix:

	typedef nums = typesetof(int,float);
	fun f[t in nums]: t -> int = "(int)$1";

makes sense, but only because it leverages C/C++
generic programming stuff, that is, it is extensionally
polymorphic (the compiler emits the code for every
call point and relies on (int)x being a generic in C).

Particularly, this *actually* means the same as:

	fun f: int -> int = "(int)$1";
	fun f: float -> int = "(int)$1";

that is, it's sugar for a type schema (first order
universal quantification) with an intersection constraint.

In Felix this kind of 'sugar' is more than just useful
for reducing several overloaded bindings to one, it is
quite mandatory for making it possible to write bindings
to libraries like OpenGL where the types are aliases
for unknown integer types. So a function like:

	void GLsetCoord(x:GLint, y:GLint)

is modelled by

	proc GLsetCoord: !ints * !ints;

which means you can call it like:

	GLsetCoord (1, 2L);

instead of having to cast every argument to GLint.


-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

Re: [Caml-list] Custom operators in the revised syntax

[Nicolas Pouillard]

On 5/12/07, Jon Harrop <jon@ffconsultancy.com> wrote:
> On Friday 11 May 2007 15:46, you wrote:
> > > Operator overloading and template metaprogramming were the only things I
> > > missed moving from C++ to OCaml. :-)
> >
> > But having these custom operators reduce the pain, right?
>
> Using, +, +., +| and +|| is better than add, add_float, add_vector, add_matrix
> but allowing + to be used to all such types ('a -> 'a -> 'a) is much better
> still. It isn't even that hard to add to the language.

Not so easy too, it depends on how general your overloading system is.

Given these declarations (in an hypothetic language):

overload (+) : 'a -> 'a -> 'a;;
instance (+) Int.(+) Float.(+) Vector.(+);;

What your system should do when encountering:

let double x = x + x;;

And then:

double 1;;
double 1.1;;
double (Vector.from_array [| 1.1; 2.2; 3.3 |]);;

Cheers,

-- 
Nicolas Pouillard

Re: [Caml-list] Custom operators in the revised syntax

[Jon Harrop]

On Saturday 12 May 2007 10:49, you wrote:
> What your system should do when encountering:
>
> let double x = x + x;;

F# ossifies global definitions to defaults (if any) or type errors. In this 
case:

  val double : int -> int

If the definition had been:

  let first a = a.[0];;

then there is no default and it would ask for clarification as to the type 
of "a" (is it an array, hash table, vector etc.).

> double 1;;

Fine.

> double 1.1;;
> double (Vector.from_array [| 1.1; 2.2; 3.3 |]);;

Both static type errors.

This seems to work very well by minimizing confusion, maximizing performance 
(everything is resolved statically) and letting me write mathematical 
expressions concisely.

If the definition of "double" is nested then its type is not ossified 
immediately but will unify to "int" at the application "double 1;;", so the 
next two calls are static type errors just as they are in OCaml.

There are other problems, like do we generalize from:

  val ( * ) : 'a -> 'a -> 'a

to:

  val ( * ) : 'a -> 'b -> 'c

e.g. "scalar * vector -> vector"?

You also have ambiguity with conventional syntax. Does "vector * vector" mean 
dot, cross or element-wise product?

Lessons can be learned from languages like Matlab, where people often 
accidentally add a scalar to each element of a vector (so we know that would 
be a useful type error).

Potentially, you could even overload "f x" to allow it to mean multiplication 
when "f" is a numeric and not a functional value. So the type could go 
through ['a -> 'b | int | float | ...].

I've written about 100k LOC of F# code now and I haven't had a single 
non-trivial type problem caused by overloading. So I'd definitely question 
the conventional view that overloading and inference do not sit well 
together. Worst case, the compiler asks for a type annotation...

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
The F#.NET Journal
http://www.ffconsultancy.com/products/fsharp_journal/?e

Re: [Caml-list] Custom operators in the revised syntax

[Richard Jones]

If it is true that parts of the program will typically use a single
class of operator, then what about a simple syntax extension like:

  with BigInt
    let a = b + c * d in

Similar, in fact, to the very desirable "local open" feature
(http://alain.frisch.fr/soft.html#openin)

Rich.

-- 
Richard Jones
Red Hat

Re: [Caml-list] Custom operators in the revised syntax

[Nicolas Pouillard]

On 5/11/07, brogoff <brogoff@speakeasy.net> wrote:
> On Fri, 11 May 2007, Nicolas Pouillard wrote:
> > On 5/11/07, brogoff <brogoff@speakeasy.net> wrote:
> > > Any chance we could have something like in Haskell where you easily
> > > define new infix names?
> >
> > Something general like: x `foo` y ?
>
> Exactly.
>

I've a tiny patch to do that:

2 ``List.mem`` [1;2;3]

I think that extension harmless, any thoughts?

-- 
Nicolas Pouillard

Re: [Caml-list] Custom operators in the revised syntax

[ketti]

[-- Attachment #1: Type: text/plain, Size: 218 bytes --]

On 5/13/07, Nicolas Pouillard <nicolas.pouillard@gmail.com> wrote:

> I've a tiny patch to do that:
>
> 2 ``List.mem`` [1;2;3]
>
> I think that extension harmless, any thoughts?


 What about: 2 ´List.mem´ [1;2;3] ?

[-- Attachment #2: Type: text/html, Size: 527 bytes --]

Re: [Caml-list] Custom operators in the revised syntax

[Christian Stork]

On Sun, May 13, 2007 at 02:27:34AM +0200, ketti wrote:
> On 5/13/07, Nicolas Pouillard <nicolas.pouillard@gmail.com> wrote:
> 
> >I've a tiny patch to do that:
> >
> >2 ``List.mem`` [1;2;3]
> >
> >I think that extension harmless, any thoughts?
> 
> 
> What about: 2 ´List.mem´ [1;2;3] ?

Or:
    2 `(List.mem) [1;2;3]

Then you could even have operators with arguments.  IIRC this idea (not
this particular syntax) was proposed for Haskell' but wasn't worth the
effort to make work with their current `single-op` syntax.  Maybe it's
worth it in this case?

-- 
Chris Stork   <>  Support eff.org!  <>   http://www.ics.uci.edu/~cstork/
OpenPGP fingerprint:  B08B 602C C806 C492 D069  021E 41F3 8C8D 50F9 CA2F

Re: [Caml-list] Custom operators in the revised syntax

[brogoff]

On Sun, 13 May 2007, Nicolas Pouillard wrote:
> I've a tiny patch to do that:
>
> 2 ``List.mem`` [1;2;3]
>
> I think that extension harmless, any thoughts?

That looks like a good start. This patch is in the new Revised?

-- Brian

Re: [Caml-list] Custom operators in the revised syntax

[skaller]

On Sat, 2007-05-12 at 22:52 -0700, brogoff wrote:
> On Sun, 13 May 2007, Nicolas Pouillard wrote:
> > I've a tiny patch to do that:
> >
> > 2 ``List.mem`` [1;2;3]
> >
> > I think that extension harmless, any thoughts?
> 
> That looks like a good start. This patch is in the new Revised?

There was a discussion on this previously, and it can be
done now with ordinary Ocaml, no camlp4 needed, and it
can be done much better than the weak Haskell formulation.

The idea is something like:

	a <+ b +> c

translates to

	b a c

however this formulation not only allows 'b' to be an arbitrary
expression, but also supports nesting. The operators are not
the ones I listed though .. perhaps someone can search the archives
of this mailing list to find the previous discussion.

Exactly how the Revised syntax would support this I don't know,
however I really think Revised should be thrown out ;(

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

Re: [Caml-list] Custom operators in the revised syntax

[Nicolas Pouillard]

On 5/13/07, Christian Stork <cstork@ics.uci.edu> wrote:
> On Sun, May 13, 2007 at 02:27:34AM +0200, ketti wrote:
> > On 5/13/07, Nicolas Pouillard <nicolas.pouillard@gmail.com> wrote:
> >
> > >I've a tiny patch to do that:
> > >
> > >2 ``List.mem`` [1;2;3]
> > >
> > >I think that extension harmless, any thoughts?
> >
> >
> > What about: 2 ´List.mem´ [1;2;3] ?

This character is plain ascii?

> Or:
>     2 `(List.mem) [1;2;3]

I prefer something more balanced.

> Then you could even have operators with arguments.  IIRC this idea (not
> this particular syntax) was proposed for Haskell' but wasn't worth the
> effort to make work with their current `single-op` syntax.  Maybe it's
> worth it in this case?

That's already supported even nesting if you put parens.

x ``f y`` z  ~~~> f y x z

x ``(y ``f`` z)`` t ~~~> f y z x t

-- 
Nicolas Pouillard

Re: [Caml-list] Custom operators in the revised syntax

[Jacques Carette]

skaller wrote:
> On Sat, 2007-05-12 at 22:52 -0700, brogoff wrote:
>   
>> On Sun, 13 May 2007, Nicolas Pouillard wrote:
>>     
>>> I've a tiny patch to do that:
>>>
>>> 2 ``List.mem`` [1;2;3]
>>>
>>> I think that extension harmless, any thoughts?
>>>       
>> That looks like a good start. This patch is in the new Revised?
>>     
>
> There was a discussion on this previously, and it can be
> done now with ordinary Ocaml, no camlp4 needed, and it
> can be done much better than the weak Haskell formulation.
>
> The idea is something like:
>
> 	a <+ b +> c
>
> translates to
>
> 	b a c
>   
It is not true that this is equivalent.  For example, most Haskellers 
have learnt the hard way that $ and application are subtly different.  
The culprit, and the same is true here, is higher-rank polymorphism.  
With syntax-driven expansions, one can involve rank-2 functions in `` `` 
quotes, but in-language operators cannot do so (at least without 
suffering all sorts of other problems).

Whether this issue is important enough, that is a completely different 
question.  I personally am undecided on that point.

Jacques

Re: [Caml-list] Custom operators in the revised syntax

[Arnaud Spiwack]

About that, Coq uses something that proved itself to be rather usefull, 
though the problematic is a bit different. It's called notation scopes. 
The idea is that infix operators are defined in a specific scope. That 
you can either open locally using (here the scope is open)%scopeName, or 
globally by using Open Scope scopeName. When a scope is open, all the 
infix operators are interpreted as its definition in that scope. There 
are also a few more technicalities to make it even more fun (for 
instance, you can bind a scope to a type t, then, whenever an expression 
is inferred to be type t, the scope t is automatically opened, it's a 
very useful feature).

This allows a milde, but rather usable notation overloading.

I've been wondering for quite a while if such a policy would be 
reasonable/usefull for OCaml.


My two pennies,
Arnaud Spiwack

Richard Jones a écrit :
> If it is true that parts of the program will typically use a single
> class of operator, then what about a simple syntax extension like:
>
>   with BigInt
>     let a = b + c * d in
>
> Similar, in fact, to the very desirable "local open" feature
> (http://alain.frisch.fr/soft.html#openin)
>
> Rich.
>
>   

Re: [Caml-list] Custom operators in the revised syntax

[ls-ocaml-developer-2006]

Arnaud Spiwack <aspiwack@lix.polytechnique.fr> writes:

> About that, Coq uses something that proved itself to be rather
> usefull, though the problematic is a bit different. It's called
> notation scopes. The idea is that infix operators are defined in a
> specific scope. That you can either open locally using (here the scope
> is open)%scopeName, or globally by using Open Scope scopeName. When a
> scope is open, all the infix operators are interpreted as its
> definition in that scope. There are also a few more technicalities to
> make it even more fun (for instance, you can bind a scope to a type t,
> then, whenever an expression is inferred to be type t, the scope t is
> automatically opened, it's a very useful feature).
>
> This allows a milde, but rather usable notation overloading.
>
> I've been wondering for quite a while if such a policy would be
> reasonable/usefull for OCaml.

I'd like to have a way to open moduls in a restricted scop, like

  with module Foo 
     
      let x = f a b c in

          ...
  end


which would be equivalent to 

      let x = Foo.f a b c in

          ...

if f is in Foo.

Regards -- Markus

Re: [Caml-list] Custom operators in the revised syntax

[Nicolas Pouillard]

On 5/13/07, ls-ocaml-developer-2006@m-e-leypold.de
<ls-ocaml-developer-2006@m-e-leypold.de> wrote:
>
> Arnaud Spiwack <aspiwack@lix.polytechnique.fr> writes:
>
> > About that, Coq uses something that proved itself to be rather
> > usefull, though the problematic is a bit different. It's called
> > notation scopes. The idea is that infix operators are defined in a
> > specific scope. That you can either open locally using (here the scope
> > is open)%scopeName, or globally by using Open Scope scopeName. When a
> > scope is open, all the infix operators are interpreted as its
> > definition in that scope. There are also a few more technicalities to
> > make it even more fun (for instance, you can bind a scope to a type t,
> > then, whenever an expression is inferred to be type t, the scope t is
> > automatically opened, it's a very useful feature).
> >
> > This allows a milde, but rather usable notation overloading.
> >
> > I've been wondering for quite a while if such a policy would be
> > reasonable/usefull for OCaml.
>
> I'd like to have a way to open moduls in a restricted scop, like

This is what the simple openin extension does (emulates using camlp4).

http://alain.frisch.fr/soft#openin

-- 
Nicolas Pouillard