Rubymoticons

ruby-talk
#1

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

路路路

--
Dave Aronson: Available Cleared Ruby on Rails Freelancer
(NoVa/DC/Remote) -- see www.DaveAronson.com, and blogs at
www.Codosaur.us, www.Dare2XL.com, www.RecruitingRants.com

#2

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.

路路路

On Tue, Feb 28, 2012 at 10:03 AM, Dave Aronson < rubytalk2dave@davearonson.com> wrote:

{}[ :-]

->() { :-}

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

--
Dave Aronson: Available Cleared Ruby on Rails Freelancer
(NoVa/DC/Remote) -- see www.DaveAronson.com, and blogs at
www.Codosaur.us, www.Dare2XL.com, www.RecruitingRants.com

--
Kendall Gifford
zettabyte@gmail.com

#3

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 Rex

路路路

2012/2/29 Kendall Gifford <zettabyte@gmail.com>:

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.

#4

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

-Dave

路路路

2012/2/29 Bartosz Dziewo艅ski <matma.rex@gmail.com>:

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.

--
Dave Aronson: Available Cleared Ruby on Rails Freelancer
(NoVa/DC/Remote) -- see www.DaveAronson.com, and blogs at
www.Codosaur.us, www.Dare2XL.com, www.RecruitingRants.com

#5

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.)

路路路

On Wed, Feb 29, 2012 at 1:51 PM, Dave Aronson <rubytalk2dave@davearonson.com> wrote:

2012/2/29 Bartosz Dziewo艅ski <matma.rex@gmail.com>:

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

#6

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 Rex

路路路

2012/2/29 Eric Christopherson <echristopherson@gmail.com>:

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.

#7

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 <matma.rex@gmail.com>

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:

#8

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

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 `<main>'
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 Prescott 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.

路路路

2012/2/29 Bartosz Dziewo艅ski <matma.rex@gmail.com>:

2012/2/29 Eric Christopherson <echristopherson@gmail.com>:

#9

Adam Prescott 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.

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

#10

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.)

路路路

On Thu, Mar 1, 2012 at 1:12 AM, Florian Gilcher <flo@andersground.net> wrote:

Adam Prescott 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.

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.

#11

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 Rex

路路路

2012/3/1 Eric Christopherson <echristopherson@gmail.com>:

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.)

#12

> 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 Rex

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 `<main>'
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???

路路路

2012/3/1 Bartosz Dziewo艅ski <matma.rex@gmail.com>

2012/3/1 Eric Christopherson <echristopherson@gmail.com>:

--
Kendall Gifford
zettabyte@gmail.com