On 16/08/2012, at 4:46 PM, Dobes Vandermeer wrote:
> 
> Ellipsis is used in a few languages to indicate "and the rest".  Java in 
> particular does it this way.
> 
> Ellipsis infix: type a**b and pattern a ... b

This suggests b is the last component, not the tail.


> Ellipsis suffix: type a * b ... , pattern a, b ...

which suggests its the second component, not the tail. But this is marginally
better if you think of

        b...

rather than

        b ...

The operator is a binary operator.

Still this is pretty bad also because:

        ?a ,, (c? ,, ?d) --> ?a , (?c , ?d ...) ...

and now the ... is far from the , symbol. Hmm..


> Scala uses the "star" suffix in a pattern to match the "rest" of an array
> Star suffix: type a * b* and pattern a , b*

Trailing * is already used in prefix notation for deref, and infix
for multiply. Also the usual meaning of 

        a*

is the Kleene closure, a string of 0 or more a's.

I actually thought of

        \*    \,

however one should note the TeX display of these is not what you expected.
A TeX infix symbol would be the best if you don't like an ASCII one.

to repeat: it's a binary operator so it should a single infix symbol.

Note we need 4 symbols as well as what we use normally:

        * , + |

Note | is the value symbol for sums as in:

        match x with | .. |  .. | .. endmatch

i.e. the vertical bar (bracketed by "match/endmatch" and with => thrown in).

The thing you should note is that the non-associative * , + operators are 
deviant:
they're normally left-associative. In particular * is not binary:

        a * b * c

is actually a single ternary operator.

YMMV but for the moment I just wouldn't bother changing it: I don't much
like ** and ,, is worse but it makes sense.

BTW: ellipsis ... is already used for varargs in C functions i think.


> Also sums are normally decomposed using separate cases rather than a single 
> case, so things will be very different there.  A unary operator might be 
> needed rather than a binary one?
> 
> The operation on a sum is seems like a kind of "shift" where we're dropping 
> the first alternative, rather than splitting it?

That seems correct for making the choice yes, but we're really modelling:

        the first choice, or, one of the remaining choices.

you can probably view this as an 
        
        if then .. 
        elif  then .. 
        elif then ....
        else .. 
        endif 

chain.


> 
> fun sum_str[X] : X -> string = match x in 
>   | case 0 of X ?x => str(x)
>   | _ => sum_str( shift(x) )
> 
> Maybe these would be funny questions to put on 
> http://programmers.stackexchange.com/?as=1 and see what suggestions come back.

I doubt stack-exchangers would have the faintest idea what was going on. 
Someone on lambda-the-ultimate might, but that forum isn't really set up
for asking questions.

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