RE: Re: Why have method "get" in Option?

I'm not sure what you mean, but my question was to Tony, about his idea that because the language inherently is not completely safe, that is a reason to have a particular unsafe method.

On Thu, Aug 19, 2010 at 7:47 AM, Detering Dirk <Dirk.Detering@bitmarck.de> wrote:

> Hmm... Is 0 unsafe methods better?
>
> Meaning, do you say "no" because of some all-or-nothing principle; or
> because it's pointless to eliminate unsafe methods in a language that's
> turing complete and therefore not inherently safe anyway?
>
> Also, when you "no" to the question "isn't it better..." do you mean
> that it's not better in any way at all, or that any way that it might
> be better is insignificant (relatively or absolutely)?

Where does this questionnaire lead to?

Perhaps "no" in the sense of: No.

By simply reducing the account of 10 by 1 without considering the context
and semantics of all 10 methods and without defining the word "better" and how
you quantify it, we are in a situation where answering your question with
'yes' would simply be wrong.  So the short answer is: 'no'.



>
>
> On Wed, Aug 18, 2010 at 4:54 AM, Tony Morris <tonymorris@gmail.com>
> wrote:
>
>
>       No.
>
>
>       Naftoli Gugenheim wrote:
>       > Okay, but isn't it better to have 9 unsafe methods than 10
> unsafe
>       > methods?
>       >
>       >
>       > On Fri, Aug 13, 2010 at 10:38 PM, Tony Morris
> <tonymorris@gmail.com
>
>       > <mailto:tonymorris@gmail.com>> wrote:
>       >
>       >     Sean,
>       >     Scala *must* have unsafe methods. It's absolutely
> necessary.
>       >     Nothing is
>       >     solved by moving or removing the get function in this
> respect.
>       >
>       >     Sean Leather wrote:
>       >     > Thanks for the response. There are quite a few replies
> here, and I'm
>       >     > certain I don't understand most. As a result, I will try
> to
>       >     clarify my
>       >     > question.
>       >     >
>       >     >     Why does the method "get" exist in the Option class?
>       >     >
>       >     >
>       >     > The point of this question is that the method "get" is by
> definition
>       >     > unsafe. By unsafe, I mean that it will likely lead a
> programmer who
>       >     > uses it into error. Why is it unsafe? Let's review the
> code:
>       >     >
>       >     >
>       >     >     sealed abstract class Option[+A] extends Product {
> def get: A }
>       >     >     final case class Some[+A](x: A) extends Option[A] {
> def get
>       >     = x }
>       >     >     case object None extends Option[Nothing] { def get =
> throw new
>       >     >     NoSuchElementException("None.get") }
>       >     >
>       >     >
>       >     > Since "get" is defined in the class Option, there is an
> implication
>       >     > that each subclass will override it and return some A
> value. Looking
>       >     > at each inheritor, we see that Some overrides and results
> in a
>       >     value,
>       >     > but None throws an exception. Since there are only two
>       >     subclasses and
>       >     > half of them are exceptional cases, I'd say it's pretty
> clear that
>       >     > "get" will lead somebody into error. Thus, it is unsafe.
>       >     >
>       >     >     For reasons of type safety, shouldn't "get" only
> exist in
>       >     Some? Or
>       >     >     is this just another way of replacing
> "x.getOrElse(default)"
>       >     with
>       >     >     "try { x.get } catch { default }"?
>       >     >
>       >     >
>       >     > I'm suggesting that "get" not be defined in Option but
> rather in
>       >     Some.
>       >     > That provides one way to get the value out of Some. But
> how do
>       >     you get
>       >     > the value out of an Option? Again, I'm new to Scala but I
>       >     already see
>       >     > multiple ways:
>       >     >
>       >     >     * getOrElse
>       >     >     * foreach/for
>       >     >     * iterator
>       >     >     * opt match { case Some(x) => ... ; case None => ...
> }
>       >     >
>       >     > And I'm sure there are others.
>       >     >
>       >     > Of course, this is not to say that a method equivalent to
> "get"
>       >     can't
>       >     > still be written outside of Option.
>       >     >
>       >     > def fromSome(opt: Option[A]) = opt match {
>       >     >   case Some(x) => x
>       >     >   case None => throw new
> NoSuchElementException("fromSome")
>       >     > }
>       >     >
>       >     > However, by putting "Option.get" (and even "orNull" and
> possibly
>       >     > others) in the standard library, it encourages
> programmers to use
>       >     > unsafe methods by making it easy. I get the impression
> that such
>       >     > unsafe methods are generally included in the Scala
> libraries. So, I
>       >     > suppose my real question should be: Why are unsafe
> methods
>       >     included in
>       >     > the standard libraries?
>       >     >
>       >     > Regards,
>       >     > Sean
>       >
>       >     --
>       >     Tony Morris
>       >     http://tmorris.net/
>       >
>       >
>       >
>
>
>
>       --
>
>       Tony Morris
>       http://tmorris.net/
>
>
>
>

I said something along the lines of "Since Scala is turing-complete,
Scala *must* have the Option.get method or some equivalent that would
ultimately not alleviate the concerns expressed (safety)." I strongly
recommend we all go away and play with Coq (or any total language) for a
while, then revisit this discussion.

Naftoli Gugenheim wrote:
> I'm not sure what you mean, but my question was to Tony, about his
> idea that because the language inherently is not completely safe, that
> is a reason to have a particular unsafe method.
>
>
> On Thu, Aug 19, 2010 at 7:47 AM, Detering Dirk
> > wrote:
>
> > Hmm... Is 0 unsafe methods better?
> >
> > Meaning, do you say "no" because of some all-or-nothing
> principle; or
> > because it's pointless to eliminate unsafe methods in a language
> that's
> > turing complete and therefore not inherently safe anyway?
> >
> > Also, when you "no" to the question "isn't it better..." do you mean
> > that it's not better in any way at all, or that any way that it
> might
> > be better is insignificant (relatively or absolutely)?
>
> Where does this questionnaire lead to?
>
> Perhaps "no" in the sense of: No.
>
> By simply reducing the account of 10 by 1 without considering the
> context
> and semantics of all 10 methods and without defining the word
> "better" and how
> you quantify it, we are in a situation where answering your
> question with
> 'yes' would simply be wrong. So the short answer is: 'no'.
>
>
>
> >
> >
> > On Wed, Aug 18, 2010 at 4:54 AM, Tony Morris
> >
> > wrote:
> >
> >
> > No.
> >
> >
> > Naftoli Gugenheim wrote:
> > > Okay, but isn't it better to have 9 unsafe methods than 10
> > unsafe
> > > methods?
> > >
> > >
> > > On Fri, Aug 13, 2010 at 10:38 PM, Tony Morris
> >
> >
> > > >> wrote:
> > >
> > > Sean,
> > > Scala *must* have unsafe methods. It's absolutely
> > necessary.
> > > Nothing is
> > > solved by moving or removing the get function in this
> > respect.
> > >
> > > Sean Leather wrote:
> > > > Thanks for the response. There are quite a few replies
> > here, and I'm
> > > > certain I don't understand most. As a result, I
> will try
> > to
> > > clarify my
> > > > question.
> > > >
> > > > Why does the method "get" exist in the Option
> class?
> > > >
> > > >
> > > > The point of this question is that the method
> "get" is by
> > definition
> > > > unsafe. By unsafe, I mean that it will likely lead a
> > programmer who
> > > > uses it into error. Why is it unsafe? Let's review the
> > code:
> > > >
> > > >
> > > > sealed abstract class Option[+A] extends Product {
> > def get: A }
> > > > final case class Some[+A](x: A) extends
> Option[A] {
> > def get
> > > = x }
> > > > case object None extends Option[Nothing] { def
> get =
> > throw new
> > > > NoSuchElementException("None.get") }
> > > >
> > > >
> > > > Since "get" is defined in the class Option, there
> is an
> > implication
> > > > that each subclass will override it and return some A
> > value. Looking
> > > > at each inheritor, we see that Some overrides and
> results
> > in a
> > > value,
> > > > but None throws an exception. Since there are only two
> > > subclasses and
> > > > half of them are exceptional cases, I'd say it's
> pretty
> > clear that
> > > > "get" will lead somebody into error. Thus, it is
> unsafe.
> > > >
> > > > For reasons of type safety, shouldn't "get" only
> > exist in
> > > Some? Or
> > > > is this just another way of replacing
> > "x.getOrElse(default)"
> > > with
> > > > "try { x.get } catch { default }"?
> > > >
> > > >
> > > > I'm suggesting that "get" not be defined in Option but
> > rather in
> > > Some.
> > > > That provides one way to get the value out of
> Some. But
> > how do
> > > you get
> > > > the value out of an Option? Again, I'm new to
> Scala but I
> > > already see
> > > > multiple ways:
> > > >
> > > > * getOrElse
> > > > * foreach/for
> > > > * iterator
> > > > * opt match { case Some(x) => ... ; case None
> => ...
> > }
> > > >
> > > > And I'm sure there are others.
> > > >
> > > > Of course, this is not to say that a method
> equivalent to
> > "get"
> > > can't
> > > > still be written outside of Option.
> > > >
> > > > def fromSome(opt: Option[A]) = opt match {
> > > > case Some(x) => x
> > > > case None => throw new
> > NoSuchElementException("fromSome")
> > > > }
> > > >
> > > > However, by putting "Option.get" (and even
> "orNull" and
> > possibly
> > > > others) in the standard library, it encourages
> > programmers to use
> > > > unsafe methods by making it easy. I get the impression
> > that such
> > > > unsafe methods are generally included in the Scala
> > libraries. So, I
> > > > suppose my real question should be: Why are unsafe
> > methods
> > > included in
> > > > the standard libraries?
> > > >
> > > > Regards,
> > > > Sean
> > >
> > > --
> > > Tony Morris
> > > http://tmorris.net/
> > >
> > >
> > >
> >
> >
> >
> > --
> >
> > Tony Morris
> > http://tmorris.net/
> >
> >
> >
> >
>
>

Dear Tony,

On Fri, Aug 20, 2010 at 13:43, Tony Morris wrote:

I said something along the lines of "Since Scala is turing-complete,
Scala *must* have the Option.get method or some equivalent that would
ultimately not alleviate the concerns expressed (safety)." I strongly
recommend we all go away and play with Coq (or any total language) for a
while, then revisit this discussion.

I never said that Scala should not have partial or unsafe functions, and I don't think anyone else in this thread has suggested such a thing. So, while you continue to insist on this, it is, as far as I can tell, outside the point of discussion.

I think Naftoli's questions are valid and are precisely what I was getting at with my initial question.

On Wed, Aug 18, 2010 at 21:50, Naftoli Gugenheim wrote:

Hmm... Is 0 unsafe methods better?
Meaning, do you say "no" because of some all-or-nothing principle; or because it's pointless to eliminate unsafe methods in a language that's turing complete and therefore not inherently safe anyway?
Also, when you "no" to the question "isn't it better..." do you mean that it's not better in any way at all, or that any way that it might be better is insignificant (relatively or absolutely)?

You do not give a sufficient response to this, and I'm still left wondering about the context to your vague "No."

It is clear that Scala as a language must, in order to inter-operate with Java, support many of the unsafe features that Java supports.

What is not clear is how one designs a library in Scala. I claim that Option.get is an element of bad library design, because there are many other ways to more safely achieve the same thing. I understand how it's used, and I see that everybody who responded in favor of it had a practical reason, e.g. I know it should work or I want it to fail. In general, people want it as a shortcut or quick-and-easy solution. But those responses do not see the mine in the minefield. By supporting numerous unsafe methods (yes, including List.head and List.tail), the Scala libraries are encouraging quick-and-easy solutions over type-safe ones.

Personally, I do not think this is the best approach. But I also see that my opinion is not shared by many in the (mailing list) community. It appears that this thread is not going to answer anybody's questions or make anybody happier, so I propose that we move on and let the dust settle before bringing it up again in a different thread. ;)

Regards,
Sean

Sean Leather wrote:
(...)
> those responses do not see the mine in the minefield. By supporting
> numerous unsafe methods (yes, including List.head and List.tail), the
> Scala libraries are encouraging quick-and-easy solutions over
> type-safe ones.

By this reasoning, aren't we doomed anyway, since the "." operator is
also inherently unsafe?

Regards
Andreas

i cannot follow this argumentation.
if i know that my list has to contain a head, i should be allowed to call head. otherwise, i'd just call headOption.get, which is unsafe as well.

if my list doesn't have a head but is supposed to, what should i do? throw an exception. which is exactly what "head" does if there is no head.

i don't see a safer way to deal with crappy input than just throwing an exception.

-------- Original-Nachricht --------
> Datum: Fri, 20 Aug 2010 14:53:55 +0200
> Von: Andreas Flierl
> An: Sean Leather
> CC: Scala Users Lists
> Betreff: Re: [scala-user] Re: Why have method "get" in Option?

>
> Sean Leather wrote:
> (...)
> > those responses do not see the mine in the minefield. By supporting
> > numerous unsafe methods (yes, including List.head and List.tail), the
> > Scala libraries are encouraging quick-and-easy solutions over
> > type-safe ones.
>
> By this reasoning, aren't we doomed anyway, since the "." operator is
> also inherently unsafe?
>
> Regards
> Andreas

Sean Leather wrote:
> Dear Tony,
>
> On Fri, Aug 20, 2010 at 13:43, Tony Morris wrote:
>
> I said something along the lines of "Since Scala is turing-complete,
> Scala *must* have the Option.get method or some equivalent that would
> ultimately not alleviate the concerns expressed (safety)." I strongly
> recommend we all go away and play with Coq (or any total language)
> for a
> while, then revisit this discussion.
>
>
> I never said that Scala should not have partial or unsafe functions,
> and I don't think anyone else in this thread has suggested such a
> thing. So, while you continue to insist on this, it is, as far as I
> can tell, outside the point of discussion.
Sean, I didn't say you said this. You said something like "for reasons
of type-safety...should get exist on Some not Option?" I have tried
explaining a very relevant answer to this question in several ways to
the benefit of a few, but not all*. I do not think I can help you any
further, but if I see an indication that might suggest otherwise, I'll
keep trying. I will try one short diversion in an effort to help.

Observe that scala.Some (which should not be a type but a constructor
for Option) is equivalent to what is more commonly called Identity [case
class Identity[A](a: A)] such that:

Option: 0 or 1 theorems
Identity: 1 theorem
List: 0 or many theorems
NonEmptyList: 1 or many theorems

The "get" method is of the form M[A] => A and we note that neither
Option nor List can satisfy this signature consistently. This (M) is
called a copointed functor and so we can say that Option and List are
not copointed functors, but this is not reason to remove get or head
functions (which has been explained earlier). As it happens Identity and
NonEmptyList are both copointed functors by satsifying this signature
and all the other requirements.

I doubt this will help, but you can see I am grasping at straws.

* as you may have noticed, I've attracted the attention of a rather dim
light bulb, which I encourage you to ignore.

On Fri, Aug 20, 2010 at 2:28 PM, Tony Morris <tonymorris@gmail.com> wrote:

* as you may have noticed, I've attracted the attention of a rather dim
light bulb, which I encourage you to ignore.

Is that right? You poor guy! Maybe you shouldn't have STARTED that private correspondence with that "dim light bulb" and repeatedly made such asinine assertions.

By the way, if it was obvious whom I was corresponding with, is that my fault? I provided absolutely no personal information. Is it my fault that you can smell this guy from a mile away?

If you are afraid of having others see what you write in private even without being identified, maybe you shouldn't write it.

--
http://RussP.us

Perfectly lucid. The critical pedagogical stroke (for me) was the introduction of the term "co-pointed functor".



On Fri, Aug 20, 2010 at 5:28 PM, Tony Morris <tonymorris@gmail.com> wrote:

Sean Leather wrote:
> Dear Tony,
>
> On Fri, Aug 20, 2010 at 13:43, Tony Morris wrote:
>
>     I said something along the lines of "Since Scala is turing-complete,
>     Scala *must* have the Option.get method or some equivalent that would
>     ultimately not alleviate the concerns expressed (safety)." I strongly
>     recommend we all go away and play with Coq (or any total language)
>     for a
>     while, then revisit this discussion.
>
>
> I never said that Scala should not have partial or unsafe functions,
> and I don't think anyone else in this thread has suggested such a
> thing. So, while you continue to insist on this, it is, as far as I
> can tell, outside the point of discussion.
Sean, I didn't say you said this. You said something like "for reasons
of type-safety...should get exist on Some not Option?" I have tried
explaining a very relevant answer to this question in several ways to
the benefit of a few, but not all*. I do not think I can help you any
further, but if I see an indication that might suggest otherwise, I'll
keep trying.  I will try one short diversion in an effort to help.

Observe that scala.Some (which should not be a type but a constructor
for Option) is equivalent to what is more commonly called Identity [case
class Identity[A](a: A)] such that:

Option: 0 or 1 theorems
Identity: 1 theorem
List: 0 or many theorems
NonEmptyList: 1 or many theorems

The "get" method is of the form M[A] => A and we note that neither
Option nor List can satisfy this signature consistently. This (M) is
called a copointed functor and so we can say that Option and List are
not copointed functors, but this is not reason to remove get or head
functions (which has been explained earlier). As it happens Identity and
NonEmptyList are both copointed functors by satsifying this signature
and all the other requirements.

I doubt this will help, but you can see I am grasping at straws.

* as you may have noticed, I've attracted the attention of a rather dim
light bulb, which I encourage you to ignore.

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

--
Bradley R. Buchsbaum
Rotman Research Institute
3560 Bathurst St.
Toronto, ON Canada M6A 2E1
email: bbuchsbaum@rotman-baycrest.on.ca

Or differently stated (but semantically equivalent)

Option and List are examples of Monads

Others (Identity, NonEmpty list)

Are co-Monads ?

But for that Hutton book will need to progress to the next level (this train ran out of fuel:) but curiosity continues. Will need to now line up a) execute some haskell functor constructs and their duals

b) sneak in into math department and ask some poor soul for examples, category is category any example will do

Generally , to know, in what, circumstances, constructing duals helps , taking from algebraic topology let say, there are areas where cohomology formulation (dual and local) makes for better and easier proof construction than homology (global) . Similarily I think, computational (or rather conceptually computational ideas such as discussion on the Option in this thread) could yield in the similar direction but probably benefit folks from the theoretical realm but I suspect all given some "motivation"

cheers

Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: Tony Morris
Date: Sat, 21 Aug 2010 07:28:30
To: Sean Leather
Cc: Scala Users Lists; Naftoli Gugenheim
Subject: Re: [scala-user] Re: Why have method "get" in Option?

Sean Leather wrote:
> Dear Tony,
>
> On Fri, Aug 20, 2010 at 13:43, Tony Morris wrote:
>
> I said something along the lines of "Since Scala is turing-complete,
> Scala *must* have the Option.get method or some equivalent that would
> ultimately not alleviate the concerns expressed (safety)." I strongly
> recommend we all go away and play with Coq (or any total language)
> for a
> while, then revisit this discussion.
>
>
> I never said that Scala should not have partial or unsafe functions,
> and I don't think anyone else in this thread has suggested such a
> thing. So, while you continue to insist on this, it is, as far as I
> can tell, outside the point of discussion.
Sean, I didn't say you said this. You said something like "for reasons
of type-safety...should get exist on Some not Option?" I have tried
explaining a very relevant answer to this question in several ways to
the benefit of a few, but not all*. I do not think I can help you any
further, but if I see an indication that might suggest otherwise, I'll
keep trying. I will try one short diversion in an effort to help.

Observe that scala.Some (which should not be a type but a constructor
for Option) is equivalent to what is more commonly called Identity [case
class Identity[A](a: A)] such that:

Option: 0 or 1 theorems
Identity: 1 theorem
List: 0 or many theorems
NonEmptyList: 1 or many theorems

The "get" method is of the form M[A] => A and we note that neither
Option nor List can satisfy this signature consistently. This (M) is
called a copointed functor and so we can say that Option and List are
not copointed functors, but this is not reason to remove get or head
functions (which has been explained earlier). As it happens Identity and
NonEmptyList are both copointed functors by satsifying this signature
and all the other requirements.

I doubt this will help, but you can see I am grasping at straws.

* as you may have noticed, I've attracted the attention of a rather dim
light bulb, which I encourage you to ignore.

Hi Andrew,
What you have said is mostly correct. Option and List are examples of
pointed functors. All monads are pointed functors, so this is a less
specific statement than yours. A pointed functor (M) is A => M[A] which
both Option and List can easily witness. All type constructors so far
discussed are covariant functors, map: M[A] => (A => B) => M[B] but not
all are pointed (A => M[A]) and not all are copointed (M[A] => A).

Monads have an additional operation on top of map and point: M[M[A]] =>
M[A] often called "join" or "flatten" while comonads have (in addition
to map and copoint) M[A] => M[M[A]] often called "extract."

Andrew Milkowski wrote:
> Or differently stated (but semantically equivalent)
>
> Option and List are examples of Monads
>
> Others (Identity, NonEmpty list)
>
> Are co-Monads ?
>
> But for that Hutton book will need to progress to the next level (this train ran out of fuel:) but curiosity continues. Will need to now line up a) execute some haskell functor constructs and their duals
>
> b) sneak in into math department and ask some poor soul for examples, category is category any example will do
>
> Generally , to know, in what, circumstances, constructing duals helps , taking from algebraic topology let say, there are areas where cohomology formulation (dual and local) makes for better and easier proof construction than homology (global) . Similarily I think, computational (or rather conceptually computational ideas such as discussion on the Option in this thread) could yield in the similar direction but probably benefit folks from the theoretical realm but I suspect all given some "motivation"
>
> cheers
>
>
> Sent from my Verizon Wireless BlackBerry
>
> -----Original Message-----
> From: Tony Morris
> Date: Sat, 21 Aug 2010 07:28:30
> To: Sean Leather
> Cc: Scala Users Lists; Naftoli Gugenheim
> Subject: Re: [scala-user] Re: Why have method "get" in Option?
>
>
> Sean Leather wrote:
>
>> Dear Tony,
>>
>> On Fri, Aug 20, 2010 at 13:43, Tony Morris wrote:
>>
>> I said something along the lines of "Since Scala is turing-complete,
>> Scala *must* have the Option.get method or some equivalent that would
>> ultimately not alleviate the concerns expressed (safety)." I strongly
>> recommend we all go away and play with Coq (or any total language)
>> for a
>> while, then revisit this discussion.
>>
>>
>> I never said that Scala should not have partial or unsafe functions,
>> and I don't think anyone else in this thread has suggested such a
>> thing. So, while you continue to insist on this, it is, as far as I
>> can tell, outside the point of discussion.
>>
> Sean, I didn't say you said this. You said something like "for reasons
> of type-safety...should get exist on Some not Option?" I have tried
> explaining a very relevant answer to this question in several ways to
> the benefit of a few, but not all*. I do not think I can help you any
> further, but if I see an indication that might suggest otherwise, I'll
> keep trying. I will try one short diversion in an effort to help.
>
> Observe that scala.Some (which should not be a type but a constructor
> for Option) is equivalent to what is more commonly called Identity [case
> class Identity[A](a: A)] such that:
>
> Option: 0 or 1 theorems
> Identity: 1 theorem
> List: 0 or many theorems
> NonEmptyList: 1 or many theorems
>
> The "get" method is of the form M[A] => A and we note that neither
> Option nor List can satisfy this signature consistently. This (M) is
> called a copointed functor and so we can say that Option and List are
> not copointed functors, but this is not reason to remove get or head
> functions (which has been explained earlier). As it happens Identity and
> NonEmptyList are both copointed functors by satsifying this signature
> and all the other requirements.
>
> I doubt this will help, but you can see I am grasping at straws.
>
> * as you may have noticed, I've attracted the attention of a rather dim
> light bulb, which I encourage you to ignore.
>
>

Excellent, thanks
------Original Message------
From: Tony Morris
To: andrewmilkowski@gmail.com
Cc: Sean Leather
Cc: Scala Users Lists
Cc: Naftoli Gugenheim
Subject: Re: [scala-user] Re: Why have method "get" in Option?
Sent: Aug 20, 2010 7:34 PM

Hi Andrew,
What you have said is mostly correct. Option and List are examples of
pointed functors. All monads are pointed functors, so this is a less
specific statement than yours. A pointed functor (M) is A => M[A] which
both Option and List can easily witness. All type constructors so far
discussed are covariant functors, map: M[A] => (A => B) => M[B] but not
all are pointed (A => M[A]) and not all are copointed (M[A] => A).

Monads have an additional operation on top of map and point: M[M[A]] =>
M[A] often called "join" or "flatten" while comonads have (in addition
to map and copoint) M[A] => M[M[A]] often called "extract."

Andrew Milkowski wrote:
> Or differently stated (but semantically equivalent)
>
> Option and List are examples of Monads
>
> Others (Identity, NonEmpty list)
>
> Are co-Monads ?
>
> But for that Hutton book will need to progress to the next level (this train ran out of fuel:) but curiosity continues. Will need to now line up a) execute some haskell functor constructs and their duals
>
> b) sneak in into math department and ask some poor soul for examples, category is category any example will do
>
> Generally , to know, in what, circumstances, constructing duals helps , taking from algebraic topology let say, there are areas where cohomology formulation (dual and local) makes for better and easier proof construction than homology (global) . Similarily I think, computational (or rather conceptually computational ideas such as discussion on the Option in this thread) could yield in the similar direction but probably benefit folks from the theoretical realm but I suspect all given some "motivation"
>
> cheers
>
>
> Sent from my Verizon Wireless BlackBerry
>
> -----Original Message-----
> From: Tony Morris
> Date: Sat, 21 Aug 2010 07:28:30
> To: Sean Leather
> Cc: Scala Users Lists; Naftoli Gugenheim
> Subject: Re: [scala-user] Re: Why have method "get" in Option?
>
>
> Sean Leather wrote:
>
>> Dear Tony,
>>
>> On Fri, Aug 20, 2010 at 13:43, Tony Morris wrote:
>>
>> I said something along the lines of "Since Scala is turing-complete,
>> Scala *must* have the Option.get method or some equivalent that would
>> ultimately not alleviate the concerns expressed (safety)." I strongly
>> recommend we all go away and play with Coq (or any total language)
>> for a
>> while, then revisit this discussion.
>>
>>
>> I never said that Scala should not have partial or unsafe functions,
>> and I don't think anyone else in this thread has suggested such a
>> thing. So, while you continue to insist on this, it is, as far as I
>> can tell, outside the point of discussion.
>>
> Sean, I didn't say you said this. You said something like "for reasons
> of type-safety...should get exist on Some not Option?" I have tried
> explaining a very relevant answer to this question in several ways to
> the benefit of a few, but not all*. I do not think I can help you any
> further, but if I see an indication that might suggest otherwise, I'll
> keep trying. I will try one short diversion in an effort to help.
>
> Observe that scala.Some (which should not be a type but a constructor
> for Option) is equivalent to what is more commonly called Identity [case
> class Identity[A](a: A)] such that:
>
> Option: 0 or 1 theorems
> Identity: 1 theorem
> List: 0 or many theorems
> NonEmptyList: 1 or many theorems
>
> The "get" method is of the form M[A] => A and we note that neither
> Option nor List can satisfy this signature consistently. This (M) is
> called a copointed functor and so we can say that Option and List are
> not copointed functors, but this is not reason to remove get or head
> functions (which has been explained earlier). As it happens Identity and
> NonEmptyList are both copointed functors by satsifying this signature
> and all the other requirements.
>
> I doubt this will help, but you can see I am grasping at straws.
>
> * as you may have noticed, I've attracted the attention of a rather dim
> light bulb, which I encourage you to ignore.
>
>

On Fri, Aug 20, 2010 at 4:34 PM, Tony Morris <tonymorris@gmail.com> wrote:

Hi Andrew,
What you have said is mostly correct. Option and List are examples of
pointed functors. All monads are pointed functors, so this is a less
specific statement than yours. A pointed functor (M) is A => M[A] which
both Option and List can easily witness. All type constructors so far
discussed are covariant functors, map: M[A] => (A => B) => M[B] but not
all are pointed (A => M[A]) and not all are copointed (M[A] => A).

Monads have an additional operation on top of map and point: M[M[A]] =>
M[A] often called "join" or "flatten" while comonads have (in addition
to map and copoint) M[A] => M[M[A]] often called "extract."

Holy copointed functor, Batman! Break out the Bat-translator for this one!

In an earlier post, in reply to my claim that the main functionality of Option could be achieved with List or Set, this Scala instructor wrote:

"What you probably really mean is that there is an injective from Option to List but not a surjective function or perhaps that there is not an
arrow from Option to Identity*."

No, I meant exactly what I wrote. No Bat translator needed. You keep trying to "guess" what I mean, but it never seems to occur to you to just read what I wrote.

Let's try plain English. An Option and a List (of length zero or one) contain exactly the same information. In fact, Option has a "toList" method to convert an Option to a List. Wow! Imagine that! So I figured, why not write a function to convert back the other way, from a List to an Option. Here it is:


    def ListToOption(list: List[Int]): Option[Int] =

        if (list isEmpty) None else Option(list head)


But what about my claim that the basic functionality of Option can be achieved with List? This Scala instructor replied at various times as follows:

Reply 1:

This is not true.

Reply 2:

"List (or Array or Set for that matter) could be used to achieve the same basic functionality [as Option]."

This is outright false. One can only guess why you think it is true, because it is complete nonsense. Does this make sense yet?

Reply 3:

Hey Russ,
Do you know you have a habit of making unsubstantiated claims? Let me give you an example:

"List (or Array or Set for that matter) could be used to achieve the same basic functionality [as Option]."

You see, not only is this not substantiated, but it is complete and utter bullshit. Proving bullshit is not a habit of mine -- the burden of proof lay elsewhere -- check the mirror.

<end of replies>

So just for fun, I decided to disprove these arrogant and bogus assertions by a Scala instructor. Even though I'm an aerospace engineer and not the most advanced Scala developer, it was not hard. I wrote a little class called "OptionBasedOnList" and gave it a few of the basic methods of Option. More could be added fairly easily. (By the way, I tried to extend List, but it is a sealed class.) I don't know if all the methods of Option could be added, but that is beside the point. Here it is:


    class OptionBasedOnList[A](val list: List[A]=Nil) {

        def get[B >: A] = list head

        def getOrElse[B >: A](default: B) =
            if (list isEmpty) default else list head

        def foreach[U](f: A => U) = list foreach(f)

        def isEmpty = list isEmpty

        override def toString = list.toString
        }

    object OptionBasedOnList {

        def apply[A](x: A): OptionBasedOnList[A] = {

            val list1 = if (x == null) List[A]() else List(x)

            new OptionBasedOnList(list1)
            }
        }


So there you have it. It uses List to perform the the same basic functionality as Option, which the Scala instructor said couldn't be done. He was clearly wrong. He knows all about "copointed functors," but the obvious relationiship between Option and List totally eludes him? Give me a break!

Pedantic instructors like this guy are more likely to turn people against Scala than to persuade them to use it. I work on problems in which 500 lives could be at stake in a single incident. You can be 100% sure that "copointed functors" will never come up in solving these problems.

I'm going to pump some iron. Have a nice day.

Russ P.

Le 22/08/2010 02:44, Russ Paielli a écrit :

QVk9LdiP [at] mail [dot] gmail [dot] com" type="cite">On Fri, Aug 20, 2010 at 4:34 PM, Tony Morris <tonymorris [at] gmail [dot] com" target="_blank" rel="nofollow">tonymorris@gmail.com> wrote:

Hi Andrew,
What you have said is mostly correct. Option and List are examples of
pointed functors. All monads are pointed functors, so this is a less
specific statement than yours. A pointed functor (M) is A => M[A] which
both Option and List can easily witness. All type constructors so far
discussed are covariant functors, map: M[A] => (A => B) => M[B] but not
all are pointed (A => M[A]) and not all are copointed (M[A] => A).

Monads have an additional operation on top of map and point: M[M[A]] =>
M[A] often called "join" or "flatten" while comonads have (in addition
to map and copoint) M[A] => M[M[A]] often called "extract."

Holy copointed functor, Batman! Break out the Bat-translator for this one!

In an earlier post, in reply to my claim that the main functionality of Option could be achieved with List or Set, this Scala instructor wrote:

"What you probably really mean is that there is an injective from Option to List but not a surjective function or perhaps that there is not an
arrow from Option to Identity*."

No, I meant exactly what I wrote. No Bat translator needed. You keep trying to "guess" what I mean, but it never seems to occur to you to just read what I wrote.

Tony just formalized what you wrote. Could you define "main functionality of Option"?

QVk9LdiP [at] mail [dot] gmail [dot] com" type="cite"> Let's try plain English. An Option and a List (of length zero or one) contain exactly the same information.

Not for the type system. How do you encode "of length zero or one" in the type system? If you read papers mentioned by Tony, you will see that types are used to prove things about programs.

QVk9LdiP [at] mail [dot] gmail [dot] com" type="cite"> In fact, Option has a "toList" method to convert an Option to a List.

That's the "injective [function] from Option to List" previously mentioned by Tony.

QVk9LdiP [at] mail [dot] gmail [dot] com" type="cite"> Wow! Imagine that! So I figured, why not write a function to convert back the other way, from a List to an Option. Here it is:


    def ListToOption(list: List[Int]): Option[Int] =

        if (list isEmpty) None else Option(list head)

(This is headOption method already defined for List)
This is only one of the candidates for this function type. Instead of "list head", you might take "list tail head" or "list tail tail head" or "list tail tail tail head" etc. So with the type of ListToOption you can't prove anything. There is no bijection between List[A] and Option[A] (no surjective function from Option to List).

QVk9LdiP [at] mail [dot] gmail [dot] com" type="cite"> But what about my claim that the basic functionality of Option can be achieved with List? This Scala instructor replied at various times as follows:

Reply 1:

This is not true.

Reply 2:

"List (or Array or Set for that matter) could be used to achieve the same basic functionality [as Option]."

This is outright false. One can only guess why you think it is true, because it is complete nonsense. Does this make sense yet?

Reply 3:

Hey Russ,
Do you know you have a habit of making unsubstantiated claims? Let me give you an example:

"List (or Array or Set for that matter) could be used to achieve the same basic functionality [as Option]."

You see, not only is this not substantiated, but it is complete and utter bullshit. Proving bullshit is not a habit of mine -- the burden of proof lay elsewhere -- check the mirror.

<end of replies>

So just for fun, I decided to disprove these arrogant and bogus assertions by a Scala instructor.

Not a good idea.

QVk9LdiP [at] mail [dot] gmail [dot] com" type="cite"> Even though I'm an aerospace engineer and not the most advanced Scala developer, it was not hard. I wrote a little class called "OptionBasedOnList" and gave it a few of the basic methods of Option. More could be added fairly easily. (By the way, I tried to extend List, but it is a sealed class.) I don't know if all the methods of Option could be added, but that is beside the point. Here it is:

You re-implemented Option using an encapsulated List. Does it prove anything about "List achieving the same basic functionality as Option"? Why did you have to implement OptionBasedOnList in the first place if List and Option have the same basic functionality?

QVk9LdiP [at] mail [dot] gmail [dot] com" type="cite">
So there you have it. It uses List to perform the the same basic functionality as Option,

No, it's OptionBasedOnList that performs the same basic functionality as Option, not List.

QVk9LdiP [at] mail [dot] gmail [dot] com" type="cite"> which the Scala instructor said couldn't be done. He was clearly wrong. He knows all about "copointed functors," but the obvious relationiship between Option and List totally eludes him? Give me a break!

Pedantic instructors like this guy are more likely to turn people against Scala than to persuade them to use it.

Guess what, computer science is a... science. It's pretty boring for people who learned some of it to listen to people who didn't and that still claim the first are "clearly wrong". I'm glad there are CS people using Scala.

QVk9LdiP [at] mail [dot] gmail [dot] com" type="cite"> I work on problems in which 500 lives could be at stake in a single incident. You can be 100% sure that "copointed functors" will never come up in solving these problems.

And that's why aerospace companies still have to prove correctness of plain old C, ADA or Fortran programs as it was done 30 years ago.

QVk9LdiP [at] mail [dot] gmail [dot] com" type="cite">
I'm going to pump some iron. Have a nice day.

Russ P.

Regards
Sylvain

On Sat, Aug 21, 2010 at 7:06 PM, Sylvain HENRY <hsyl20@gmail.com> wrote:

Tony just formalized what you wrote. Could you define "main functionality of Option"?

I defined what I meant by that earlier. I mean passing an object that can have a valid value or not, and not using null or in-band signaling to indicate the absence of a valid value. I think you know what I meant.

You re-implemented Option using an encapsulated List. Does it prove anything about "List achieving the same basic functionality as Option"? Why did you have to implement OptionBasedOnList in the first place if List and Option have the same basic functionality?

I did that to make a point, but it wasn't necessary. I could just pass a List where I need an Option, and use existing methods of List (e.g., "foreach," "for," "isEmpty," etc.). That was my original point.

Guess what, computer science is a... science. It's pretty boring for people who learned some of it to listen to people who didn't and that still claim the first are "clearly wrong". I'm glad there are CS people using Scala.

It's a science that is of little value in the hands of pedants who can regurgitate the jargon but don't understand the practical import.

Regards,
Russ P

--
http://RussP.us

Hi,

On Fri, Aug 20, 2010 at 7:43 AM, Tony Morris <tonymorris@gmail.com> wrote:

I said something along the lines of "Since Scala is turing-complete,
Scala *must* have the Option.get method or some equivalent that would
ultimately not alleviate the concerns expressed (safety)." I strongly
recommend we all go away and play with Coq (or any total language) for a
while, then revisit this discussion.

Right, I remember you saying that, among other things. However, since I (and I think others) are not sure whether they understand your intention, I would appreciate if you could answer my question.
A quick recap:
Tony: Sean, Scala *must* have unsafe methods. It's absolutely necessary. Nothing is solved by moving or removing the get function in this respect. Me: Okay, but isn't it better to have 9 unsafe methods than 10 unsafe methods? [Meaning, how does "Scala must have unsafe methods" lead to "Nothing is solved by removing the get function in this respect." Maybe I should have noticed the added "in this respect": Perhaps Tony did not mean "nothing is gained" but rather, quite simply, that removing "get" won't solve or change the fact that Scala must have unsafe methods. (I won't get into why Scala must have any method--couldn't Scala hypothetically not have a standard library?--but that's tangential.) In any case if the latter is true, that Tony did not contradict the claim that "there is a pragmatic (not theoretical) gain to removing Option.get", then I'm not sure what bearing his comment has to the opening post, which was argued purely on pragmatic grounds. In any case if Tony will answer that 9 unsafe methods is better than 10, then he is relating to the pragmatic nature of the OP. If not, then his intent remains unclear to me...] Tony: No.Me: Hmm... Is 0 unsafe methods better? [Now if he answers "yes", then it would seem he is indeed relating to the practical nature of the OP---the practical disadvantage of unsafe methods---and the reason he said "no" to 9 is because he won't be happy with a partially safe language. But if he says "no" then it's clear that he meant that nothing is solved by removing unsafe methods from an unsafe language, period---presumably because it remains unsafe in theory, if not in practice.] Meaning, do you say "no" [to the previous question] because of some all-or-nothing principle; or because it's pointless to eliminate unsafe methods in a language that's turing complete and therefore not inherently safe anyway? Also, when you [say] "no" to the question "isn't it better..." do you mean that it's not better in any way at all, or that any way that it might be better is insignificant (relatively or absolutely)?


To answer the ambiguity Detering Dirk pointed out in my wording, the answer is simple: According to whatever criteria Tony was using. He said that nothing is solved by removing an unsafe method in an unsafe language. *Based on the context*, Tony's statement implied "removing it would not be better." So when I asked why do you imply that it's not better to have fewer unsafe methods, the definition of "better" was whichever definition was implied by Tony's vague (to some) question.

Naftoli Gugenheim wrote:
> I'm not sure what you mean, but my question was to Tony, about his
> idea that because the language inherently is not completely safe, that
> is a reason to have a particular unsafe method.
>
>
> On Thu, Aug 19, 2010 at 7:47 AM, Detering Dirk
> <Dirk.Detering@bitmarck.de <mailto:Dirk.Detering@bitmarck.de>> wrote:
>
>     > Hmm... Is 0 unsafe methods better?
>     >
>     > Meaning, do you say "no" because of some all-or-nothing
>     principle; or
>     > because it's pointless to eliminate unsafe methods in a language
>     that's
>     > turing complete and therefore not inherently safe anyway?
>     >
>     > Also, when you "no" to the question "isn't it better..." do you mean
>     > that it's not better in any way at all, or that any way that it
>     might
>     > be better is insignificant (relatively or absolutely)?
>
>     Where does this questionnaire lead to?
>
>     Perhaps "no" in the sense of: No.
>
>     By simply reducing the account of 10 by 1 without considering the
>     context
>     and semantics of all 10 methods and without defining the word
>     "better" and how
>     you quantify it, we are in a situation where answering your
>     question with
>     'yes' would simply be wrong.  So the short answer is: 'no'.
>
>
>
>     >
>     >
>     > On Wed, Aug 18, 2010 at 4:54 AM, Tony Morris
>     <tonymorris@gmail.com <mailto:tonymorris@gmail.com>>
>     > wrote:
>     >
>     >
>     >       No.
>     >
>     >
>     >       Naftoli Gugenheim wrote:
>     >       > Okay, but isn't it better to have 9 unsafe methods than 10
>     > unsafe
>     >       > methods?
>     >       >
>     >       >
>     >       > On Fri, Aug 13, 2010 at 10:38 PM, Tony Morris
>     > <tonymorris@gmail.com <mailto:tonymorris@gmail.com>
>     >
>     >       > <mailto:tonymorris@gmail.com
>     <mailto:tonymorris@gmail.com>>> wrote:
>     >       >
>     >       >     Sean,
>     >       >     Scala *must* have unsafe methods. It's absolutely
>     > necessary.
>     >       >     Nothing is
>     >       >     solved by moving or removing the get function in this
>     > respect.
>     >       >
>     >       >     Sean Leather wrote:
>     >       >     > Thanks for the response. There are quite a few replies
>     > here, and I'm
>     >       >     > certain I don't understand most. As a result, I
>     will try
>     > to
>     >       >     clarify my
>     >       >     > question.
>     >       >     >
>     >       >     >     Why does the method "get" exist in the Option
>     class?
>     >       >     >
>     >       >     >
>     >       >     > The point of this question is that the method
>     "get" is by
>     > definition
>     >       >     > unsafe. By unsafe, I mean that it will likely lead a
>     > programmer who
>     >       >     > uses it into error. Why is it unsafe? Let's review the
>     > code:
>     >       >     >
>     >       >     >
>     >       >     >     sealed abstract class Option[+A] extends Product {
>     > def get: A }
>     >       >     >     final case class Some[+A](x: A) extends
>     Option[A] {
>     > def get
>     >       >     = x }
>     >       >     >     case object None extends Option[Nothing] { def
>     get =
>     > throw new
>     >       >     >     NoSuchElementException("None.get") }
>     >       >     >
>     >       >     >
>     >       >     > Since "get" is defined in the class Option, there
>     is an
>     > implication
>     >       >     > that each subclass will override it and return some A
>     > value. Looking
>     >       >     > at each inheritor, we see that Some overrides and
>     results
>     > in a
>     >       >     value,
>     >       >     > but None throws an exception. Since there are only two
>     >       >     subclasses and
>     >       >     > half of them are exceptional cases, I'd say it's
>     pretty
>     > clear that
>     >       >     > "get" will lead somebody into error. Thus, it is
>     unsafe.
>     >       >     >
>     >       >     >     For reasons of type safety, shouldn't "get" only
>     > exist in
>     >       >     Some? Or
>     >       >     >     is this just another way of replacing
>     > "x.getOrElse(default)"
>     >       >     with
>     >       >     >     "try { x.get } catch { default }"?
>     >       >     >
>     >       >     >
>     >       >     > I'm suggesting that "get" not be defined in Option but
>     > rather in
>     >       >     Some.
>     >       >     > That provides one way to get the value out of
>     Some. But
>     > how do
>     >       >     you get
>     >       >     > the value out of an Option? Again, I'm new to
>     Scala but I
>     >       >     already see
>     >       >     > multiple ways:
>     >       >     >
>     >       >     >     * getOrElse
>     >       >     >     * foreach/for
>     >       >     >     * iterator
>     >       >     >     * opt match { case Some(x) => ... ; case None
>     => ...
>     > }
>     >       >     >
>     >       >     > And I'm sure there are others.
>     >       >     >
>     >       >     > Of course, this is not to say that a method
>     equivalent to
>     > "get"
>     >       >     can't
>     >       >     > still be written outside of Option.
>     >       >     >
>     >       >     > def fromSome(opt: Option[A]) = opt match {
>     >       >     >   case Some(x) => x
>     >       >     >   case None => throw new
>     > NoSuchElementException("fromSome")
>     >       >     > }
>     >       >     >
>     >       >     > However, by putting "Option.get" (and even
>     "orNull" and
>     > possibly
>     >       >     > others) in the standard library, it encourages
>     > programmers to use
>     >       >     > unsafe methods by making it easy. I get the impression
>     > that such
>     >       >     > unsafe methods are generally included in the Scala
>     > libraries. So, I
>     >       >     > suppose my real question should be: Why are unsafe
>     > methods
>     >       >     included in
>     >       >     > the standard libraries?
>     >       >     >
>     >       >     > Regards,
>     >       >     > Sean
>     >       >
>     >       >     --
>     >       >     Tony Morris
>     >       >     http://tmorris.net/
>     >       >
>     >       >
>     >       >
>     >
>     >
>     >
>     >       --
>     >
>     >       Tony Morris
>     >       http://tmorris.net/
>     >
>     >
>     >
>     >
>
>


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

Russ, I think the problem here is that you are interested in pragmatics: getting something to work, and thinking in those terms, which is fine. But some people are trained to see the world differently. By them everything is defined in terms of proofs and types and functional jargon. So there are two groups not speaking two different languages, but speaking about two different universes. Pragmatists and theorists, perhaps. Is one right or wrong? Is one *inherently* better? By the very nature of those two questions, it is not in human capacity to determine their answer.So ask a theorist: Why is your approach better? He can only hope to demonstrate how his approach yields better results (less errors, etc.), because any theoretical advantage of the theoretical view (which surely exists by definition) would amount to circular logic. Hence, the theorist's advantage would have to be a pragmatic one. But that means that he agrees that ultimately it's the pragmatic that matter; only he believes that the theoretical view is more pragmatic than the pragmatic one. So ultimately there's no debate---at the end of the day everyone is pragmatic. And he lived happily every after.THE END


On Sat, Aug 21, 2010 at 11:08 PM, Russ Paielli <russ.paielli@gmail.com> wrote:

On Sat, Aug 21, 2010 at 7:06 PM, Sylvain HENRY <hsyl20@gmail.com> wrote:

Tony just formalized what you wrote. Could you define "main functionality of Option"?

I defined what I meant by that earlier. I mean passing an object that can have a valid value or not, and not using null or in-band signaling to indicate the absence of a valid value. I think you know what I meant.

You re-implemented Option using an encapsulated List. Does it prove anything about "List achieving the same basic functionality as Option"? Why did you have to implement OptionBasedOnList in the first place if List and Option have the same basic functionality?

I did that to make a point, but it wasn't necessary. I could just pass a List where I need an Option, and use existing methods of List (e.g., "foreach," "for," "isEmpty," etc.). That was my original point.

Guess what, computer science is a... science. It's pretty boring for people who learned some of it to listen to people who didn't and that still claim the first are "clearly wrong". I'm glad there are CS people using Scala.

It's a science that is of little value in the hands of pedants who can regurgitate the jargon but don't understand the practical import.

Regards,
Russ P

--
http://RussP.us

Yes, that's all true, and it partly explains what's going here with this "discussion." However, I'm sure you will agree that no one can be all theoretical or all pragmatic all the time. Sometimes we're talking about theory, and sometimes we're talking about practical reality.

My initial statement, which I had didn't think would be the least bit "controversial," was a simple, practical statement. I merely stated that the basic functionality of Option could be achieved with List.

Let's do a little hypothetical thought experiment. Suppose Scala did not have the Option class, and you need to pass data to a function or return data from a function. Sometimes you have valid data, and sometimes you don't. What choices do you have? Well, you can use null or in-band signaling, of course. Oh, but wait ... if you do that, a certain Scala instructor will be disgusted with you. (In fact, when I even brought the idea of using -1 as an in-band signal for an invalid index, he tersely replied, "Do not do that.")

So what the hell are you going to do? Well, if you're brilliant and you have lots of time to spend, you could write Option yourself. But if you don't have time to go off on every tangent that comes up, that is not realistic. So what are you left with? Well, you could just return a List that could be empty or contain a valid value. Then, on the receiving end, you use "for" (or "isEmpty" to check for a valie). Problem solved!

Why does this have to be so controversial? Yes, I realize that List can contain more than one element. So what? Just don't use more than one element! The concern about "injection" and "surjection" is an abstract theoretical issue that is IRRELEVANT to the practical issue at hand. Yes, it is worthwhile to think about in the long term, but in the short term, List will do the frickin' job -- even if some pedantic goofball asserts that it can't. Good grief!

Russ P.


On Sat, Aug 21, 2010 at 9:56 PM, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

Russ, I think the problem here is that you are interested in pragmatics: getting something to work, and thinking in those terms, which is fine. But some people are trained to see the world differently. By them everything is defined in terms of proofs and types and functional jargon. So there are two groups not speaking two different languages, but speaking about two different universes. Pragmatists and theorists, perhaps. Is one right or wrong? Is one *inherently* better? By the very nature of those two questions, it is not in human capacity to determine their answer.So ask a theorist: Why is your approach better? He can only hope to demonstrate how his approach yields better results (less errors, etc.), because any theoretical advantage of the theoretical view (which surely exists by definition) would amount to circular logic. Hence, the theorist's advantage would have to be a pragmatic one. But that means that he agrees that ultimately it's the pragmatic that matter; only he believes that the theoretical view is more pragmatic than the pragmatic one. So ultimately there's no debate---at the end of the day everyone is pragmatic. And he lived happily every after.THE END


On Sat, Aug 21, 2010 at 11:08 PM, Russ Paielli <russ.paielli@gmail.com> wrote:

On Sat, Aug 21, 2010 at 7:06 PM, Sylvain HENRY <hsyl20@gmail.com> wrote:

Tony just formalized what you wrote. Could you define "main functionality of Option"?

I defined what I meant by that earlier. I mean passing an object that can have a valid value or not, and not using null or in-band signaling to indicate the absence of a valid value. I think you know what I meant.

You re-implemented Option using an encapsulated List. Does it prove anything about "List achieving the same basic functionality as Option"? Why did you have to implement OptionBasedOnList in the first place if List and Option have the same basic functionality?

I did that to make a point, but it wasn't necessary. I could just pass a List where I need an Option, and use existing methods of List (e.g., "foreach," "for," "isEmpty," etc.). That was my original point.

Guess what, computer science is a... science. It's pretty boring for people who learned some of it to listen to people who didn't and that still claim the first are "clearly wrong". I'm glad there are CS people using Scala.

It's a science that is of little value in the hands of pedants who can regurgitate the jargon but don't understand the practical import.

Regards,
Russ P

--
http://RussP.us

--
http://RussP.us

Hi Russ,

If you think you need to be brilliant to write something like Option then it means you have still have a few things to learn about FP, but really, anybody a bit curious and motivated could do it. It is really like learning to drive a bicycle and
it is easier if you have someone to guide you around until you get it.

It is a matter of composability, expressiveness and correctness. In FP a lot can be said by just looking at the signature of a function. Using List instead of Option, while what you really mean is this method returns zero or one value is a poor
hack in a programming language like Scala which can be a lot more expressive that Java. But the fact you can do it is the reason why Scala has a smooth learning curve and is really a good learning tool - you can still burry hacks deep into API's (in the short term) till you hit the wall (in the long term) then you can learn from your mistakes and fix things progressively using these new FP techniques you learned along the way.

With time you tend to see programs as proof of correctness but most of the programs we write are smaller or bigger lies that get the job done. Some people here will tell you that the Yoda way (maybe in stronger terms) just to let you start thinking there are things you don't know and hope steer your curiosity. The difficulty in this exercise is to estimate correctly the knowledge gap and tell someone who thinks he knows a lot because his programs work quite well usually that he is trying to prove a lie/bullshit in a tactful manner and by email. I noticed it is often at this point discussions tend to slip :-)

Sebastien

2010/8/22 Russ Paielli <russ.paielli@gmail.com>

Yes, that's all true, and it partly explains what's going here with this "discussion." However, I'm sure you will agree that no one can be all theoretical or all pragmatic all the time. Sometimes we're talking about theory, and sometimes we're talking about practical reality.

My initial statement, which I had didn't think would be the least bit "controversial," was a simple, practical statement. I merely stated that the basic functionality of Option could be achieved with List.

Let's do a little hypothetical thought experiment. Suppose Scala did not have the Option class, and you need to pass data to a function or return data from a function. Sometimes you have valid data, and sometimes you don't. What choices do you have? Well, you can use null or in-band signaling, of course. Oh, but wait ... if you do that, a certain Scala instructor will be disgusted with you. (In fact, when I even brought the idea of using -1 as an in-band signal for an invalid index, he tersely replied, "Do not do that.")

So what the hell are you going to do? Well, if you're brilliant and you have lots of time to spend, you could write Option yourself. But if you don't have time to go off on every tangent that comes up, that is not realistic. So what are you left with? Well, you could just return a List that could be empty or contain a valid value. Then, on the receiving end, you use "for" (or "isEmpty" to check for a valie). Problem solved!

Why does this have to be so controversial? Yes, I realize that List can contain more than one element. So what? Just don't use more than one element! The concern about "injection" and "surjection" is an abstract theoretical issue that is IRRELEVANT to the practical issue at hand. Yes, it is worthwhile to think about in the long term, but in the short term, List will do the frickin' job -- even if some pedantic goofball asserts that it can't. Good grief!

Russ P.


On Sat, Aug 21, 2010 at 9:56 PM, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

Russ, I think the problem here is that you are interested in pragmatics: getting something to work, and thinking in those terms, which is fine. But some people are trained to see the world differently. By them everything is defined in terms of proofs and types and functional jargon. So there are two groups not speaking two different languages, but speaking about two different universes. Pragmatists and theorists, perhaps. Is one right or wrong? Is one *inherently* better? By the very nature of those two questions, it is not in human capacity to determine their answer.So ask a theorist: Why is your approach better? He can only hope to demonstrate how his approach yields better results (less errors, etc.), because any theoretical advantage of the theoretical view (which surely exists by definition) would amount to circular logic. Hence, the theorist's advantage would have to be a pragmatic one. But that means that he agrees that ultimately it's the pragmatic that matter; only he believes that the theoretical view is more pragmatic than the pragmatic one. So ultimately there's no debate---at the end of the day everyone is pragmatic. And he lived happily every after.THE END


On Sat, Aug 21, 2010 at 11:08 PM, Russ Paielli <russ.paielli@gmail.com> wrote:

On Sat, Aug 21, 2010 at 7:06 PM, Sylvain HENRY <hsyl20@gmail.com> wrote:

Tony just formalized what you wrote. Could you define "main functionality of Option"?

I defined what I meant by that earlier. I mean passing an object that can have a valid value or not, and not using null or in-band signaling to indicate the absence of a valid value. I think you know what I meant.

You re-implemented Option using an encapsulated List. Does it prove anything about "List achieving the same basic functionality as Option"? Why did you have to implement OptionBasedOnList in the first place if List and Option have the same basic functionality?

I did that to make a point, but it wasn't necessary. I could just pass a List where I need an Option, and use existing methods of List (e.g., "foreach," "for," "isEmpty," etc.). That was my original point.

Guess what, computer science is a... science. It's pretty boring for people who learned some of it to listen to people who didn't and that still claim the first are "clearly wrong". I'm glad there are CS people using Scala.

It's a science that is of little value in the hands of pedants who can regurgitate the jargon but don't understand the practical import.

Regards,
Russ P

--
http://RussP.us

--
http://RussP.us

--
Sébastien

If I may repeat my earlier advice... please ignore it.

Sylvain HENRY wrote:
> Le 22/08/2010 02:44, Russ Paielli a écrit :
>> On Fri, Aug 20, 2010 at 4:34 PM, Tony Morris > > wrote:
>>
>> Hi Andrew,
>> What you have said is mostly correct. Option and List are examples of
>> pointed functors. All monads are pointed functors, so this is a less
>> specific statement than yours. A pointed functor (M) is A => M[A]
>> which
>> both Option and List can easily witness. All type constructors so far
>> discussed are covariant functors, map: M[A] => (A => B) => M[B]
>> but not
>> all are pointed (A => M[A]) and not all are copointed (M[A] => A).
>>
>> Monads have an additional operation on top of map and point:
>> M[M[A]] =>
>> M[A] often called "join" or "flatten" while comonads have (in
>> addition
>> to map and copoint) M[A] => M[M[A]] often called "extract."
>>
>>
>>
>> Holy copointed functor, Batman! Break out the Bat-translator for this
>> one!
>>
>> In an earlier post, in reply to my claim that the main functionality
>> of Option could be achieved with List or Set, this Scala instructor
>> wrote:
>>
>> "What you probably really mean is that there is an injective from
>> Option to List but not a surjective function or perhaps that there is
>> not an
>> arrow from Option to Identity*."
>>
>> No, I meant exactly what I wrote. No Bat translator needed. You keep
>> trying to "guess" what I mean, but it never seems to occur to you to
>> just read what I wrote.
>
> Tony just formalized what you wrote. Could you define "main
> functionality of Option"?
>> Let's try plain English. An Option and a List (of length zero or one)
>> contain exactly the same information.
> Not for the type system. How do you encode "of length zero or one" in
> the type system? If you read papers mentioned by Tony, you will see
> that types are used to prove things about programs.
>> In fact, Option has a "toList" method to convert an Option to a List.
> That's the "injective [function] from Option to List" previously
> mentioned by Tony.
>> Wow! Imagine that! So I figured, why not write a function to convert
>> back the other way, from a List to an Option. Here it is:
>>
>>
>> def ListToOption(list: List[Int]): Option[Int] =
>>
>> if (list isEmpty) None else Option(list head)
> (This is headOption method already defined for List)
> This is only one of the candidates for this function type. Instead of
> "list head", you might take "list tail head" or "list tail tail head"
> or "list tail tail tail head" etc. So with the type of ListToOption
> you can't prove anything. There is no bijection between List[A] and
> Option[A] (no surjective function from Option to List).
>> But what about my claim that the basic functionality of Option can be
>> achieved with List? This Scala instructor replied at various times as
>> follows:
>>
>> Reply 1:
>>
>> This is not true.
>>
>> Reply 2:
>>
>> "List (or Array or Set for that matter) could be used to achieve the
>> same basic functionality [as Option]."
>>
>> This is outright false. One can only guess why you think it is true,
>> because it is complete nonsense. Does this make sense yet?
>>
>> Reply 3:
>>
>> Hey Russ,
>> Do you know you have a habit of making unsubstantiated claims? Let me
>> give you an example:
>>
>> "List (or Array or Set for that matter) could be used to achieve the
>> same basic functionality [as Option]."
>>
>> You see, not only is this not substantiated, but it is complete and
>> utter bullshit. Proving bullshit is not a habit of mine -- the burden
>> of proof lay elsewhere -- check the mirror.
>>
>>
>>
>> So just for fun, I decided to disprove these arrogant and bogus
>> assertions by a Scala instructor.
> Not a good idea.
>> Even though I'm an aerospace engineer and not the most advanced Scala
>> developer, it was not hard. I wrote a little class called
>> "OptionBasedOnList" and gave it a few of the basic methods of Option.
>> More could be added fairly easily. (By the way, I tried to extend
>> List, but it is a sealed class.) I don't know if all the methods of
>> Option could be added, but that is beside the point. Here it is:
>>
> You re-implemented Option using an encapsulated List. Does it prove
> anything about "List achieving the same basic functionality as
> Option"? Why did you have to implement OptionBasedOnList in the first
> place if List and Option have the same basic functionality?
>>
>> So there you have it. It uses List to perform the the same basic
>> functionality as Option,
> No, it's OptionBasedOnList that performs the same basic functionality
> as Option, not List.
>> which the Scala instructor said couldn't be done. He was clearly
>> wrong. He knows all about "copointed functors," but the obvious
>> relationiship between Option and List totally eludes him? Give me a
>> break!
>>
>> Pedantic instructors like this guy are more likely to turn people
>> against Scala than to persuade them to use it.
> Guess what, computer science is a... science. It's pretty boring for
> people who learned some of it to listen to people who didn't and that
> still claim the first are "clearly wrong". I'm glad there are CS
> people using Scala.
>> I work on problems in which 500 lives could be at stake in a single
>> incident. You can be 100% sure that "copointed functors" will never
>> come up in solving these problems.
> And that's why aerospace companies still have to prove correctness of
> plain old C, ADA or Fortran programs as it was done 30 years ago.
>>
>> I'm going to pump some iron. Have a nice day.
>>
>> Russ P.
>>
> Regards
> Sylvain

Hi Naftoli,
I admire your enthusiasm, but I think you are on the wrong track. There
is nothing about "pragmatics" or "seeing the world differently" that
permits a blatantly false statement to become otherwise. I apologise for
my blunt and perhaps "not-as-helpful-as-we'd-both-like" responses to
your questions but as you can probably see, expanding often comes with
the extreme risk of attracting undesirable attention, which I will go to
extraordinary lengths to avoid, often at your expense :(

I'd be happy to make it up to you by providing you with less vague
answers that those previous, but it's difficult in the current climate.
I have no good answers to this dilemma. I lament and, perhaps cowardly,
put the ball in your court on this one, hoping you can come up with a
better solution than I.

Naftoli Gugenheim wrote:
> Russ, I think the problem here is that you are interested in
> pragmatics: getting something to work, and thinking in those terms,
> which is fine. But some people are trained to see the world
> differently. By them everything is defined in terms of proofs and
> types and functional jargon. So there are two groups not speaking two
> different languages, but speaking about two different universes.
> Pragmatists and theorists, perhaps.
> Is one right or wrong? Is one *inherently* better? By the very nature
> of those two questions, it is not in human capacity to determine their
> answer.
> So ask a theorist: Why is your approach better? He can only hope to
> demonstrate how his approach yields better results (less errors,
> etc.), because any theoretical advantage of the theoretical view
> (which surely exists by definition) would amount to circular logic.
> Hence, the theorist's advantage would have to be a pragmatic one. But
> that means that he agrees that ultimately it's the pragmatic that
> matter; only he believes that the theoretical view is more pragmatic
> than the pragmatic one. So ultimately there's no debate---at the end
> of the day everyone is pragmatic.
> And he lived happily every after.
> THE END
>
>
>
> On Sat, Aug 21, 2010 at 11:08 PM, Russ Paielli > wrote:
>
>
>
> On Sat, Aug 21, 2010 at 7:06 PM, Sylvain HENRY > wrote:
>
> Tony just formalized what you wrote. Could you define "main
> functionality of Option"?
>
>
> I defined what I meant by that earlier. I mean passing an object
> that can have a valid value or not, and not using null or in-band
> signaling to indicate the absence of a valid value. I think you
> know what I meant.
>
>>
> You re-implemented Option using an encapsulated List. Does it
> prove anything about "List achieving the same basic
> functionality as Option"? Why did you have to implement
> OptionBasedOnList in the first place if List and Option have
> the same basic functionality?
>
>
>
> I did that to make a point, but it wasn't necessary. I could just
> pass a List where I need an Option, and use existing methods of
> List (e.g., "foreach," "for," "isEmpty," etc.). That was my
> original point.
>
>
> Guess what, computer science is a... science. It's pretty
> boring for people who learned some of it to listen to people
> who didn't and that still claim the first are "clearly wrong".
> I'm glad there are CS people using Scala.
>
>
> It's a science that is of little value in the hands of pedants who
> can regurgitate the jargon but don't understand the practical import.
>
> Regards,
> Russ P
>
> --
> http://RussP.us
>
>

I think another issue is in terms of "truth".   Pragmatism is all about relative truth.  If it worked, then it must be true.   Thinking like that can lead to belief in spontaneous combustion.   It's always good to have someone who has a black and white view on truth validate our assumptions, or point us to the underlying concepts behind idioms we use every day.   An example of this is pushing people using random assignable values as "invalid" indicators on variables.   All of us who have done this and lived a long enough project have eventually gotten burned, either by someone know who didn't know the assumption and forgot to check his variables, or when we were coding ourselves and simply forgot about initialization.   Option insures you *never* forget about the non-initialization issue and that you, essentially, place walls around functions that use a particular variable.   These "walls"  will deal with the initialisation and then pass some value to the core logic of your system.   In other words, option (and initialisation checks) shouldn't permeate all of your code, as it does not have to.

Tony happens to be someone who knows many of the terms referencing specific concepts in functional programming.  These are specific idioms that you can encode into a language like Scala.  Often times pragmatics rediscover things that functional programmers have known about for years.   At these times, the "black and white scala instructor" will try to inform the developer with the "AHA!" moment which functional concept they've just rediscovered and the pros/cons of that particular idiom.   As they usually speak in theoretical "absolute truth" terms, sometimes users do not appreciate this.   Also, when in debates with pragmatics, the seasoned FP developer will whip out a bunch of these terms and idioms and it usually gives the pragmatic, who is a very smart person otherwise, a feeling of inferiority that leads to an explosion on this mailing list. 

What it comes down to, is there are a bunch of "Patterns" in functional program with research behind them and lots of write-ups.  I will say this once:  Do not ignore what Tony says.   If he uses a word you do not understand, take the hours or days to research what it means and why he used it.   Even if you're a pragmatic (like I am), this will improve your skills as a software developer and is usually rewarding.   Think of it as your opportunity to read "Design Patterns for Functional Programming".   Functional Programming just builds software in a very different manner than we are used to.

In terms of this specific debate:   Using List as an Option, while technically feasible, is dangerous for the same reason using -1 as un-initialised is bad.  You are not conveying the meaning you wish if you use a List.   In the absence of an Option class in the standard library, inevitable people would rediscover and write their own Option class.   Similar to the "loaner" pattern and Automatic Resource Management, which I've rediscovered on every project until I wrote scala-arm.

There is another side to this and this is of understanding the meaning of functions from their type signatures.   In an OO language, when discovering how a system works, we usually investigate the API in our IDE of choice and see a bunch of functions pop up from a class.   The Class name in combination with the method name and its arguments give us a good clue of what the function does.   We then call this function, write a unit test and make sure it does what we expected.   All of this wihthout reading the API documentation unless absolutely necessary (as it takes longer).

You can imagine in functional programming you'd like to do the same thing, discover how to use an API from signatures.   Well, what do you have available to you?   If you have a free standing function the *only* thing you can use to understand what's happening is the function's type signature.  This means you can use the type of the arguments and the type of the result and perhaps the name of the function.

The key here is the Option.foreach and List.foreach do *not* mean the same thing.  if the List has one item, then yes it would operator similarly.   However it does not convey the appropriate meaning to the programmer.    Also  OptionFromList's foreach should really be def foreach(f : A => Unit) = if(list.empty) () else f(list.head).   The .toList method on option is really designed to help satisfy the function     extractAllValid( stuff : List[Option[A]]) : List[A]  which could be based on the function:  
def what_is_my_name[A, M[_], N[_]](x : M[N[A]], y : N[A] => M[A]) : M[A].   (Note: You would need some monad implicit help here so you could flatten and perhaps a few others.  ).

In any case, the point is that those underlying functions have names and are meaningful and sound funny to our pragmatic ears.   I'm hoping over time, and perhaps with a few good books on Scala, some of these will become more natural to everyday programmers.

When it comes to turing complete languages and why it doesn't make sense to remove the get from option, well you should look at Coq.  If you want to work towards a more provably safe language you will end up moving in that direction.

Finally when it comes to this thread, I think the exchange of ideas has gotten to the hurt feeling stage.   At this point it's no longer productive to continue until things have settled down.   I'd ask those who wish to continue discussions to do so privately.

On Sun, Aug 22, 2010 at 12:56 AM, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

Russ, I think the problem here is that you are interested in pragmatics: getting something to work, and thinking in those terms, which is fine. But some people are trained to see the world differently. By them everything is defined in terms of proofs and types and functional jargon. So there are two groups not speaking two different languages, but speaking about two different universes. Pragmatists and theorists, perhaps. Is one right or wrong? Is one *inherently* better? By the very nature of those two questions, it is not in human capacity to determine their answer.So ask a theorist: Why is your approach better? He can only hope to demonstrate how his approach yields better results (less errors, etc.), because any theoretical advantage of the theoretical view (which surely exists by definition) would amount to circular logic. Hence, the theorist's advantage would have to be a pragmatic one. But that means that he agrees that ultimately it's the pragmatic that matter; only he believes that the theoretical view is more pragmatic than the pragmatic one. So ultimately there's no debate---at the end of the day everyone is pragmatic. And he lived happily every after.THE END


On Sat, Aug 21, 2010 at 11:08 PM, Russ Paielli <russ.paielli@gmail.com> wrote:

On Sat, Aug 21, 2010 at 7:06 PM, Sylvain HENRY <hsyl20@gmail.com> wrote:

Tony just formalized what you wrote. Could you define "main functionality of Option"?

I defined what I meant by that earlier. I mean passing an object that can have a valid value or not, and not using null or in-band signaling to indicate the absence of a valid value. I think you know what I meant.

You re-implemented Option using an encapsulated List. Does it prove anything about "List achieving the same basic functionality as Option"? Why did you have to implement OptionBasedOnList in the first place if List and Option have the same basic functionality?

I did that to make a point, but it wasn't necessary. I could just pass a List where I need an Option, and use existing methods of List (e.g., "foreach," "for," "isEmpty," etc.). That was my original point.

Guess what, computer science is a... science. It's pretty boring for people who learned some of it to listen to people who didn't and that still claim the first are "clearly wrong". I'm glad there are CS people using Scala.

It's a science that is of little value in the hands of pedants who can regurgitate the jargon but don't understand the practical import.

Regards,
Russ P

--
http://RussP.us

Russ,The practicality of something largely depends on what one intends to do with it.
Consider:/** sees if there is a Foo and if there is, returns it */def findFoo(): Option[Foo] = // ... versus:def findFoo(): List[Foo] = // ...
Those tell your fellow programmer very different things.  One says "this method will return 0..1 Foos", the other says "this method will return 0 to many Foos."  The multiplicity of the return values is made clear by Option, so the programmer using it doesn't need to look at the documentation to know what is really meant.
So Option versus List communicates something of practical value to people working with the code.
Likewise, it provides assurances that will be enforced by the compile.  Documentation and code have been known to deviate from one another over time.  Someone could change the implementation of findFoo(): List[Foo] such that it could return several Foos without changing the documentation or telling anyone.  In this case, most of the code that assumes the list is 0..1 is very silently broken.  The compiler doesn't catch it, and unless someone was really anal and asserted that the returned list indeed didn't have more than one element (I do this all the time), the code won't even noisily fail at runtime.  It will just hum along and produce a likely invalid result.
If the signature is def findFoo(): Option[Foo], and someone comes along and changes it to def findFoo(): List[Foo] because it really could return several Foos, then the compiler will noisily inform him of how much code he is breaking in his immediate codebase, and any people using his code will be informed by the compiler of problems as soon as they update to the new code.
One could use a bunch of arcane CS terms to describe this, but I like the way one of my CS professors put it better.  The compiler is your friend.  Share as much information with it as you can.
Now, this all assumes that being told by the compiler about likely broken code is of practical importance.  It is always of practical importance at some point before the code enters a real system (especially one were lives are at stake).  But it is not necessarily of practical importance at early stages, because relative to other problems these are often just a distraction.  I personally don't find Scala good for these early stages.  Python is better.
-Erik
On Sat, Aug 21, 2010 at 11:08 PM, Russ Paielli <russ.paielli@gmail.com> wrote:

On Sat, Aug 21, 2010 at 7:06 PM, Sylvain HENRY <hsyl20@gmail.com> wrote:

Tony just formalized what you wrote. Could you define "main functionality of Option"?

I defined what I meant by that earlier. I mean passing an object that can have a valid value or not, and not using null or in-band signaling to indicate the absence of a valid value. I think you know what I meant.

You re-implemented Option using an encapsulated List. Does it prove anything about "List achieving the same basic functionality as Option"? Why did you have to implement OptionBasedOnList in the first place if List and Option have the same basic functionality?

I did that to make a point, but it wasn't necessary. I could just pass a List where I need an Option, and use existing methods of List (e.g., "foreach," "for," "isEmpty," etc.). That was my original point.

Guess what, computer science is a... science. It's pretty boring for people who learned some of it to listen to people who didn't and that still claim the first are "clearly wrong". I'm glad there are CS people using Scala.

It's a science that is of little value in the hands of pedants who can regurgitate the jargon but don't understand the practical import.

Regards,
Russ P

--
http://RussP.us

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

Hey. Could you guys take this Option thread to scala-debate, please?

A similar thread was previously ended with the following quote from a modest everyman:

"I believe abstraction can help enormously but can also be overdone. And everyone has a different limit where more abstraction hurts rather than helps. For instance for me category theory is over the limit but for some others it's fine."
 -- Martin

On Sun, Aug 22, 2010 at 10:32 AM, Seth Tisue <seth@tisue.net> wrote:

Hey.  Could you guys take this Option thread to scala-debate, please?

--
Seth Tisue @ Northwestern University | http://tisue.net
lead developer, NetLogo: http://ccl.northwestern.edu/netlogo/

--
Bradley R. Buchsbaum
Rotman Research Institute
3560 Bathurst St.
Toronto, ON Canada M6A 2E1
email: bbuchsbaum@rotman-baycrest.on.ca

On Sun, Aug 22, 2010 at 12:39 AM, Russ Paielli <russ.paielli@gmail.com> wrote:

Then, on the receiving end, you use "for" (or "isEmpty" to check for a valie). Problem solved!

Wearing my pragmatic hat, this is the only point I would disagree with you on. If, in an alternate universe, Option didn't exist and you chose List to represent optionality, using 'for' would be horrible, because the List could very well contain more than 1 element. A combination of isEmpty and head would have to be the way to do it, and maybe even check size < 2 or else throw an exception.
And this part, I think, is the crux of the disagreement.

On 8/22/2010 9:02 AM, Josh Suereth wrote:
> I think another issue is in terms of "truth". Pragmatism is all
> about relative truth. If it worked, then it must be true. Thinking
> like that can lead to belief in spontaneous combustion. It's always
> good to have someone who has a black and white view on truth validate
> our assumptions, or point us to the underlying concepts behind idioms
> we use every day. An example of this is pushing people using random
> assignable values as "invalid" indicators on variables. All of us
> who have done this and lived a long enough project have eventually
> gotten burned, either by someone know who didn't know the assumption
> and forgot to check his variables, or when we were coding ourselves
> and simply forgot about initialization. Option insures you *never*
> forget about the non-initialization issue and that you, essentially,
> place walls around functions that use a particular variable. These
> "walls" will deal with the initialisation and then pass some value to
> the core logic of your system. In other words, option (and
> initialisation checks) shouldn't permeate all of your code, as it does
> not have to.

>
> In terms of this specific debate: Using List as an Option, while
> technically feasible, is dangerous for the same reason using -1 as
> un-initialised is bad. You are not conveying the meaning you wish if
> you use a List.

So taking this logic, as well as the notion someone else brought up of
"The compiler is your friend. Share as much information with it as you
can", which I agree are good arguments for why one would not want to use
List for Option, should we not also arrive at the idea that Option
should not have a get method?

Would not the lack of a get method in Option encourage us to put up
"walls" in our programs between code in which a variable should be able
to be either Some or None, and code where a variable ought only ever be
Some? I'm very much in sympathy with the view of wanting code to fail
fast when my assumption that a given line piece of code ought only be
able have a Some is incorrect, which I think was used as a pro
Option.get-producing-RuntimeException argument. If there were a wall
between the code with that assumption that was enforced by the type
system (i.e. that code using a Some rather than an Option) wouldn't that
be sharing more information with the compiler, and wouldn't that lead to
an ever faster failure?

Is perhaps the pragmatic explanation of the reason for Option having a
"get" actually entirely opposite to the reasons for not using a List
instead of an Option? Might the reason simply be an acceptance of the
idea that not having a get and forcing you to explicitly convert to
Option would pass a point of diminishing returns of communicating all of
your assumptions to the type system have having the type system try to
enforce everything last bit of correctness?

Or am I barking up the wrong tree here?

Eric

Eric,

I sincerely hope this is my last contribution to this thread. God knows I've already spent more time on it than I should have.

I agree with most everything you wrote, but I am confused about why you wrote it, because I never suggested otherwise. For the record, I never claimed that:

1. List is a good long-term replacement for Option
2. List behaves exactly the same as Option
3. The List type is equivalent to the Option type

All I claimed is that, like Option, List can be used to avoid null and in-band signaling for invalid data.

People keep pointing out here that List is not equivalent to Option, because it can contain more than one element. I am well aware of that fact. However, it is a trivial matter to create a List with less than two elements. No, the compiler cannot verify this, but neither can it verify many other requirements. (The compiler cannot check List indexing bounds either. Does that mean we should have separate types for every possible length of List up to, say, 50? I don't think so.) The programmer who creates the List can include a comment saying, "Do NOT put more than one element in this List!!!!" Is that as good as a compiler check? No, but it's safer than using null or in-band signaling.

Furthermore, the fact that List can contain more than one element could be used to advantage in some cases. The way I normally use Option, having more than one element would cause no problem at all. The "for" loop would simply process each element as if they were sent in separate Option objects.

Suppose you are going to paint a room. You go to open a can of paint, and you realize that you have no paint can opener. What would you do? Would you drop everything and run to the hardware store to get one? Or would you just use a screwdriver? I don't know about you, but I would just use a screwdriver, even though the screwdriver is not the ideal tool for the job. To say this is not to claim that the screwdriver is as good as an actual paint can opener for the job of opening a can of paint. It is merely a recognition of practical reality. Only a moron would arrogantly assert that the screwdriver can't possibly do the job of a paint can opener because it was not designed or intended for that purpose.

Russ P.


On Sun, Aug 22, 2010 at 6:13 AM, Erik Engbrecht <erik.engbrecht@gmail.com> wrote:

Russ,The practicality of something largely depends on what one intends to do with it.
Consider:/** sees if there is a Foo and if there is, returns it */def findFoo(): Option[Foo] = // ... versus:def findFoo(): List[Foo] = // ...
Those tell your fellow programmer very different things.  One says "this method will return 0..1 Foos", the other says "this method will return 0 to many Foos."  The multiplicity of the return values is made clear by Option, so the programmer using it doesn't need to look at the documentation to know what is really meant.
So Option versus List communicates something of practical value to people working with the code.
Likewise, it provides assurances that will be enforced by the compile.  Documentation and code have been known to deviate from one another over time.  Someone could change the implementation of findFoo(): List[Foo] such that it could return several Foos without changing the documentation or telling anyone.  In this case, most of the code that assumes the list is 0..1 is very silently broken.  The compiler doesn't catch it, and unless someone was really anal and asserted that the returned list indeed didn't have more than one element (I do this all the time), the code won't even noisily fail at runtime.  It will just hum along and produce a likely invalid result.
If the signature is def findFoo(): Option[Foo], and someone comes along and changes it to def findFoo(): List[Foo] because it really could return several Foos, then the compiler will noisily inform him of how much code he is breaking in his immediate codebase, and any people using his code will be informed by the compiler of problems as soon as they update to the new code.
One could use a bunch of arcane CS terms to describe this, but I like the way one of my CS professors put it better.  The compiler is your friend.  Share as much information with it as you can.
Now, this all assumes that being told by the compiler about likely broken code is of practical importance.  It is always of practical importance at some point before the code enters a real system (especially one were lives are at stake).  But it is not necessarily of practical importance at early stages, because relative to other problems these are often just a distraction.  I personally don't find Scala good for these early stages.  Python is better.
-Erik
On Sat, Aug 21, 2010 at 11:08 PM, Russ Paielli <russ.paielli@gmail.com> wrote:

On Sat, Aug 21, 2010 at 7:06 PM, Sylvain HENRY <hsyl20@gmail.com> wrote:

Tony just formalized what you wrote. Could you define "main functionality of Option"?

I defined what I meant by that earlier. I mean passing an object that can have a valid value or not, and not using null or in-band signaling to indicate the absence of a valid value. I think you know what I meant.

You re-implemented Option using an encapsulated List. Does it prove anything about "List achieving the same basic functionality as Option"? Why did you have to implement OptionBasedOnList in the first place if List and Option have the same basic functionality?

I did that to make a point, but it wasn't necessary. I could just pass a List where I need an Option, and use existing methods of List (e.g., "foreach," "for," "isEmpty," etc.). That was my original point.

Guess what, computer science is a... science. It's pretty boring for people who learned some of it to listen to people who didn't and that still claim the first are "clearly wrong". I'm glad there are CS people using Scala.

It's a science that is of little value in the hands of pedants who can regurgitate the jargon but don't understand the practical import.

Regards,
Russ P

--
http://RussP.us

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

--
http://RussP.us

(moved to Scala debate)
Russ,Sorry...I didn't read all of this 70+ message thread...  Also, like most mailing list posts, the target audience was much wider than yourself, even if it was addressed to you....
So, we're imagining a Scala without Option, and we want to return something with a multiplicity of 0..1.  We have a few options:

1. Roll our own Option class
2. Return null
3. Return a collection (e.g. List)
4. Go find a language with a more complete standard library.

As far as I can tell, the non-personality related portion of this debate centers around the question:  What is the most practical thing to do in this situation?
Your assertion is that #3 is the most practical course of action.  Personally, if was in a huge hurry I would probably just use null, because I think that's closer to the correct semantics than List is and null doesn't bother me nearly as much as it bothers some people around here.  If I wasn't in a hurry I'd roll my own, and I have rolled my own on many occasions when Option didn't fit as well as I would have liked (I also think using None to signal an error condition is slightly worse than in-band signaling - at least with ints and longs people kind of expect it).  In your painting analogy, it's more like walking across the room to get the paint opener as opposed to driving to the hardware store.
The practicality question here boils down to two criteria:

1. How much is type correctness worth?
2. How much effort does it take to achieve?

The answer to these questions is extremely context dependent, and thus I believe almost all questions about practicality tend to be context dependent.  For the pedantic Scala tutor, type correctness holds a very high worth (partially because he is expert at reasoning about it, and thus can use it more effectively) and it requires little effort (because countless patterns for achieving it are second nature to him).  For the rest of us the balance is different.
I was trying to add some context to the conversation.
-Erik
On Sun, Aug 22, 2010 at 3:37 PM, Russ Paielli <russ.paielli@gmail.com> wrote:

Eric,

I sincerely hope this is my last contribution to this thread. God knows I've already spent more time on it than I should have.

I agree with most everything you wrote, but I am confused about why you wrote it, because I never suggested otherwise. For the record, I never claimed that:

1. List is a good long-term replacement for Option
2. List behaves exactly the same as Option
3. The List type is equivalent to the Option type

All I claimed is that, like Option, List can be used to avoid null and in-band signaling for invalid data.

People keep pointing out here that List is not equivalent to Option, because it can contain more than one element. I am well aware of that fact. However, it is a trivial matter to create a List with less than two elements. No, the compiler cannot verify this, but neither can it verify many other requirements. (The compiler cannot check List indexing bounds either. Does that mean we should have separate types for every possible length of List up to, say, 50? I don't think so.) The programmer who creates the List can include a comment saying, "Do NOT put more than one element in this List!!!!" Is that as good as a compiler check? No, but it's safer than using null or in-band signaling.

Furthermore, the fact that List can contain more than one element could be used to advantage in some cases. The way I normally use Option, having more than one element would cause no problem at all. The "for" loop would simply process each element as if they were sent in separate Option objects.

Suppose you are going to paint a room. You go to open a can of paint, and you realize that you have no paint can opener. What would you do? Would you drop everything and run to the hardware store to get one? Or would you just use a screwdriver? I don't know about you, but I would just use a screwdriver, even though the screwdriver is not the ideal tool for the job. To say this is not to claim that the screwdriver is as good as an actual paint can opener for the job of opening a can of paint. It is merely a recognition of practical reality. Only a moron would arrogantly assert that the screwdriver can't possibly do the job of a paint can opener because it was not designed or intended for that purpose.

Russ P.


On Sun, Aug 22, 2010 at 6:13 AM, Erik Engbrecht <erik.engbrecht@gmail.com> wrote:

Russ,The practicality of something largely depends on what one intends to do with it.
Consider:/** sees if there is a Foo and if there is, returns it */def findFoo(): Option[Foo] = // ... versus:def findFoo(): List[Foo] = // ...
Those tell your fellow programmer very different things.  One says "this method will return 0..1 Foos", the other says "this method will return 0 to many Foos."  The multiplicity of the return values is made clear by Option, so the programmer using it doesn't need to look at the documentation to know what is really meant.
So Option versus List communicates something of practical value to people working with the code.
Likewise, it provides assurances that will be enforced by the compile.  Documentation and code have been known to deviate from one another over time.  Someone could change the implementation of findFoo(): List[Foo] such that it could return several Foos without changing the documentation or telling anyone.  In this case, most of the code that assumes the list is 0..1 is very silently broken.  The compiler doesn't catch it, and unless someone was really anal and asserted that the returned list indeed didn't have more than one element (I do this all the time), the code won't even noisily fail at runtime.  It will just hum along and produce a likely invalid result.
If the signature is def findFoo(): Option[Foo], and someone comes along and changes it to def findFoo(): List[Foo] because it really could return several Foos, then the compiler will noisily inform him of how much code he is breaking in his immediate codebase, and any people using his code will be informed by the compiler of problems as soon as they update to the new code.
One could use a bunch of arcane CS terms to describe this, but I like the way one of my CS professors put it better.  The compiler is your friend.  Share as much information with it as you can.
Now, this all assumes that being told by the compiler about likely broken code is of practical importance.  It is always of practical importance at some point before the code enters a real system (especially one were lives are at stake).  But it is not necessarily of practical importance at early stages, because relative to other problems these are often just a distraction.  I personally don't find Scala good for these early stages.  Python is better.
-Erik
On Sat, Aug 21, 2010 at 11:08 PM, Russ Paielli <russ.paielli@gmail.com> wrote:

On Sat, Aug 21, 2010 at 7:06 PM, Sylvain HENRY <hsyl20@gmail.com> wrote:

Tony just formalized what you wrote. Could you define "main functionality of Option"?

I defined what I meant by that earlier. I mean passing an object that can have a valid value or not, and not using null or in-band signaling to indicate the absence of a valid value. I think you know what I meant.

You re-implemented Option using an encapsulated List. Does it prove anything about "List achieving the same basic functionality as Option"? Why did you have to implement OptionBasedOnList in the first place if List and Option have the same basic functionality?

I did that to make a point, but it wasn't necessary. I could just pass a List where I need an Option, and use existing methods of List (e.g., "foreach," "for," "isEmpty," etc.). That was my original point.

Guess what, computer science is a... science. It's pretty boring for people who learned some of it to listen to people who didn't and that still claim the first are "clearly wrong". I'm glad there are CS people using Scala.

It's a science that is of little value in the hands of pedants who can regurgitate the jargon but don't understand the practical import.

Regards,
Russ P

--
http://RussP.us

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

--
http://RussP.us

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

-scala-users
+scala-debate

I was never for or against adding or removing option.get.

I think it is a don't care for me.  In the absence of a get method, all my recent code would be fine.  However i do think others would reinvent their own get method in the absence of having one on the standard library.

The get method debate, to me, is an argument of having a thick vs. thin interface.  Having lived with a library that favored thin interfaces, i think striking a balance is best here.  Where that balance is for option is certainly debatable, however i would not mind the absence of get greatly.  However if i saw it implemented in many projects, then i think its removal was the wrong decision.

On Aug 22, 2010 1:12 PM, "Eric Schwarzenbach" <subscriber@blackbrook.org> wrote:

 On 8/22/2010 9:02 AM, Josh Suereth wrote:
>
> I think another issue is in terms of "truth".   Pragm...

<snip>

>
>
> In terms of this specific debate:   Using List as an Option, while technically feasible, is d...

So taking this logic, as well as the notion someone else brought up of "The compiler is your friend.  Share as much information with it as you can", which I agree are good arguments for why one would not want to use List for Option, should we not also arrive at the idea that Option should not have a get method?

Would not the lack of a get method in Option encourage us to put up "walls" in our programs between code in which a variable should be able to be either Some or None, and code where a variable ought only ever be Some? I'm very much in sympathy with the view of wanting code to fail fast when my assumption that a given line piece of code ought only be able have a Some is incorrect, which I think was used as a pro Option.get-producing-RuntimeException argument. If there were a wall between the code with that assumption that was enforced by the type system (i.e. that code using a Some rather than an Option) wouldn't that be sharing more information with the compiler, and wouldn't that lead to an ever faster failure?

Is perhaps the pragmatic explanation of the reason for Option having a "get" actually entirely opposite to the reasons for not using a List instead of an Option? Might the reason simply be an acceptance of the idea that not having a get and forcing you to explicitly convert to Option would pass a point of diminishing returns of communicating all of your assumptions to the type system have having the type system try to enforce everything last bit of correctness?

Or am I barking up the wrong tree here?

Eric

But using null or in-band signaling are risky, because the receiver of the object might be unaware of the convention or might simply forget to check it. On that point I am in complete agreement with the most stalwart Scala perfectionist.

As for writing your own Option class, yes I would probably do that eventually myself, but if I had higher priorities at the time (highly likely), I'd use List at least temporarily.

This whole issue of List not being usable in place of Option because it can contain more than one element seems overly cautious to me. Suppose a List or Array were used to represent the 3D position or velocity of an aircraft. We know that position and velocity cannot have more than three components, but a List can have more than three. So, does that mean I should write my own class that can guarantee at compile that more three elements are not possible? Well, I could do that, I suppose, but then any utility methods (addition, subtraction, multiplication, etc.)I have written for vectors of general length will need to be re-implemented. And then what if, in a particular instance I only need two components (e.g., to represent horizontal position or velocity only)? Oh, now I need another class. I don't think that's the way to go.

Russ P.


On Sun, Aug 22, 2010 at 1:22 PM, Erik Engbrecht <erik.engbrecht@gmail.com> wrote:

(moved to Scala debate)
Russ,Sorry...I didn't read all of this 70+ message thread...  Also, like most mailing list posts, the target audience was much wider than yourself, even if it was addressed to you....
So, we're imagining a Scala without Option, and we want to return something with a multiplicity of 0..1.  We have a few options:

1. Roll our own Option class
2. Return null
3. Return a collection (e.g. List)
4. Go find a language with a more complete standard library.

As far as I can tell, the non-personality related portion of this debate centers around the question:  What is the most practical thing to do in this situation?
Your assertion is that #3 is the most practical course of action.  Personally, if was in a huge hurry I would probably just use null, because I think that's closer to the correct semantics than List is and null doesn't bother me nearly as much as it bothers some people around here.  If I wasn't in a hurry I'd roll my own, and I have rolled my own on many occasions when Option didn't fit as well as I would have liked (I also think using None to signal an error condition is slightly worse than in-band signaling - at least with ints and longs people kind of expect it).  In your painting analogy, it's more like walking across the room to get the paint opener as opposed to driving to the hardware store.
The practicality question here boils down to two criteria:

1. How much is type correctness worth?
2. How much effort does it take to achieve?

The answer to these questions is extremely context dependent, and thus I believe almost all questions about practicality tend to be context dependent.  For the pedantic Scala tutor, type correctness holds a very high worth (partially because he is expert at reasoning about it, and thus can use it more effectively) and it requires little effort (because countless patterns for achieving it are second nature to him).  For the rest of us the balance is different.
I was trying to add some context to the conversation.
-Erik
On Sun, Aug 22, 2010 at 3:37 PM, Russ Paielli <russ.paielli@gmail.com> wrote:

Eric,

I sincerely hope this is my last contribution to this thread. God knows I've already spent more time on it than I should have.

I agree with most everything you wrote, but I am confused about why you wrote it, because I never suggested otherwise. For the record, I never claimed that:

1. List is a good long-term replacement for Option
2. List behaves exactly the same as Option
3. The List type is equivalent to the Option type

All I claimed is that, like Option, List can be used to avoid null and in-band signaling for invalid data.

People keep pointing out here that List is not equivalent to Option, because it can contain more than one element. I am well aware of that fact. However, it is a trivial matter to create a List with less than two elements. No, the compiler cannot verify this, but neither can it verify many other requirements. (The compiler cannot check List indexing bounds either. Does that mean we should have separate types for every possible length of List up to, say, 50? I don't think so.) The programmer who creates the List can include a comment saying, "Do NOT put more than one element in this List!!!!" Is that as good as a compiler check? No, but it's safer than using null or in-band signaling.

Furthermore, the fact that List can contain more than one element could be used to advantage in some cases. The way I normally use Option, having more than one element would cause no problem at all. The "for" loop would simply process each element as if they were sent in separate Option objects.

Suppose you are going to paint a room. You go to open a can of paint, and you realize that you have no paint can opener. What would you do? Would you drop everything and run to the hardware store to get one? Or would you just use a screwdriver? I don't know about you, but I would just use a screwdriver, even though the screwdriver is not the ideal tool for the job. To say this is not to claim that the screwdriver is as good as an actual paint can opener for the job of opening a can of paint. It is merely a recognition of practical reality. Only a moron would arrogantly assert that the screwdriver can't possibly do the job of a paint can opener because it was not designed or intended for that purpose.

Russ P.


On Sun, Aug 22, 2010 at 6:13 AM, Erik Engbrecht <erik.engbrecht@gmail.com> wrote:

Russ,The practicality of something largely depends on what one intends to do with it.
Consider:/** sees if there is a Foo and if there is, returns it */def findFoo(): Option[Foo] = // ... versus:def findFoo(): List[Foo] = // ...
Those tell your fellow programmer very different things.  One says "this method will return 0..1 Foos", the other says "this method will return 0 to many Foos."  The multiplicity of the return values is made clear by Option, so the programmer using it doesn't need to look at the documentation to know what is really meant.
So Option versus List communicates something of practical value to people working with the code.
Likewise, it provides assurances that will be enforced by the compile.  Documentation and code have been known to deviate from one another over time.  Someone could change the implementation of findFoo(): List[Foo] such that it could return several Foos without changing the documentation or telling anyone.  In this case, most of the code that assumes the list is 0..1 is very silently broken.  The compiler doesn't catch it, and unless someone was really anal and asserted that the returned list indeed didn't have more than one element (I do this all the time), the code won't even noisily fail at runtime.  It will just hum along and produce a likely invalid result.
If the signature is def findFoo(): Option[Foo], and someone comes along and changes it to def findFoo(): List[Foo] because it really could return several Foos, then the compiler will noisily inform him of how much code he is breaking in his immediate codebase, and any people using his code will be informed by the compiler of problems as soon as they update to the new code.
One could use a bunch of arcane CS terms to describe this, but I like the way one of my CS professors put it better.  The compiler is your friend.  Share as much information with it as you can.
Now, this all assumes that being told by the compiler about likely broken code is of practical importance.  It is always of practical importance at some point before the code enters a real system (especially one were lives are at stake).  But it is not necessarily of practical importance at early stages, because relative to other problems these are often just a distraction.  I personally don't find Scala good for these early stages.  Python is better.
-Erik
On Sat, Aug 21, 2010 at 11:08 PM, Russ Paielli <russ.paielli@gmail.com> wrote:

On Sat, Aug 21, 2010 at 7:06 PM, Sylvain HENRY <hsyl20@gmail.com> wrote:

Tony just formalized what you wrote. Could you define "main functionality of Option"?

I defined what I meant by that earlier. I mean passing an object that can have a valid value or not, and not using null or in-band signaling to indicate the absence of a valid value. I think you know what I meant.

You re-implemented Option using an encapsulated List. Does it prove anything about "List achieving the same basic functionality as Option"? Why did you have to implement OptionBasedOnList in the first place if List and Option have the same basic functionality?

I did that to make a point, but it wasn't necessary. I could just pass a List where I need an Option, and use existing methods of List (e.g., "foreach," "for," "isEmpty," etc.). That was my original point.

Guess what, computer science is a... science. It's pretty boring for people who learned some of it to listen to people who didn't and that still claim the first are "clearly wrong". I'm glad there are CS people using Scala.

It's a science that is of little value in the hands of pedants who can regurgitate the jargon but don't understand the practical import.

Regards,
Russ P

--
http://RussP.us

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

--
http://RussP.us

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

--
http://RussP.us

It all depends on what you consider over-cautious.  I've been bitten by assuming that a returned collection should contain zero to one elements on a bunch of occasions, and I've spent a great deal of personal energy arguing with people about the need for algorithms to handle such cases (not critical algorithms, but ones for doing analysis).
The last time I recall being bit by an NPE was a time when I was having problems with initialization order in a Scala program...the time before that I had a complex initialization problem with a Python program because it made heavy use of metaprogramming and was trying to boot-strap itself (I solved it by implementing lazy values using descriptors).  Years ago I used to write lots of C++ and never had problems with such things.  Also, NPEs manifest themselves quite obnoxiously at runtime.  Thinking you have only one datapoint when really you have three (and those will make you span off into all sorts of subgraphs) just creates bad outputs that are almost impossible to identify.
Anyway, so it's a matter of context.  One type of error has caused me lots of pain, another type hasn't.  I prefer risking the type that hasn't.

On Sun, Aug 22, 2010 at 5:17 PM, Russ Paielli <russ.paielli@gmail.com> wrote:

But using null or in-band signaling are risky, because the receiver of the object might be unaware of the convention or might simply forget to check it. On that point I am in complete agreement with the most stalwart Scala perfectionist.

As for writing your own Option class, yes I would probably do that eventually myself, but if I had higher priorities at the time (highly likely), I'd use List at least temporarily.

This whole issue of List not being usable in place of Option because it can contain more than one element seems overly cautious to me. Suppose a List or Array were used to represent the 3D position or velocity of an aircraft. We know that position and velocity cannot have more than three components, but a List can have more than three. So, does that mean I should write my own class that can guarantee at compile that more three elements are not possible? Well, I could do that, I suppose, but then any utility methods (addition, subtraction, multiplication, etc.)I have written for vectors of general length will need to be re-implemented. And then what if, in a particular instance I only need two components (e.g., to represent horizontal position or velocity only)? Oh, now I need another class. I don't think that's the way to go.

Russ P.


On Sun, Aug 22, 2010 at 1:22 PM, Erik Engbrecht <erik.engbrecht@gmail.com> wrote:

(moved to Scala debate)
Russ,Sorry...I didn't read all of this 70+ message thread...  Also, like most mailing list posts, the target audience was much wider than yourself, even if it was addressed to you....
So, we're imagining a Scala without Option, and we want to return something with a multiplicity of 0..1.  We have a few options:

1. Roll our own Option class
2. Return null
3. Return a collection (e.g. List)
4. Go find a language with a more complete standard library.

As far as I can tell, the non-personality related portion of this debate centers around the question:  What is the most practical thing to do in this situation?
Your assertion is that #3 is the most practical course of action.  Personally, if was in a huge hurry I would probably just use null, because I think that's closer to the correct semantics than List is and null doesn't bother me nearly as much as it bothers some people around here.  If I wasn't in a hurry I'd roll my own, and I have rolled my own on many occasions when Option didn't fit as well as I would have liked (I also think using None to signal an error condition is slightly worse than in-band signaling - at least with ints and longs people kind of expect it).  In your painting analogy, it's more like walking across the room to get the paint opener as opposed to driving to the hardware store.
The practicality question here boils down to two criteria:

1. How much is type correctness worth?
2. How much effort does it take to achieve?

The answer to these questions is extremely context dependent, and thus I believe almost all questions about practicality tend to be context dependent.  For the pedantic Scala tutor, type correctness holds a very high worth (partially because he is expert at reasoning about it, and thus can use it more effectively) and it requires little effort (because countless patterns for achieving it are second nature to him).  For the rest of us the balance is different.
I was trying to add some context to the conversation.
-Erik
On Sun, Aug 22, 2010 at 3:37 PM, Russ Paielli <russ.paielli@gmail.com> wrote:

Eric,

I sincerely hope this is my last contribution to this thread. God knows I've already spent more time on it than I should have.

I agree with most everything you wrote, but I am confused about why you wrote it, because I never suggested otherwise. For the record, I never claimed that:

1. List is a good long-term replacement for Option
2. List behaves exactly the same as Option
3. The List type is equivalent to the Option type

All I claimed is that, like Option, List can be used to avoid null and in-band signaling for invalid data.

People keep pointing out here that List is not equivalent to Option, because it can contain more than one element. I am well aware of that fact. However, it is a trivial matter to create a List with less than two elements. No, the compiler cannot verify this, but neither can it verify many other requirements. (The compiler cannot check List indexing bounds either. Does that mean we should have separate types for every possible length of List up to, say, 50? I don't think so.) The programmer who creates the List can include a comment saying, "Do NOT put more than one element in this List!!!!" Is that as good as a compiler check? No, but it's safer than using null or in-band signaling.

Furthermore, the fact that List can contain more than one element could be used to advantage in some cases. The way I normally use Option, having more than one element would cause no problem at all. The "for" loop would simply process each element as if they were sent in separate Option objects.

Suppose you are going to paint a room. You go to open a can of paint, and you realize that you have no paint can opener. What would you do? Would you drop everything and run to the hardware store to get one? Or would you just use a screwdriver? I don't know about you, but I would just use a screwdriver, even though the screwdriver is not the ideal tool for the job. To say this is not to claim that the screwdriver is as good as an actual paint can opener for the job of opening a can of paint. It is merely a recognition of practical reality. Only a moron would arrogantly assert that the screwdriver can't possibly do the job of a paint can opener because it was not designed or intended for that purpose.

Russ P.


On Sun, Aug 22, 2010 at 6:13 AM, Erik Engbrecht <erik.engbrecht@gmail.com> wrote:

Russ,The practicality of something largely depends on what one intends to do with it.
Consider:/** sees if there is a Foo and if there is, returns it */def findFoo(): Option[Foo] = // ... versus:def findFoo(): List[Foo] = // ...
Those tell your fellow programmer very different things.  One says "this method will return 0..1 Foos", the other says "this method will return 0 to many Foos."  The multiplicity of the return values is made clear by Option, so the programmer using it doesn't need to look at the documentation to know what is really meant.
So Option versus List communicates something of practical value to people working with the code.
Likewise, it provides assurances that will be enforced by the compile.  Documentation and code have been known to deviate from one another over time.  Someone could change the implementation of findFoo(): List[Foo] such that it could return several Foos without changing the documentation or telling anyone.  In this case, most of the code that assumes the list is 0..1 is very silently broken.  The compiler doesn't catch it, and unless someone was really anal and asserted that the returned list indeed didn't have more than one element (I do this all the time), the code won't even noisily fail at runtime.  It will just hum along and produce a likely invalid result.
If the signature is def findFoo(): Option[Foo], and someone comes along and changes it to def findFoo(): List[Foo] because it really could return several Foos, then the compiler will noisily inform him of how much code he is breaking in his immediate codebase, and any people using his code will be informed by the compiler of problems as soon as they update to the new code.
One could use a bunch of arcane CS terms to describe this, but I like the way one of my CS professors put it better.  The compiler is your friend.  Share as much information with it as you can.
Now, this all assumes that being told by the compiler about likely broken code is of practical importance.  It is always of practical importance at some point before the code enters a real system (especially one were lives are at stake).  But it is not necessarily of practical importance at early stages, because relative to other problems these are often just a distraction.  I personally don't find Scala good for these early stages.  Python is better.
-Erik
On Sat, Aug 21, 2010 at 11:08 PM, Russ Paielli <russ.paielli@gmail.com> wrote:

On Sat, Aug 21, 2010 at 7:06 PM, Sylvain HENRY <hsyl20@gmail.com> wrote:

Tony just formalized what you wrote. Could you define "main functionality of Option"?

I defined what I meant by that earlier. I mean passing an object that can have a valid value or not, and not using null or in-band signaling to indicate the absence of a valid value. I think you know what I meant.

You re-implemented Option using an encapsulated List. Does it prove anything about "List achieving the same basic functionality as Option"? Why did you have to implement OptionBasedOnList in the first place if List and Option have the same basic functionality?

I did that to make a point, but it wasn't necessary. I could just pass a List where I need an Option, and use existing methods of List (e.g., "foreach," "for," "isEmpty," etc.). That was my original point.

Guess what, computer science is a... science. It's pretty boring for people who learned some of it to listen to people who didn't and that still claim the first are "clearly wrong". I'm glad there are CS people using Scala.

It's a science that is of little value in the hands of pedants who can regurgitate the jargon but don't understand the practical import.

Regards,
Russ P

--
http://RussP.us

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

--
http://RussP.us

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

--
http://RussP.us

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

On Sun, Aug 22, 2010 at 9:02 AM, Josh Suereth <joshua.suereth@gmail.com> wrote:

I think another issue is in terms of "truth".   Pragmatism is all about relative truth.  If it worked, then it must be true.   Thinking like

I'm not sure why you say that. Why not just short-circuit that logic: Pragmatism is about whether it works, not about whether it's true. I'm assuming you're using "truth" here in the mathematical sense, not in the real world sense. 

that can lead to belief in spontaneous combustion.   It's always good to have someone who has a black and white view on truth validate our assumptions, or point us to the underlying concepts behind idioms we use every day.   An example of this is pushing people using random assignable values as "invalid" indicators on variables.   All of us who have done this and lived a long enough project have eventually gotten burned, either by someone know who didn't know the assumption and forgot to check his variables, or when we were coding ourselves and simply forgot about initialization.   Option insures you *never* forget about the non-initialization issue and that you, essentially, place walls around functions that use a particular variable.   These "walls"  will deal with the initialisation and then pass some value to the core logic of your system.   In other words, option (and initialisation checks) shouldn't permeate all of your code, as it does not have to.

I've heard it said that when the shoemaker walks down the street, what he sees is what shoes everyone is wearing; when the real estate agent walks down the street what he sees is which houses are for sale; the psychologist sees the world in terms of emotions, etc. The problem here is not that the pragmatists disagree with the theorists. The problem is that when the pragmatist talks, the theorist hears something different than what was actually said.For instance, a logician may see the world in terms of truth tables, and thus he hears the pragmatist's remarks as a series of logical assertions. And from a logic standpoint he may be correct. But he still totally missed the point.  

Tony happens to be someone who knows many of the terms referencing specific concepts in functional programming.  These are specific idioms that you can encode into a language like Scala.  Often times pragmatics rediscover things that functional programmers have known about for years.   At these times, the "black and white scala instructor" will try to inform the developer with the "AHA!" moment which functional concept they've just rediscovered and the pros/cons of that particular idiom.   As they usually speak in theoretical "absolute truth" terms, sometimes users do not appreciate this.   Also, when in debates with pragmatics, the seasoned FP developer will whip out a bunch of these terms and idioms and it usually gives the pragmatic, who is a very smart person otherwise, a feeling of inferiority that leads to an explosion on this mailing list. 

I very highly doubt the issue is a feeling of inferiority, but rather an accurate feeling of being repeatedly misunderstood.I know you didn't mean this, but the implication of your wording is that seasoned FP developers are superior (their knowledge is beneficial but doesn't make them better, superior people) to "otherwise smart people" (again, an unintentional implication that lack of FP experience is a lack of smartness), and others, who are jealous, feel inferior around them.

What it comes down to, is there are a bunch of "Patterns" in functional program with research behind them and lots of write-ups.  I will say this once:  Do not ignore what Tony says.   If he uses a word you do not understand, take the hours or days to

 I don't think the value of his insights were being questioned, but their bearing on the point being made. 

research what it means and why he used it.   Even if you're a pragmatic (like I am), this will improve your skills as a software developer and is usually rewarding.   Think of it as your opportunity to read "Design Patterns for Functional Programming".   Functional Programming just builds software in a very different manner than we are used to.

In terms of this specific debate:   Using List as an Option, while technically feasible, is dangerous for the same reason using -1 as un-initialised is bad.  You are not conveying the meaning you wish if you use a List.   In the absence of an Option class in the standard library, inevitable people would rediscover and write their own Option class.   Similar to the "loaner" pattern and Automatic Resource Management, which I've rediscovered on every project until I wrote scala-arm.

There is another side to this and this is of understanding the meaning of functions from their type signatures.   In an OO language, when discovering how a system works, we usually investigate the API in our IDE of choice and see a bunch of functions pop up from a class.   The Class name in combination with the method name and its arguments give us a good clue of what the function does.   We then call this function, write a unit test and make sure it does what we expected.   All of this wihthout reading the API documentation unless absolutely necessary (as it takes longer).

You can imagine in functional programming you'd like to do the same thing, discover how to use an API from signatures.   Well, what do you have available to you?   If you have a free standing function the *only* thing you can use to understand what's happening is the function's type signature.  This means you can use the type of the arguments and the type of the result and perhaps the name of the function.

The key here is the Option.foreach and List.foreach do *not* mean the same thing.  if the List has one item, then yes it would operator similarly.   However it does not convey the appropriate meaning to the programmer.    Also  OptionFromList's foreach should really be def foreach(f : A => Unit) = if(list.empty) () else f(list.head).   The .toList method on option is really designed to help satisfy the function     extractAllValid( stuff : List[Option[A]]) : List[A]  which could be based on the function:  
def what_is_my_name[A, M[_], N[_]](x : M[N[A]], y : N[A] => M[A]) : M[A].   (Note: You would need some monad implicit help here so you could flatten and perhaps a few others.  ).

In any case, the point is that those underlying functions have names and are meaningful and sound funny to our pragmatic ears.   I'm hoping over time, and perhaps with a few good books on Scala, some of these will become more natural to everyday programmers.

Again, I would question terming them "underlying functions" in the absolute sense, as though the functional paradigm is The Truth, rather than one of many paradigms. Perhaps even the most beneficial one. Personally I would use wording like "The .toList method on option can be seen as satisfying a function extractAllValid..." etc. I'm sure that wasn't your intention, just pointing out that this common implicit way of thinking might be part of the problem.  

When it comes to turing complete languages and why it doesn't make sense to remove the get from option, well you should look at Coq.  If you want to work towards a more provably safe language you will end up moving in that direction.

I do not understand the logic of that.Jack: Can we get rid of this nail sticking out the the carpet? People keep getting hurt on it.Mike: Perhaps you should switch to linoleum. Carpet always ends up having nails sticking out of it. (I know, that was a bit random, but you get the point.)
 

Finally when it comes to this thread, I think the exchange of ideas has gotten to the hurt feeling stage.   At this point it's no longer productive to continue until things have settled down.   I'd ask those who wish to continue discussions to do so privately.

On Sun, Aug 22, 2010 at 12:56 AM, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

Russ, I think the problem here is that you are interested in pragmatics: getting something to work, and thinking in those terms, which is fine. But some people are trained to see the world differently. By them everything is defined in terms of proofs and types and functional jargon. So there are two groups not speaking two different languages, but speaking about two different universes. Pragmatists and theorists, perhaps. Is one right or wrong? Is one *inherently* better? By the very nature of those two questions, it is not in human capacity to determine their answer.So ask a theorist: Why is your approach better? He can only hope to demonstrate how his approach yields better results (less errors, etc.), because any theoretical advantage of the theoretical view (which surely exists by definition) would amount to circular logic. Hence, the theorist's advantage would have to be a pragmatic one. But that means that he agrees that ultimately it's the pragmatic that matter; only he believes that the theoretical view is more pragmatic than the pragmatic one. So ultimately there's no debate---at the end of the day everyone is pragmatic. And he lived happily every after.THE END


On Sat, Aug 21, 2010 at 11:08 PM, Russ Paielli <russ.paielli@gmail.com> wrote:

On Sat, Aug 21, 2010 at 7:06 PM, Sylvain HENRY <hsyl20@gmail.com> wrote:

Tony just formalized what you wrote. Could you define "main functionality of Option"?

I defined what I meant by that earlier. I mean passing an object that can have a valid value or not, and not using null or in-band signaling to indicate the absence of a valid value. I think you know what I meant.

You re-implemented Option using an encapsulated List. Does it prove anything about "List achieving the same basic functionality as Option"? Why did you have to implement OptionBasedOnList in the first place if List and Option have the same basic functionality?

I did that to make a point, but it wasn't necessary. I could just pass a List where I need an Option, and use existing methods of List (e.g., "foreach," "for," "isEmpty," etc.). That was my original point.

Guess what, computer science is a... science. It's pretty boring for people who learned some of it to listen to people who didn't and that still claim the first are "clearly wrong". I'm glad there are CS people using Scala.

It's a science that is of little value in the hands of pedants who can regurgitate the jargon but don't understand the practical import.

Regards,
Russ P

--
http://RussP.us

And what is it that prohibits a blatantly false statement (assuming there is one)?

P.S. I also don't understand how it is that the negative consequences of attention which you don't desire, whatever they are, are bad enough to scare you away from giving "as-helpful-as-we'd-both-like" responses, but I guess everyone's different---who am I to judge? Anyway, I appreciate the strength of spirit it surely required to concede that your answers were somewhat on the vague side. May you go from strength to strength and ultimately reach a solution to this terrible dilemma.


On Sun, Aug 22, 2010 at 6:39 AM, Tony Morris <tonymorris@gmail.com> wrote:

Hi Naftoli,
I admire your enthusiasm, but I think you are on the wrong track. There
is nothing about "pragmatics" or "seeing the world differently" that
permits a blatantly false statement to become otherwise. I apologise for
my blunt and perhaps "not-as-helpful-as-we'd-both-like" responses to
your questions but as you can probably see, expanding often comes with
the extreme risk of attracting undesirable attention, which I will go to
extraordinary lengths to avoid, often at your expense :(

I'd be happy to make it up to you by providing you with less vague
answers that those previous, but it's difficult in the current climate.
I have no good answers to this dilemma. I lament and, perhaps cowardly,
put the ball in your court on this one, hoping you can come up with a
better solution than I.

Naftoli Gugenheim wrote:
> Russ, I think the problem here is that you are interested in
> pragmatics: getting something to work, and thinking in those terms,
> which is fine. But some people are trained to see the world
> differently. By them everything is defined in terms of proofs and
> types and functional jargon. So there are two groups not speaking two
> different languages, but speaking about two different universes.
> Pragmatists and theorists, perhaps.
> Is one right or wrong? Is one *inherently* better? By the very nature
> of those two questions, it is not in human capacity to determine their
> answer.
> So ask a theorist: Why is your approach better? He can only hope to
> demonstrate how his approach yields better results (less errors,
> etc.), because any theoretical advantage of the theoretical view
> (which surely exists by definition) would amount to circular logic.
> Hence, the theorist's advantage would have to be a pragmatic one. But
> that means that he agrees that ultimately it's the pragmatic that
> matter; only he believes that the theoretical view is more pragmatic
> than the pragmatic one. So ultimately there's no debate---at the end
> of the day everyone is pragmatic.
> And he lived happily every after.
> THE END
>
>
>
> On Sat, Aug 21, 2010 at 11:08 PM, Russ Paielli <russ.paielli@gmail.com
> <mailto:russ.paielli@gmail.com>> wrote:
>
>
>
>     On Sat, Aug 21, 2010 at 7:06 PM, Sylvain HENRY <hsyl20@gmail.com
>     <mailto:hsyl20@gmail.com>> wrote:
>
>         Tony just formalized what you wrote. Could you define "main
>         functionality of Option"?
>
>
>     I defined what I meant by that earlier. I mean passing an object
>     that can have a valid value or not, and not using null or in-band
>     signaling to indicate the absence of a valid value. I think you
>     know what I meant.
>
>>
>         You re-implemented Option using an encapsulated List. Does it
>         prove anything about "List achieving the same basic
>         functionality as Option"? Why did you have to implement
>         OptionBasedOnList in the first place if List and Option have
>         the same basic functionality?
>
>
>
>     I did that to make a point, but it wasn't necessary. I could just
>     pass a List where I need an Option, and use existing methods of
>     List (e.g., "foreach," "for," "isEmpty," etc.). That was my
>     original point.
>
>
>         Guess what, computer science is a... science. It's pretty
>         boring for people who learned some of it to listen to people
>         who didn't and that still claim the first are "clearly wrong".
>         I'm glad there are CS people using Scala.
>
>
>     It's a science that is of little value in the hands of pedants who
>     can regurgitate the jargon but don't understand the practical import.
>
>     Regards,
>     Russ P
>
>     --
>     http://RussP.us
>
>

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

On Mon, Aug 23, 2010 at 5:25 PM, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

Jack: Can we get rid of this nail sticking out the the carpet? People keep getting hurt on it.

But is that really the case? Do people consistently treat Option like a reference, i.e. calling 'get' indiscriminately, without thought? If that is really true, it goes against the entire purpose of Option.
BTW, I don't think it's true, certainly not for me. I call 'get' when I know it should be Some and I want it to fail if it's not. The alternative is making me write more annoying boilerplate and manually throw an exception. Why should I be forced to do that?

On Monday August 23 2010, Naftoli Gugenheim wrote:
> ....
> Jack: Can we get rid of this nail sticking out the the carpet? People
> keep getting hurt on it.
> Mike: Perhaps you should switch to linoleum. Carpet always ends up
> having nails sticking out of it.
> ...

Linoleum is held down by adhesives containing toxic and carcinogenic
substances. I'd prefer to cut my foot than develop a life-threatening
illness.

And remember:
"Proof by analogy is fraud."
— Bjarne Stroustrup

Randall Schulz

Naftoli> [...] The problem here is not that the pragmatists
Naftoli> disagree with the theorists. [...]

These words for the two sides were obviously chosen by a so-called
"pragmatist", not by a so-called "theorist". No one (no working
programmer?) is going to accept the designation "unpragmatic". Both
camps in this debate are attempting to efficiently construct working
programs, so I think politeness requires granting both camps equal
levels of "pragmatism".

I like the terms that were (are?) used in the AI world for two similar
camps: "neats" and "scruffies".

I'm not seriously pushing those particular terms, but you should find
*some* other words to use. Calling your opponents "theorists" while you
call yourself a "pragmatist" is name-calling, not debate.

On Mon, Aug 23, 2010 at 4:20 PM, Seth Tisue <seth@tisue.net> wrote:

 Naftoli> [...] The problem here is not that the pragmatists
 Naftoli> disagree with the theorists. [...]

These words for the two sides were obviously chosen by a so-called
"pragmatist", not by a so-called "theorist".  No one (no working
programmer?) is going to accept the designation "unpragmatic".  Both
camps in this debate are attempting to efficiently construct working
programs, so I think politeness requires granting both camps equal
levels of "pragmatism".

I like the terms that were (are?) used in the AI world for two similar
camps: "neats" and "scruffies".

I'm not seriously pushing those particular terms, but you should find
*some* other words to use.  Calling your opponents "theorists" while you
call yourself a "pragmatist" is name-calling, not debate.

--
Seth Tisue @ Northwestern University | http://tisue.net
lead developer, NetLogo: http://ccl.northwestern.edu/netlogo/

Believe it or not, I was once a bit of a theorist myself (in aerospace control theory), so I certainly don't consider it a derogatory label. (See http://RussP.us/attcon.pdf and http://RussP.us/publist.htm)

The problem with "theorists" is that they can sometimes be arrogant and pedantic. Worse yet, they are sometimes arrogant, pedantic, and WRONG! That's a bad combination.

When I suggested that List could perform some of the basic functionality of Option (by circumventing the need for null and in-band signaling), a Scala instructor who probably considers himself a theorist tersely (and falsely) claimed "that is not true," with no explanation whatsoever. When I attempted to correct him, he became rude and insulting, insisting that it was "bullshit," and referring to me on this forum as a "dim light bulb."

Folks, I am not suggesting for one second that List *should* be used in place of Option, but to claim that it absolutely cannot be used as such is clearly wrong.

Several people have pointed out that, whereas Option can hold at most one element, List can hold more than one, and a compiler cannot guarantee that it will not hold more than one value. That is true, but if that fact rules out List for this usage, think about what else it rules out List for. You could not use List (or Array) to hold three coordinates of position, because the compiler cannot guarantee that more than three coordinates will not be put in it. If you have a school with 1,598 students, you could use a List to hold their data, because the compiler cannot guarantee that someone will not put 1,599 students in it. Is it becoming clear how silly that objection is?

I understand that the "theorist" in question is highly regarded by some here and is not stupid, at least not all the time. That is why I am simply perplexed by his bogus assertions. I won't demand an apology, but I certainly don't think one would be out of order. I realize that he knows a lot about Scala and functional programming, and I have no desire to be at perpetual war with him on this forum. If he shows me basic respect, I will do the same for him. If not, I won't. Thanks.

Russ P.


--
http://RussP.us

<... heated rhetoric omitted ...>

Thank goodness Scala is a multiparadigm language, so each of us is free to be wrong in a different way.

A

I have stayed out of this because it borders on idiocy but this reply simply baffles me.

3 coordinates in an array ? If its really a conceptual tuple then use one.
list of school kids example is strange, a school can have a variable number of kids. If its important to have a limit then enforce one in a type.

Option is 0 or 1, that is its meaning. You have recommended using foreach with a list - how many times will the body get called?

Programming with types is meant to make software more provably correct and to help with communication. In the case of 500 peoples lives I would also hope one would care enough to want to be exact and leverage types as far as possible.  

Now if you really only develop on your own, nobody else will ever touch your code and you can remember every line of code you have ever written then you may have an argument. 

On Aug 24, 2010 7:36 AM, "Russ Paielli" <russ.paielli@gmail.com> wrote:

On Mon, Aug 23, 2010 at 4:20 PM, Seth Tisue <seth@tisue.net> wrote: > > >  Naftoli> [...] The proble...

Believe it or not, I was once a bit of a theorist myself (in aerospace control theory), so I certainly don't consider it a derogatory label. (See http://RussP.us/attcon.pdf and http://RussP.us/publist.htm)

The problem with "theorists" is that they can sometimes be arrogant and pedantic. Worse yet, they are sometimes arrogant, pedantic, and WRONG! That's a bad combination.

When I suggested that List could perform some of the basic functionality of Option (by circumventing the need for null and in-band signaling), a Scala instructor who probably considers himself a theorist tersely (and falsely) claimed "that is not true," with no explanation whatsoever. When I attempted to correct him, he became rude and insulting, insisting that it was "bullshit," and referring to me on this forum as a "dim light bulb."

Folks, I am not suggesting for one second that List *should* be used in place of Option, but to claim that it absolutely cannot be used as such is clearly wrong.

Several people have pointed out that, whereas Option can hold at most one element, List can hold more than one, and a compiler cannot guarantee that it will not hold more than one value. That is true, but if that fact rules out List for this usage, think about what else it rules out List for. You could not use List (or Array) to hold three coordinates of position, because the compiler cannot guarantee that more than three coordinates will not be put in it. If you have a school with 1,598 students, you could use a List to hold their data, because the compiler cannot guarantee that someone will not put 1,599 students in it. Is it becoming clear how silly that objection is?

I understand that the "theorist" in question is highly regarded by some here and is not stupid, at least not all the time. That is why I am simply perplexed by his bogus assertions. I won't demand an apology, but I certainly don't think one would be out of order. I realize that he knows a lot about Scala and functional programming, and I have no desire to be at perpetual war with him on this forum. If he shows me basic respect, I will do the same for him. If not, I won't. Thanks.

Russ P.

On Tue, Aug 24, 2010 at 12:40 AM, Chris Twiner <chris.twiner@gmail.com> wrote:

I have stayed out of this because it borders on idiocy but this reply simply baffles me.

3 coordinates in an array ? If its really a conceptual tuple then use one.
list of school kids example is strange, a school can have a variable number of kids. If its important to have a limit then enforce one in a type.

Yeah, I guess you could use a tuple for three coordinates of position, but I don't think that's a good idea. You wouldn't want to write vector math utilities (for finding position differences, coordinate transformations, etc.) for tuples.
 

Option is 0 or 1, that is its meaning. You have recommended using foreach with a list - how many times will the body get called?

Programming with types is meant to make software more provably correct and to help with communication. In the case of 500 peoples lives I would also hope one would care enough to want to be exact and leverage types as far as possible.  

It's absolutely amazing. No matter how many times I say I am not actually recommending the use of List in lieu of Option, people reply as if I *am* recommending it and explain why it's not a good idea. Can anyone read English anymore?

Actually, I just thought of a case in which List supersedes Option. Suppose I am receiving a socket message with surveillance tracking data (in ASCII format) for 250 flights every 6 seconds. In my work, I actually do receive these sorts of messages. I parse the data record for each flight and try to determine if it is valid or not. An altitude of zero is invalid, for example, as is a garbled altitude of "34.44.22" or some such thing. Invalid data should be rare, but I need to identify it and reject it to the extent possible.

So now I need to send the data to my application. How should I do it? Should I put the tracking data for each flight in an Option, and put all the Options in a List? Well, that would be silly, wouldn't it. I might as well just ignore the invalid records and put the remaining valid ones in a List. No Options needed. List does the job all by itself! (But wait, what if it's the middle of the night and there's only one airplane in the sky? Oh, wait... then I have a List of zero or one element in lieu of an Option! Imagine that!)

Russ P.

--
http://RussP.us

Seth Tisue wrote:
> No one (no working
> programmer?) is going to accept the designation "unpragmatic".
>
I do, and so do a few well-read programmers that I know of (I assume
there are more that I don't).

Being assigned a label of "pragmatic" is perhaps one of the most
offensive things to say to those fond of reality.

PS: "Works for me" is a cognitive effect, not reality.

On Mon, Aug 23, 2010 at 6:25 PM, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

<snip/>  

Tony happens to be someone who knows many of the terms referencing specific concepts in functional programming.  These are specific idioms that you can encode into a language like Scala.  Often times pragmatics rediscover things that functional programmers have known about for years.   At these times, the "black and white scala instructor" will try to inform the developer with the "AHA!" moment which functional concept they've just rediscovered and the pros/cons of that particular idiom.   As they usually speak in theoretical "absolute truth" terms, sometimes users do not appreciate this.   Also, when in debates with pragmatics, the seasoned FP developer will whip out a bunch of these terms and idioms and it usually gives the pragmatic, who is a very smart person otherwise, a feeling of inferiority that leads to an explosion on this mailing list. 

I very highly doubt the issue is a feeling of inferiority, but rather an accurate feeling of being repeatedly misunderstood.I know you didn't mean this, but the implication of your wording is that seasoned FP developers are superior (their knowledge is beneficial but doesn't make them better, superior people) to "otherwise smart people" (again, an unintentional implication that lack of FP experience is a lack of smartness), and others, who are jealous, feel inferior around them.

I did not mean any intentional implication here.  I think of myself more in the pragmatic camp, although I like to understand the motivations of people.   I agree that the feeling of being repeatedly misunderstood is frustrating, but can be confounded by someone using foreign terms in a manner that makes one feel "being talked down to".   The natural reaction there is normal to become aggravated (at least in myself).   I'm just cautioning against that reaction on both sides, as it limits the exchange of ideas and understanding.  

When it comes to turing complete languages and why it doesn't make sense to remove the get from option, well you should look at Coq.  If you want to work towards a more provably safe language you will end up moving in that direction.

I do not understand the logic of that.Jack: Can we get rid of this nail sticking out the the carpet? People keep getting hurt on it.Mike: Perhaps you should switch to linoleum. Carpet always ends up having nails sticking out of it. (I know, that was a bit random, but you get the point.)

True, however it's important to understand what you're asking for.   "The grass is always greener on the other side", well, the other side may not be as green as we hoped.

On Tue, Aug 24, 2010 at 2:47 AM, Russ Paielli wrote:
> On Tue, Aug 24, 2010 at 12:40 AM, Chris Twiner
> wrote:
>>
>> I have stayed out of this because it borders on idiocy but this reply
>> simply baffles me.
>>
>> 3 coordinates in an array ? If its really a conceptual tuple then use one.
>> list of school kids example is strange, a school can have a variable
>> number of kids. If its important to have a limit then enforce one in a type.
>
> Yeah, I guess you could use a tuple for three coordinates of position, but I
> don't think that's a good idea. You wouldn't want to write vector math
> utilities (for finding position differences, coordinate transformations,
> etc.) for tuples.
>
>>
>> Option is 0 or 1, that is its meaning. You have recommended using foreach
>> with a list - how many times will the body get called?
>>
>> Programming with types is meant to make software more provably correct and
>> to help with communication. In the case of 500 peoples lives I would also
>> hope one would care enough to want to be exact and leverage types as far as
>> possible.
>
> It's absolutely amazing. No matter how many times I say I am not actually
> recommending the use of List in lieu of Option, people reply as if I *am*
> recommending it and explain why it's not a good idea. Can anyone read
> English anymore?
>
> Actually, I just thought of a case in which List supersedes Option. Suppose
> I am receiving a socket message with surveillance tracking data (in ASCII
> format) for 250 flights every 6 seconds. In my work, I actually do receive
> these sorts of messages. I parse the data record for each flight and try to
> determine if it is valid or not. An altitude of zero is invalid, for
> example, as is a garbled altitude of "34.44.22" or some such thing. Invalid
> data should be rare, but I need to identify it and reject it to the extent
> possible.
>
> So now I need to send the data to my application. How should I do it? Should
> I put the tracking data for each flight in an Option, and put all the
> Options in a List? Well, that would be silly, wouldn't it. I might as well
> just ignore the invalid records and put the remaining valid ones in a List.
> No Options needed. List does the job all by itself! (But wait, what if it's
> the middle of the night and there's only one airplane in the sky? Oh,
> wait... then I have a List of zero or one element in lieu of an Option!
> Imagine that!)
>
> Russ P.
>
> --

I'd use a List[Either[BadData, Altitude]], myself.

On Mon, Aug 23, 2010 at 9:20 PM, Randall R Schulz <rschulz@sonic.net> wrote:

On Monday August 23 2010, Naftoli Gugenheim wrote:
> ....
> Jack: Can we get rid of this nail sticking out the the carpet? People
> keep getting hurt on it.
> Mike: Perhaps you should switch to linoleum. Carpet always ends up
> having nails sticking out of it.
> ...

Linoleum is held down by adhesives containing toxic and carcinogenic
substances. I'd prefer to cut my foot than develop a life-threatening
illness.

And remember:
       "Proof by analogy is fraud."
       — Bjarne Stroustrup

Right--that's why it wasn't a proof, simply an analogy. :)Although come to think of it, if you took it as a proof then maybe you just proved my point! :)  

Randall Schulz

Define reality.

On Tue, Aug 24, 2010 at 6:49 AM, Tony Morris <tonymorris@gmail.com> wrote:

Seth Tisue wrote:
> No one (no working
> programmer?) is going to accept the designation "unpragmatic".
>
I do, and so do a few well-read programmers that I know of (I assume
there are more that I don't).

Being assigned a label of "pragmatic" is perhaps one of the most
offensive things to say to those fond of reality.

PS: "Works for me" is a cognitive effect, not reality.

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

I hear you, although the point doesn't depend on the particular terminology.Also, it may not actually be a dichotomy between two sets of people where people on side are completely on one side or the other. Perhaps everyone is a little of both. Maybe it's really left brain vs. right brain? Who knows... :)
Tony, do you consider yourself completely left-brained? :)


On Mon, Aug 23, 2010 at 7:20 PM, Seth Tisue <seth@tisue.net> wrote:

 Naftoli> [...] The problem here is not that the pragmatists
 Naftoli> disagree with the theorists. [...]

These words for the two sides were obviously chosen by a so-called
"pragmatist", not by a so-called "theorist".  No one (no working
programmer?) is going to accept the designation "unpragmatic".  Both
camps in this debate are attempting to efficiently construct working
programs, so I think politeness requires granting both camps equal
levels of "pragmatism".

I like the terms that were (are?) used in the AI world for two similar
camps: "neats" and "scruffies".

I'm not seriously pushing those particular terms, but you should find
*some* other words to use.  Calling your opponents "theorists" while you
call yourself a "pragmatist" is name-calling, not debate.

--
Seth Tisue @ Northwestern University | http://tisue.net
lead developer, NetLogo: http://ccl.northwestern.edu/netlogo/