NEWBIE QUESTION: pattern with nil

[David A. Black]

Hi --

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

I'd say it's undefined, or just meaningless. One could say that -3
"contains" three -1's... but I don't find that compelling. It could
be said, equally (and equally wrongly, in my view), to "contain" a 5
and a -8.

I don't consider something a container unless there's some meaning to
the concept of inserting, removing, counting, iterating over elements.
Even in the case of, say, a frozen array, there's still a meaning to
the concept of altering the collection. You can't remove a 1 from 3.
You can subtract 1 from 3, but that doesn't change 3. If it were
otherwise, then the expression "3 - 1" would turn 3 into 2, which
would cause lots of problems

I would say that propagating the notion of emptiness to
non-collections definitely isn't the way to address nil-related
issues.


David

 

[Florian Frank]

By definition, axioms are not provable.

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.

 

[Austin Ziegler]

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.

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?

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
--=20
Austin Ziegler * (e-mail address removed)
* Alternate: (e-mail address removed)

 

[John Carter]

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

http://mathworld.wolfram.com/OrdinalNumber.html


John Carter Phone : (64)(3) 358 6639
Tait Electronics Fax : (64)(3) 359 4632
PO Box 1645 Christchurch Email : (e-mail address removed)
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.

 

[Kev Jackson]

http://mathworld.wolfram.com/OrdinalNumber.html

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

 

[Devin Mullins]

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

 

[Kev Jackson]

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

 

[David A. Black]

http://mathworld.wolfram.com/OrdinalNumber.html

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.

 

[daz]

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

 

[Adam Sanderson]

Don't worry, you can redefine it to return :mu
http://en.wikipedia.org/wiki/Mu_(Japanese_word)
Or for added entertainment just return nil again.

Oh wait, you didn't want to confuse the rest of the world?
.adam sanderson

 

[Trans]

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.

 

[Austin Ziegler]

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
--=20
Austin Ziegler * (e-mail address removed)
* Alternate: (e-mail address removed)

 

[Julian Leviston]

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

When reasoning, it's very important to be aware of your nouns, and to
expand your terms (ie meanings) ;-) 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.