Earlier quoted context omitted.
[deleted]
Smalltalk messages/methods: a in: set. 2 * 4. Just sayin'
Of course, but then
2 * 4 + 5.
An 'in' operator for Ruby
61–69 of 69 posts
Re: An 'in' operator for Ruby
#62Earlier quoted context omitted.
You should be happy, as Python 3 would have renamed it to "Ekke Ekke Ekke Ekke Ptang Zoo Boing!" As to the "what else resembles this"? I would turn it around and ask what else could resemble this. I'm not sure the conclusion would be that "not in" is a good thing, but not sure of the reverse, either: if x not = 3 looks weird, but I think I could grow to like it.
Well, shell has the '-ne' operator, which is 'not equals' in a terser style. Really '!=' is just an attempt at rendering '≠' using only ASCII characters. They're a bit like digraphs and trigraphs in C/C++, except everyone is used to them. I wonder if Unicode is ubiquitous enough now that you could write a language where the real maths operators were used instead. What would that look like?
Scala allows using unicode arrows (→) in place of their ASCII version (->), but not things like '≠'.
I'm currently using the Monoid font (https://larsenwork.com/monoid/), which uses ligatures to achieve the visual effect of things like the not equals symbol, while the underlying code remains the same. It's a pretty nice work-around for current languages.
Re: An 'in' operator for Ruby
#63Earlier quoted context omitted.
You should be happy, as Python 3 would have renamed it to "Ekke Ekke Ekke Ekke Ptang Zoo Boing!" As to the "what else resembles this"? I would turn it around and ask what else could resemble this. I'm not sure the conclusion would be that "not in" is a good thing, but not sure of the reverse, either: if x not = 3 looks weird, but I think I could grow to like it.
Well, shell has the '-ne' operator, which is 'not equals' in a terser style. Really '!=' is just an attempt at rendering '≠' using only ASCII characters. They're a bit like digraphs and trigraphs in C/C++, except everyone is used to them. I wonder if Unicode is ubiquitous enough now that you could write a language where the real maths operators were used instead. What would that look like?
Haskell allows unicode in operators and there appear to be packages that implement aliases for the default ASCII versions.
Re: An 'in' operator for Ruby
#64Earlier quoted context omitted.
Smalltalk messages/methods: a in: set. 2 * 4. Just sayin'
Of course, but then 2 * 4 + 5. In Smalltalk evaluates to 18.
No, that's 13. You probably meant
4 + 5 * 2.
Compilation Order: Smalltalk-78 had perpetuated the post-evaluation of receiver expressions so as to avoid delving into the stack to find the receiver. In the Smalltalk-80 language, however, we encoded the number of arguments in the send instruction. This enabled strictly left- to-right evaluation, and no one has since complained about surprising order of evaluation. We suspect that this change will yield further fruit in the future when someone tries to build a very simple compiler.
http://sdmeta.gforge.inria.fr/FreeBooks/BitsOfHistory/BitsOf... p. 21
Re: An 'in' operator for Ruby
#65Earlier quoted context omitted.
It's not a problem using non ASCII method names in Ruby: https://gist.github.com/bhaak/91428b9aee88ac50dd1d I can't think of any modern programming language that isn't unicode aware even though for the standard library methods, there are very good reasons not to use them (I know, Perl 6 does but even in this case there are ASCII fallbacks). You should also have very good reasons to put methods on the root class of yo…
> It's not a problem using non ASCII method names in Ruby Making it easy for people to type them, on the other hand...
> Making it easy for people to type them, on the other hand...
That's a problem of the code editors people are using. ;-)
I'm often surprised with how dysfunctional editors people are programming.
For example if all editors would show tabs and spaces (or whitespace in general) in a reasonable way, we wouldn't have had that much pointless discussion about the correct indentation whitespace character.
Re: An 'in' operator for Ruby
#66One of my favorite aspects of Ruby is that everything is an object with methods. Adding global operators/functions like this would only complicate the language. > But we also -- perhaps more often? -- ask questions like "Is this item part of this group?" We are asking a question about the item . Here we are actually asking the group a question about itself. An item would not know a group's contents.
> One of my favorite aspects of Ruby is that everything is an object with methods. Adding global operators/functions like this would only complicate the language.
But people love operators, that's why Ruby already includes loads of them instead of giving them identifier names and requiring you to call them with a dot. You have x+y instead of x.plus y, x==y instead of x.equals? y, x<y instead of x.less_than? y, most people write x..y instead of Range.new(x,y), etc. I don't think most Ruby programmers or the language designers agree with you about not wanting operators.
Re: An 'in' operator for Ruby
#67Earlier quoted context omitted.
I agree, I quite like it as a method as it keeps its congruence with .include? as an opposite of .in? (what .in? does should have been what .include? did from the get go). Perhaps another way of doing this is calling the method .within?
Seconded. One of the ways in which I prefer Ruby to Python is the way that it always favours "plain methods" over "syntax that maps to special methods under the covers".
But that's not true, as far as I can tell. Ruby does allow you to write 5.+(8), but as far as I can tell most people prefer 5+8. Ruby also has special syntax for <, == and indexing arrays. What things does Python have special syntax for that Ruby doesn't? Off the top of my head I can only remember "in".
Re: An 'in' operator for Ruby
#68Earlier quoted context omitted.
Of course, but then 2 * 4 + 5. In Smalltalk evaluates to 18.
No, that's 13. You probably meant 4 + 5 * 2. Also: Compilation Order: Smalltalk-78 had perpetuated the post-evaluation of receiver expressions so as to avoid delving into the stack to find the receiver. In the Smalltalk-80 language, however, we encoded the number of arguments in the send instruction. This enabled strictly left- to-right evaluation, and no one has since complained about surprising order of evaluation.…
Ah, thanks. I sit corrected :-)
Re: An 'in' operator for Ruby
#69so.. is 10 'in' 10..100? is 100?
10..100 is a Range in Ruby. 10..100 does include 100 (it includes both bounds). On the other hand 10...100 (note the three dots) does not.
> On the other hand 10...100 (note the three dots) does not.
reply
> On the other hand 10...100 (note the three dots) does not.
To be clear, 10...100 includes 10, but not 100. So, it includes one bound: the one mentioned first, the lower bound.
(10...100).to_a
=> [10, 11, 12, 13, ... 98, 99]