Rubymoticons

I was demonstrating injection of a symbol, and noticed a familiar
pattern of characters. That inspired a bit more investigation. So
now I present some basic Rubymoticons:

[].inject( :slight_smile:

{}[ :-]

->() { :-}

These are perfectly valid Ruby code, and evaluate to nil, nil, and a
lambda.

Of course, the nose is easily substitutable, and noseless ones can use
any mouth they please… but what about changing the eyes, or the
mouth on full-size ones, and additional adornments? Let’s see how
creative you can get, especially in as few characters as possible on
either side.

-Dave

lol

and also

how insanely useless

:wink:

On Tue, Feb 28, 2012 at 10:03 AM, Dave A. <
[email protected]> wrote:

I was demonstrating injection of a symbol, and noticed a familiar
pattern of characters. That inspired a bit more investigation. So
now I present some basic Rubymoticons:

[].inject( :slight_smile:

Hmm, a little off-topic, but how come my ruby 1.9.2-p290 version of irb
behaves “funny” with certain, apparently valid symbols?

Example

00: irb
01: > :hi
02: => :hi
03: > :"-"
04: => :-
05: > :-
06: > :+
07: > x = :-
08: > x
09: => :-
…

Basically, certain characters that the ruby (1.9.2-p290) parser is fine
with having as unquoted symbols above make irb fail to print out the
statement’s value. Specifically, no result line is printed for lines 5,
6,
or 7.

Obviously, I noticed this while playing around with Dave’s challenge and
I’m just curious if anyone knows what’s going on.

2012/2/29 Kendall G. [email protected]:

Basically, certain characters that the ruby (1.9.2-p290) parser is fine with
having as unquoted symbols above make irb fail to print out the statement’s
value. Specifically, no result line is printed for lines 5, 6, or 7.

Obviously, I noticed this while playing around with Dave’s challenge and I’m
just curious if anyone knows what’s going on.

I think that irb, seeing a - or + sign at end of lines, assumes it’s
an operator and that expression will be continued on next line.

– Matma R.

On Wed, Feb 29, 2012 at 1:51 PM, Dave A.
[email protected] wrote:

2012/2/29 Bartosz Dziewoński [email protected]:

I think that irb, seeing a - or + sign at end of lines, assumes it’s
an operator and that expression will be continued on next line.

That makes sense, but it should be smart enough to realize that it’s a
symbol…

-Dave

Also, it should then take the next line entered and attempt to use it
to complete the previous line – which it doesn’t.

(In my case, it does show * instead of > as the prompt, which makes it
look like it’s going to join the lines together; but it doesn’t.)

2012/2/29 Bartosz Dziewoński [email protected]:

I think that irb, seeing a - or + sign at end of lines, assumes it’s
an operator and that expression will be continued on next line.

That makes sense, but it should be smart enough to realize that it’s a
symbol…

-Dave

2012/2/29 Eric C. [email protected]:

That makes sense, but it should be smart enough to realize that it’s a
symbol…

-Dave

Also, it should then take the next line entered and attempt to use it
to complete the previous line – which it doesn’t.

Actually, I think it does. But it doesn’t strip the newline signs from
input, so just incidentally the resulting code is still valid Ruby,
with multiple lines.

For example try this:

irb(main):001:0> :-
irb(main):002:0* .object_id
=> 548

I agree it seems like a bug. Anybody cares enough to report it? :wink:

– Matma R.

2012/2/29 Bartosz Dziewoński [email protected]

I agree it seems like a bug. Anybody cares enough to report it? :wink:

Maybe I’m missing something, but:

$ ruby -ve ‘puts :-
.class’
ruby 1.9.2p180 (2011-02-18 revision 30909) [i686-linux]
Symbol

2012/2/29 Bartosz Dziewoński [email protected]:

input, so just incidentally the resulting code is still valid Ruby,
with multiple lines.

For example try this:

irb(main):001:0> :-
irb(main):002:0* .object_id
=> 548

Hmm, strange. Here’s more irb interaction:
irb(main):001:0> :-
irb(main):002:0* .object_id
=> 548
irb(main):003:0> :-
irb(main):004:0* 1
=> 1
irb(main):005:0> :- 1
SyntaxError: (irb):5: syntax error, unexpected tINTEGER, expecting $end
from X:/Ruby/bin/irb:12:in `’
irb(main):006:0>

Notice how when I typed “1”, it just discarded the :- on the previous
line.

I agree it seems like a bug. Anybody cares enough to report it? :wink:

If I get around to it.

Adam P. wrote:

Maybe I’m missing something, but:

$ ruby -ve ‘puts :-
.class’
ruby 1.9.2p180 (2011-02-18 revision 30909) [i686-linux]
Symbol

So Ruby and IRB are consistent in this respect. But I would still
expect Ruby not to wait for the next line when it encounters a
symbol like :- at the end of a line.

On Thu, Mar 1, 2012 at 1:12 AM, Florian G. [email protected]
wrote:

So Ruby and IRB are consistent in this respect. But I would still
So, it works with any expression, also with symbols.
Yes, but not in irb; in irb, after you type “foo \n”, it is
immediately evaluated.

irb should also treat symbols that way – and not halfway interpret
them as operators. (I say “halfway” because on the one hand it waits
for the next line, as it would with a dangling operator; but on the
other hand, it then just throws away the symbol and evaluates the next
line as if it stood alone.)

So Ruby and IRB are consistent in this respect. But I would still
expect Ruby not to wait for the next line when it encounters a
symbol like :- at the end of a line.

This is not a bug. Ruby 1.9 can chain methods like this:

“foo \n”
.chomp
.reverse

So, it works with any expression, also with symbols.

Regards,
Florian

2012/3/1 Eric C. [email protected]:

irb should also treat symbols that way – and not halfway interpret
them as operators. (I say “halfway” because on the one hand it waits
for the next line, as it would with a dangling operator; but on the
other hand, it then just throws away the symbol and evaluates the next
line as if it stood alone.)

No. It does not discard it; it’s simply the effect of syntax. Consider
this:

ruby -e ‘p eval(“:-; 1”)’

There are two expressions evaled here, “:-” and “1”.

Now this:

ruby -e ‘p eval(“:-\n1”)’

Just as above, there are two expressions. IRB does not strip
newlines
; and when evaling some code, only the result of last
expresion is returned.

The only bug here (or, IMO, a lack of feature) is that IRB does not
parse the code at all; it simply checks if the line ends with an
operator, a dot or a backslash, and in this case does not eval code
immediately, but joins it with next line of input.

– Matma R.

2012/3/1 Bartosz Dziewoński [email protected]

ruby -e ‘p eval(“:-; 1”)’

The only bug here (or, IMO, a lack of feature) is that IRB does not
parse the code at all; it simply checks if the line ends with an
operator, a dot or a backslash, and in this case does not eval code
immediately, but joins it with next line of input.

– Matma R.

So, if I’m reading you correctly, in your opinion, the real lacking
feature of IRB might be stated by demonstrating that, due to the fact
that IRB doesn’t parse the code, the following fails:

$ irb
1.9.2p290 :001 > “Hello world”
=> “Hello world”
1.9.2p290 :002 > .gsub(/Hello/, “Goodbye”)
SyntaxError: (irb):2: syntax error, unexpected ‘.’
.gsub(/Hello/, “Goodbye”)
^
from /Users/kendall/.rvm/rubies/ruby-1.9.2-p290/bin/irb:16:in `’
1.9.2p290 :003 >

Whereas the follow works in ruby:

$ ruby <<EOF

“Hello world”
.gsub(/Hello/, “Goodbye”)
EOF

(no output is printed, of course, but no error is raised either).

With, of course, IRB trying to be a little helpful with some
simplistic line-parsing rules in place (as opposed to full language
parsing) which is the cause of some of the “weird” behavior that’s
been pointed out (and it is “weird” to have a language environment
provided REPL tool appear to silently ignore lines of code since it
doesn’t print out the “ignored” statement’s value)

That said, it’s good to understand now that it may be necessary, for
specific code statements in IRB, to explicitly terminate some lines of
code:

$ irb
1.9.2p290 :001 > :- ;
1.9.2p290 :002 >
1.9.2p290 :003 >

Oops! IRB just ignored my explicit semi-colon???