ooc-lang / rock

:ocean: self-hosted ooc compiler that generates c99
http://ooc-lang.org/
MIT License
403 stars 40 forks source link

Add support for unary plus #484

Closed wandernauta closed 10 years ago

wandernauta commented 11 years ago

Rock currently supports unary minus for literals just fine, but I would like rock to have support for unary plus too :)

glVertex2f(-1, 1) // Works
glVertex2f(+1, 1) // Doesn't work
duckinator commented 11 years ago

I'm not sure of the usefulness of this, but there have been a few things I thought would look nicer with an explicit + (like coordinates). Would this work on variables? If so, would it basically just make +a the same as (a > 0 ? a : -a)?

nddrylliog commented 11 years ago

I'm pretty much for it. Makes copy/pasting from C OpenGL examples easier ;)

alexnask commented 11 years ago

Ok, this sounds easy enough to implement. @duckinator, I'm not quite sure if +a should be equivalent to a abs(), I'd rather have it the mathematical way, +a == a

nddrylliog commented 11 years ago

Agree with @shamanas here. No funny business, no surprises.

duckinator commented 11 years ago

Sounds good to me!

wandernauta commented 11 years ago

Some languages (including, I believe, C) have the unary + as an upcast (psuedo):

fun foo(short): print "Short"
fun foo(int): print "Int"

short x
foo(+x) # prints "Int"

I don't know ooc/rock well enough to know if this makes sense for ooc. Personally I wouldn't like it - I hate surprises and would rather have the + as a noop (i.e. +a == a).

duckinator commented 11 years ago

Noop > upcast, imo.

nddrylliog commented 11 years ago

I'm not sure if we should depart from C's behaviour here...

nddrylliog commented 11 years ago

I don't think having + as type promotion would be a bad surprise for the unknowing: you never lose precision anyway.

However, having + as a noop would be a bad surprise for people coming from C and expecting it to behave the same way.

My points:

wandernauta commented 11 years ago

Good points. If don't know ooc well enough to know if it follows C upcasting rules for all other cases, it if it does, it should also do that here IMHO. If it doesn't, there is a potential 'why is foo(int) begin called instead of foo(short) WTF' that can be avoided here.

On Mon, Nov 26, 2012 at 10:08 PM, Amos Wenger notifications@github.comwrote:

I don't think having + as type promotion would be a bad surprise for the unknowing: you never lose precision anyway.

However, having + as a noop would be a bad surprise for people coming from C and expecting it to behave the same way.

My points:

  • Using + unknowingly = no big harm, doesn't change much to your code
  • Using + because it upcasts = disappointed/wtf-y if ooc differes from C.

    — Reply to this email directly or view it on GitHubhttps://github.com/nddrylliog/rock/issues/484#issuecomment-10733917.

nddrylliog commented 10 years ago

Alright, after reading various answers in this StackOverflow thread I came to join @duckinator's side (hi nick!) and to say fuck upcasting.

Can we please just get this in as a no-op for the 0.9.8 release?