Syntactic sugar buzz

ruby-talk
21

*snip*

As another poster mentioned or hinted at, since "something" may not have
a type yet, there's no way to get the needed object type from that. I
was hoping for something that can't be done without mind reading
interpreters.

*snip*

I think it's a bit nastier than that. It's not just that you don't know
what type to use when the thing could be nil. You also possibly don't
know what value to use either.

[This seems related to the identity element in a group.]

For example, for a multiplication operation on integers, we might want 1
to replace nil. For an addition operation, we would probably prefer 0.
To illustrate:

I use .magic as the method that you can call on nil that "does the right
thing"

1 + 1.magic => 2
1 + nil.magic => 1
# nil.magic => 0

1 * 1.majic => 1
1 * nil.magic => 1
# nil.magic => 1

Which is kind of interesting? :slight_smile:

Cheers,
  Benjohn

22

> Daniel Lucraft wrote:
> >>> This could be written:
> >>> blah = (foo.bar||"").split
> >
> > Sometimes I think the brackets spoil how the expression reads. You could
> > define a method that looks like this:
> >
> > blah = foo.bar.or("").split
> >
> > Trainwreck though...
> >
> > Dan
>
> Thanks everyone. This has at least convinced me that I wasn't missing
> some well known way to do this.

I believe another (obvious?) solution has not been mentioned so far:

I believe Aur has ...

# note, I used the empty array as replacement
# because split would return an array
blah = foo.bar.split rescue

... and I think it is nice.

I lost the fight with myself to propose this :slight_smile:

class Nil
  def split; end
  def join(x); "" end
  def each &blk; end
  etc.etc
end

now there might be many reasons against this, and I believe that they
outweight the benefits, but look at this

irb(main):005:0> nil.to_i
=> 0
irb(main):006:0> ## and worse
irb(main):007:0* Integer(nil)
=> 0

so I am still suffering from Ruby's inconsistency (do not laugh Lionel).

<snip>
robert

···

On 7/18/07, Robert Klemme <shortcutter@googlemail.com> wrote:

2007/7/18, Jeff Pritchard <jp@jeffpritchard.com>:
> >> On Jul 17, 6:52 pm, Jeff Pritchard <j...@jeffpritchard.com> wrote:

--
I always knew that one day Smalltalk would replace Java.
I just didn't know it would be called Ruby
-- Kent Beck

23

Hi --

>> > Daniel Lucraft wrote:
>> > >>> This could be written:
>> > >>> blah = (foo.bar||"").split
>> > >
>> > > Sometimes I think the brackets spoil how the expression reads. You
>> could
>> > > define a method that looks like this:
>> > >
>> > > blah = foo.bar.or("").split
>> > >
>> > > Trainwreck though...
>> > >
>> > > Dan
>> >
>> > Thanks everyone. This has at least convinced me that I wasn't missing
>> > some well known way to do this.
>>
>> I believe another (obvious?) solution has not been mentioned so far:
> I believe Aur has ...
>>
>> # note, I used the empty array as replacement
>> # because split would return an array
>> blah = foo.bar.split rescue
> ... and I think it is nice.
>
> I lost the fight with myself to propose this :slight_smile:
>
> class Nil
> def split; end
> def join(x); "" end
> def each &blk; end
> etc.etc
> end
>
> now there might be many reasons against this, and I believe that they
> outweight the benefits, but look at this
>
> irb(main):005:0> nil.to_i
> => 0
> irb(main):006:0> ## and worse
> irb(main):007:0* Integer(nil)
> => 0
>
> so I am still suffering from Ruby's inconsistency (do not laugh Lionel).

My favorite slogan for Ruby is:

   The triumph of balance over symmetry.

It means, for example, that it might make sense for nil to have #to_s
-- and that it still might *not* make sense for nil to have #split.
One does not imply the other. Every decision is made carefully, one
at a time, in the interest of the usefulness of the system overall.

I do have problems with such err strict statements, and I have never
seen such from you before. I am however challenging the usefulness of
Integer(nil) =>0 and doubting the usefulness of nil.to_s => 0.

That's why I don't care about symmetry or consistency (which I think
in this case mean much the same thing). We're lucky enough to have
Matz hand-crafting the language with the greatest care; I think that's
a higher-percentage prospect than a principle of uniformity :slight_smile:

No sorry I can only disagree.
Matz has tons of my respect but should that be any reason not to be
consistent or symmetric.

Asymmetrical behavior is not very POLS and once a user has learned
that Integer("david") will throw an exception she will expect the same
for Integer(nil).

nil.to_i => 0 is exactly the same as nil.split =>
expressing equivalancy of different forms of void.
I do not agree with this equivalency but I believe it should be
expressed consistently.

Hmm I feel it is too easy to say look "Ruby is just perfect thus you
shalt not criticize", well that's how I interpreted your reply.

David

--
* Books:
   RAILS ROUTING (new! http://www.awprofessional.com/title/0321509242\)
   RUBY FOR RAILS (http://www.manning.com/black\)
* Ruby/Rails training
     & consulting: Ruby Power and Light, LLC (http://www.rubypal.com)

Cheers
Robert

···

On 7/18/07, dblack@wobblini.net <dblack@wobblini.net> wrote:

On Wed, 18 Jul 2007, Robert Dober wrote:
> On 7/18/07, Robert Klemme <shortcutter@googlemail.com> wrote:
>> 2007/7/18, Jeff Pritchard <jp@jeffpritchard.com>:
>> > >> On Jul 17, 6:52 pm, Jeff Pritchard <j...@jeffpritchard.com> wrote:

--
I always knew that one day Smalltalk would replace Java.
I just didn't know it would be called Ruby
-- Kent Beck

24

My favorite slogan for Ruby is:

  The triumph of balance over symmetry.

It means, for example, that it might make sense for nil to have #to_s
-- and that it still might *not* make sense for nil to have #split.
One does not imply the other. Every decision is made carefully, one
at a time, in the interest of the usefulness of the system overall.

That makes perfect sense, since the logical way to use split would be
with something like nil.to_s.split. If you really want split to return
something "useful" from nil directly, I'd say add your own split to
NilClass and be done with it.

That's why I don't care about symmetry or consistency (which I think
in this case mean much the same thing). We're lucky enough to have
Matz hand-crafting the language with the greatest care; I think that's
a higher-percentage prospect than a principle of uniformity :slight_smile:

I care about consistency -- in a way that makes sense, of course. I
don't see how nil lacking a split() violates that.

···

On Wed, Jul 18, 2007 at 09:17:45PM +0900, dblack@wobblini.net wrote:

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
awj @reddit: "The terms never and always are never always true."

25

Hi --

Hmm I feel it is too easy to say look "Ruby is just perfect thus you
shalt not criticize", well that's how I interpreted your reply.

Read it again :slight_smile: It's not that Ruby's perfect; it's that the process
in place for improving Ruby is, in my view, more nuanced and careful
than if everything were made to be sort of homogenous and uniform.

I don't mean I think that there should be weird or confusing
exceptions to things -- and people certainly disagree as to what's
weird or confusing -- but only that I don't generally find symmetry or
consistency, as such, to be sufficient reasons for design decisions in
Ruby.

(Of course, it all depends on what level of abstraction you're dealing
with. I could say, for example: "Ruby is completely consistent, in
the sense that every feature has been carefully designed by Matz" :slight_smile:
But I know that's not what you mean.)

David

···

On Wed, 18 Jul 2007, Robert Dober wrote:

--
* Books:
   RAILS ROUTING (new! http://www.awprofessional.com/title/0321509242\)
   RUBY FOR RAILS (http://www.manning.com/black\)
* Ruby/Rails training
     & consulting: Ruby Power and Light, LLC (http://www.rubypal.com)

26

>
> My favorite slogan for Ruby is:
>
> The triumph of balance over symmetry.
>
> It means, for example, that it might make sense for nil to have #to_s
> -- and that it still might *not* make sense for nil to have #split.
> One does not imply the other. Every decision is made carefully, one
> at a time, in the interest of the usefulness of the system overall.

That makes perfect sense, since the logical way to use split would be
with something like nil.to_s.split. If you really want split to return
something "useful" from nil directly, I'd say add your own split to
NilClass and be done with it.

It makes perfect sense, but it is an example ex nihilis as I was
complaining about nil.to_i and Integer(nil), or am I in the wrong
thread (has happened to me before :()?

>
> That's why I don't care about symmetry or consistency (which I think
> in this case mean much the same thing). We're lucky enough to have
> Matz hand-crafting the language with the greatest care; I think that's
> a higher-percentage prospect than a principle of uniformity :slight_smile:

I care about consistency -- in a way that makes sense, of course. I
don't see how nil lacking a split() violates that.

Nor do I, nor did I say so, I just wanted to say, hey if nil has to_i,
it can have split too, that would be no big deal at all.

Cheers
Robert

···

On 7/18/07, Chad Perrin <perrin@apotheon.com> wrote:

On Wed, Jul 18, 2007 at 09:17:45PM +0900, dblack@wobblini.net wrote:

--
I always knew that one day Smalltalk would replace Java.
I just didn't know it would be called Ruby
-- Kent Beck

27

Oh well that, actually you are completely right, but that was not at
all I was thinking about :frowning:

I feel that there are some, let us say "rules" that really hurt and
that's what I wanted to discuss, but that will hijack the thread,
which was not my intention, because Nil#split would help OP, so I will
just move this out slowly...
Robert

···

On 7/18/07, dblack@wobblini.net <dblack@wobblini.net> wrote:

Hi --

On Wed, 18 Jul 2007, Robert Dober wrote:

> Hmm I feel it is too easy to say look "Ruby is just perfect thus you
> shalt not criticize", well that's how I interpreted your reply.

Read it again :slight_smile: It's not that Ruby's perfect; it's that the process
in place for improving Ruby is, in my view, more nuanced and careful
than if everything were made to be sort of homogenous and uniform.

I don't mean I think that there should be weird or confusing
exceptions to things -- and people certainly disagree as to what's
weird or confusing -- but only that I don't generally find symmetry or
consistency, as such, to be sufficient reasons for design decisions in
Ruby.

(Of course, it all depends on what level of abstraction you're dealing
with. I could say, for example: "Ruby is completely consistent, in
the sense that every feature has been carefully designed by Matz" :slight_smile:
But I know that's not what you mean.)

--
I always knew that one day Smalltalk would replace Java.
I just didn't know it would be called Ruby
-- Kent Beck

28

unknown wrote:

I don't mean I think that there should be weird or confusing
exceptions to things -- and people certainly disagree as to what's
weird or confusing -- but only that I don't generally find symmetry or
consistency, as such, to be sufficient reasons for design decisions in
Ruby.

Ralph Waldo Emerson wrote:
"A foolish consistency is the hobgoblin of little minds, adored by
little statesman and philosophers and divines. With consistency a great
soul has simply nothing to do."

Consistency is very helpful in some situations. (If everything in system
XX worked in the same way, it would be very easy to figure out how a new
proposed feature should behave, and it would be very easy for a newcomer
to know exactly how it worked, since it wouldn't be a special case.)

But like an unyielding policeman who still writes you a ticket for
speeding when you're rushing to the hospital with your sick daughter, a
foolish consistency makes no allowance for special cases. It blindly
applies the set of rules with no consideration if there might be a good
argument for an exception.

This is what I think of when I hear Matz argue for certain
inconsistencies. Handcrafted features may show nicks and scratches from
inconsistent application. They may not have the pure, clean lines of
something that was honed by a machine. But those special cases carve out
bumps that (by and large) make sense for the common case.

A final example: blocks. It would be more notionally pure to allow an
arbitrary number of blocks to be passed to a method. It would be
consistent with other method arguments if the method validated that the
right number of blocks were passed. It would be consistent if the blocks
passed as parameters were objects assigned to variables that you had to
call methods on to get them to do something.

(And, of course, you can do this if you want.)

But what we have is the special handcrafted notation of one-block per
method, a special block that is optional, and that can be called simply
with the "yield" keyword. And I find it elegant, and appropriate for 95%
of the cases. I don't think I'd call it pure or consistent, but I'd be
angry if it were removed from the language.

And...a final comparison. I program in Lua for a living. It is a great
language because at its core it's very simple, very consistent. It's
very, very easy to learn, because there are so very few special cases.
It has very little syntactic sugar. (You can't even write a+=b, but must
write out a = a+b.) I loved learning Lua, in large part because of its
consistency. And I really don't like writing in it much, because it is
so rigid and simple-minded.

···

--
Posted via http://www.ruby-forum.com/\.

29

Unless nil.split simply returned nil, like:
  Class NilClass
    def split
      self
    end
  end
. . . I don't see how NilClass.split could reasonably be incorporated as
a standard part of the language. The only other alternatives that
spring to mind would be to return false (as though split() were a
boolean test in this case) or to return an empty list. I don't think
either of those really works very well, since returning false doesn't
bring anything new to the table and an empty list would be turning
nothing (nil) into something (even if it's an empty something), which is
a severely broken approach in my opinion.

Unfortunately, returning nil is also a little troublesome, since split()
is expected to return a list, but nil is definitely not a list.

Maybe nil.split should just return an exception. Oh, wait . . .

···

On Thu, Jul 19, 2007 at 06:09:43AM +0900, Robert Dober wrote:

On 7/18/07, Chad Perrin <perrin@apotheon.com> wrote:
>On Wed, Jul 18, 2007 at 09:17:45PM +0900, dblack@wobblini.net wrote:
>>
>> My favorite slogan for Ruby is:
>>
>> The triumph of balance over symmetry.
>>
>> It means, for example, that it might make sense for nil to have #to_s
>> -- and that it still might *not* make sense for nil to have #split.
>> One does not imply the other. Every decision is made carefully, one
>> at a time, in the interest of the usefulness of the system overall.
>
>That makes perfect sense, since the logical way to use split would be
>with something like nil.to_s.split. If you really want split to return
>something "useful" from nil directly, I'd say add your own split to
>NilClass and be done with it.
It makes perfect sense, but it is an example ex nihilis as I was
complaining about nil.to_i and Integer(nil), or am I in the wrong
thread (has happened to me before :()?

>
>
>>
>> That's why I don't care about symmetry or consistency (which I think
>> in this case mean much the same thing). We're lucky enough to have
>> Matz hand-crafting the language with the greatest care; I think that's
>> a higher-percentage prospect than a principle of uniformity :slight_smile:
>
>I care about consistency -- in a way that makes sense, of course. I
>don't see how nil lacking a split() violates that.
Nor do I, nor did I say so, I just wanted to say, hey if nil has to_i,
it can have split too, that would be no big deal at all.

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
Paul Graham: "Real ugliness is not harsh-looking syntax, but having to
build programs out of the wrong concepts."

30

unknown wrote:
> I don't mean I think that there should be weird or confusing
> exceptions to things -- and people certainly disagree as to what's
> weird or confusing -- but only that I don't generally find symmetry or
> consistency, as such, to be sufficient reasons for design decisions in
> Ruby.

Ralph Waldo Emerson wrote:
"A foolish consistency is the hobgoblin of little minds, adored by
little statesman and philosophers and divines. With consistency a great
soul has simply nothing to do."

Gavin I am astonished, by what reason do you throw good ol'Emerson at me?
Is there a single indication that I was talking about foolish consistencies?
BTW the sentence of RWE is quite ( I spare you the adjective ) would
be nice to see the context.
Consistency for me is much more to react logically, much in Gödels' sense,
Extreme examples:
Integer#to_f implies Array#to_f that would be a stupid consistency.
String#to_i implies Nil#to_i what do you think about this?

Object#to_s for an intelligent consistency

Consistency is very helpful in some situations. (If everything in system
XX worked in the same way,

that's not consistency that is conformism

it would be very easy to figure out how a new
proposed feature should behave, and it would be very easy for a newcomer
to know exactly how it worked, since it wouldn't be a special case.)

and hence there would be no power to achieve anything, of course.

But like an unyielding policeman who still writes you a ticket for
speeding when you're rushing to the hospital with your sick daughter, a
foolish consistency makes no allowance for special cases. It blindly
applies the set of rules with no consideration if there might be a good
argument for an exception.

Please read again, what is this all about?

This is what I think of when I hear Matz argue for certain
inconsistencies.

Than let us argue for certain inconsitencies

Handcrafted features may show nicks and scratches from
inconsistent application. They may not have the pure, clean lines of
something that was honed by a machine. But those special cases carve out
bumps that (by and large) make sense for the common case.

A final example: blocks. It would be more notionally pure to allow an
arbitrary number of blocks to be passed to a method. It would be
consistent with other method arguments if the method validated that the
right number of blocks were passed.

Honestly these are much too strong statements to be postulated like that.
>It would be consistent if the blocks

passed as parameters were objects assigned to variables that you had to
call methods on to get them to do something.

Well they are, so what are you trying to say?

(And, of course, you can do this if you want.)

But what we have is the special handcrafted notation of one-block per
method, a special block that is optional, and that can be called simply
with the "yield" keyword. And I find it elegant, and appropriate for 95%
of the cases. I don't think I'd call it pure or consistent, but I'd be
angry if it were removed from the language.

Well I call it pure and consistent and you are talking about something
completely unrelated here.

And...a final comparison. I program in Lua for a living. It is a great
language because at its core it's very simple, very consistent.

I was indeed intrigued by that

It's
very, very easy to learn, because there are so very few special cases.
It has very little syntactic sugar. (You can't even write a+=b, but must
write out a = a+b.) I loved learning Lua, in large part because of its
consistency. And I really don't like writing in it much, because it is
so rigid and simple-minded.

Completely agree!

But to draw a conclusion, you have thrown all that at me because I said that
Integer(nil) -> 0 is inconsistent in itself and that it's usefulness
could be discussed and that I feel that Nil#split --> might be more
useful, and that I consider this kind of design choices inconsistent,
and I was hoping to have some explanations about that, and I get
"Ruby's cool" and good ol' Waldo.

It is somehow disappointing.

Robert

···

On 7/18/07, Gavin Kistner <gavin@refinery.com> wrote:

--
I always knew that one day Smalltalk would replace Java.
I just didn't know it would be called Ruby
-- Kent Beck

31

> >>
> >> My favorite slogan for Ruby is:
> >>
> >> The triumph of balance over symmetry.
> >>
> >> It means, for example, that it might make sense for nil to have #to_s
> >> -- and that it still might *not* make sense for nil to have #split.
> >> One does not imply the other. Every decision is made carefully, one
> >> at a time, in the interest of the usefulness of the system overall.
> >
> >That makes perfect sense, since the logical way to use split would be
> >with something like nil.to_s.split. If you really want split to return
> >something "useful" from nil directly, I'd say add your own split to
> >NilClass and be done with it.
> It makes perfect sense, but it is an example ex nihilis as I was
> complaining about nil.to_i and Integer(nil), or am I in the wrong
> thread (has happened to me before :()?
>
> >
> >>
> >> That's why I don't care about symmetry or consistency (which I think
> >> in this case mean much the same thing). We're lucky enough to have
> >> Matz hand-crafting the language with the greatest care; I think that's
> >> a higher-percentage prospect than a principle of uniformity :slight_smile:
> >
> >I care about consistency -- in a way that makes sense, of course. I
> >don't see how nil lacking a split() violates that.
> Nor do I, nor did I say so, I just wanted to say, hey if nil has to_i,
> it can have split too, that would be no big deal at all.

Unless nil.split simply returned nil, like:
  Class NilClass
    def split
      self
    end
  end
. . . I don't see how NilClass.split could reasonably be incorporated as
a standard part of the language. The only other alternatives that
spring to mind would be to return false (as though split() were a
boolean test in this case) or to return an empty list. I don't think
either of those really works very well, since returning false doesn't
bring anything new to the table and an empty list would be turning
nothing (nil) into something (even if it's an empty something), which is
a severely broken approach in my opinion.

Unfortunately, returning nil is also a little troublesome, since split()
is expected to return a list, but nil is definitely not a list.

Maybe nil.split should just return an exception. Oh, wait . . .

do you mean NoMethodError :wink: ?
Your thoughts are intriguing me, I am really surprised for me split
shall return an array, but wait, split might be intended from the
Chronograph module and it should return 0.

Hmmm, nil#split makes not much sense I agree, but what about
nil#to_i?
Actually that is Off-Topic, I have to admit :(.

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
Paul Graham: "Real ugliness is not harsh-looking syntax, but having to
build programs out of the wrong concepts."

Robert

···

On 7/18/07, Chad Perrin <perrin@apotheon.com> wrote:

On Thu, Jul 19, 2007 at 06:09:43AM +0900, Robert Dober wrote:
> On 7/18/07, Chad Perrin <perrin@apotheon.com> wrote:
> >On Wed, Jul 18, 2007 at 09:17:45PM +0900, dblack@wobblini.net wrote:

--
I always knew that one day Smalltalk would replace Java.
I just didn't know it would be called Ruby
-- Kent Beck

32

Hmmm, nil#split makes not much sense I agree, but what about
nil#to_i?
Actually that is Off-Topic, I have to admit :(.

I think to_i() fits in well enough. You're specifically returning a
different type in this case. While an array looks like a type, from a
certain perspective, it's actually a collection of "things" of some other
type(s) -- it's a data structure, not a datum. As such, I'm not sure the
same rules should apply.

The closest thing to a nil.split that makes sense to me is nil.to_a
which, by the way, already exists.

  > ri NilClass#to_a
  ---------------------------------------------------------- NilClass#to_a
       nil.to_a =>

···

On Thu, Jul 19, 2007 at 06:31:46AM +0900, Robert Dober wrote:
  ------------------------------------------------------------------------
       Always returns an empty array.

          nil.to_a #=>

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
John W. Russell: "People point. Sometimes that's just easier. They also use
words. Sometimes that's just easier. For the same reasons that pointing has
not made words obsolete, there will always be command lines."