On 16/08/2012, at 5:51 AM, Dobes Vandermeer wrote:

>   stuple_cons_pattern := stuple_pattern ",," stuple_pattern =>#  // 
> <---------------
>     "`(pat_tuple_cons ,_sr ,_1 ,_3)";

> Er, yes, but perhaps we should agree on something first?

I chose ,, for symmetry with **. I chose ** because it is available.
It seemed sane to do:

        *       **
        ,       ,,

but there's an extension to sums to think about:

        +       ++

and i have no idea how the value operation looks!

More generally, i wouldn't make piecemeal changes,
but rather try to take a big picture approach to symbols.

For example in C we have

        + - * / % & ^ | 

and

        += -= *= /= %= &= ^= |=

which is sort of cool.

In Felix there's another rule: the syntax for types and expressions
is the same. We do not have a distinct type language. This is why
in Felix, since:

        a + b + c + d
        a * b * c * d

considered as types, the operators are non-associative,. and this
means that for values they're also non-associative. This means that
you cannot put - and / on the same precedence. This means that
in Felix

        a + b - c + d  = (a + (b - c)) + d

and NOT ((a + b) - c) + d) and similarly with division.

This makes no difference for integers, but it DOES matter
for floats. Watch out for it!

In general, we have a lack of symbols in most languages.
In Felix this isn't quite the same. Much as I'd like to use Unicode
it probably isn't practical, but we do have TeX:

        src/lib/grammar/texsyms.flxh

and in conjunction with the Felix webserver you can actually see
these as nice mathematical symbols.

Unfortunately in programming we tend to need structural symbols
(categorical operators) not numerical ones.

The trick is to have a nice, systematic, symbolic algebra that matches
with the primitives well, and combines well in sync with how the
primitives combine.

I threw in some stuff that just "seemed reasonable" for example:

        "#one" means "one ()"

but with very high precedence. I'm not sure I didn't waste an operator
doing that but it makes it easy to understand #one is a constant
(typeclasses do not allow values in them, so we have to use
a function "one" to represent value 1)


I also changed the whole lexical structure by allowing this:

        fun + (x:int, y:int) => ...

whereas previously you had to write:

        fun add(x:int, y:int) => ...

and the connection between + and add was entirely in the parser.
Which meant it had to be documented.

In any case if you want to add

        match x with
        | Tuple_Cons (?a,?b) => ...

you can do that without removing ,, and see how it looks, then remove ,,
afterwards (but you have to fix all the code that uses it first).

You may find that nasty because Tuple_Cons would normally be a 
constructor name defined in user space: you just stole a user name.

For the pattern matching you HAVE to provide both extractors at once
(head and tail). You cannot split them up into "head" and "tail", because
that would require TWO matches instead of one to extract both
the head and tail.

If instead you want to do:

        match rectuple x with 
        | ?a,?b => ..

you will create a mess because you can only apply "rectuple" to convert
from one shape to another at the top level of an expression. If the "tuple"
you're involved with is not at the top level you'd have to factor the control
flow which is bad (it has to be done often enough already!). for example

        var x = (1, (2,"x","y","z",4.2));
        match x with
        | ?a, (?b ,, ?c) => ..
        | ?a, (?b, ?c) => ..
        | ?a, ?b => ...

is what you might need now. you cannot "rectuple" the nested tuple.
So the functional approach doesn't look good. Thats the beauty of patterns,
they work from the inside out (bottom up) rather than what functional symbols
do, which is apply top down.

Anyhow, you can certainly try out anything if it doesn't break what's already
there, and if it works nicely we can remove what is there. I try to do this 
usually.
Remember I implemented that thing and I didn't make the choices entirely freely:
the compiler itself drove some of the choices (like using an infix operator
for tuple cons)

--
john skaller
skal...@users.sourceforge.net
http://felix-lang.org




------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language

Reply via email to