Re: Cost of Option / Some vs null

Fri, 2009-11-20, 11:47

#1

Ricky Clarkson

Joined: 2008-12-19,

Re: Cost of Option / Some vs null

There was nothing condescending in what Ismael wrote.

2009/11/20 Philip Köster :
>
>
> Ismael Juma schrieb:
>>
>> On Fri, 2009-11-20 at 11:13 +0100, Philip Köster wrote:
>>>
>>> Now this is a good example of how libraries should *not* be designed. It
>>> places the burden on the user of a lib, who really just wants to get his job
>>> done and not worry about subleties such as the difference between `null' and
>>> `None'. This imposes a new kind of fuzzy logic leading to even more
>>> if-then-else branches than we really need.
>>
>> This leads me to think that you're using it wrong. Option is meant to
>> help with the if/else problem that one finds with null (and also the
>> problem that one never knows where null is expected). You may want to
>> check some tutorials on Option and the various ways you can use it
>> without having to rely on if/else all the time.
>>
>> Best,
>> Ismael
>>
>>
>
> I read all the tutorials, so please don't talk to me like a was a child,
> 'cause that is something that really pisses me off and makes me speechless.
> I can very well understand why beginners are confused about the diff between
> `Option' and the Java-native null value, and I predict many failures will
> arise from this basic misunderstanding. A user asked what the difference
> was, and you gave no answer but only increased the confusedness. QED.
>

Fri, 2009-11-20, 11:57

#2

ijuma

Joined: 2008-08-20,

Re: Cost of Option / Some vs null

On Fri, 2009-11-20 at 11:34 +0100, Viktor Klang wrote:
> I'll try to dig it up and send it to you, can't promise anything
> though :/
>
> I'm at the "Universal VM" presentation at Devoxx right now, perhaps I
> can try to ask Alex Buckley afterwards.

OK, thanks. The stack allocation bit is slightly surprising because
HotSpot engineers have not seemed enthusiastic about the performance
improvement that would come out of that when compared to the existing
allocation fast path.[1]

Ismael

[1] "compiled code has a "fast path" of a few instructions which tries
to bump a high-water mark in the current thread's TLAB, successfully
allocating an object if the bumped mark falls before a TLAB-specific
limit address" from

http://openjdk.java.net/groups/hotspot/docs/HotSpotGlossary.html

Fri, 2009-11-20, 15:07

#3

ijuma

Joined: 2008-08-20,

Re: Re: Cost of Option / Some vs null

On Fri, 2009-11-20 at 13:51 +0000, dave.l.griffith@gmail.com wrote:
> That's not the reason for the confusion, that's an implementation
> detail of the confusion. There's not much reason
> for Map to inherit from PartialFunction other than to get the
> special-case apply syntax.

I think you're mistaken, but we'll only actually know if the person who
did it clarifies it for us. If the aim was to get special apply syntax,
it would make more sense to simply add the method directly to Map and
have it return Option. One would use the special syntax a lot more often
then.

As it is, the special syntax is used rarely.

Best,
Ismael

Sat, 2009-11-21, 07:37

#4

phkoester

Joined: 2009-08-23,

Re: Cost of Option / Some vs null

Tony Morris schrieb:
> Don't look up "Church Numeral Encoding."

Schön. Das war jetzt Deine Antwort? Ich bin hellauf begeistert. Church
Numeral Encoding muß ja wirklich ein dickes Ding sein. Das Ding kann
furzen, meine Mikrowelle ersetzen und Krebs heilen? Wow.

Sat, 2009-11-21, 08:37

#5

Ricky Clarkson

Joined: 2008-12-19,

Re: Re: Cost of Option / Some vs null

Maxime,

I guess you'd need a larger audience than just me to ask an audience,
so I'm forwarding your message to the list.

2009/11/21 Maxime Lévesque :
>
>> Option replacing null distinguishes possibly-null values from
>> never-null values. Calling .get is deliberate; you know it can fail.
>
> Ricky, you've managed to sumarize the usefulness of Option in the
> shortest, straight to the point way. I would suggest adding this
> to the Scala doc, currently the doc only says :
>
> This class represents optional values. Instances of Option are either
> instances of case
> class Some or it is case object None.
>
> Are there any scaladoc commiter in the audience that agree and would care to
> add it ?
>
> Cheers
>
>

Sat, 2009-11-21, 13:07

#6

Tony Morris 2

Joined: 2009-03-20,

Re: Cost of Option / Some vs null

That's merely saying that some programs fail to terminate. Option did
"change NullPointerException to NoSuchElementException" any more than it
changed IOException to NoSuchElementException.

Erik Engbrecht wrote:
> Someone naively using references that may be null might write:
> val x = 5 + foo.integerValue // may throw NPE because foo may be null
>
> Using option, the same person might write:
> val x = 5 + foo.get().integerValue // may throw
> NoSuchElementException because foo may be None
>
> On Sat, Nov 21, 2009 at 6:52 AM, Tony Morris > wrote:
>
> What am I looking for exactly? I see no evidence for "Option changes
> NullPointerException to NoSuchElementException." Is it there?
>
> Erik Engbrecht wrote:
> >
> http://lampsvn.epfl.ch/trac/scala/browser/scala/trunk/src/library/scala/...
> >
> >
> > Look at the bottom of the file.
> >
> > On Sat, Nov 21, 2009 at 12:26 AM, Tony Morris
>
> > >> wrote:
> >
> > Stepan Koltsov wrote:
> > > You probably missed parts of the discussion where
> explained how
> > Option
> > > changes NullPointerException to NoSuchElementException.
> > >
> > Except it doesn't.
> >
> > --
> > Tony Morris
> > http://tmorris.net/
> >
> >
> >
> >
> >
> > --
> > http://erikengbrecht.blogspot.com/
>
> --
> Tony Morris
> http://tmorris.net/
>
>
>
>
>

Sat, 2009-11-21, 13:07

#7

phkoester

Joined: 2009-08-23,

Re: Cost of Option / Some vs null

All of this reassures me that nullness or nonnullness should be part of
a function contract and so detected at compile time, not at runtime.

Erik Engbrecht schrieb:
> Someone naively using references that may be null might write:
> val x = 5 + foo.integerValue // may throw NPE because foo may be null
>
> Using option, the same person might write:
> val x = 5 + foo.get().integerValue // may throw NoSuchElementException
> because foo may be None
>
> On Sat, Nov 21, 2009 at 6:52 AM, Tony Morris > wrote:
>
> What am I looking for exactly? I see no evidence for "Option changes
> NullPointerException to NoSuchElementException." Is it there?
>
> Erik Engbrecht wrote:
> >
> http://lampsvn.epfl.ch/trac/scala/browser/scala/trunk/src/library/scala/...
> >
> >
> > Look at the bottom of the file.
> >
> > On Sat, Nov 21, 2009 at 12:26 AM, Tony Morris
>
> > >> wrote:
> >
> > Stepan Koltsov wrote:
> > > You probably missed parts of the discussion where explained how
> > Option
> > > changes NullPointerException to NoSuchElementException.
> > >
> > Except it doesn't.
> >
> > --
> > Tony Morris
> > http://tmorris.net/
> >
> >
> >
> >
> >
> > --
> > http://erikengbrecht.blogspot.com/
>
> --
> Tony Morris
> http://tmorris.net/
>
>
>
>
>

Sat, 2009-11-21, 13:07

#8

Tony Morris 2

Joined: 2009-03-20,

Re: Cost of Option / Some vs null

May I generalise your statement? forall X. forall Y. Using X provides no
extra protection against non-termination over using Y.

That's what I meant in my previous response. There is nothing
particularly interesting with respect to Option and null.

Erik Engbrecht wrote:
> Ok, let me reprhase...
>
> When used in the way I pointed out below, using Option provides no
> extra protection against non-termination over using null.
>
> On Sat, Nov 21, 2009 at 7:00 AM, Tony Morris > wrote:
>
> That's merely saying that some programs fail to terminate. Option did
> "change NullPointerException to NoSuchElementException" any more
> than it
> changed IOException to NoSuchElementException.
>
> Erik Engbrecht wrote:
> > Someone naively using references that may be null might write:
> > val x = 5 + foo.integerValue // may throw NPE because foo may
> be null
> >
> > Using option, the same person might write:
> > val x = 5 + foo.get().integerValue // may throw
> > NoSuchElementException because foo may be None
> >
> > On Sat, Nov 21, 2009 at 6:52 AM, Tony Morris
>
> > >> wrote:
> >
> > What am I looking for exactly? I see no evidence for "Option
> changes
> > NullPointerException to NoSuchElementException." Is it there?
> >
> > Erik Engbrecht wrote:
> > >
> >
> http://lampsvn.epfl.ch/trac/scala/browser/scala/trunk/src/library/scala/...
> > >
> > >
> > > Look at the bottom of the file.
> > >
> > > On Sat, Nov 21, 2009 at 12:26 AM, Tony Morris
> >
> >
> > >
> >>> wrote:
> > >
> > > Stepan Koltsov wrote:
> > > > You probably missed parts of the discussion where
> > explained how
> > > Option
> > > > changes NullPointerException to NoSuchElementException.
> > > >
> > > Except it doesn't.
> > >
> > > --
> > > Tony Morris
> > > http://tmorris.net/
> > >
> > >
> > >
> > >
> > >
> > > --
> > > http://erikengbrecht.blogspot.com/
> >
> > --
> > Tony Morris
> > http://tmorris.net/
> >
> >
> >
> >
> >
> > --
> > http://erikengbrecht.blogspot.com/
>
> --
> Tony Morris
> http://tmorris.net/
>
>
>
>
>

Sat, 2009-11-21, 13:17

#9

Erik Engbrecht

Joined: 2008-12-19,

Re: Cost of Option / Some vs null

Ahhh... Then we agree. Cheers.
On Sat, Nov 21, 2009 at 7:05 AM, Tony Morris <tonymorris@gmail.com> wrote:

May I generalise your statement? forall X. forall Y. Using X provides no
extra protection against non-termination over using Y.

That's what I meant in my previous response. There is nothing
particularly interesting with respect to Option and null.

Erik Engbrecht wrote:
> Ok, let me reprhase...
>
> When used in the way I pointed out below, using Option provides no
> extra protection against non-termination over using null.
>
> On Sat, Nov 21, 2009 at 7:00 AM, Tony Morris <tonymorris@gmail.com
> <mailto:tonymorris@gmail.com>> wrote:
>
> That's merely saying that some programs fail to terminate. Option did
> "change NullPointerException to NoSuchElementException" any more
> than it
> changed IOException to NoSuchElementException.
>
> Erik Engbrecht wrote:
> > Someone naively using references that may be null might write:
> > val x = 5 + foo.integerValue // may throw NPE because foo may
> be null
> >
> > Using option, the same person might write:
> > val x = 5 + foo.get().integerValue // may throw
> > NoSuchElementException because foo may be None
> >
> > On Sat, Nov 21, 2009 at 6:52 AM, Tony Morris
> <tonymorris@gmail.com <mailto:tonymorris@gmail.com>
> > <mailto:tonymorris@gmail.com <mailto:tonymorris@gmail.com>>> wrote:
> >
> > What am I looking for exactly? I see no evidence for "Option
> changes
> > NullPointerException to NoSuchElementException." Is it there?
> >
> > Erik Engbrecht wrote:
> > >
> >
> http://lampsvn.epfl.ch/trac/scala/browser/scala/trunk/src/library/scala/Option.scala
> > >
> > >
> > > Look at the bottom of the file.
> > >
> > > On Sat, Nov 21, 2009 at 12:26 AM, Tony Morris
> > <tonymorris@gmail.com <mailto:tonymorris@gmail.com>
> <mailto:tonymorris@gmail.com <mailto:tonymorris@gmail.com>>
> > > <mailto:tonymorris@gmail.com <mailto:tonymorris@gmail.com>
> <mailto:tonymorris@gmail.com <mailto:tonymorris@gmail.com>>>> wrote:
> > >
> > > Stepan Koltsov wrote:
> > > > You probably missed parts of the discussion where
> > explained how
> > > Option
> > > > changes NullPointerException to NoSuchElementException.
> > > >
> > > Except it doesn't.
> > >
> > > --
> > > Tony Morris
> > > http://tmorris.net/
> > >
> > >
> > >
> > >
> > >
> > > --
> > > http://erikengbrecht.blogspot.com/
> >
> > --
> > Tony Morris
> > http://tmorris.net/
> >
> >
> >
> >
> >
> > --
> > http://erikengbrecht.blogspot.com/
>
> --
> Tony Morris
> http://tmorris.net/
>
>
>
>
>
> --
> http://erikengbrecht.blogspot.com/

--
Tony Morris
http://tmorris.net/

--
http://erikengbrecht.blogspot.com/

Sat, 2009-11-21, 13:27

#10

Ishaaq Chandy

Joined: 2009-02-16,

Re: Cost of Option / Some vs null

Other than, (hopefully), the client programmer would stop to think:

"Hmm, why do I have to do this silly foo.get()? What is this Option thing that foo refrences? - aha, it can be one of two things Some or None - perhaps I should read up and find out what they mean..."

It is not guaranteed that every programmer will have a similar train of though, however it is less likely that foo being equal to null instead of an Option will kick off a similar train of thought.

Ishaaq

2009/11/21 Erik Engbrecht <erik.engbrecht@gmail.com>

Ok, let me reprhase...
When used in the way I pointed out below, using Option provides no extra protection against non-termination over using null.

On Sat, Nov 21, 2009 at 7:00 AM, Tony Morris <tonymorris@gmail.com> wrote:

That's merely saying that some programs fail to terminate. Option did
"change NullPointerException to NoSuchElementException" any more than it
changed IOException to NoSuchElementException.

Erik Engbrecht wrote:
> Someone naively using references that may be null might write:
> val x = 5 + foo.integerValue // may throw NPE because foo may be null
>
> Using option, the same person might write:
> val x = 5 + foo.get().integerValue // may throw
> NoSuchElementException because foo may be None
>
> On Sat, Nov 21, 2009 at 6:52 AM, Tony Morris <tonymorris@gmail.com
> <mailto:tonymorris@gmail.com>> wrote:
>
> What am I looking for exactly? I see no evidence for "Option changes
> NullPointerException to NoSuchElementException." Is it there?
>
> Erik Engbrecht wrote:
> >
> http://lampsvn.epfl.ch/trac/scala/browser/scala/trunk/src/library/scala/Option.scala
> >
> >
> > Look at the bottom of the file.
> >
> > On Sat, Nov 21, 2009 at 12:26 AM, Tony Morris
> <tonymorris@gmail.com <mailto:tonymorris@gmail.com>
> > <mailto:tonymorris@gmail.com <mailto:tonymorris@gmail.com>>> wrote:
> >
> > Stepan Koltsov wrote:
> > > You probably missed parts of the discussion where
> explained how
> > Option
> > > changes NullPointerException to NoSuchElementException.
> > >
> > Except it doesn't.
> >
> > --
> > Tony Morris
> > http://tmorris.net/
> >
> >
> >
> >
> >
> > --
> > http://erikengbrecht.blogspot.com/
>
> --
> Tony Morris
> http://tmorris.net/
>
>
>
>
>
> --
> http://erikengbrecht.blogspot.com/

--
Tony Morris
http://tmorris.net/

--
http://erikengbrecht.blogspot.com/

Sat, 2009-11-21, 13:27

#11

Johannes Rudolph

Joined: 2008-12-17,

Re: Cost of Option / Some vs null

On Sat, Nov 21, 2009 at 1:00 PM, Philip Köster wrote:
> All of this reassures me that nullness or nonnullness should be part of a
> function contract and so detected at compile time, not at runtime.

That's what Option is about actually. It makes it explicit if a
function can return the missing value None. You may now ask why this
is not possible with null itself instead of Option. First, the
checking/annotation for NotNull values at compile-time is just not
done. Second, with Option the concept of returning nothing or one
result is abstracted and embedded into the concept of sequences and so
it gets you a whole new bunch of functionality from that area for
free.

>
> Erik Engbrecht schrieb:
>>
>> Someone naively using references that may be null might write:
>> val x = 5 + foo.integerValue // may throw NPE because foo may be null
>>
>> Using option, the same person might write:
>> val x = 5 + foo.get().integerValue // may throw NoSuchElementException
>> because foo may be None
>>
>> On Sat, Nov 21, 2009 at 6:52 AM, Tony Morris > > wrote:
>>
>> What am I looking for exactly? I see no evidence for "Option changes
>> NullPointerException to NoSuchElementException." Is it there?
>>
>> Erik Engbrecht wrote:
>> >
>>
>> http://lampsvn.epfl.ch/trac/scala/browser/scala/trunk/src/library/scala/Option.scala
>> >
>> >
>> > Look at the bottom of the file.
>> >
>> > On Sat, Nov 21, 2009 at 12:26 AM, Tony Morris
>>
>> > >> wrote:
>> >
>> > Stepan Koltsov wrote:
>> > > You probably missed parts of the discussion where explained
>> how
>> > Option
>> > > changes NullPointerException to NoSuchElementException.
>> > >
>> > Except it doesn't.
>> >
>> > --
>> > Tony Morris
>> > http://tmorris.net/
>> >
>> >
>> >
>> >
>> >
>> > --
>> > http://erikengbrecht.blogspot.com/
>>
>> --
>> Tony Morris
>> http://tmorris.net/
>>
>>
>>
>>
>>
>> --
>> http://erikengbrecht.blogspot.com/
>

Sat, 2009-11-21, 13:37

#12

Erik Engbrecht

Joined: 2008-12-19,

Re: Cost of Option / Some vs null

Ok, let me reprhase...
When used in the way I pointed out below, using Option provides no extra protection against non-termination over using null.

On Sat, Nov 21, 2009 at 7:00 AM, Tony Morris <tonymorris@gmail.com> wrote:

That's merely saying that some programs fail to terminate. Option did
"change NullPointerException to NoSuchElementException" any more than it
changed IOException to NoSuchElementException.

Erik Engbrecht wrote:
> Someone naively using references that may be null might write:
> val x = 5 + foo.integerValue // may throw NPE because foo may be null
>
> Using option, the same person might write:
> val x = 5 + foo.get().integerValue // may throw
> NoSuchElementException because foo may be None
>
> On Sat, Nov 21, 2009 at 6:52 AM, Tony Morris <tonymorris@gmail.com
> <mailto:tonymorris@gmail.com>> wrote:
>
> What am I looking for exactly? I see no evidence for "Option changes
> NullPointerException to NoSuchElementException." Is it there?
>
> Erik Engbrecht wrote:
> >
> http://lampsvn.epfl.ch/trac/scala/browser/scala/trunk/src/library/scala/Option.scala
> >
> >
> > Look at the bottom of the file.
> >
> > On Sat, Nov 21, 2009 at 12:26 AM, Tony Morris
> <tonymorris@gmail.com <mailto:tonymorris@gmail.com>
> > <mailto:tonymorris@gmail.com <mailto:tonymorris@gmail.com>>> wrote:
> >
> > Stepan Koltsov wrote:
> > > You probably missed parts of the discussion where
> explained how
> > Option
> > > changes NullPointerException to NoSuchElementException.
> > >
> > Except it doesn't.
> >
> > --
> > Tony Morris
> > http://tmorris.net/
> >
> >
> >
> >
> >
> > --
> > http://erikengbrecht.blogspot.com/
>
> --
> Tony Morris
> http://tmorris.net/
>
>
>
>
>
> --
> http://erikengbrecht.blogspot.com/

--
Tony Morris
http://tmorris.net/

--
http://erikengbrecht.blogspot.com/

Sat, 2009-11-21, 13:37

#13

Tony Morris 2

Joined: 2009-03-20,

Re: Cost of Option / Some vs null

I thought I gave some code earlier that demonstrated that Option is not
necessarily "one of two things Some or None." It is the *shape* if the
structure that is of importance here and importantly, the functions that
can derive from that shape. (i.e. Option is a covariant functor, etc.)

forall A. Option[A] is exactly equal (isomorphic) to forall X. (A => X)
=> (=> X) => X
This is called the catamorphism for Option, or (cover your eyes if you
have an aversion to thinking), the church encoding for Option.

Yes, I am hoping to twist all your minds, to prepare you for the next
enlightenment :)

Ishaaq Chandy wrote:
> Other than, (hopefully), the client programmer would stop to think:
>
> "Hmm, why do I have to do this silly foo.get()? What is this Option
> thing that foo refrences? - aha, it can be one of two things Some or
> None - perhaps I should read up and find out what they mean..."
>
> It is not guaranteed that every programmer will have a similar train
> of though, however it is less likely that foo being equal to null
> instead of an Option will kick off a similar train of thought.
>
> Ishaaq
>
> 2009/11/21 Erik Engbrecht >
>
> Ok, let me reprhase...
>
> When used in the way I pointed out below, using Option provides no
> extra protection against non-termination over using null.
>
>
> On Sat, Nov 21, 2009 at 7:00 AM, Tony Morris > wrote:
>
> That's merely saying that some programs fail to terminate.
> Option did
> "change NullPointerException to NoSuchElementException" any
> more than it
> changed IOException to NoSuchElementException.
>
> Erik Engbrecht wrote:
> > Someone naively using references that may be null might write:
> > val x = 5 + foo.integerValue // may throw NPE because foo
> may be null
> >
> > Using option, the same person might write:
> > val x = 5 + foo.get().integerValue // may throw
> > NoSuchElementException because foo may be None
> >
> > On Sat, Nov 21, 2009 at 6:52 AM, Tony Morris
>
> > >>
> wrote:
> >
> > What am I looking for exactly? I see no evidence for
> "Option changes
> > NullPointerException to NoSuchElementException." Is it
> there?
> >
> > Erik Engbrecht wrote:
> > >
> >
> http://lampsvn.epfl.ch/trac/scala/browser/scala/trunk/src/library/scala/...
> > >
> > >
> > > Look at the bottom of the file.
> > >
> > > On Sat, Nov 21, 2009 at 12:26 AM, Tony Morris
> >
> >
> > > >>> wrote:
> > >
> > > Stepan Koltsov wrote:
> > > > You probably missed parts of the discussion where
> > explained how
> > > Option
> > > > changes NullPointerException to
> NoSuchElementException.
> > > >
> > > Except it doesn't.
> > >
> > > --
> > > Tony Morris
> > > http://tmorris.net/
> > >
> > >
> > >
> > >
> > >
> > > --
> > > http://erikengbrecht.blogspot.com/
> >
> > --
> > Tony Morris
> > http://tmorris.net/
> >
> >
> >
> >
> >
> > --
> > http://erikengbrecht.blogspot.com/
>
> --
> Tony Morris
> http://tmorris.net/
>
>
>
>
>
> --
> http://erikengbrecht.blogspot.com/
>
>

Sat, 2009-11-21, 13:37

#14

Tony Morris 2

Joined: 2009-03-20,

Re: Cost of Option / Some vs null

A good exercise is to write the Option API yourself. I've done map and
flatMap, what about the others?

I absolutely promise you that any method you can write for scala.Option
you can also write for Optionn and vice versa. getOrElse, get that fails
for "None", etc.

Let me know if you get stuck.

Ishaaq Chandy wrote:
> Yes, I was meaning to ask you about that, I'm afraid I did not
> understand it - I have no aversion to learning - I just did not
> understand it.
>
> And yes, before you get stuck into me :) - I did read it, I did
> compile it.... and then I got stuck, I have no idea how one might use
> your Optionn[+A] trait and how it could be used to replace scala.Option.
>
> awaiting enlightenment....
>
> 2009/11/21 Tony Morris >
>
> I thought I gave some code earlier that demonstrated that Option
> is not
> necessarily "one of two things Some or None." It is the *shape*
> if the
> structure that is of importance here and importantly, the
> functions that
> can derive from that shape. (i.e. Option is a covariant functor, etc.)
>
> forall A. Option[A] is exactly equal (isomorphic) to forall X. (A
> => X)
> => (=> X) => X
> This is called the catamorphism for Option, or (cover your eyes if you
> have an aversion to thinking), the church encoding for Option.
>
> Yes, I am hoping to twist all your minds, to prepare you for the next
> enlightenment :)
>
> Ishaaq Chandy wrote:
> > Other than, (hopefully), the client programmer would stop to think:
> >
> > "Hmm, why do I have to do this silly foo.get()? What is this Option
> > thing that foo refrences? - aha, it can be one of two things Some or
> > None - perhaps I should read up and find out what they mean..."
> >
> > It is not guaranteed that every programmer will have a similar train
> > of though, however it is less likely that foo being equal to null
> > instead of an Option will kick off a similar train of thought.
> >
> > Ishaaq
> >
> > 2009/11/21 Erik Engbrecht
> > >>
> >
> > Ok, let me reprhase...
> >
> > When used in the way I pointed out below, using Option
> provides no
> > extra protection against non-termination over using null.
> >
> >
> > On Sat, Nov 21, 2009 at 7:00 AM, Tony Morris
>
> > >>
> wrote:
> >
> > That's merely saying that some programs fail to terminate.
> > Option did
> > "change NullPointerException to NoSuchElementException" any
> > more than it
> > changed IOException to NoSuchElementException.
> >
> > Erik Engbrecht wrote:
> > > Someone naively using references that may be null
> might write:
> > > val x = 5 + foo.integerValue // may throw NPE
> because foo
> > may be null
> > >
> > > Using option, the same person might write:
> > > val x = 5 + foo.get().integerValue // may throw
> > > NoSuchElementException because foo may be None
> > >
> > > On Sat, Nov 21, 2009 at 6:52 AM, Tony Morris
> >
> >
> > > >>>
> > wrote:
> > >
> > > What am I looking for exactly? I see no evidence for
> > "Option changes
> > > NullPointerException to NoSuchElementException." Is it
> > there?
> > >
> > > Erik Engbrecht wrote:
> > > >
> > >
> >
> http://lampsvn.epfl.ch/trac/scala/browser/scala/trunk/src/library/scala/...
> > > >
> > > >
> > > > Look at the bottom of the file.
> > > >
> > > > On Sat, Nov 21, 2009 at 12:26 AM, Tony Morris
> > > >
> > >>
> > > >
> > >
> > >>>> wrote:
> > > >
> > > > Stepan Koltsov wrote:
> > > > > You probably missed parts of the
> discussion where
> > > explained how
> > > > Option
> > > > > changes NullPointerException to
> > NoSuchElementException.
> > > > >
> > > > Except it doesn't.
> > > >
> > > > --
> > > > Tony Morris
> > > > http://tmorris.net/
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > http://erikengbrecht.blogspot.com/
> > >
> > > --
> > > Tony Morris
> > > http://tmorris.net/
> > >
> > >
> > >
> > >
> > >
> > > --
> > > http://erikengbrecht.blogspot.com/
> >
> > --
> > Tony Morris
> > http://tmorris.net/
> >
> >
> >
> >
> >
> > --
> > http://erikengbrecht.blogspot.com/
> >
> >
>
> --
> Tony Morris
> http://tmorris.net/
>
>
>

Sat, 2009-11-21, 13:37

#15

Tony Morris 2

Joined: 2009-03-20,

Re: Cost of Option / Some vs null

Here's a giggle. Write this method on Optionn[A]:

Optionn[A => B] => Optionn[B]
Use flatMap.

Now do the same for List (but as an object method or your own List (PS:
what's the cata for List?)).
List[A] => List[A => B] => List[B]
Also use flatMap.

Now try Function1[T, _] if you're game.
Function1[T, A] => Function1[T, A => B] => Function1[T, B]
Use... bugger, no flatMap, let's write it!
Function1[T, A] => Function1[T, A => Function1[T, B]] => Function1[T, B]

Sorry, getting carried away. Learning is fun. I'm off to bed.

Tony Morris wrote:
> A good exercise is to write the Option API yourself. I've done map and
> flatMap, what about the others?
>
> I absolutely promise you that any method you can write for scala.Option
> you can also write for Optionn and vice versa. getOrElse, get that fails
> for "None", etc.
>
> Let me know if you get stuck.
>
> Ishaaq Chandy wrote:
>
>> Yes, I was meaning to ask you about that, I'm afraid I did not
>> understand it - I have no aversion to learning - I just did not
>> understand it.
>>
>> And yes, before you get stuck into me :) - I did read it, I did
>> compile it.... and then I got stuck, I have no idea how one might use
>> your Optionn[+A] trait and how it could be used to replace scala.Option.
>>
>> awaiting enlightenment....
>>
>> 2009/11/21 Tony Morris > >
>>
>> I thought I gave some code earlier that demonstrated that Option
>> is not
>> necessarily "one of two things Some or None." It is the *shape*
>> if the
>> structure that is of importance here and importantly, the
>> functions that
>> can derive from that shape. (i.e. Option is a covariant functor, etc.)
>>
>> forall A. Option[A] is exactly equal (isomorphic) to forall X. (A
>> => X)
>> => (=> X) => X
>> This is called the catamorphism for Option, or (cover your eyes if you
>> have an aversion to thinking), the church encoding for Option.
>>
>> Yes, I am hoping to twist all your minds, to prepare you for the next
>> enlightenment :)
>>
>> Ishaaq Chandy wrote:
>> > Other than, (hopefully), the client programmer would stop to think:
>> >
>> > "Hmm, why do I have to do this silly foo.get()? What is this Option
>> > thing that foo refrences? - aha, it can be one of two things Some or
>> > None - perhaps I should read up and find out what they mean..."
>> >
>> > It is not guaranteed that every programmer will have a similar train
>> > of though, however it is less likely that foo being equal to null
>> > instead of an Option will kick off a similar train of thought.
>> >
>> > Ishaaq
>> >
>> > 2009/11/21 Erik Engbrecht >
>> > >>
>> >
>> > Ok, let me reprhase...
>> >
>> > When used in the way I pointed out below, using Option
>> provides no
>> > extra protection against non-termination over using null.
>> >
>> >
>> > On Sat, Nov 21, 2009 at 7:00 AM, Tony Morris
>>
>> > >>
>> wrote:
>> >
>> > That's merely saying that some programs fail to terminate.
>> > Option did
>> > "change NullPointerException to NoSuchElementException" any
>> > more than it
>> > changed IOException to NoSuchElementException.
>> >
>> > Erik Engbrecht wrote:
>> > > Someone naively using references that may be null
>> might write:
>> > > val x = 5 + foo.integerValue // may throw NPE
>> because foo
>> > may be null
>> > >
>> > > Using option, the same person might write:
>> > > val x = 5 + foo.get().integerValue // may throw
>> > > NoSuchElementException because foo may be None
>> > >
>> > > On Sat, Nov 21, 2009 at 6:52 AM, Tony Morris
>> >
>> >
>> > > > > >>>
>> > wrote:
>> > >
>> > > What am I looking for exactly? I see no evidence for
>> > "Option changes
>> > > NullPointerException to NoSuchElementException." Is it
>> > there?
>> > >
>> > > Erik Engbrecht wrote:
>> > > >
>> > >
>> >
>> http://lampsvn.epfl.ch/trac/scala/browser/scala/trunk/src/library/scala/...
>> > > >
>> > > >
>> > > > Look at the bottom of the file.
>> > > >
>> > > > On Sat, Nov 21, 2009 at 12:26 AM, Tony Morris
>> > > > > >
>> > > > >>
>> > > > >
>> > > > >
>> > > >>>> wrote:
>> > > >
>> > > > Stepan Koltsov wrote:
>> > > > > You probably missed parts of the
>> discussion where
>> > > explained how
>> > > > Option
>> > > > > changes NullPointerException to
>> > NoSuchElementException.
>> > > > >
>> > > > Except it doesn't.
>> > > >
>> > > > --
>> > > > Tony Morris
>> > > > http://tmorris.net/
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > --
>> > > > http://erikengbrecht.blogspot.com/
>> > >
>> > > --
>> > > Tony Morris
>> > > http://tmorris.net/
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > --
>> > > http://erikengbrecht.blogspot.com/
>> >
>> > --
>> > Tony Morris
>> > http://tmorris.net/
>> >
>> >
>> >
>> >
>> >
>> > --
>> > http://erikengbrecht.blogspot.com/
>> >
>> >
>>
>> --
>> Tony Morris
>> http://tmorris.net/
>>
>>
>>
>>
>
>

Sat, 2009-11-21, 13:47

#16

Erik Engbrecht

Joined: 2008-12-19,

Re: Cost of Option / Some vs null

Yes, that's why I said that the way null is used is semantically ambiguous. Option provides more information about the intent, but no real enforcement because there are other possible situations: val x = 5 + foo.get().integerValue // throws NPE because foo is null
or the more devious:val x = foo match { case Some(y) => 5 + y.integerValue // throws NPE because y is null, e.g. we have Some(null) case None => 5 // treat None as 0 }
I'm not trying to say Option isn't useful. It is and I use it a lot. But it's not a silver bullet...or maybe I should say a nerf bullet for those determined to shoot themselves in the foot. I think a lot of arguments in favor of it exaggerate the protections it provides.
On Sat, Nov 21, 2009 at 7:14 AM, Ishaaq Chandy <ishaaq@gmail.com> wrote:

Other than, (hopefully), the client programmer would stop to think:

"Hmm, why do I have to do this silly foo.get()? What is this Option thing that foo refrences? - aha, it can be one of two things Some or None - perhaps I should read up and find out what they mean..."

It is not guaranteed that every programmer will have a similar train of though, however it is less likely that foo being equal to null instead of an Option will kick off a similar train of thought.

Ishaaq

2009/11/21 Erik Engbrecht <erik.engbrecht@gmail.com>
Ok, let me reprhase...
When used in the way I pointed out below, using Option provides no extra protection against non-termination over using null.

On Sat, Nov 21, 2009 at 7:00 AM, Tony Morris <tonymorris@gmail.com> wrote:

That's merely saying that some programs fail to terminate. Option did
"change NullPointerException to NoSuchElementException" any more than it
changed IOException to NoSuchElementException.

Erik Engbrecht wrote:
> Someone naively using references that may be null might write:
> val x = 5 + foo.integerValue // may throw NPE because foo may be null
>
> Using option, the same person might write:
> val x = 5 + foo.get().integerValue // may throw
> NoSuchElementException because foo may be None
>
> On Sat, Nov 21, 2009 at 6:52 AM, Tony Morris <tonymorris@gmail.com
> <mailto:tonymorris@gmail.com>> wrote:
>
> What am I looking for exactly? I see no evidence for "Option changes
> NullPointerException to NoSuchElementException." Is it there?
>
> Erik Engbrecht wrote:
> >
> http://lampsvn.epfl.ch/trac/scala/browser/scala/trunk/src/library/scala/Option.scala
> >
> >
> > Look at the bottom of the file.
> >
> > On Sat, Nov 21, 2009 at 12:26 AM, Tony Morris
> <tonymorris@gmail.com <mailto:tonymorris@gmail.com>
> > <mailto:tonymorris@gmail.com <mailto:tonymorris@gmail.com>>> wrote:
> >
> > Stepan Koltsov wrote:
> > > You probably missed parts of the discussion where
> explained how
> > Option
> > > changes NullPointerException to NoSuchElementException.
> > >
> > Except it doesn't.
> >
> > --
> > Tony Morris
> > http://tmorris.net/
> >
> >
> >
> >
> >
> > --
> > http://erikengbrecht.blogspot.com/
>
> --
> Tony Morris
> http://tmorris.net/
>
>
>
>
>
> --
> http://erikengbrecht.blogspot.com/

--
Tony Morris
http://tmorris.net/

--
http://erikengbrecht.blogspot.com/

--
http://erikengbrecht.blogspot.com/

Sat, 2009-11-21, 13:57

#17

Ishaaq Chandy

Joined: 2009-02-16,

Re: Cost of Option / Some vs null

Yes, I was meaning to ask you about that, I'm afraid I did not understand it - I have no aversion to learning - I just did not understand it.

And yes, before you get stuck into me :) - I did read it, I did compile it.... and then I got stuck, I have no idea how one might use your Optionn[+A] trait and how it could be used to replace scala.Option.

awaiting enlightenment....

2009/11/21 Tony Morris <tonymorris@gmail.com>

I thought I gave some code earlier that demonstrated that Option is not
necessarily "one of two things Some or None." It is the *shape* if the
structure that is of importance here and importantly, the functions that
can derive from that shape. (i.e. Option is a covariant functor, etc.)

forall A. Option[A] is exactly equal (isomorphic) to forall X. (A => X)
=> (=> X) => X
This is called the catamorphism for Option, or (cover your eyes if you
have an aversion to thinking), the church encoding for Option.

Yes, I am hoping to twist all your minds, to prepare you for the next
enlightenment :)

Ishaaq Chandy wrote:
> Other than, (hopefully), the client programmer would stop to think:
>
> "Hmm, why do I have to do this silly foo.get()? What is this Option
> thing that foo refrences? - aha, it can be one of two things Some or
> None - perhaps I should read up and find out what they mean..."
>
> It is not guaranteed that every programmer will have a similar train
> of though, however it is less likely that foo being equal to null
> instead of an Option will kick off a similar train of thought.
>
> Ishaaq
>
> 2009/11/21 Erik Engbrecht <erik.engbrecht@gmail.com
> <mailto:erik.engbrecht@gmail.com>>
>
> Ok, let me reprhase...
>
> When used in the way I pointed out below, using Option provides no
> extra protection against non-termination over using null.
>
>
> On Sat, Nov 21, 2009 at 7:00 AM, Tony Morris <tonymorris@gmail.com
> <mailto:tonymorris@gmail.com>> wrote:
>
> That's merely saying that some programs fail to terminate.
> Option did
> "change NullPointerException to NoSuchElementException" any
> more than it
> changed IOException to NoSuchElementException.
>
> Erik Engbrecht wrote:
> > Someone naively using references that may be null might write:
> > val x = 5 + foo.integerValue // may throw NPE because foo
> may be null
> >
> > Using option, the same person might write:
> > val x = 5 + foo.get().integerValue // may throw
> > NoSuchElementException because foo may be None
> >
> > On Sat, Nov 21, 2009 at 6:52 AM, Tony Morris
> <tonymorris@gmail.com <mailto:tonymorris@gmail.com>
> > <mailto:tonymorris@gmail.com <mailto:tonymorris@gmail.com>>>
> wrote:
> >
> > What am I looking for exactly? I see no evidence for
> "Option changes
> > NullPointerException to NoSuchElementException." Is it
> there?
> >
> > Erik Engbrecht wrote:
> > >
> >
> http://lampsvn.epfl.ch/trac/scala/browser/scala/trunk/src/library/scala/Option.scala
> > >
> > >
> > > Look at the bottom of the file.
> > >
> > > On Sat, Nov 21, 2009 at 12:26 AM, Tony Morris
> > <tonymorris@gmail.com <mailto:tonymorris@gmail.com>
> <mailto:tonymorris@gmail.com <mailto:tonymorris@gmail.com>>
> > > <mailto:tonymorris@gmail.com
> <mailto:tonymorris@gmail.com> <mailto:tonymorris@gmail.com
> <mailto:tonymorris@gmail.com>>>> wrote:
> > >
> > > Stepan Koltsov wrote:
> > > > You probably missed parts of the discussion where
> > explained how
> > > Option
> > > > changes NullPointerException to
> NoSuchElementException.
> > > >
> > > Except it doesn't.
> > >
> > > --
> > > Tony Morris
> > > http://tmorris.net/
> > >
> > >
> > >
> > >
> > >
> > > --
> > > http://erikengbrecht.blogspot.com/
> >
> > --
> > Tony Morris
> > http://tmorris.net/
> >
> >
> >
> >
> >
> > --
> > http://erikengbrecht.blogspot.com/
>
> --
> Tony Morris
> http://tmorris.net/
>
>
>
>
>
> --
> http://erikengbrecht.blogspot.com/
>
>

--
Tony Morris
http://tmorris.net/

Sat, 2009-11-21, 14:07

#18

Ishaaq Chandy

Joined: 2009-02-16,

Re: Cost of Option / Some vs null

Then we are in agreement - I put a caveat in my statement deliberately - it is not guaranteed that a programmer will always do the right thing given an Option reference as opposed to a reference that could possibly be null, but it is less likely - programmer stupidity is always a possibility (and I reserve the right to resort to it in the future - as I have done multiple times in the past).

2009/11/21 Erik Engbrecht <erik.engbrecht@gmail.com>

Yes, that's why I said that the way null is used is semantically ambiguous. Option provides more information about the intent, but no real enforcement because there are other possible situations: val x = 5 + foo.get().integerValue // throws NPE because foo is null
or the more devious:val x = foo match { case Some(y) => 5 + y.integerValue // throws NPE because y is null, e.g. we have Some(null) case None => 5 // treat None as 0 }
I'm not trying to say Option isn't useful. It is and I use it a lot. But it's not a silver bullet...or maybe I should say a nerf bullet for those determined to shoot themselves in the foot. I think a lot of arguments in favor of it exaggerate the protections it provides.
On Sat, Nov 21, 2009 at 7:14 AM, Ishaaq Chandy <ishaaq@gmail.com> wrote:

Other than, (hopefully), the client programmer would stop to think:

"Hmm, why do I have to do this silly foo.get()? What is this Option thing that foo refrences? - aha, it can be one of two things Some or None - perhaps I should read up and find out what they mean..."

It is not guaranteed that every programmer will have a similar train of though, however it is less likely that foo being equal to null instead of an Option will kick off a similar train of thought.

Ishaaq

2009/11/21 Erik Engbrecht <erik.engbrecht@gmail.com>
Ok, let me reprhase...
When used in the way I pointed out below, using Option provides no extra protection against non-termination over using null.

On Sat, Nov 21, 2009 at 7:00 AM, Tony Morris <tonymorris@gmail.com> wrote:

That's merely saying that some programs fail to terminate. Option did
"change NullPointerException to NoSuchElementException" any more than it
changed IOException to NoSuchElementException.

Erik Engbrecht wrote:
> Someone naively using references that may be null might write:
> val x = 5 + foo.integerValue // may throw NPE because foo may be null
>
> Using option, the same person might write:
> val x = 5 + foo.get().integerValue // may throw
> NoSuchElementException because foo may be None
>
> On Sat, Nov 21, 2009 at 6:52 AM, Tony Morris <tonymorris@gmail.com
> <mailto:tonymorris@gmail.com>> wrote:
>
> What am I looking for exactly? I see no evidence for "Option changes
> NullPointerException to NoSuchElementException." Is it there?
>
> Erik Engbrecht wrote:
> >
> http://lampsvn.epfl.ch/trac/scala/browser/scala/trunk/src/library/scala/Option.scala
> >
> >
> > Look at the bottom of the file.
> >
> > On Sat, Nov 21, 2009 at 12:26 AM, Tony Morris
> <tonymorris@gmail.com <mailto:tonymorris@gmail.com>
> > <mailto:tonymorris@gmail.com <mailto:tonymorris@gmail.com>>> wrote:
> >
> > Stepan Koltsov wrote:
> > > You probably missed parts of the discussion where
> explained how
> > Option
> > > changes NullPointerException to NoSuchElementException.
> > >
> > Except it doesn't.
> >
> > --
> > Tony Morris
> > http://tmorris.net/
> >
> >
> >
> >
> >
> > --
> > http://erikengbrecht.blogspot.com/
>
> --
> Tony Morris
> http://tmorris.net/
>
>
>
>
>
> --
> http://erikengbrecht.blogspot.com/

--
Tony Morris
http://tmorris.net/

--
http://erikengbrecht.blogspot.com/

--
http://erikengbrecht.blogspot.com/

Sat, 2009-11-21, 14:17

#19

Ishaaq Chandy

Joined: 2009-02-16,

Re: Cost of Option / Some vs null

I don't disbelieve you, however the stumbling point for me is not about how to rewrite the Option API
- no, I just don't know how one would actually use Optionn.

Would you expect to extend the trait for any class that needs to potray non-existance? If so, how does one implement:

def cata[X](ding: A => X, dong: => X): X

In short, how could Optionn be used to do the equivalent of this:

val maybe: Option[String] = someFuncReturningOptionString()
maybe match {
case None => doSomethingForNone()
case Some(string) => doSomethingWithString(string)
}

I ask, not because I don't believe it can't, its just that I don't understand how - probably my failing not yours.

Ishaaq

2009/11/21 Tony Morris <tonymorris@gmail.com>

A good exercise is to write the Option API yourself. I've done map and
flatMap, what about the others?

I absolutely promise you that any method you can write for scala.Option
you can also write for Optionn and vice versa. getOrElse, get that fails
for "None", etc.

Let me know if you get stuck.

Ishaaq Chandy wrote:
> Yes, I was meaning to ask you about that, I'm afraid I did not
> understand it - I have no aversion to learning - I just did not
> understand it.
>
> And yes, before you get stuck into me :) - I did read it, I did
> compile it.... and then I got stuck, I have no idea how one might use
> your Optionn[+A] trait and how it could be used to replace scala.Option.
>
> awaiting enlightenment....
>
> 2009/11/21 Tony Morris <tonymorris@gmail.com
> <mailto:tonymorris@gmail.com>>
>
> I thought I gave some code earlier that demonstrated that Option
> is not
> necessarily "one of two things Some or None." It is the *shape*
> if the
> structure that is of importance here and importantly, the
> functions that
> can derive from that shape. (i.e. Option is a covariant functor, etc.)
>
> forall A. Option[A] is exactly equal (isomorphic) to forall X. (A
> => X)
> => (=> X) => X
> This is called the catamorphism for Option, or (cover your eyes if you
> have an aversion to thinking), the church encoding for Option.
>
> Yes, I am hoping to twist all your minds, to prepare you for the next
> enlightenment :)
>
> Ishaaq Chandy wrote:
> > Other than, (hopefully), the client programmer would stop to think:
> >
> > "Hmm, why do I have to do this silly foo.get()? What is this Option
> > thing that foo refrences? - aha, it can be one of two things Some or
> > None - perhaps I should read up and find out what they mean..."
> >
> > It is not guaranteed that every programmer will have a similar train
> > of though, however it is less likely that foo being equal to null
> > instead of an Option will kick off a similar train of thought.
> >
> > Ishaaq
> >
> > 2009/11/21 Erik Engbrecht <erik.engbrecht@gmail.com
> <mailto:erik.engbrecht@gmail.com>
> > <mailto:erik.engbrecht@gmail.com <mailto:erik.engbrecht@gmail.com>>>
> >
> > Ok, let me reprhase...
> >
> > When used in the way I pointed out below, using Option
> provides no
> > extra protection against non-termination over using null.
> >
> >
> > On Sat, Nov 21, 2009 at 7:00 AM, Tony Morris
> <tonymorris@gmail.com <mailto:tonymorris@gmail.com>
> > <mailto:tonymorris@gmail.com <mailto:tonymorris@gmail.com>>>
> wrote:
> >
> > That's merely saying that some programs fail to terminate.
> > Option did
> > "change NullPointerException to NoSuchElementException" any
> > more than it
> > changed IOException to NoSuchElementException.
> >
> > Erik Engbrecht wrote:
> > > Someone naively using references that may be null
> might write:
> > > val x = 5 + foo.integerValue // may throw NPE
> because foo
> > may be null
> > >
> > > Using option, the same person might write:
> > > val x = 5 + foo.get().integerValue // may throw
> > > NoSuchElementException because foo may be None
> > >
> > > On Sat, Nov 21, 2009 at 6:52 AM, Tony Morris
> > <tonymorris@gmail.com <mailto:tonymorris@gmail.com>
> <mailto:tonymorris@gmail.com <mailto:tonymorris@gmail.com>>
> > > <mailto:tonymorris@gmail.com
> <mailto:tonymorris@gmail.com> <mailto:tonymorris@gmail.com
> <mailto:tonymorris@gmail.com>>>>
> > wrote:
> > >
> > > What am I looking for exactly? I see no evidence for
> > "Option changes
> > > NullPointerException to NoSuchElementException." Is it
> > there?
> > >
> > > Erik Engbrecht wrote:
> > > >
> > >
> >
> http://lampsvn.epfl.ch/trac/scala/browser/scala/trunk/src/library/scala/Option.scala
> > > >
> > > >
> > > > Look at the bottom of the file.
> > > >
> > > > On Sat, Nov 21, 2009 at 12:26 AM, Tony Morris
> > > <tonymorris@gmail.com
> <mailto:tonymorris@gmail.com> <mailto:tonymorris@gmail.com
> <mailto:tonymorris@gmail.com>>
> > <mailto:tonymorris@gmail.com
> <mailto:tonymorris@gmail.com> <mailto:tonymorris@gmail.com
> <mailto:tonymorris@gmail.com>>>
> > > > <mailto:tonymorris@gmail.com
> <mailto:tonymorris@gmail.com>
> > <mailto:tonymorris@gmail.com
> <mailto:tonymorris@gmail.com>> <mailto:tonymorris@gmail.com
> <mailto:tonymorris@gmail.com>
> > <mailto:tonymorris@gmail.com
> <mailto:tonymorris@gmail.com>>>>> wrote:
> > > >
> > > > Stepan Koltsov wrote:
> > > > > You probably missed parts of the
> discussion where
> > > explained how
> > > > Option
> > > > > changes NullPointerException to
> > NoSuchElementException.
> > > > >
> > > > Except it doesn't.
> > > >
> > > > --
> > > > Tony Morris
> > > > http://tmorris.net/
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > http://erikengbrecht.blogspot.com/
> > >
> > > --
> > > Tony Morris
> > > http://tmorris.net/
> > >
> > >
> > >
> > >
> > >
> > > --
> > > http://erikengbrecht.blogspot.com/
> >
> > --
> > Tony Morris
> > http://tmorris.net/
> >
> >
> >
> >
> >
> > --
> > http://erikengbrecht.blogspot.com/
> >
> >
>
> --
> Tony Morris
> http://tmorris.net/
>
>
>

--
Tony Morris
http://tmorris.net/

Sat, 2009-11-21, 14:27

#20

Johannes Rudolph

Joined: 2008-12-17,

Re: Cost of Option / Some vs null

You use cata

someFuncReturningOptionString().cata(doSomethingWithString(_),
doSomethingForNone())

The implementation calls either the first or the second parameter
function and returns the result.

On Sat, Nov 21, 2009 at 2:15 PM, Ishaaq Chandy wrote:
> I don't disbelieve you, however the stumbling point for me is not about how
> to rewrite the Option API
> - no, I just don't know how one would actually use Optionn.
>
> Would you expect to extend the trait for any class that needs to potray
> non-existance? If so, how does one implement:
>
> def cata[X](ding: A => X, dong: => X): X
>
> In short, how could Optionn be used to do the equivalent of this:
>
> val maybe: Option[String] = someFuncReturningOptionString()
> maybe match {
> case None => doSomethingForNone()
> case Some(string) => doSomethingWithString(string)
> }
>
> I ask, not because I don't believe it can't, its just that I don't
> understand how - probably my failing not yours.
>
> Ishaaq
>
> 2009/11/21 Tony Morris
>>
>> A good exercise is to write the Option API yourself. I've done map and
>> flatMap, what about the others?
>>
>> I absolutely promise you that any method you can write for scala.Option
>> you can also write for Optionn and vice versa. getOrElse, get that fails
>> for "None", etc.
>>
>> Let me know if you get stuck.
>>
>> Ishaaq Chandy wrote:
>> > Yes, I was meaning to ask you about that, I'm afraid I did not
>> > understand it - I have no aversion to learning - I just did not
>> > understand it.
>> >
>> > And yes, before you get stuck into me :) - I did read it, I did
>> > compile it.... and then I got stuck, I have no idea how one might use
>> > your Optionn[+A] trait and how it could be used to replace
>> > scala.Option.
>> >
>> > awaiting enlightenment....
>> >
>> > 2009/11/21 Tony Morris > > >
>> >
>> > I thought I gave some code earlier that demonstrated that Option
>> > is not
>> > necessarily "one of two things Some or None." It is the *shape*
>> > if the
>> > structure that is of importance here and importantly, the
>> > functions that
>> > can derive from that shape. (i.e. Option is a covariant functor,
>> > etc.)
>> >
>> > forall A. Option[A] is exactly equal (isomorphic) to forall X. (A
>> > => X)
>> > => (=> X) => X
>> > This is called the catamorphism for Option, or (cover your eyes if
>> > you
>> > have an aversion to thinking), the church encoding for Option.
>> >
>> > Yes, I am hoping to twist all your minds, to prepare you for the
>> > next
>> > enlightenment :)
>> >
>> > Ishaaq Chandy wrote:
>> > > Other than, (hopefully), the client programmer would stop to
>> > think:
>> > >
>> > > "Hmm, why do I have to do this silly foo.get()? What is this
>> > Option
>> > > thing that foo refrences? - aha, it can be one of two things Some
>> > or
>> > > None - perhaps I should read up and find out what they mean..."
>> > >
>> > > It is not guaranteed that every programmer will have a similar
>> > train
>> > > of though, however it is less likely that foo being equal to null
>> > > instead of an Option will kick off a similar train of thought.
>> > >
>> > > Ishaaq
>> > >
>> > > 2009/11/21 Erik Engbrecht > >
>> > > > > >>
>> > >
>> > > Ok, let me reprhase...
>> > >
>> > > When used in the way I pointed out below, using Option
>> > provides no
>> > > extra protection against non-termination over using null.
>> > >
>> > >
>> > > On Sat, Nov 21, 2009 at 7:00 AM, Tony Morris
>> >
>> > > >>
>> > wrote:
>> > >
>> > > That's merely saying that some programs fail to terminate.
>> > > Option did
>> > > "change NullPointerException to NoSuchElementException"
>> > any
>> > > more than it
>> > > changed IOException to NoSuchElementException.
>> > >
>> > > Erik Engbrecht wrote:
>> > > > Someone naively using references that may be null
>> > might write:
>> > > > val x = 5 + foo.integerValue // may throw NPE
>> > because foo
>> > > may be null
>> > > >
>> > > > Using option, the same person might write:
>> > > > val x = 5 + foo.get().integerValue // may throw
>> > > > NoSuchElementException because foo may be None
>> > > >
>> > > > On Sat, Nov 21, 2009 at 6:52 AM, Tony Morris
>> > >
>> > >
>> > > > > > > > >>>
>> > > wrote:
>> > > >
>> > > > What am I looking for exactly? I see no evidence for
>> > > "Option changes
>> > > > NullPointerException to NoSuchElementException." Is
>> > it
>> > > there?
>> > > >
>> > > > Erik Engbrecht wrote:
>> > > > >
>> > > >
>> > >
>> >
>> > http://lampsvn.epfl.ch/trac/scala/browser/scala/trunk/src/library/scala/...
>> > > > >
>> > > > >
>> > > > > Look at the bottom of the file.
>> > > > >
>> > > > > On Sat, Nov 21, 2009 at 12:26 AM, Tony Morris
>> > > > > > > > >
>> > > > > > > >>
>> > > > > > >
>> > > > > > > >
>> > > > > >>>> wrote:
>> > > > >
>> > > > > Stepan Koltsov wrote:
>> > > > > > You probably missed parts of the
>> > discussion where
>> > > > explained how
>> > > > > Option
>> > > > > > changes NullPointerException to
>> > > NoSuchElementException.
>> > > > > >
>> > > > > Except it doesn't.
>> > > > >
>> > > > > --
>> > > > > Tony Morris
>> > > > > http://tmorris.net/
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > > --
>> > > > > http://erikengbrecht.blogspot.com/
>> > > >
>> > > > --
>> > > > Tony Morris
>> > > > http://tmorris.net/
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > --
>> > > > http://erikengbrecht.blogspot.com/
>> > >
>> > > --
>> > > Tony Morris
>> > > http://tmorris.net/
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > --
>> > > http://erikengbrecht.blogspot.com/
>> > >
>> > >
>> >
>> > --
>> > Tony Morris
>> > http://tmorris.net/
>> >
>> >
>> >
>>
>> --
>> Tony Morris
>> http://tmorris.net/
>>
>>
>
>

Sat, 2009-11-21, 15:07

#21

Ishaaq Chandy

Joined: 2009-02-16,

Re: Cost of Option / Some vs null

doh! Yes, of course. Thanks!

So, you have to extend Optionn for any type A that you would expect to have to either have a value for or not.

It is interesting. However, does it not require that A has to extend Optionn? So, in effect, you cannot actually reimplement my example with Optionn - simply because I used Option[String] - where String does not extend Optionn.

... unless of course you resort to some sort of an implicit conversion function from String to Optionn[String]

Ishaaq

2009/11/22 Johannes Rudolph <johannes.rudolph@googlemail.com>

You use cata

someFuncReturningOptionString().cata(doSomethingWithString(_),
doSomethingForNone())

The implementation calls either the first or the second parameter
function and returns the result.

On Sat, Nov 21, 2009 at 2:15 PM, Ishaaq Chandy <ishaaq@gmail.com> wrote:
> I don't disbelieve you, however the stumbling point for me is not about how
> to rewrite the Option API
> - no, I just don't know how one would actually use Optionn.
>
> Would you expect to extend the trait for any class that needs to potray
> non-existance? If so, how does one implement:
>
> def cata[X](ding: A => X, dong: => X): X
>
> In short, how could Optionn be used to do the equivalent of this:
>
> val maybe: Option[String] = someFuncReturningOptionString()
> maybe match {
> case None => doSomethingForNone()
> case Some(string) => doSomethingWithString(string)
> }
>
> I ask, not because I don't believe it can't, its just that I don't
> understand how - probably my failing not yours.
>
> Ishaaq
>
> 2009/11/21 Tony Morris <tonymorris@gmail.com>
>>
>> A good exercise is to write the Option API yourself. I've done map and
>> flatMap, what about the others?
>>
>> I absolutely promise you that any method you can write for scala.Option
>> you can also write for Optionn and vice versa. getOrElse, get that fails
>> for "None", etc.
>>
>> Let me know if you get stuck.
>>
>> Ishaaq Chandy wrote:
>> > Yes, I was meaning to ask you about that, I'm afraid I did not
>> > understand it - I have no aversion to learning - I just did not
>> > understand it.
>> >
>> > And yes, before you get stuck into me :) - I did read it, I did
>> > compile it.... and then I got stuck, I have no idea how one might use
>> > your Optionn[+A] trait and how it could be used to replace
>> > scala.Option.
>> >
>> > awaiting enlightenment....
>> >
>> > 2009/11/21 Tony Morris <tonymorris@gmail.com
>> > <mailto:tonymorris@gmail.com>>
>> >
>> > I thought I gave some code earlier that demonstrated that Option
>> > is not
>> > necessarily "one of two things Some or None." It is the *shape*
>> > if the
>> > structure that is of importance here and importantly, the
>> > functions that
>> > can derive from that shape. (i.e. Option is a covariant functor,
>> > etc.)
>> >
>> > forall A. Option[A] is exactly equal (isomorphic) to forall X. (A
>> > => X)
>> > => (=> X) => X
>> > This is called the catamorphism for Option, or (cover your eyes if
>> > you
>> > have an aversion to thinking), the church encoding for Option.
>> >
>> > Yes, I am hoping to twist all your minds, to prepare you for the
>> > next
>> > enlightenment :)
>> >
>> > Ishaaq Chandy wrote:
>> > > Other than, (hopefully), the client programmer would stop to
>> > think:
>> > >
>> > > "Hmm, why do I have to do this silly foo.get()? What is this
>> > Option
>> > > thing that foo refrences? - aha, it can be one of two things Some
>> > or
>> > > None - perhaps I should read up and find out what they mean..."
>> > >
>> > > It is not guaranteed that every programmer will have a similar
>> > train
>> > > of though, however it is less likely that foo being equal to null
>> > > instead of an Option will kick off a similar train of thought.
>> > >
>> > > Ishaaq
>> > >
>> > > 2009/11/21 Erik Engbrecht <erik.engbrecht@gmail.com
>> > <mailto:erik.engbrecht@gmail.com>
>> > > <mailto:erik.engbrecht@gmail.com
>> > <mailto:erik.engbrecht@gmail.com>>>
>> > >
>> > > Ok, let me reprhase...
>> > >
>> > > When used in the way I pointed out below, using Option
>> > provides no
>> > > extra protection against non-termination over using null.
>> > >
>> > >
>> > > On Sat, Nov 21, 2009 at 7:00 AM, Tony Morris
>> > <tonymorris@gmail.com <mailto:tonymorris@gmail.com>
>> > > <mailto:tonymorris@gmail.com <mailto:tonymorris@gmail.com>>>
>> > wrote:
>> > >
>> > > That's merely saying that some programs fail to terminate.
>> > > Option did
>> > > "change NullPointerException to NoSuchElementException"
>> > any
>> > > more than it
>> > > changed IOException to NoSuchElementException.
>> > >
>> > > Erik Engbrecht wrote:
>> > > > Someone naively using references that may be null
>> > might write:
>> > > > val x = 5 + foo.integerValue // may throw NPE
>> > because foo
>> > > may be null
>> > > >
>> > > > Using option, the same person might write:
>> > > > val x = 5 + foo.get().integerValue // may throw
>> > > > NoSuchElementException because foo may be None
>> > > >
>> > > > On Sat, Nov 21, 2009 at 6:52 AM, Tony Morris
>> > > <tonymorris@gmail.com <mailto:tonymorris@gmail.com>
>> > <mailto:tonymorris@gmail.com <mailto:tonymorris@gmail.com>>
>> > > > <mailto:tonymorris@gmail.com
>> > <mailto:tonymorris@gmail.com> <mailto:tonymorris@gmail.com
>> > <mailto:tonymorris@gmail.com>>>>
>> > > wrote:
>> > > >
>> > > > What am I looking for exactly? I see no evidence for
>> > > "Option changes
>> > > > NullPointerException to NoSuchElementException." Is
>> > it
>> > > there?
>> > > >
>> > > > Erik Engbrecht wrote:
>> > > > >
>> > > >
>> > >
>> >
>> > http://lampsvn.epfl.ch/trac/scala/browser/scala/trunk/src/library/scala/Option.scala
>> > > > >
>> > > > >
>> > > > > Look at the bottom of the file.
>> > > > >
>> > > > > On Sat, Nov 21, 2009 at 12:26 AM, Tony Morris
>> > > > <tonymorris@gmail.com
>> > <mailto:tonymorris@gmail.com> <mailto:tonymorris@gmail.com
>> > <mailto:tonymorris@gmail.com>>
>> > > <mailto:tonymorris@gmail.com
>> > <mailto:tonymorris@gmail.com> <mailto:tonymorris@gmail.com
>> > <mailto:tonymorris@gmail.com>>>
>> > > > > <mailto:tonymorris@gmail.com
>> > <mailto:tonymorris@gmail.com>
>> > > <mailto:tonymorris@gmail.com
>> > <mailto:tonymorris@gmail.com>> <mailto:tonymorris@gmail.com
>> > <mailto:tonymorris@gmail.com>
>> > > <mailto:tonymorris@gmail.com
>> > <mailto:tonymorris@gmail.com>>>>> wrote:
>> > > > >
>> > > > > Stepan Koltsov wrote:
>> > > > > > You probably missed parts of the
>> > discussion where
>> > > > explained how
>> > > > > Option
>> > > > > > changes NullPointerException to
>> > > NoSuchElementException.
>> > > > > >
>> > > > > Except it doesn't.
>> > > > >
>> > > > > --
>> > > > > Tony Morris
>> > > > > http://tmorris.net/
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > > --
>> > > > > http://erikengbrecht.blogspot.com/
>> > > >
>> > > > --
>> > > > Tony Morris
>> > > > http://tmorris.net/
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > --
>> > > > http://erikengbrecht.blogspot.com/
>> > >
>> > > --
>> > > Tony Morris
>> > > http://tmorris.net/
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > --
>> > > http://erikengbrecht.blogspot.com/
>> > >
>> > >
>> >
>> > --
>> > Tony Morris
>> > http://tmorris.net/
>> >
>> >
>> >
>>
>> --
>> Tony Morris
>> http://tmorris.net/
>>
>>
>
>

--
Johannes

-----------------------------------------------
Johannes Rudolph
http://virtual-void.net

Sat, 2009-11-21, 15:27

#22

Johannes Rudolph

Joined: 2008-12-17,

Re: Cost of Option / Some vs null

On Sat, Nov 21, 2009 at 2:48 PM, Ishaaq Chandy wrote:
> doh! Yes, of course. Thanks!
>
> So, you have to extend Optionn for any type A that you would expect to have
> to either have a value for or not.
No :) I think Tony just omitted the (polymorphic) constructors. You
can create them by implementing Optionn.cata. He wanted to show that
the structure of the Option type is completely defined by its
catamorphism. If you could create polymorphic values in Scala you
could almost write:

type Option[A] = [X](A => X, =>X) => X

As Tony showed, you can implement all the other auxillary functions in
terms of the catamorphism.

Encoding data types as functions (originally in the lambda calculus)
is called "Church Encoding". You can define tuples, Either, natural
numbers and more just using functions.

Sat, 2009-11-21, 20:27

#23

dcsobral

Joined: 2009-04-23,

Re: Cost of Option / Some vs null

That's just saying that Option is not useful because null still exists. That is silly.
I'll make a claim here.
Premises:1. Given and identifier "id" and a method "m". 2. Assuming id is of type T, which defines "m".3. Assuming id was assigned by code you control.4. Assuming you never use "null" in your code, nor call any APIs which might return null. 5. Assuming m does not through exceptions.
Then:If id.m compiles, it will not through an exception at run time.
I think that is a pretty powerful statement. In particular, if (4) is not true, then that statement goes out of the window. If that's not an indictment of null, I don't know what else can be.
So, Java libraries may return null. So what? You fence them and convert anything that might return null to Option. If anything stilll throws an exception, you at least can be sure it wasn't something about your code, but, rather, some external library you called and did not check for null. If you avoid nulls and use Option.
Frankly, nulls are a left-over from memory management, and should have gone the same way.
On Sat, Nov 21, 2009 at 10:32 AM, Erik Engbrecht <erik.engbrecht@gmail.com> wrote:

Yes, that's why I said that the way null is used is semantically ambiguous. Option provides more information about the intent, but no real enforcement because there are other possible situations: val x = 5 + foo.get().integerValue // throws NPE because foo is null
or the more devious:val x = foo match { case Some(y) => 5 + y.integerValue // throws NPE because y is null, e.g. we have Some(null) case None => 5 // treat None as 0 }
I'm not trying to say Option isn't useful. It is and I use it a lot. But it's not a silver bullet...or maybe I should say a nerf bullet for those determined to shoot themselves in the foot. I think a lot of arguments in favor of it exaggerate the protections it provides.
On Sat, Nov 21, 2009 at 7:14 AM, Ishaaq Chandy <ishaaq@gmail.com> wrote:

Other than, (hopefully), the client programmer would stop to think:

"Hmm, why do I have to do this silly foo.get()? What is this Option thing that foo refrences? - aha, it can be one of two things Some or None - perhaps I should read up and find out what they mean..."

It is not guaranteed that every programmer will have a similar train of though, however it is less likely that foo being equal to null instead of an Option will kick off a similar train of thought.

Ishaaq

2009/11/21 Erik Engbrecht <erik.engbrecht@gmail.com>
Ok, let me reprhase...
When used in the way I pointed out below, using Option provides no extra protection against non-termination over using null.

On Sat, Nov 21, 2009 at 7:00 AM, Tony Morris <tonymorris@gmail.com> wrote:

That's merely saying that some programs fail to terminate. Option did
"change NullPointerException to NoSuchElementException" any more than it
changed IOException to NoSuchElementException.

Erik Engbrecht wrote:
> Someone naively using references that may be null might write:
> val x = 5 + foo.integerValue // may throw NPE because foo may be null
>
> Using option, the same person might write:
> val x = 5 + foo.get().integerValue // may throw
> NoSuchElementException because foo may be None
>
> On Sat, Nov 21, 2009 at 6:52 AM, Tony Morris <tonymorris@gmail.com
> <mailto:tonymorris@gmail.com>> wrote:
>
> What am I looking for exactly? I see no evidence for "Option changes
> NullPointerException to NoSuchElementException." Is it there?
>
> Erik Engbrecht wrote:
> >
> http://lampsvn.epfl.ch/trac/scala/browser/scala/trunk/src/library/scala/Option.scala
> >
> >
> > Look at the bottom of the file.
> >
> > On Sat, Nov 21, 2009 at 12:26 AM, Tony Morris
> <tonymorris@gmail.com <mailto:tonymorris@gmail.com>
> > <mailto:tonymorris@gmail.com <mailto:tonymorris@gmail.com>>> wrote:
> >
> > Stepan Koltsov wrote:
> > > You probably missed parts of the discussion where
> explained how
> > Option
> > > changes NullPointerException to NoSuchElementException.
> > >
> > Except it doesn't.
> >
> > --
> > Tony Morris
> > http://tmorris.net/
> >
> >
> >
> >
> >
> > --
> > http://erikengbrecht.blogspot.com/
>
> --
> Tony Morris
> http://tmorris.net/
>
>
>
>
>
> --
> http://erikengbrecht.blogspot.com/

--
Tony Morris
http://tmorris.net/

--
http://erikengbrecht.blogspot.com/

--
http://erikengbrecht.blogspot.com/

--
Daniel C. Sobral

Veni, vidi, veterni.

Sat, 2009-11-21, 20:37

#24

Sebastien Bocq

Joined: 2008-12-18,

Re: Cost of Option / Some vs null

Here is my solution, is it what was expected? I didn't play further with Function1 because I had already too much fun for my own health with Option and List. Is it acceptable to generalise this approach in Scala, how bad is it wrt to performance?

I would appreciate comments.

Thanks,
Sebastien

trait Optionn[+A] { self =>
// Church Encoding (abstract method)
def cata[X](ding: A => X, dong: => X): X

// Look ma, no case classes!
def map[B](f: A => B) = new Optionn[B] {
   def cata[X](ding: B => X, dong: => X) = self.cata(ding compose f, dong)
}

def flatMap[B](f: A => Optionn[B]) = new Optionn[B] {
   def cata[X](ding: B => X, dong: => X) =
     self.cata(f(_).cata(ding, dong), dong)
}

def mmap[B](o:Optionn[A => B]) = o.flatMap(f => map(f))

override def toString() = cata("Some(" + _.toString + ")", "None")
}

object Nonen extends Optionn[Nothing] {

def cata[X](ding: Nothing => X, dong: => X): X = dong

def ::[B](x:B) = new Optionn[B] {
   def cata[X](ding: B => X, dong: => X): X = ding(x)
}
}

trait Listt[+A] { self =>

def cata[X](ding:(A, Listt[A]) => X, dong: => X):X

def map[B](f: A => B):Listt[B] = new Listt[B] {
    def cata[X](ding:(B, Listt[B]) => X, dong: => X) = self.cata((head, tail) => ding(f(head), tail.map(f)), dong)
}

def flatMap[B](f: A => Listt[B]):Listt[B] = new Listt[B] {
    def cata[X](ding:(B, Listt[B]) => X, dong: => X):X =
      self.cata[X]((head, tail) => (f(head) mplus tail.flatMap(f)).cata[X](ding, dong), dong)
}

def mmap[B](o:Listt[A => B]) = o.flatMap(f => map(f))

def foldl[X](z:X)(op:(X, A) => X):X = self.cata((head, tail) => tail.foldl(op(z, head))(op), z)
def foldr[X](z:X)(op:(A, X) => X):X = self.cata((head, tail) => op(head, tail.foldr(z)(op)), z)

def mplus[B >: A](l:Listt[B]):Listt[B] = new Listt[B] {
    def cata[X](ding:(B, Listt[B]) => X, dong: => X):X = {
      self.cata((head, tail) => ding(head, tail mplus l), l.cata(ding, dong))
    }
}

def ::[B >: A](x:B) = new Listt[B] {
    def cata[X](ding:(B, Listt[B]) => X, dong: => X) = ding(x, self)
}

def foreach(f: A => Unit):Unit = cata((h, t) => {f(h); t.foreach(f)}, ())

override def toString() = "Listt[" + cata((h, t) => t.foldl(h.toString)((p, n) => p + "," + n.toString), "") + "]"
}

object Nil extends Listt[Nothing] {
def cata[X](ding:(Nothing, Listt[Nothing]) => X, dong: => X):X = dong
}

2009/11/21 Tony Morris <tonymorris@gmail.com>

Here's a giggle. Write this method on Optionn[A]:

Optionn[A => B] => Optionn[B]
Use flatMap.

Now do the same for List (but as an object method or your own List (PS:
what's the cata for List?)).
List[A] => List[A => B] => List[B]
Also use flatMap.

Now try Function1[T, _] if you're game.
Function1[T, A] => Function1[T, A => B] => Function1[T, B]
Use... bugger, no flatMap, let's write it!
Function1[T, A] => Function1[T, A => Function1[T, B]] => Function1[T, B]

Sorry, getting carried away. Learning is fun. I'm off to bed.

Tony Morris wrote:
> A good exercise is to write the Option API yourself. I've done map and
> flatMap, what about the others?
>
> I absolutely promise you that any method you can write for scala.Option
> you can also write for Optionn and vice versa. getOrElse, get that fails
> for "None", etc.
>
> Let me know if you get stuck.
>
> Ishaaq Chandy wrote:
>
>> Yes, I was meaning to ask you about that, I'm afraid I did not
>> understand it - I have no aversion to learning - I just did not
>> understand it.
>>
>> And yes, before you get stuck into me :) - I did read it, I did
>> compile it.... and then I got stuck, I have no idea how one might use
>> your Optionn[+A] trait and how it could be used to replace scala.Option.
>>
>> awaiting enlightenment....
>>
>> 2009/11/21 Tony Morris <tonymorris@gmail.com
>> <mailto:tonymorris@gmail.com>>
>>
>> I thought I gave some code earlier that demonstrated that Option
>> is not
>> necessarily "one of two things Some or None." It is the *shape*
>> if the
>> structure that is of importance here and importantly, the
>> functions that
>> can derive from that shape. (i.e. Option is a covariant functor, etc.)
>>
>> forall A. Option[A] is exactly equal (isomorphic) to forall X. (A
>> => X)
>> => (=> X) => X
>> This is called the catamorphism for Option, or (cover your eyes if you
>> have an aversion to thinking), the church encoding for Option.
>>
>> Yes, I am hoping to twist all your minds, to prepare you for the next
>> enlightenment :)
>>
>> Ishaaq Chandy wrote:
>> > Other than, (hopefully), the client programmer would stop to think:
>> >
>> > "Hmm, why do I have to do this silly foo.get()? What is this Option
>> > thing that foo refrences? - aha, it can be one of two things Some or
>> > None - perhaps I should read up and find out what they mean..."
>> >
>> > It is not guaranteed that every programmer will have a similar train
>> > of though, however it is less likely that foo being equal to null
>> > instead of an Option will kick off a similar train of thought.
>> >
>> > Ishaaq
>> >
>> > 2009/11/21 Erik Engbrecht <erik.engbrecht@gmail.com
>> <mailto:erik.engbrecht@gmail.com>
>> > <mailto:erik.engbrecht@gmail.com <mailto:erik.engbrecht@gmail.com>>>
>> >
>> > Ok, let me reprhase...
>> >
>> > When used in the way I pointed out below, using Option
>> provides no
>> > extra protection against non-termination over using null.
>> >
>> >
>> > On Sat, Nov 21, 2009 at 7:00 AM, Tony Morris
>> <tonymorris@gmail.com <mailto:tonymorris@gmail.com>
>> > <mailto:tonymorris@gmail.com <mailto:tonymorris@gmail.com>>>
>> wrote:
>> >
>> > That's merely saying that some programs fail to terminate.
>> > Option did
>> > "change NullPointerException to NoSuchElementException" any
>> > more than it
>> > changed IOException to NoSuchElementException.
>> >
>> > Erik Engbrecht wrote:
>> > > Someone naively using references that may be null
>> might write:
>> > > val x = 5 + foo.integerValue // may throw NPE
>> because foo
>> > may be null
>> > >
>> > > Using option, the same person might write:
>> > > val x = 5 + foo.get().integerValue // may throw
>> > > NoSuchElementException because foo may be None
>> > >
>> > > On Sat, Nov 21, 2009 at 6:52 AM, Tony Morris
>> > <tonymorris@gmail.com <mailto:tonymorris@gmail.com>
>> <mailto:tonymorris@gmail.com <mailto:tonymorris@gmail.com>>
>> > > <mailto:tonymorris@gmail.com
>> <mailto:tonymorris@gmail.com> <mailto:tonymorris@gmail.com
>> <mailto:tonymorris@gmail.com>>>>
>> > wrote:
>> > >
>> > > What am I looking for exactly? I see no evidence for
>> > "Option changes
>> > > NullPointerException to NoSuchElementException." Is it
>> > there?
>> > >
>> > > Erik Engbrecht wrote:
>> > > >
>> > >
>> >
>> http://lampsvn.epfl.ch/trac/scala/browser/scala/trunk/src/library/scala/Option.scala
>> > > >
>> > > >
>> > > > Look at the bottom of the file.
>> > > >
>> > > > On Sat, Nov 21, 2009 at 12:26 AM, Tony Morris
>> > > <tonymorris@gmail.com
>> <mailto:tonymorris@gmail.com> <mailto:tonymorris@gmail.com
>> <mailto:tonymorris@gmail.com>>
>> > <mailto:tonymorris@gmail.com
>> <mailto:tonymorris@gmail.com> <mailto:tonymorris@gmail.com
>> <mailto:tonymorris@gmail.com>>>
>> > > > <mailto:tonymorris@gmail.com
>> <mailto:tonymorris@gmail.com>
>> > <mailto:tonymorris@gmail.com
>> <mailto:tonymorris@gmail.com>> <mailto:tonymorris@gmail.com
>> <mailto:tonymorris@gmail.com>
>> > <mailto:tonymorris@gmail.com
>> <mailto:tonymorris@gmail.com>>>>> wrote:
>> > > >
>> > > > Stepan Koltsov wrote:
>> > > > > You probably missed parts of the
>> discussion where
>> > > explained how
>> > > > Option
>> > > > > changes NullPointerException to
>> > NoSuchElementException.
>> > > > >
>> > > > Except it doesn't.
>> > > >
>> > > > --
>> > > > Tony Morris
>> > > > http://tmorris.net/
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > --
>> > > > http://erikengbrecht.blogspot.com/
>> > >
>> > > --
>> > > Tony Morris
>> > > http://tmorris.net/
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > --
>> > > http://erikengbrecht.blogspot.com/
>> >
>> > --
>> > Tony Morris
>> > http://tmorris.net/
>> >
>> >
>> >
>> >
>> >
>> > --
>> > http://erikengbrecht.blogspot.com/
>> >
>> >
>>
>> --
>> Tony Morris
>> http://tmorris.net/
>>
>>
>>
>>
>
>

--
Tony Morris
http://tmorris.net/

Sat, 2009-11-21, 21:07

#25

Erik Engbrecht

Joined: 2008-12-19,

Re: Cost of Option / Some vs null

No, it's not saying Option is not useful because null still exists. It's saying that just because you have Option doesn't mean you can safely pretend that null no longer exists. As you said, you have to fence of calls to external libraries that may return null end ensure those nulls doesn't propagate into your code.
On Sat, Nov 21, 2009 at 2:23 PM, Daniel Sobral <dcsobral@gmail.com> wrote:

That's just saying that Option is not useful because null still exists. That is silly.
I'll make a claim here.
Premises:1. Given and identifier "id" and a method "m". 2. Assuming id is of type T, which defines "m".3. Assuming id was assigned by code you control.4. Assuming you never use "null" in your code, nor call any APIs which might return null. 5. Assuming m does not through exceptions.
Then:If id.m compiles, it will not through an exception at run time.
I think that is a pretty powerful statement. In particular, if (4) is not true, then that statement goes out of the window. If that's not an indictment of null, I don't know what else can be.
So, Java libraries may return null. So what? You fence them and convert anything that might return null to Option. If anything stilll throws an exception, you at least can be sure it wasn't something about your code, but, rather, some external library you called and did not check for null. If you avoid nulls and use Option.
Frankly, nulls are a left-over from memory management, and should have gone the same way.
On Sat, Nov 21, 2009 at 10:32 AM, Erik Engbrecht <erik.engbrecht@gmail.com> wrote:

Yes, that's why I said that the way null is used is semantically ambiguous. Option provides more information about the intent, but no real enforcement because there are other possible situations: val x = 5 + foo.get().integerValue // throws NPE because foo is null
or the more devious:val x = foo match { case Some(y) => 5 + y.integerValue // throws NPE because y is null, e.g. we have Some(null) case None => 5 // treat None as 0 }
I'm not trying to say Option isn't useful. It is and I use it a lot. But it's not a silver bullet...or maybe I should say a nerf bullet for those determined to shoot themselves in the foot. I think a lot of arguments in favor of it exaggerate the protections it provides.
On Sat, Nov 21, 2009 at 7:14 AM, Ishaaq Chandy <ishaaq@gmail.com> wrote:

Other than, (hopefully), the client programmer would stop to think:

"Hmm, why do I have to do this silly foo.get()? What is this Option thing that foo refrences? - aha, it can be one of two things Some or None - perhaps I should read up and find out what they mean..."

It is not guaranteed that every programmer will have a similar train of though, however it is less likely that foo being equal to null instead of an Option will kick off a similar train of thought.

Ishaaq

2009/11/21 Erik Engbrecht <erik.engbrecht@gmail.com>
Ok, let me reprhase...
When used in the way I pointed out below, using Option provides no extra protection against non-termination over using null.

On Sat, Nov 21, 2009 at 7:00 AM, Tony Morris <tonymorris@gmail.com> wrote:

That's merely saying that some programs fail to terminate. Option did
"change NullPointerException to NoSuchElementException" any more than it
changed IOException to NoSuchElementException.

Erik Engbrecht wrote:
> Someone naively using references that may be null might write:
> val x = 5 + foo.integerValue // may throw NPE because foo may be null
>
> Using option, the same person might write:
> val x = 5 + foo.get().integerValue // may throw
> NoSuchElementException because foo may be None
>
> On Sat, Nov 21, 2009 at 6:52 AM, Tony Morris <tonymorris@gmail.com
> <mailto:tonymorris@gmail.com>> wrote:
>
> What am I looking for exactly? I see no evidence for "Option changes
> NullPointerException to NoSuchElementException." Is it there?
>
> Erik Engbrecht wrote:
> >
> http://lampsvn.epfl.ch/trac/scala/browser/scala/trunk/src/library/scala/Option.scala
> >
> >
> > Look at the bottom of the file.
> >
> > On Sat, Nov 21, 2009 at 12:26 AM, Tony Morris
> <tonymorris@gmail.com <mailto:tonymorris@gmail.com>
> > <mailto:tonymorris@gmail.com <mailto:tonymorris@gmail.com>>> wrote:
> >
> > Stepan Koltsov wrote:
> > > You probably missed parts of the discussion where
> explained how
> > Option
> > > changes NullPointerException to NoSuchElementException.
> > >
> > Except it doesn't.
> >
> > --
> > Tony Morris
> > http://tmorris.net/
> >
> >
> >
> >
> >
> > --
> > http://erikengbrecht.blogspot.com/
>
> --
> Tony Morris
> http://tmorris.net/
>
>
>
>
>
> --
> http://erikengbrecht.blogspot.com/

--
Tony Morris
http://tmorris.net/

--
http://erikengbrecht.blogspot.com/

--
http://erikengbrecht.blogspot.com/

--
Daniel C. Sobral

Veni, vidi, veterni.

--
http://erikengbrecht.blogspot.com/

Sat, 2009-11-21, 21:17

#26

Kevin Wright

Joined: 2009-06-09,

Re: Cost of Option / Some vs null

What Option has that null doesn't have is that it's a monad
You can use a function to map a monad of one type to a monad of another type, you can daisy chain a whole series of these things if you want. And if you find you need not one value but 10, then switch the Option for a List, the existing mapping logic remains unaltered.
This is a whole level of abstraction above and beyond nullable references

On Sat, Nov 21, 2009 at 7:54 PM, Erik Engbrecht <erik.engbrecht@gmail.com> wrote:

No, it's not saying Option is not useful because null still exists. It's saying that just because you have Option doesn't mean you can safely pretend that null no longer exists. As you said, you have to fence of calls to external libraries that may return null end ensure those nulls doesn't propagate into your code.
On Sat, Nov 21, 2009 at 2:23 PM, Daniel Sobral <dcsobral@gmail.com> wrote:

That's just saying that Option is not useful because null still exists. That is silly.
I'll make a claim here.
Premises:1. Given and identifier "id" and a method "m". 2. Assuming id is of type T, which defines "m".3. Assuming id was assigned by code you control.4. Assuming you never use "null" in your code, nor call any APIs which might return null. 5. Assuming m does not through exceptions.
Then:If id.m compiles, it will not through an exception at run time.
I think that is a pretty powerful statement. In particular, if (4) is not true, then that statement goes out of the window. If that's not an indictment of null, I don't know what else can be.
So, Java libraries may return null. So what? You fence them and convert anything that might return null to Option. If anything stilll throws an exception, you at least can be sure it wasn't something about your code, but, rather, some external library you called and did not check for null. If you avoid nulls and use Option.
Frankly, nulls are a left-over from memory management, and should have gone the same way.
On Sat, Nov 21, 2009 at 10:32 AM, Erik Engbrecht <erik.engbrecht@gmail.com> wrote:

Yes, that's why I said that the way null is used is semantically ambiguous. Option provides more information about the intent, but no real enforcement because there are other possible situations: val x = 5 + foo.get().integerValue // throws NPE because foo is null
or the more devious:val x = foo match { case Some(y) => 5 + y.integerValue // throws NPE because y is null, e.g. we have Some(null) case None => 5 // treat None as 0 }
I'm not trying to say Option isn't useful. It is and I use it a lot. But it's not a silver bullet...or maybe I should say a nerf bullet for those determined to shoot themselves in the foot. I think a lot of arguments in favor of it exaggerate the protections it provides.
On Sat, Nov 21, 2009 at 7:14 AM, Ishaaq Chandy <ishaaq@gmail.com> wrote:

Other than, (hopefully), the client programmer would stop to think:

"Hmm, why do I have to do this silly foo.get()? What is this Option thing that foo refrences? - aha, it can be one of two things Some or None - perhaps I should read up and find out what they mean..."

It is not guaranteed that every programmer will have a similar train of though, however it is less likely that foo being equal to null instead of an Option will kick off a similar train of thought.

Ishaaq

2009/11/21 Erik Engbrecht <erik.engbrecht@gmail.com>
Ok, let me reprhase...
When used in the way I pointed out below, using Option provides no extra protection against non-termination over using null.

On Sat, Nov 21, 2009 at 7:00 AM, Tony Morris <tonymorris@gmail.com> wrote:

That's merely saying that some programs fail to terminate. Option did
"change NullPointerException to NoSuchElementException" any more than it
changed IOException to NoSuchElementException.

Erik Engbrecht wrote:
> Someone naively using references that may be null might write:
> val x = 5 + foo.integerValue // may throw NPE because foo may be null
>
> Using option, the same person might write:
> val x = 5 + foo.get().integerValue // may throw
> NoSuchElementException because foo may be None
>
> On Sat, Nov 21, 2009 at 6:52 AM, Tony Morris <tonymorris@gmail.com
> <mailto:tonymorris@gmail.com>> wrote:
>
> What am I looking for exactly? I see no evidence for "Option changes
> NullPointerException to NoSuchElementException." Is it there?
>
> Erik Engbrecht wrote:
> >
> http://lampsvn.epfl.ch/trac/scala/browser/scala/trunk/src/library/scala/Option.scala
> >
> >
> > Look at the bottom of the file.
> >
> > On Sat, Nov 21, 2009 at 12:26 AM, Tony Morris
> <tonymorris@gmail.com <mailto:tonymorris@gmail.com>
> > <mailto:tonymorris@gmail.com <mailto:tonymorris@gmail.com>>> wrote:
> >
> > Stepan Koltsov wrote:
> > > You probably missed parts of the discussion where
> explained how
> > Option
> > > changes NullPointerException to NoSuchElementException.
> > >
> > Except it doesn't.
> >
> > --
> > Tony Morris
> > http://tmorris.net/
> >
> >
> >
> >
> >
> > --
> > http://erikengbrecht.blogspot.com/
>
> --
> Tony Morris
> http://tmorris.net/
>
>
>
>
>
> --
> http://erikengbrecht.blogspot.com/

--
Tony Morris
http://tmorris.net/

--
http://erikengbrecht.blogspot.com/

--
http://erikengbrecht.blogspot.com/

--
Daniel C. Sobral

Veni, vidi, veterni.

--
http://erikengbrecht.blogspot.com/

Sat, 2009-11-21, 21:57

#27

Tony Morris 2

Joined: 2009-03-20,

Re: Cost of Option / Some vs null

Excellent Sébastien! I might think of some more.

Sébastien Bocq wrote:
> Here is my solution, is it what was expected? I didn't play further
> with Function1 because I had already too much fun for my own health
> with Option and List. Is it acceptable to generalise this approach in
> Scala, how bad is it wrt to performance?
>
> I would appreciate comments.
>
> Thanks,
> Sebastien
>
> trait Optionn[+A] { self =>
> // Church Encoding (abstract method)
> def cata[X](ding: A => X, dong: => X): X
>
> // Look ma, no case classes!
> def map[B](f: A => B) = new Optionn[B] {
> def cata[X](ding: B => X, dong: => X) = self.cata(ding compose f, dong)
> }
>
> def flatMap[B](f: A => Optionn[B]) = new Optionn[B] {
> def cata[X](ding: B => X, dong: => X) =
> self.cata(f(_).cata(ding, dong), dong)
> }
>
> def mmap[B](o:Optionn[A => B]) = o.flatMap(f => map(f))
>
> override def toString() = cata("Some(" + _.toString + ")", "None")
> }
>
> object Nonen extends Optionn[Nothing] {
>
> def cata[X](ding: Nothing => X, dong: => X): X = dong
>
> def ::[B](x:B) = new Optionn[B] {
> def cata[X](ding: B => X, dong: => X): X = ding(x)
> }
> }
>
> trait Listt[+A] { self =>
>
> def cata[X](ding:(A, Listt[A]) => X, dong: => X):X
>
> def map[B](f: A => B):Listt[B] = new Listt[B] {
> def cata[X](ding:(B, Listt[B]) => X, dong: => X) =
> self.cata((head, tail) => ding(f(head), tail.map(f)), dong)
> }
>
> def flatMap[B](f: A => Listt[B]):Listt[B] = new Listt[B] {
> def cata[X](ding:(B, Listt[B]) => X, dong: => X):X =
> self.cata[X]((head, tail) => (f(head) mplus
> tail.flatMap(f)).cata[X](ding, dong), dong)
> }
>
> def mmap[B](o:Listt[A => B]) = o.flatMap(f => map(f))
>
> def foldl[X](z:X)(op:(X, A) => X):X = self.cata((head, tail) =>
> tail.foldl(op(z, head))(op), z)
> def foldr[X](z:X)(op:(A, X) => X):X = self.cata((head, tail) =>
> op(head, tail.foldr(z)(op)), z)
>
> def mplus[B >: A](l:Listt[B]):Listt[B] = new Listt[B] {
> def cata[X](ding:(B, Listt[B]) => X, dong: => X):X = {
> self.cata((head, tail) => ding(head, tail mplus l), l.cata(ding,
> dong))
> }
> }
>
> def ::[B >: A](x:B) = new Listt[B] {
> def cata[X](ding:(B, Listt[B]) => X, dong: => X) = ding(x, self)
> }
>
> def foreach(f: A => Unit):Unit = cata((h, t) => {f(h);
> t.foreach(f)}, ())
>
> override def toString() = "Listt[" + cata((h, t) =>
> t.foldl(h.toString)((p, n) => p + "," + n.toString), "") + "]"
> }
>
> object Nil extends Listt[Nothing] {
> def cata[X](ding:(Nothing, Listt[Nothing]) => X, dong: => X):X = dong
> }
>
>
> 2009/11/21 Tony Morris >
>
> Here's a giggle. Write this method on Optionn[A]:
>
> Optionn[A => B] => Optionn[B]
> Use flatMap.
>
> Now do the same for List (but as an object method or your own List
> (PS:
> what's the cata for List?)).
> List[A] => List[A => B] => List[B]
> Also use flatMap.
>
> Now try Function1[T, _] if you're game.
> Function1[T, A] => Function1[T, A => B] => Function1[T, B]
> Use... bugger, no flatMap, let's write it!
> Function1[T, A] => Function1[T, A => Function1[T, B]] =>
> Function1[T, B]
>
> Sorry, getting carried away. Learning is fun. I'm off to bed.
>
> Tony Morris wrote:
> > A good exercise is to write the Option API yourself. I've done
> map and
> > flatMap, what about the others?
> >
> > I absolutely promise you that any method you can write for
> scala.Option
> > you can also write for Optionn and vice versa. getOrElse, get
> that fails
> > for "None", etc.
> >
> > Let me know if you get stuck.
> >
> > Ishaaq Chandy wrote:
> >
> >> Yes, I was meaning to ask you about that, I'm afraid I did not
> >> understand it - I have no aversion to learning - I just did not
> >> understand it.
> >>
> >> And yes, before you get stuck into me :) - I did read it, I did
> >> compile it.... and then I got stuck, I have no idea how one
> might use
> >> your Optionn[+A] trait and how it could be used to replace
> scala.Option.
> >>
> >> awaiting enlightenment....
> >>
> >> 2009/11/21 Tony Morris
> >> >>
> >>
> >> I thought I gave some code earlier that demonstrated that
> Option
> >> is not
> >> necessarily "one of two things Some or None." It is the
> *shape*
> >> if the
> >> structure that is of importance here and importantly, the
> >> functions that
> >> can derive from that shape. (i.e. Option is a covariant
> functor, etc.)
> >>
> >> forall A. Option[A] is exactly equal (isomorphic) to forall
> X. (A
> >> => X)
> >> => (=> X) => X
> >> This is called the catamorphism for Option, or (cover your
> eyes if you
> >> have an aversion to thinking), the church encoding for Option.
> >>
> >> Yes, I am hoping to twist all your minds, to prepare you
> for the next
> >> enlightenment :)
> >>
> >> Ishaaq Chandy wrote:
> >> > Other than, (hopefully), the client programmer would stop
> to think:
> >> >
> >> > "Hmm, why do I have to do this silly foo.get()? What is
> this Option
> >> > thing that foo refrences? - aha, it can be one of two
> things Some or
> >> > None - perhaps I should read up and find out what they
> mean..."
> >> >
> >> > It is not guaranteed that every programmer will have a
> similar train
> >> > of though, however it is less likely that foo being equal
> to null
> >> > instead of an Option will kick off a similar train of
> thought.
> >> >
> >> > Ishaaq
> >> >
> >> > 2009/11/21 Erik Engbrecht
> >> >
> >> > >>>
> >> >
> >> > Ok, let me reprhase...
> >> >
> >> > When used in the way I pointed out below, using Option
> >> provides no
> >> > extra protection against non-termination over using null.
> >> >
> >> >
> >> > On Sat, Nov 21, 2009 at 7:00 AM, Tony Morris
> >>
> >
> >> > >>>
> >> wrote:
> >> >
> >> > That's merely saying that some programs fail to
> terminate.
> >> > Option did
> >> > "change NullPointerException to
> NoSuchElementException" any
> >> > more than it
> >> > changed IOException to NoSuchElementException.
> >> >
> >> > Erik Engbrecht wrote:
> >> > > Someone naively using references that may be null
> >> might write:
> >> > > val x = 5 + foo.integerValue // may throw NPE
> >> because foo
> >> > may be null
> >> > >
> >> > > Using option, the same person might write:
> >> > > val x = 5 + foo.get().integerValue // may throw
> >> > > NoSuchElementException because foo may be None
> >> > >
> >> > > On Sat, Nov 21, 2009 at 6:52 AM, Tony Morris
> >> > >
> >>
> >>
> >> > >
> >> >
>
> >> >>>>
> >> > wrote:
> >> > >
> >> > > What am I looking for exactly? I see no
> evidence for
> >> > "Option changes
> >> > > NullPointerException to
> NoSuchElementException." Is it
> >> > there?
> >> > >
> >> > > Erik Engbrecht wrote:
> >> > > >
> >> > >
> >> >
> >>
> http://lampsvn.epfl.ch/trac/scala/browser/scala/trunk/src/library/scala/...
> >> > > >
> >> > > >
> >> > > > Look at the bottom of the file.
> >> > > >
> >> > > > On Sat, Nov 21, 2009 at 12:26 AM, Tony Morris
> >> > >
> >> >
>
> >> >>
> >> >
> >> >
>
> >> >>>
> >> > > >
> >> >
> >> >
> >> >>
> >> >
> >> >
> >> >>>>> wrote:
> >> > > >
> >> > > > Stepan Koltsov wrote:
> >> > > > > You probably missed parts of the
> >> discussion where
> >> > > explained how
> >> > > > Option
> >> > > > > changes NullPointerException to
> >> > NoSuchElementException.
> >> > > > >
> >> > > > Except it doesn't.
> >> > > >
> >> > > > --
> >> > > > Tony Morris
> >> > > > http://tmorris.net/
> >> > > >
> >> > > >
> >> > > >
> >> > > >
> >> > > >
> >> > > > --
> >> > > > http://erikengbrecht.blogspot.com/
> >> > >
> >> > > --
> >> > > Tony Morris
> >> > > http://tmorris.net/
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > > --
> >> > > http://erikengbrecht.blogspot.com/
> >> >
> >> > --
> >> > Tony Morris
> >> > http://tmorris.net/
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > --
> >> > http://erikengbrecht.blogspot.com/
> >> >
> >> >
> >>
> >> --
> >> Tony Morris
> >> http://tmorris.net/
> >>
> >>
> >>
> >>
> >
> >
>
> --
> Tony Morris
> http://tmorris.net/
>
>
>

Sat, 2009-11-21, 22:27

#28

phkoester

Joined: 2009-08-23,

Re: Cost of Option / Some vs null

Sebastien wrote;

>> trait Optionn[+A] { self =>
>> // Church Encoding (abstract method)
>> def cata[X](ding: A => X, dong: => X): X
>>
>> // Look ma, no case classes!
>> def map[B](f: A => B) = new Optionn[B] {
>> def cata[X](ding: B => X, dong: => X) = self.cata(ding compose f, dong)
>> }
>>
>> def flatMap[B](f: A => Optionn[B]) = new Optionn[B] {
>> def cata[X](ding: B => X, dong: => X) =
>> self.cata(f(_).cata(ding, dong), dong)
>> }
>>
>> def mmap[B](o:Optionn[A => B]) = o.flatMap(f => map(f))
>>
>> override def toString() = cata("Some(" + _.toString + ")", "None")
>> }
>>
>> object Nonen extends Optionn[Nothing] {
>>
>> def cata[X](ding: Nothing => X, dong: => X): X = dong
>>
>> def ::[B](x:B) = new Optionn[B] {
>> def cata[X](ding: B => X, dong: => X): X = ding(x)
>> }
>> }
>>
>> trait Listt[+A] { self =>
>>
>> def cata[X](ding:(A, Listt[A]) => X, dong: => X):X
>>
>> def map[B](f: A => B):Listt[B] = new Listt[B] {
>> def cata[X](ding:(B, Listt[B]) => X, dong: => X) =
>> self.cata((head, tail) => ding(f(head), tail.map(f)), dong)
>> }
>>
>> def flatMap[B](f: A => Listt[B]):Listt[B] = new Listt[B] {
>> def cata[X](ding:(B, Listt[B]) => X, dong: => X):X =
>> self.cata[X]((head, tail) => (f(head) mplus
>> tail.flatMap(f)).cata[X](ding, dong), dong)
>> }
>>
>> def mmap[B](o:Listt[A => B]) = o.flatMap(f => map(f))
>>
>> def foldl[X](z:X)(op:(X, A) => X):X = self.cata((head, tail) =>
>> tail.foldl(op(z, head))(op), z)
>> def foldr[X](z:X)(op:(A, X) => X):X = self.cata((head, tail) =>
>> op(head, tail.foldr(z)(op)), z)
>>
>> def mplus[B >: A](l:Listt[B]):Listt[B] = new Listt[B] {
>> def cata[X](ding:(B, Listt[B]) => X, dong: => X):X = {
>> self.cata((head, tail) => ding(head, tail mplus l), l.cata(ding,
>> dong))
>> }
>> }
>>
>> def ::[B >: A](x:B) = new Listt[B] {
>> def cata[X](ding:(B, Listt[B]) => X, dong: => X) = ding(x, self)
>> }
>>
>> def foreach(f: A => Unit):Unit = cata((h, t) => {f(h);
>> t.foreach(f)}, ())
>>
>> override def toString() = "Listt[" + cata((h, t) =>
>> t.foldl(h.toString)((p, n) => p + "," + n.toString), "") + "]"
>> }
>>
>> object Nil extends Listt[Nothing] {
>> def cata[X](ding:(Nothing, Listt[Nothing]) => X, dong: => X):X = dong
>> }

Crazy. Provided all of this compiles, and I have no reason not to
believe you, I see why Scala can be good fun. I would not override
`toString' with empty parantheses because it does not alter state, so
say `toString' and not `toString()' but that was really just a sidenote.

Sat, 2009-11-21, 22:47

#29

phkoester

Joined: 2009-08-23,

Re: Cost of Option / Some vs null

I'd like to add this: I'm not a Scala expert of course, with only three
months of experience a newbie, but I'm somehow disapointed that Martin
didn't reintroduce `const', which would spare us so many runtime errors.
Other than that, I am really impressed by Martin's work, he truly is a
language designer.

Sun, 2009-11-22, 03:57

#30

dcsobral

Joined: 2009-04-23,

Re: Cost of Option / Some vs null

Oh, we are in agreement, then.

On Sat, Nov 21, 2009 at 5:54 PM, Erik Engbrecht <erik.engbrecht@gmail.com> wrote:

No, it's not saying Option is not useful because null still exists. It's saying that just because you have Option doesn't mean you can safely pretend that null no longer exists. As you said, you have to fence of calls to external libraries that may return null end ensure those nulls doesn't propagate into your code.
On Sat, Nov 21, 2009 at 2:23 PM, Daniel Sobral <dcsobral@gmail.com> wrote:

That's just saying that Option is not useful because null still exists. That is silly.
I'll make a claim here.
Premises:1. Given and identifier "id" and a method "m". 2. Assuming id is of type T, which defines "m".3. Assuming id was assigned by code you control.4. Assuming you never use "null" in your code, nor call any APIs which might return null. 5. Assuming m does not through exceptions.
Then:If id.m compiles, it will not through an exception at run time.
I think that is a pretty powerful statement. In particular, if (4) is not true, then that statement goes out of the window. If that's not an indictment of null, I don't know what else can be.
So, Java libraries may return null. So what? You fence them and convert anything that might return null to Option. If anything stilll throws an exception, you at least can be sure it wasn't something about your code, but, rather, some external library you called and did not check for null. If you avoid nulls and use Option.
Frankly, nulls are a left-over from memory management, and should have gone the same way.
On Sat, Nov 21, 2009 at 10:32 AM, Erik Engbrecht <erik.engbrecht@gmail.com> wrote:

Yes, that's why I said that the way null is used is semantically ambiguous. Option provides more information about the intent, but no real enforcement because there are other possible situations: val x = 5 + foo.get().integerValue // throws NPE because foo is null
or the more devious:val x = foo match { case Some(y) => 5 + y.integerValue // throws NPE because y is null, e.g. we have Some(null) case None => 5 // treat None as 0 }
I'm not trying to say Option isn't useful. It is and I use it a lot. But it's not a silver bullet...or maybe I should say a nerf bullet for those determined to shoot themselves in the foot. I think a lot of arguments in favor of it exaggerate the protections it provides.
On Sat, Nov 21, 2009 at 7:14 AM, Ishaaq Chandy <ishaaq@gmail.com> wrote:

Other than, (hopefully), the client programmer would stop to think:

"Hmm, why do I have to do this silly foo.get()? What is this Option thing that foo refrences? - aha, it can be one of two things Some or None - perhaps I should read up and find out what they mean..."

It is not guaranteed that every programmer will have a similar train of though, however it is less likely that foo being equal to null instead of an Option will kick off a similar train of thought.

Ishaaq

2009/11/21 Erik Engbrecht <erik.engbrecht@gmail.com>
Ok, let me reprhase...
When used in the way I pointed out below, using Option provides no extra protection against non-termination over using null.

On Sat, Nov 21, 2009 at 7:00 AM, Tony Morris <tonymorris@gmail.com> wrote:

That's merely saying that some programs fail to terminate. Option did
"change NullPointerException to NoSuchElementException" any more than it
changed IOException to NoSuchElementException.

Erik Engbrecht wrote:
> Someone naively using references that may be null might write:
> val x = 5 + foo.integerValue // may throw NPE because foo may be null
>
> Using option, the same person might write:
> val x = 5 + foo.get().integerValue // may throw
> NoSuchElementException because foo may be None
>
> On Sat, Nov 21, 2009 at 6:52 AM, Tony Morris <tonymorris@gmail.com
> <mailto:tonymorris@gmail.com>> wrote:
>
> What am I looking for exactly? I see no evidence for "Option changes
> NullPointerException to NoSuchElementException." Is it there?
>
> Erik Engbrecht wrote:
> >
> http://lampsvn.epfl.ch/trac/scala/browser/scala/trunk/src/library/scala/Option.scala
> >
> >
> > Look at the bottom of the file.
> >
> > On Sat, Nov 21, 2009 at 12:26 AM, Tony Morris
> <tonymorris@gmail.com <mailto:tonymorris@gmail.com>
> > <mailto:tonymorris@gmail.com <mailto:tonymorris@gmail.com>>> wrote:
> >
> > Stepan Koltsov wrote:
> > > You probably missed parts of the discussion where
> explained how
> > Option
> > > changes NullPointerException to NoSuchElementException.
> > >
> > Except it doesn't.
> >
> > --
> > Tony Morris
> > http://tmorris.net/
> >
> >
> >
> >
> >
> > --
> > http://erikengbrecht.blogspot.com/
>
> --
> Tony Morris
> http://tmorris.net/
>
>
>
>
>
> --
> http://erikengbrecht.blogspot.com/

--
Tony Morris
http://tmorris.net/

--
http://erikengbrecht.blogspot.com/

--
http://erikengbrecht.blogspot.com/

--
Daniel C. Sobral

Veni, vidi, veterni.

--
http://erikengbrecht.blogspot.com/

--
Daniel C. Sobral

Veni, vidi, veterni.

Tue, 2009-11-24, 17:07

#31

Phil! Gold

Joined: 2009-03-30,

Re: Cost of Option / Some vs null

* Philip Köster [2009-11-21 22:40 +0100]:
> I'm somehow disapointed that Martin didn't reintroduce `const', which
> would spare us so many runtime errors.

How is

const foo = 17

any different than

val foo = 17

?

Tue, 2009-11-24, 18:27

#32

nilskp

Joined: 2009-01-30,

Re: Re: Cost of Option / Some vs null

On Tue, Nov 24, 2009 at 10:06 AM, Phil! Gold <phil_g@pobox.com> wrote:

* Philip Köster <philip.koester@web.de> [2009-11-21 22:40 +0100]:
> I'm somehow disapointed that Martin didn't reintroduce `const', which
> would spare us so many runtime errors.

How is

const foo = 17

any different than

val foo = 17

It isn't, but this would be:

const foo = Array(1,2,3)
val foo = Array(1,2,3)

It's a meaningless discussion though, because there's nothing in the Java platform to support this.

Tue, 2009-11-24, 18:37

#33

Phil! Gold

Joined: 2009-03-30,

Re: Cost of Option / Some vs null

* Phil! Gold [2009-11-24 11:06 -0500]:
> How is
> const foo = 17
> any different than
> val foo = 17
> ?

Never mind. I see what Philip was getting at after reading other branches
of the discussion.

Sun, 2009-11-29, 23:37

#34

phkoester

Joined: 2009-08-23,

Re: Re: Cost of Option / Some vs null [Turned into philosophica

Phil! Gold wrote:

> How is
>
> const foo = 17
>
> any different than
>
> val foo = 17

In Java/Scala, I cannot declare an object to be `const'. While `final'
and `const' may behave similarly for primitives, they do not for
objects. In Java, for instance, an array may be `final', but that
wouldn't prevent me from changing its elements. I think we all agree
that possible nullness and constness are two basic traits of every
object or reference to an object. So a language that enables me to
express this is a good language.

But two points here:

1. There's no need to make fun of my name, although I see I deserve it.

2. I'm not only a programmer but also a human, and may as such sometimes
have bad days. I realize I wrote a lotta foolish posts and would like to
apologize. As a result of this, I shut up already and will wait some
time before I return to this list. I hope you will welcome me back then.
I have a bad disease that at times spoils my life, and I suffer enough
already.

So please excuse me
---Philip

Mon, 2009-11-30, 00:17

#35

Ishaaq Chandy

Joined: 2009-02-16,

Re: Re: Cost of Option / Some vs null [Turned into philosophic

???

I've obviously missed something - I thought that discussion, while heated, long and meandering, was pretty civil. If, while participating in it, I contributed in some way towards offending you it was unknowingly and without malice. Even so, I apologise unreservedly, no offence was intended. We're all learning here.

Ishaaq

2009/11/30 Philip Köster <philip.koester@web.de>

But two points here:

1. There's no need to make fun of my name, although I see I deserve it.

2. I'm not only a programmer but also a human, and may as such sometimes have bad days. I realize I wrote a lotta foolish posts and would like to apologize. As a result of this, I shut up already and will wait some time before I return to this list. I hope you will welcome me back then. I have a bad disease that at times spoils my life, and I suffer enough already.

So please excuse me
---Philip

Mon, 2009-11-30, 00:27

#36

Tony Morris 2

Joined: 2009-03-20,

Re: Re: Cost of Option / Some vs null [Turned into philosophica

> 2. I'm not only a programmer but also a human, and may as such
> sometimes have bad days. I realize I wrote a lotta foolish posts and
> would like to apologize. As a result of this, I shut up already and
> will wait some time before I return to this list. I hope you will
> welcome me back then. I have a bad disease that at times spoils my
> life, and I suffer enough already.
>
> So please excuse me
> ---Philip
>
Forgiven.

Scala Main Menu

Scala Quick Links

Featured News

User login