Parameter defaults are awesome, but undocumented

[davidhesselbom]

I can do

import lang/IO
aFunction: func (value := 2) { value toString() println() }
aFunction(1) // prints 1
aFunction() // prints 2

which is totally awesome, but not mentioned anywhere in the ooc documentation as far as I can tell. I was missing out until another guy tried it assuming it would just work, and it did :)

So then I tried to do

testClass: class {
    value: Int
    init: func (=value := 4)
}

Which didn't fly:

error Malformed function argument (remember, it's name: Type in ooc, not Type name)

Unless anyone thinks this is a terrible idea, I'll see if I can figure out how hard it would be to get this to work (maybe with a slightly different syntax, like init: func (=value = 4), dropping the :). I guess Nagaqueen.c is a good place to start?

[fasterthanlime]

Well, (=value := 4) is kind of ugly :(

Thinking of other options: (.value := 4), or just (value = 4) (but it's not
obvious that it's a member)

I'm pretty sure @Shamanas could get it done easily - and just for
reference, NagaQueen.c is generated using greg from the nagaqueen LEG
grammar, links:

https://github.com/fasterthanlime/greg
https://github.com/fasterthanlime/nagaqueen

That feature will probably require some changes in rock/middle/Argument.ooc
as well

Cheers,

• A

On Wed, Aug 20, 2014 at 1:01 PM, davidhesselbom notifications@github.com
wrote:

I can do

import lang/IOaFunction: func (value := 2) { value toString() println() }aFunction(1) // prints 1aFunction() // prints 2

which is totally awesome, but not mentioned anywhere in the ooc
documentation as far as I can tell. I was missing out until another guy
tried it assuming it would just work, and it did :)

So then I tried to do

testClass: class {
value: Int
init: func (=value := 4)}

Which didn't fly:

error Malformed function argument (remember, it's name: Type in ooc, not Type
name)

Unless anyone thinks this is a terrible idea, I'll see if I can figure out
how hard it would be to get this to work. I guess Nagaqueen.c is a good
place to start?

—
Reply to this email directly or view it on GitHub
#808.

[davidhesselbom]

Agreed, it's not exactly pretty. Thanks for the info about NagaQueen, that C file also isn't exactly pretty ^^

[alexnask]

Yeah, generated parsers tend to be that way :)
I think this would be pretty trivial to implement indeed but I'm not too fond of the syntax either

Perhaps

Foo: func {
    x: Int

    init: func (x =:= 4)
}

[alexnask]

And of course

    init: func(.x := 4) { this x = x + 1 }

for (dot + default)-arg

[fasterthanlime]

for (dot + default)-arg

Isn't that what I suggested? :)

[alexnask]

Ah the way you phrased it I thought you were suggesting .x := y as an alternative to =x := y and I just pointed out that the default dot-arg syntax is obvious and not that ugly as-is (if it were implemented).

Any thoughts on =:= ?

[fasterthanlime]

=:= is a backward version of the famous "cat with a mustache" operator from
Perl 7. I don't like it

On Wed, Aug 20, 2014 at 2:46 PM, Alexandros Naskos <notifications@github.com

wrote:

Ah the way you phrased it I thought yo uwere suggesting .x := y as an
alternative to =x := y and I just pointed out that the default dot-arg
syntax is obvious and not that ugly.

Any thoughts on =:= ?

—
Reply to this email directly or view it on GitHub
#808 (comment).

[davidhesselbom]

.x := y is similar to .x, but x =:= y is not very similar to =x compared to =x := y.

Anyway, .x := y, while not ugly, seems strange to me, since you're assigning a variable of a known type a value using the := operator from another known type. Or is y's type not known?

[alexnask]

Yeah, I think you are right, .x = y should work, since the dot is just a way to get the type of the argument from the class field.

Actually there isn't much of a point in doing .x = y anyway, x := y should be the same thing if y is the same type as the class's x field.

[davidhesselbom]

Not unless you want to enforce that the parameter x is the same type as the class field. x := y does not enforce that. For assignment, like I wrote in the OP, the colon is also not needed, =x = y should work. But it's still ugly.

[alexnask]

Yeah if y is a child class of x's class it would make sense to do .x = y indeed.
=x = y still seems quite awkward but I can't think of anything better :/

[davidhesselbom]

Amos suggested earlier to just do x = y, which should then fail to compile if x isn't the name of a class field (I think), since no type was specified. This would make things a little prettier, but it's not obvious to the uninitiated that this also assigns the class field x the value of y, and it's not clear whether x can be used later, i.e. whether

Foo: func {
    x: Int
    init: func(x = 4) { x toString() println() }
}

should be possible or not.