NEWBIE QUESTION: pattern with nil

ruby-talk
21

Austin, I'd like to see a _real_ example of where Nilclass' suppossed
contract of not responding to #empty? is going to cause a major
malfunction. If anyone is depending on #empty? to throw an error on a
errant nil result, they really need to reconsider their programming
strategy to begin with.

But that aside, there are other ways to intgerate polymorphic
charateristices between conceptually distinct classes. RoR's #blank? is
an example, albiet a lousy one, both in how it is defined and it's
semantic value. A better one that I have used is #to_b (akin to but
more fluid then to_bool):

  class NilClass
    def to_b ; false ; end
  end

  class String
    def to_b ; !empty? ; end
  end

And so on for the other classes.

Lastly, let me say that there is indeed a rasonable distinction between
two types of nil, and only two types. The first is the non-object
object. This is the typical use of Ruby's nil, it is a kind of filler,
or dummy object, often removed as in Array#compact. The other type is a
_nack_, a not-acknowledged object. Nack isn't a useful object in and of
itself. It does nothing more then communicate a message that something
is invalid or to be ignored. As such it would has no useful methods
other then those to raise the error for which it is essentially a
supression of. In fact the NackClass I designed was originally a
subclass of Exception (now it uses delegation instead for unrelated
reasons).

T.

22

Hi --

The original poster had a NoThing type of nil. Your fear arises from the possibility of applying the empty? method to an Unitialized or NotApplicable type of nil.

I would say that asking whether nil is empty is like asking whether 12
is empty: it just doesn't mean anything. Even having it say "false"
suggests that "true" is possible. In general, I don't think
non-container objects should be declaring themselves "empty".

class Fixnum
def each
   # I'm throwing this exception, not because it is required,
   # but because a headache is damping my imagination
   # as to what -1.each means. I think it means the something
   # like collect or sum, but my head hurts too much to say.
   raise "Negative number" if self < 0

   (1..self).each{|i| yield 1}
end

def empty?
   self == 0
end
end

12.each {|i| puts i}

Well, yes, Ruby lets you do that. I would still argue that "it just
doesn't mean anything" :slight_smile: I don't think that 0 is empty.
Containers contain 0 elements are empty. 0 isn't a container.

What does NoThing contain? Obvious it contains NoThing.
noThing.shift returns noThing. Is NoThing empty? Yes.

This is a bit like "a ham sandwich is better than God" :slight_smile: [1] I'd
actually say there's a difference between: it contains [Nn]o[Tt]hing,
and: it's not a container.

The current axioms of "nil" are valid and consistent. But more
useful, equally consistent axioms of "nil" can be proposed.

I look at it the other way around: not "What can nil evolve to from
what it is?" but "Is it desireable to have an object that has
no dimensional characteristics (no size, no fullness or emptiness,
etc.)?" If it's good to have that, then it will either be nil or
whatever new term is created to replace nil if nil is changed. So I'd
just as soon keep nil nil and come up with something else if there's a
demonstrated need for something else.

Anyway, in practical terms I would certainly agree with Austin that
one should not change nil in any code that one plans to share.

David

[1] I don't where it originated, but the syllogism goes: A ham
sandwich is better than nothing. Nothing is better than God. Ergo...

···

On Thu, 11 Aug 2005, John Carter wrote:

On Thu, 11 Aug 2005, David A. Black wrote:

--
David A. Black
dblack@wobblini.net

23

John Carter wrote:

It's all like non-euclidean geometry. Nobody could prove Euclid's 5
postulate even though it was ugly enough to be a theorem not an axiom.

By definition, axioms are not provable.

24

I didn't go into detail there, John, but it's worth noting that
originally Codd thought that there should be several different
NULL values for relational databases. Later in life, he came to
believe that NULL values (both the single NULL value in SQL
databases and the multiple NULL values in his original relational
papers) were bad.

No, as I remember it, his problem wasn't with NULL, but rather the
DB design.

ie. All instances where you have NotApplicable or NoThing null IN
A DB TABLE can be refactored to a better relational design that
didn't require them.

Um. In part, yes. The point is, though, that Codd believed toward
the end that multiple NULL values weren't nearly as useful as once
advocated.

However, having factored the DB into more tables so neither
variety of NULL occurred, there is still a need for NULL. There is
still a need on occasion to construct reports for user display
which are joins of various tables. And in those "views" there may
be some fields are going to be NULL. And again, it is still
necessary to disambiguate between NotApplicable and NoThing.

Is it? I don't think so, based on my experience. More often than
not, NULL -- whether "Not Applicable" or "No Thing" is blanked or
zeroed depending on the nature of the database.

Your proposal of multiple types of nil makes life harder. Instead
of:
if foo.nil?
# blah
end
I would have to do:
if foo.nothing? or foo.undefined? or foo.not_applicable?
# blah
end

How about starting with the following in the core

[snip implementation of bad proposal]

It still expands the number of tests that we would ultimately have
to deal with for very questionable gain. You haven't convinced me
that the need for knowing the difference between a Nothing nil and
an Undefined nil, etc. is worth knowing. To be more specific, I have
not yet needed such a differentiation in ten years of professional
software development.

Now if the rest of the system chose the right version of nil when
it assigned nil to something, the problem would go away and we can
extend the NoThing in a sane harm free fashion.

*shrug* I still don't think that it's valuable. Where's the Real
World Applicability?

The problem, as others have stated, is that adding #empty? to
NilClass implies a containment. I'd have as big a problem if we
added #empty? to Fixnum so that 0 returned true and everything
else returned false. (Indeed, would that be correct? Would
-3.empty? be true or false?)

Tut! Tut! I'm having this same problem with my son at school, they
teach him the rote mechanics, but forget to teach the principles.
(To be fair, I only started learning these things when I start
reading foundations of mathematics type books from the university
library...)

Come now, what is 3? 3 is 1+1+1. What do we mean by 1+1+1 we mean
three contains a 1 and a 1 and a 1! So if I extract the contents
of three I get 1 and 1 and 1 back.

And -3? Surprise surprise it contains three minus ones!

There is a strong overlap between core system design and axiomatic
mathematics.

Um. No wonder you're having problems, if you are trying to teach him
things that aren't real. I'll be the first to admit that I'm weak,
but I don't recall arithmetic or numerical theory being based on set
theory (that is, numbers as sets).

-austin

···

On 8/11/05, John Carter <john.carter@tait.co.nz> wrote:

On Thu, 11 Aug 2005, Austin Ziegler wrote:

--
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca

25

Austin, I'd like to see a _real_ example of where NilClass' suppossed
contract of not responding to #empty? is going to cause a major
malfunction. If anyone is depending on #empty? to throw an error on a
errant nil result, they really need to reconsider their programming
strategy to begin with.

1. It isn't a supposed contract. By default, Ruby does not offer #empty?
   on nil.
2. If an object does not respond to a message -- either through its
   methods or its ancestral methods -- an exception will be thrown.
3. Software that uses #empty? in duck typing often expects that invalid
   values won't respond to it but will, instead, throw an exception.
4. Most of the software that I've written in the last fourteen months
   rather depends on #3. That's because I do everything I can to make
   sure that the method is called with correct values; if it is not
   called with a correct value, then I expect that an error will be
   thrown.

This isn't a matter of needing to reconsider my programming strategy.
This is a matter of using the facilities which are available to me. It
gets worse if you accept Mr Carter's premise that +nil+ is better as an
"eater" object, because many things are NOT correct if a method is just
eaten and it is MORE correct to throw an exception than to produce
invalid data.

If you want something like this, use a new method. Make it clear. But
+nil+ isn't anything; therefore it can't be empty and it can't be
non-empty.

Lastly, let me say that there is indeed a rasonable distinction
between two types of nil, and only two types. The first is the
non-object object. This is the typical use of Ruby's nil, it is a kind
of filler, or dummy object, often removed as in Array#compact. The
other type is a _nack_, a not-acknowledged object. Nack isn't a useful
object in and of itself. It does nothing more then communicate a
message that something is invalid or to be ignored. As such it would
has no useful methods other then those to raise the error for which it
is essentially a supression of. In fact the NackClass I designed was
originally a subclass of Exception (now it uses delegation instead for
unrelated reasons).

I disagree. The distinction between that which is +nil+ and that which
is +nack+ed merely adds complexity without adding significant meaning or
utility. Perl doesn't escape this in the least, with its "undef"
keyword.

-austin

···

On 8/17/05, Trans <transfire@gmail.com> wrote:
--
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca

26

Yes, but back then it wasn't known, that the 5th Euclidean axiom was
indead an axiom. That's why people tried to deduce it from the other
axioms - without success.

···

On 2005-08-12 07:06:11 +0900, William James wrote:

> It's all like non-euclidean geometry. Nobody could prove Euclid's 5
> postulate even though it was ugly enough to be a theorem not an axiom.

By definition, axioms are not provable.

--
Florian Frank

27

John Carter Phone : (64)(3) 358 6639
Tait Electronics Fax : (64)(3) 359 4632
PO Box 1645 Christchurch Email : john.carter@tait.co.nz
New Zealand

Carter's Clarification of Murphy's Law.

"Things only ever go right so that they may go more spectacularly wrong later."

From this principle, all of life and physics may be deduced.

···

On Fri, 12 Aug 2005, Austin Ziegler wrote:

Um. No wonder you're having problems, if you are trying to teach him
things that aren't real. I'll be the first to admit that I'm weak,
but I don't recall arithmetic or numerical theory being based on set
theory (that is, numbers as sets).

28

David A. Black wrote:

> What does NoThing contain? Obvious it contains NoThing.
> noThing.shift returns noThing. Is NoThing empty? Yes.

This is a bit like "a ham sandwich is better than God" :slight_smile: [1]

< [...]

David

[1] I don't where it originated, but the syllogism goes: A ham
sandwich is better than nothing. Nothing is better than God. Ergo...

"Nothing is better than eternal happiness.
   A ham sandwich is better than nothing.
    Therefore, a ham sandwich is better than eternal happiness."

- R. S. Nickerson.
   (Reflections on reasoning. Erlbaum, Hillsdale NJ, 1986.)

···

On Thu, 11 Aug 2005, John Carter wrote:

29

Um. No wonder you're having problems, if you are trying to teach him
things that aren't real. I'll be the first to admit that I'm weak,
but I don't recall arithmetic or numerical theory being based on set
theory (that is, numbers as sets).

Ordinal Number -- from Wolfram MathWorld

Yeah I have to agree here, integers are a Set of values based on a single number line (according to my recollection), reals/floats/engineering units are also a Set of values that exist on this line (with them both exist the negative values), and for complex numbers we have to expand into 2 dimensions. The Set theory of numbers allows us to perform proof by induction (I think, it was a while ago) - ie if something is true for n, then we can prove for n+1. I'm pretty sure that was what 4 courses on (2)formal methods + mathematics + algorithm design were trying to teach us - of course we were all concentrating on the hot russian blonde in the front row! And I have to admit to having never used this information professionally (hence it's incredible rustiness), so I could be miles out. If so, sorry.

Kev

30

Nothing on that page remotely implies that the Ruby Integer object 3
is a collection of three 1 objects, as you have claimed. In fact, the
elements of the ordinal number 3 are given clearly as {0,1,2}. But
even that doesn't matter because Ruby Integers are not ordinal numbers
in the first place.

Ruby Integers are integers. The whole concept of ordinal numbers is
explicitly and manifestly not about integers per se. As the page you
cite says, "an ordinal number...is one of the numbers in Georg
Cantor's extension of the whole numbers." Ruby Integers are not an
extension of the whole numbers. They're integers.

If you google for, say, "add two ordinals", or "negative ordinals",
you'll start to see even more clearly how irrelevant all of this is to
Integer objects.

More informative and relevant would be:
http://mathworld.wolfram.com/Integer.html[1\] There's really no need to
cast about for something other than integers for Ruby Integers to be
like. If you want to write an OrdinalNumber class, you should. As
far as I know there isn't one yet.

David

[1] Eric W. Weisstein. "Integer." From MathWorld--A Wolfram Web
Resource.

···

On Fri, 12 Aug 2005, John Carter wrote:

On Fri, 12 Aug 2005, Austin Ziegler wrote:

Um. No wonder you're having problems, if you are trying to teach him
things that aren't real. I'll be the first to admit that I'm weak,
but I don't recall arithmetic or numerical theory being based on set
theory (that is, numbers as sets).

Ordinal Number -- from Wolfram MathWorld

--
David A. Black
dblack@wobblini.net

31

Hehe It's quite useful to know our language well, isn't it?

The word nothing actually stand in place as a shortcut for a few different meanings:

not anything (no things at all), not something (no particular thing out of a set of things).

Also, we have this tendency in english to take the (what would be succinct in meaning) negative out of the verb and either build it into a noun or precede a noun with not someplace in our sentences. It feels more human, natural and "flowing". The trouble with that is that we potentially lose our meaning to vagueness. But ironically enough, succinct meaning is usually pitted against "the flow of things" or rather - it's one extreme side of the intersection between flow and precision where usually people who insist on precision of meaning lose the flow of things (as I have potentially just done myself) :wink:

When reasoning, it's very important to be aware of your nouns, and to expand your terms (ie meanings) :wink: However ironically the more expanded your description / meanings / terms / words become, the less people your audience includes - it excludes them through complicatedness ;-).

"Not anything (the negative of all things) is better than eternal happiness.
     A ham sandwich is better than not something (no particular thing)
         Therefore, there is no therefore .... ? :-)"

Julian.

···

On 17/08/2005, at 1:21 PM, daz wrote:

David A. Black wrote:

"Nothing is better than eternal happiness.
   A ham sandwich is better than nothing.
    Therefore, a ham sandwich is better than eternal happiness."

- R. S. Nickerson.
   (Reflections on reasoning. Erlbaum, Hillsdale NJ, 1986.)

32

Kev Jackson wrote:

Ordinal Number -- from Wolfram MathWorld

Yeah I have to agree here, integers are a Set of values based on a single number line (according to my recollection), reals/floats/engineering units are also a Set of values that exist on this line (with them both exist the negative values), and for complex numbers we have to expand into 2 dimensions.

Woah, woah, woah. Integers are just things that satisfy a specific set of axioms. The cool Georgian definition is just one way of defining a bunch of items that are Integers, as much as anything that satisfies those axioms are Integers. Isomorphism is a wonderful thing.

Devin

33

Woah, woah, woah. Integers are just things that satisfy a specific set of axioms. The cool Georgian definition is just one way of defining a bunch of items that are Integers, as much as anything that satisfies those axioms are Integers. Isomorphism is a wonderful thing.

Ok, agreed it's just one way of defining 'things' that happen to satisfy a set of properties. The number line thing is a suitable image that can be used to instruct young bored undergrads, but I think it's a helpful one .
Kev