New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

i++ #41

Open
hakunin opened this Issue Jan 13, 2011 · 6 comments

Comments

Projects
None yet
5 participants
@hakunin

hakunin commented Jan 13, 2011

I often find myself in need of i++, for example:

i = 0
rows.each { |row|
  row_class = (i % 2 == 0) ? "even" : "odd"
  html += "..."
  i += 1
}

Writing i += 1 sucks. Also i++ seems to be more expressive because I don't mean to add one, I man to increment.

@headius

This comment has been minimized.

Show comment
Hide comment
@headius

headius Jan 13, 2011

Member

I agree. I have never liked the lack of i++ in Ruby, and I don't buy that it's misleading to make it an alias for "i += 1".

Java itself makes no explicit guarantees about ++ atomicity, making it atomic for local variables (iinc bytecode) and non-atomic for fields or array elements. So for us, making ++ follow the same atomicity guarantees seems quite reasonable.

Member

headius commented Jan 13, 2011

I agree. I have never liked the lack of i++ in Ruby, and I don't buy that it's misleading to make it an alias for "i += 1".

Java itself makes no explicit guarantees about ++ atomicity, making it atomic for local variables (iinc bytecode) and non-atomic for fields or array elements. So for us, making ++ follow the same atomicity guarantees seems quite reasonable.

@baroquebobcat

This comment has been minimized.

Show comment
Hide comment
@baroquebobcat

baroquebobcat Aug 26, 2011

Member

How hard would it be to do this, do we want it in 0.0.8?

Member

baroquebobcat commented Aug 26, 2011

How hard would it be to do this, do we want it in 0.0.8?

@consiliens

This comment has been minimized.

Show comment
Hide comment
@consiliens

consiliens Aug 26, 2011

Contributor

"Comment 3 by rogerpack2005, May 28, 2011
++ !"
http://code.google.com/p/mirah/issues/detail?id=19

Contributor

consiliens commented Aug 26, 2011

"Comment 3 by rogerpack2005, May 28, 2011
++ !"
http://code.google.com/p/mirah/issues/detail?id=19

@baroquebobcat

This comment has been minimized.

Show comment
Hide comment
@baroquebobcat

baroquebobcat Jan 8, 2012

Member

++ does this currently:

$ mirah -e "i=1;i++"
expected terms before '++' (at line: 1, char: 5)

I think it's because it's not in the grammar yet. I think you change the grammar through this file ( https://github.com/mirah/mirah-parser/blob/master/src/mirahparser/impl/Mirah.mmeta ) in the mirah-parser project.

Member

baroquebobcat commented Jan 8, 2012

++ does this currently:

$ mirah -e "i=1;i++"
expected terms before '++' (at line: 1, char: 5)

I think it's because it's not in the grammar yet. I think you change the grammar through this file ( https://github.com/mirah/mirah-parser/blob/master/src/mirahparser/impl/Mirah.mmeta ) in the mirah-parser project.

@felixvf

This comment has been minimized.

Show comment
Hide comment
@felixvf

felixvf May 13, 2017

Contributor

I’d like to close this as "WONTFIX".

Ruby does not have "i++", Crystal does not have "i++" and

f(i++,a[i++],i++)[i++] = b[i++] + c[i++]

is not well defined.

In addition, unlike some languages close to machine code (C), there is no performance optimization to say "i++". Instead, "i++" will always have to translate to the bytecode of "i+=1".

In addition, there is no clear meaning of "++"-style postfix operators. Should i++ mean the same as i = i.+(1)? If so, should i-- mean the same as i = i.-(1)? If so, should i** mean the same as i = i.*(1)? If so, should i// mean the same as i = i./(1)? If so, should i&& mean the same as i = i.&(1)?

Apparently, it is not useful to extend this concept to operators beyond "++" or "--". But if the concept is not generic enough, is its ungenericness, its peculiarity, its oddity warranted by its usefulness? I doubt that. In C and C++, "++" works on integers and pointers. In Mirah, we do not have pointer arithmetic. And we do not need explicit incrementing as often as in C, as we have #each, #map and other ways of iterating.

So I’m up for closing this.

However, if there is a strong need, I’m open for patches which make postfix "++" and postfix "--" an operator, so users can define their own meaning of "++" by defining a macro int#++ if the really want to.

Contributor

felixvf commented May 13, 2017

I’d like to close this as "WONTFIX".

Ruby does not have "i++", Crystal does not have "i++" and

f(i++,a[i++],i++)[i++] = b[i++] + c[i++]

is not well defined.

In addition, unlike some languages close to machine code (C), there is no performance optimization to say "i++". Instead, "i++" will always have to translate to the bytecode of "i+=1".

In addition, there is no clear meaning of "++"-style postfix operators. Should i++ mean the same as i = i.+(1)? If so, should i-- mean the same as i = i.-(1)? If so, should i** mean the same as i = i.*(1)? If so, should i// mean the same as i = i./(1)? If so, should i&& mean the same as i = i.&(1)?

Apparently, it is not useful to extend this concept to operators beyond "++" or "--". But if the concept is not generic enough, is its ungenericness, its peculiarity, its oddity warranted by its usefulness? I doubt that. In C and C++, "++" works on integers and pointers. In Mirah, we do not have pointer arithmetic. And we do not need explicit incrementing as often as in C, as we have #each, #map and other ways of iterating.

So I’m up for closing this.

However, if there is a strong need, I’m open for patches which make postfix "++" and postfix "--" an operator, so users can define their own meaning of "++" by defining a macro int#++ if the really want to.

@baroquebobcat

This comment has been minimized.

Show comment
Hide comment
@baroquebobcat

baroquebobcat May 13, 2017

Member
Member

baroquebobcat commented May 13, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment