[Lift] Re: Can or Box or something else

[David Pollak]

On Wed, Jan 7, 2009 at 1:22 AM, Tony Morris  wrote:

>
> Jorge Ortiz wrote:
> > You're talking about algebraic data types.
> >
> > The rest of us are discussing classes and inheritance.
> >
> > When someone says that a Dog "is" an Animal, they clearly don't
> > mean "is isomorphic to".
> >
> > --j
> >
> >
> I will make one last ditch effort.
>
> We are talking about Can and Option, both of which are algebraic data
> types. You might be discussing inheritance somehow (how?) but
> nevertheless, so was I when I tried to save the proposition i.e.
> implication and inheritance are equivalent for the purposes of the
> earlier discussion (forall A. Can[A] -> Option[A]). In any case, this
> does not somehow save the false proposition "Can is Option" unless...
>
> Perhaps you mean "an instance of Can is an instance of Option"? I
> don't think so. Perhaps then you mean "an instance of Can *could be
> written* as if it inherited from Option". Well this may be so, but the
> same can be said for every single function that exists. Int could
> inherit from Short but we do not say Int is (the data type?) Short. So
> what exactly do you mean when you say "Can is Option"? Or worse, "Can
> is an enhanced Option"? What is "enhanced" about the addition of a
> data constructor? I hope you see why I am protective of Oliver as he
> is bombarded with such falsehoods.
>
> Can is no more Option than it is List.
>
> "But" you say "It almost is, it just needs one more data constructor".
>
> Fine then, Unit is Option.
>
> "No, when I say Can is Option I mean to utilise the existing knowledge
> of the intended audience who is aware of Option. I really mean Can is
> like Option"
>
> Fine, now that this fact is admitted, we are in agreement - the false
> statement exists to appease a cognitive aspect, nothing more.
>
> When you say Can is Option, what exactly do you mean? Then when you
> have conveyed that meaning I will apply it elsewhere and have your
> agreement. If I do not, I will demand that you revise your intended
> meaning. We will repeat until you are either logically consistent or
> you have retracted the notion. This is inductive reasoning - an
> aversion of pragmatism sure - but I am compelled to use it nonetheless.


Tony,

I do not recall saying or hearing any Lift committers say "A Box [formerly
Can] is an Option".  We have said, "A Box is *like* an Option, except that
Box has Failure in addition to Empty/None."  Box and Option are *not* the
same and no one has claimed that they are.  Any Option can be converted to a
Box.  Any Box can be converted to an Option, but in some cases there is loss
of information, and in the case of a conversion, perhaps the developer who
makes the choice to convert Box -> Option is okay with losing that
information.  This is the final word on the substance of this topic.

In terms of this discussion, as I noted privately, you have been way out of
bounds in your behavior on this list.  This list is for an exchange of ideas
and you have exchanged nothing.  You have made demands and belittled people
who have not agreed with you.  I do not say this lightly, but, if you make
posts with demands rather than questions, I will ban you from this list.
Whatever value your brains and skill have are radically offset by your
presentation and demeanor.

David



>
>
> The recognition of a topological isomorphism between a square and a
> triangle requires my metaphor to be subverted somewhat to save it - I
> will abandon it instead (there are many examples of misintegration all
> around you after all).
>
> If this only fuels a fire and causes further diversion, then I resign.
>
> --
> Tony Morris
> http://tmorris.net/
>
> S, K and I ought to be enough for anybody.
>
>
>
> >
>


-- 
Lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Can or Box or something else

[Tony Morris]

Jorge Ortiz wrote:
> You're talking about algebraic data types.
>
> The rest of us are discussing classes and inheritance.
>
> When someone says that a Dog "is" an Animal, they clearly don't
> mean "is isomorphic to".
>
> --j
>
>
I will make one last ditch effort.

We are talking about Can and Option, both of which are algebraic data
types. You might be discussing inheritance somehow (how?) but
nevertheless, so was I when I tried to save the proposition i.e.
implication and inheritance are equivalent for the purposes of the
earlier discussion (forall A. Can[A] -> Option[A]). In any case, this
does not somehow save the false proposition "Can is Option" unless...

Perhaps you mean "an instance of Can is an instance of Option"? I
don't think so. Perhaps then you mean "an instance of Can *could be
written* as if it inherited from Option". Well this may be so, but the
same can be said for every single function that exists. Int could
inherit from Short but we do not say Int is (the data type?) Short. So
what exactly do you mean when you say "Can is Option"? Or worse, "Can
is an enhanced Option"? What is "enhanced" about the addition of a
data constructor? I hope you see why I am protective of Oliver as he
is bombarded with such falsehoods.

Can is no more Option than it is List.

"But" you say "It almost is, it just needs one more data constructor".

Fine then, Unit is Option.

"No, when I say Can is Option I mean to utilise the existing knowledge
of the intended audience who is aware of Option. I really mean Can is
like Option"

Fine, now that this fact is admitted, we are in agreement - the false
statement exists to appease a cognitive aspect, nothing more.

When you say Can is Option, what exactly do you mean? Then when you
have conveyed that meaning I will apply it elsewhere and have your
agreement. If I do not, I will demand that you revise your intended
meaning. We will repeat until you are either logically consistent or
you have retracted the notion. This is inductive reasoning - an
aversion of pragmatism sure - but I am compelled to use it nonetheless.

The recognition of a topological isomorphism between a square and a
triangle requires my metaphor to be subverted somewhat to save it - I
will abandon it instead (there are many examples of misintegration all
around you after all).

If this only fuels a fire and causes further diversion, then I resign.

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

S, K and I ought to be enough for anybody.



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Can or Box or something else

[Jorge Ortiz]

And, by the way, squares and triangles are isomorphic (
http://en.wikipedia.org/wiki/Topological_isomorphism).

--j

On Tue, Jan 6, 2009 at 6:44 PM, Tony Morris  wrote:

>
> "related to a combination of Option and Either"
> I'm not sure how I am missing that point since that is exactly the
> code I provided earlier. There is no point, except to assist Oliver in
> looking passed these fancy language tricks.
>
> In a pragmatic and therefore, not very useful way, yes Can is like
> Option. But now that I have subverted what it means for Can to "be
> like" anything I'm going to propose that Can is List - it is either
> empty or has a value (right?). Let's all chime in now with our
> preferred cognitive biases now that we have lost meaning into the
> impractical infection called pragmatism.
>
> A square is like a triangle, but with one extra side. No wait, a
> square is a combination of four triangles. Oh actually, a square is
> like a triangle, except it is not in any way at all.
>
> Don't fall for it Oliver - it's a misintegration.
>
> --
> Tony Morris
> http://tmorris.net/
>
> S, K and I ought to be enough for anybody.
>
>
> Miles Sabin wrote:
> > On Tue, Jan 6, 2009 at 11:23 PM, Tony Morris 
> > wrote:
> >> No this is a mistake. Can is not an Option. Indeed it is (almost)
> >>  impossible to write Can using Option (if you are familiar with
> >> Peano Arithmetic you will understand the need to qualify with
> >> almost).
> >
> > While you're right in a (very) narrowly technical sense you're
> > missing the point that Lift's Can has functionality that is very
> > closely related to a combination of Option and Either in a
> > touchy-feely pragmatic getting-useful-things-actually-done sort of
> > sense.
> >
> > To prove the point, here,
> >
> > http://www.milessabin.com/misc/Chain.scala
> >
> > is something I put together a while ago which can be used in a very
> >  similar way to Can (at least, I expect that's the case ... I
> > haven't worked with Lift so I can't be sure) but which only exposes
> > Option and Either in it's public interface. It's also sufficiently
> > Monad like to get along nicely with for comprehensions.
> >
> > Given the likelihood of confusion between Can and Option
> > (irrespective the algebraic niceties) I wish Lift had gone for
> > something more like that than a rename to Box.
> >
> > Cheers,
> >
> >
> > Miles
> >
>
>
>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Can or Box or something else

[Jorge Ortiz]

You're talking about algebraic data types.

The rest of us are discussing classes and inheritance.

When someone says that a Dog "is" an Animal, they clearly don't mean "is
isomorphic to".

--j

On Tue, Jan 6, 2009 at 6:46 PM, Tony Morris  wrote:

>
> Jorge Ortiz wrote:
> > For most people, "is" does not always and exclusively mean
> > "bi-implication". You are free to think this way, if you choose,
> > but please don't impose your Language Police on us.
> >
> > --j
>
> For most people, "is" means "is isomorphic to" when talking about data
> types. Furthermore, you are free to invent your own definition, but it
> is loaded with nothing more than cognitive bias. If Can is Option -
> under a (failed) definition, then Can is also List by precisely the
> same flawed method.
>
> Somehow, I'm not sure it is I who is "missing the point".
>
> I had no intention of this. I'm finished. I hope Oliver has understood.
>
>
> --
> Tony Morris
> http://tmorris.net/
>
> S, K and I ought to be enough for anybody.
>
>
>
>
>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Can or Box or something else

[Tony Morris]

Warren Henning wrote:
> On Tue, Jan 6, 2009 at 3:49 PM, Tony Morris 
> wrote:
>> not an Option. It was not even close (lack of totality in this
>> test is catastrophic).
>
> Who cares?
>
> >
>
Oliver did when he asked me. I will be seeing him tomorrow in Sydney
where I can clarify any misunderstandings that he might still have.
Also, I care a little when nonsense is propagated at the expense of
people wishing to learn (Oliver), but not enough to battle the
pragmatists.

Have fun.

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

S, K and I ought to be enough for anybody.



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Can or Box or something else

[Tony Morris]

Jorge Ortiz wrote:
> For most people, "is" does not always and exclusively mean
> "bi-implication". You are free to think this way, if you choose,
> but please don't impose your Language Police on us.
>
> --j

For most people, "is" means "is isomorphic to" when talking about data
types. Furthermore, you are free to invent your own definition, but it
is loaded with nothing more than cognitive bias. If Can is Option -
under a (failed) definition, then Can is also List by precisely the
same flawed method.

Somehow, I'm not sure it is I who is "missing the point".

I had no intention of this. I'm finished. I hope Oliver has understood.


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

S, K and I ought to be enough for anybody.






--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Can or Box or something else

[Tony Morris]

"related to a combination of Option and Either"
I'm not sure how I am missing that point since that is exactly the
code I provided earlier. There is no point, except to assist Oliver in
looking passed these fancy language tricks.

In a pragmatic and therefore, not very useful way, yes Can is like
Option. But now that I have subverted what it means for Can to "be
like" anything I'm going to propose that Can is List - it is either
empty or has a value (right?). Let's all chime in now with our
preferred cognitive biases now that we have lost meaning into the
impractical infection called pragmatism.

A square is like a triangle, but with one extra side. No wait, a
square is a combination of four triangles. Oh actually, a square is
like a triangle, except it is not in any way at all.

Don't fall for it Oliver - it's a misintegration.

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

S, K and I ought to be enough for anybody.


Miles Sabin wrote:
> On Tue, Jan 6, 2009 at 11:23 PM, Tony Morris 
> wrote:
>> No this is a mistake. Can is not an Option. Indeed it is (almost)
>>  impossible to write Can using Option (if you are familiar with
>> Peano Arithmetic you will understand the need to qualify with
>> almost).
>
> While you're right in a (very) narrowly technical sense you're
> missing the point that Lift's Can has functionality that is very
> closely related to a combination of Option and Either in a
> touchy-feely pragmatic getting-useful-things-actually-done sort of
> sense.
>
> To prove the point, here,
>
> http://www.milessabin.com/misc/Chain.scala
>
> is something I put together a while ago which can be used in a very
>  similar way to Can (at least, I expect that's the case ... I
> haven't worked with Lift so I can't be sure) but which only exposes
> Option and Either in it's public interface. It's also sufficiently
> Monad like to get along nicely with for comprehensions.
>
> Given the likelihood of confusion between Can and Option
> (irrespective the algebraic niceties) I wish Lift had gone for
> something more like that than a rename to Box.
>
> Cheers,
>
>
> Miles
>




--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Can or Box or something else

[Warren Henning]

On Tue, Jan 6, 2009 at 3:49 PM, Tony Morris  wrote:
> not an Option. It was not even close (lack of totality in this test is
> catastrophic).

Who cares?

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Can or Box or something else

[David Pollak]

On Tue, Jan 6, 2009 at 5:27 PM, Josh Suereth wrote:

> Do any conversions exist to treat a Box[_] as an
> Either[Option[_],Exception] or as an Option[_]?  Are there any helper
> functions that lift could benefit from by having these?
>

Box instances have a toOption method.  Full -> Some, Empty/Failure -> None
The Box object has:
apply[T](in: Option[T]): Box[T] = in match {case Some(t) => Full(t) case _
=> Empty}

There's an implicit conversion from Box to Option.


>
>
> Also, anytime I see the line "I leave this as an excercise to the reader" I
> feel like I'm being lectured :)
>
> On Jan 6, 2009, at 7:38 PM, "Jorge Ortiz"  wrote:
>
> For most people, "is" does not always and exclusively mean
> "bi-implication". You are free to think this way, if you choose, but please
> don't impose your Language Police on us.
>
> --j
>
> On Tue, Jan 6, 2009 at 5:49 PM, Tony Morris < 
> tonymor...@gmail.com> wrote:
>
>>
>> When talking about data types "is" means "is congruent to" or "is
>> isomorphic to". You are not free to use "is" arbitrarily, since if you
>> are then Can "is" anything I want it to be.
>> Since equivalence can be broken into an implication both ways e.g. A
>> -> B and B -> A then it is quite easy to test if "Can is an Option".
>>
>> def f[A](o: Option[A]): Can[A] // this should be total and bijective
>> def g[A](c: Can[A]): Option[A] // this should be total and bijective
>>
>> The use of => in function signatures means logical implication. Does
>> Can imply Option? Yes (you can complete the g function). Does Option
>> imply Can? No (you cannot complete the f function). Therefore, Can is
>> not an Option. It was not even close (lack of totality in this test is
>> catastrophic).
>>
>> If you want to try to save this notion of "Well Can is a something",
>> then I have already pointed out a suggestion. Try to think of others,
>> but do not say that Can is an Option - it is not, not even close. Poor
>> Oliver was all confuzzled when he popped this one to me the other day.
>>
>> --
>> Tony Morris
>>  http://tmorris.net/
>>
>> S, K and I ought to be enough for anybody.
>>
>>
>> Jorge Ortiz wrote:
>> > It depends on what the meaning of "is" is.
>> >
>> > If Option were not sealed, "Can" could be "implemented" as an
>> > Option... by adding Failure and Empty as subclasses of None. In
>> > this (OO) sense, a Can is an option.
>> >
>> > In the algebraic sense, then you're probably right that a Can is
>> > not an Option.
>> >
>> > --j
>> >
>> > On Tue, Jan 6, 2009 at 5:23 PM, Tony Morris < 
>> tonymor...@gmail.com
>> > tonymor...@gmail.com>> wrote:
>> >
>> >
>> > No this is a mistake. Can is not an Option. Indeed it is (almost)
>> > impossible to write Can using Option (if you are familiar with
>> > Peano Arithmetic you will understand the need to qualify with
>> > almost). There is an arrow from forall A. Can[A] to Option[A] but
>> > not from forall A. Option[A] to Can[A] (easily) - try it for
>> > yourself. To suggest that Can is an Option (or "an Option with more
>> > features" or "an Either") is a mistake of misintegration (Peikoff
>> > DIM Hypothesis). Indeed the Can algebra has nothing to do with
>> > Option (except for the aforementioned function). There is no
>> > isomorphism between Can and Option - they are not the same, not
>> > even close.
>> >
>> > Here is a bit of code for fun. Note the bijective function using
>> > Either alone:
>> >
>> > sealed trait T[+A] { val e: Either[(String, T[Throwable],
>> > List[(String, Throwable)], Either[A, Unit]]
>> >
>> > // bijection to e val c: Can[A] = e match { case Left(m, e, c) =>
>> > Failure(m, e, // Can makes the mistake of using a data constructor
>> > as a type. // Unfortunately Scala permits this. c map toFailure)
>> > case Right(e) => e match { case Left(a) => Full(a) case Right(_) =>
>> > Empty } } }
>> >
>> > object T { // construct with Either or Can }
>> >
>> > -- Tony Morris http://tmorris.net/
>> >
>> > S, K and I ought to be enough for anybody.
>> >
>> >
>> > David Pollak wrote:
>> >> It's an Option.
>> >>
>> >> It contains a value or it doesn't. In the case that it does not
>> >> contain a value, it may contain out of band information. This is
>> >> not any different from None which contains information. It
>> >> contains the information that it lacks information.
>> >>
>> >> Sure, you can write Option[T] as Either[T, Nothing], but the
>> >> value of only having on type is lost.
>> >>
>> >> On Tue, Jan 6, 2009 at 2:59 PM, Tony Morris
>> > < tonymor...@gmail.com 
>> tonymor...@gmail.com>
>> >> tonymor...@gmail.com 
>> >> 
>> tonymor...@gmail.com>>>
>> > wrote:
>> >>
>> >>
>> >> Right, that's what Oliver said and I was reinforcing it with
>> >> deductive reasoning. It is also not Option. It is something else
>> >> altogether. Nevertheless, an isomorphism can easily be written
>> > with
>> >> Either alone (ignoring bottoms). So in some loose sense "it is an
>> >>  Either".
>> >>
>> >> -- Tony Morris 

[Lift] Re: Can or Box or something else

[Josh Suereth]

Do any conversions exist to treat a Box[_] as an  
Either[Option[_],Exception] or as an Option[_]?  Are there any helper  
functions that lift could benefit from by having these?

Also, anytime I see the line "I leave this as an excercise to the  
reader" I feel like I'm being lectured :)

On Jan 6, 2009, at 7:38 PM, "Jorge Ortiz"  wrote:

> For most people, "is" does not always and exclusively mean "bi- 
> implication". You are free to think this way, if you choose, but  
> please don't impose your Language Police on us.
>
> --j
>
> On Tue, Jan 6, 2009 at 5:49 PM, Tony Morris   
> wrote:
>
> When talking about data types "is" means "is congruent to" or "is
> isomorphic to". You are not free to use "is" arbitrarily, since if you
> are then Can "is" anything I want it to be.
> Since equivalence can be broken into an implication both ways e.g. A
> -> B and B -> A then it is quite easy to test if "Can is an Option".
>
> def f[A](o: Option[A]): Can[A] // this should be total and bijective
> def g[A](c: Can[A]): Option[A] // this should be total and bijective
>
> The use of => in function signatures means logical implication. Does
> Can imply Option? Yes (you can complete the g function). Does Option
> imply Can? No (you cannot complete the f function). Therefore, Can is
> not an Option. It was not even close (lack of totality in this test is
> catastrophic).
>
> If you want to try to save this notion of "Well Can is a something",
> then I have already pointed out a suggestion. Try to think of others,
> but do not say that Can is an Option - it is not, not even close. Poor
> Oliver was all confuzzled when he popped this one to me the other day.
>
> --
> Tony Morris
> http://tmorris.net/
>
> S, K and I ought to be enough for anybody.
>
>
> Jorge Ortiz wrote:
> > It depends on what the meaning of "is" is.
> >
> > If Option were not sealed, "Can" could be "implemented" as an
> > Option... by adding Failure and Empty as subclasses of None. In
> > this (OO) sense, a Can is an option.
> >
> > In the algebraic sense, then you're probably right that a Can is
> > not an Option.
> >
> > --j
> >
> > On Tue, Jan 6, 2009 at 5:23 PM, Tony Morris  > > wrote:
> >
> >
> > No this is a mistake. Can is not an Option. Indeed it is (almost)
> > impossible to write Can using Option (if you are familiar with
> > Peano Arithmetic you will understand the need to qualify with
> > almost). There is an arrow from forall A. Can[A] to Option[A] but
> > not from forall A. Option[A] to Can[A] (easily) - try it for
> > yourself. To suggest that Can is an Option (or "an Option with more
> > features" or "an Either") is a mistake of misintegration (Peikoff
> > DIM Hypothesis). Indeed the Can algebra has nothing to do with
> > Option (except for the aforementioned function). There is no
> > isomorphism between Can and Option - they are not the same, not
> > even close.
> >
> > Here is a bit of code for fun. Note the bijective function using
> > Either alone:
> >
> > sealed trait T[+A] { val e: Either[(String, T[Throwable],
> > List[(String, Throwable)], Either[A, Unit]]
> >
> > // bijection to e val c: Can[A] = e match { case Left(m, e, c) =>
> > Failure(m, e, // Can makes the mistake of using a data constructor
> > as a type. // Unfortunately Scala permits this. c map toFailure)
> > case Right(e) => e match { case Left(a) => Full(a) case Right(_) =>
> > Empty } } }
> >
> > object T { // construct with Either or Can }
> >
> > -- Tony Morris http://tmorris.net/
> >
> > S, K and I ought to be enough for anybody.
> >
> >
> > David Pollak wrote:
> >> It's an Option.
> >>
> >> It contains a value or it doesn't. In the case that it does not
> >> contain a value, it may contain out of band information. This is
> >> not any different from None which contains information. It
> >> contains the information that it lacks information.
> >>
> >> Sure, you can write Option[T] as Either[T, Nothing], but the
> >> value of only having on type is lost.
> >>
> >> On Tue, Jan 6, 2009 at 2:59 PM, Tony Morris
> > mailto:tonymor...@gmail.com>
> >> >>
> > wrote:
> >>
> >>
> >> Right, that's what Oliver said and I was reinforcing it with
> >> deductive reasoning. It is also not Option. It is something else
> >> altogether. Nevertheless, an isomorphism can easily be written
> > with
> >> Either alone (ignoring bottoms). So in some loose sense "it is an
> >>  Either".
> >>
> >> -- Tony Morris http://tmorris.net/
> >>
> >> S, K and I ought to be enough for anybody.
> >>
> >>
> >> David Pollak wrote:
> >>> Tony,
> >>>
> >>> Can (now Box) is not an Either.
> >>>
> >>> David
> >>>
> >>> On Tue, Jan 6, 2009 at 2:37 PM, Tony Morris
> >> mailto:tonymor...@gmail.com>
> > >
> >>> 
> >  >> wrote:
> >>>
> >>>
> >>> Can is n

[Lift] Re: Can or Box or something else

[Jorge Ortiz]

For most people, "is" does not always and exclusively mean "bi-implication".
You are free to think this way, if you choose, but please don't impose your
Language Police on us.

--j

On Tue, Jan 6, 2009 at 5:49 PM, Tony Morris  wrote:

>
> When talking about data types "is" means "is congruent to" or "is
> isomorphic to". You are not free to use "is" arbitrarily, since if you
> are then Can "is" anything I want it to be.
> Since equivalence can be broken into an implication both ways e.g. A
> -> B and B -> A then it is quite easy to test if "Can is an Option".
>
> def f[A](o: Option[A]): Can[A] // this should be total and bijective
> def g[A](c: Can[A]): Option[A] // this should be total and bijective
>
> The use of => in function signatures means logical implication. Does
> Can imply Option? Yes (you can complete the g function). Does Option
> imply Can? No (you cannot complete the f function). Therefore, Can is
> not an Option. It was not even close (lack of totality in this test is
> catastrophic).
>
> If you want to try to save this notion of "Well Can is a something",
> then I have already pointed out a suggestion. Try to think of others,
> but do not say that Can is an Option - it is not, not even close. Poor
> Oliver was all confuzzled when he popped this one to me the other day.
>
> --
> Tony Morris
> http://tmorris.net/
>
> S, K and I ought to be enough for anybody.
>
>
> Jorge Ortiz wrote:
> > It depends on what the meaning of "is" is.
> >
> > If Option were not sealed, "Can" could be "implemented" as an
> > Option... by adding Failure and Empty as subclasses of None. In
> > this (OO) sense, a Can is an option.
> >
> > In the algebraic sense, then you're probably right that a Can is
> > not an Option.
> >
> > --j
> >
> > On Tue, Jan 6, 2009 at 5:23 PM, Tony Morris  > > wrote:
> >
> >
> > No this is a mistake. Can is not an Option. Indeed it is (almost)
> > impossible to write Can using Option (if you are familiar with
> > Peano Arithmetic you will understand the need to qualify with
> > almost). There is an arrow from forall A. Can[A] to Option[A] but
> > not from forall A. Option[A] to Can[A] (easily) - try it for
> > yourself. To suggest that Can is an Option (or "an Option with more
> > features" or "an Either") is a mistake of misintegration (Peikoff
> > DIM Hypothesis). Indeed the Can algebra has nothing to do with
> > Option (except for the aforementioned function). There is no
> > isomorphism between Can and Option - they are not the same, not
> > even close.
> >
> > Here is a bit of code for fun. Note the bijective function using
> > Either alone:
> >
> > sealed trait T[+A] { val e: Either[(String, T[Throwable],
> > List[(String, Throwable)], Either[A, Unit]]
> >
> > // bijection to e val c: Can[A] = e match { case Left(m, e, c) =>
> > Failure(m, e, // Can makes the mistake of using a data constructor
> > as a type. // Unfortunately Scala permits this. c map toFailure)
> > case Right(e) => e match { case Left(a) => Full(a) case Right(_) =>
> > Empty } } }
> >
> > object T { // construct with Either or Can }
> >
> > -- Tony Morris http://tmorris.net/
> >
> > S, K and I ought to be enough for anybody.
> >
> >
> > David Pollak wrote:
> >> It's an Option.
> >>
> >> It contains a value or it doesn't. In the case that it does not
> >> contain a value, it may contain out of band information. This is
> >> not any different from None which contains information. It
> >> contains the information that it lacks information.
> >>
> >> Sure, you can write Option[T] as Either[T, Nothing], but the
> >> value of only having on type is lost.
> >>
> >> On Tue, Jan 6, 2009 at 2:59 PM, Tony Morris
> > mailto:tonymor...@gmail.com>
> >> >>
> > wrote:
> >>
> >>
> >> Right, that's what Oliver said and I was reinforcing it with
> >> deductive reasoning. It is also not Option. It is something else
> >> altogether. Nevertheless, an isomorphism can easily be written
> > with
> >> Either alone (ignoring bottoms). So in some loose sense "it is an
> >>  Either".
> >>
> >> -- Tony Morris http://tmorris.net/
> >>
> >> S, K and I ought to be enough for anybody.
> >>
> >>
> >> David Pollak wrote:
> >>> Tony,
> >>>
> >>> Can (now Box) is not an Either.
> >>>
> >>> David
> >>>
> >>> On Tue, Jan 6, 2009 at 2:37 PM, Tony Morris
> >> mailto:tonymor...@gmail.com>
> > >
> >>> 
> >  >> wrote:
> >>>
> >>>
> >>> Can is not an Option and to call it so in any way is an error
> >>> of misintegration. Indeed it would be an error to "replace
> >>> Option
> >> with
> >>> Can" - they are completely different algebras. Either is kinded
> >>> * -> * -> * so cannot possible be isomorphic and cannot
> >>> possibly
> >> have
> >>> map, flatMap etc (though it can have a bifunctor map bei

[Lift] Re: Can or Box or something else

[Miles Sabin]

On Tue, Jan 6, 2009 at 11:23 PM, Tony Morris  wrote:
> No this is a mistake. Can is not an Option. Indeed it is (almost)
> impossible to write Can using Option (if you are familiar with Peano
> Arithmetic you will understand the need to qualify with almost).

While you're right in a (very) narrowly technical sense you're missing
the point that Lift's Can has functionality that is very closely
related to a combination of Option and Either in a touchy-feely
pragmatic getting-useful-things-actually-done sort of sense.

To prove the point, here,

  http://www.milessabin.com/misc/Chain.scala

is something I put together a while ago which can be used in a very
similar way to Can (at least, I expect that's the case ... I haven't
worked with Lift so I can't be sure) but which only exposes Option and
Either in it's public interface. It's also sufficiently Monad like to
get along nicely with for comprehensions.

Given the likelihood of confusion between Can and Option (irrespective
the algebraic niceties) I wish Lift had gone for something more like
that than a rename to Box.

Cheers,


Miles

-- 
Miles Sabin
tel:+44 (0)1273 720 779
mobile: +44 (0)7813 944 528
skype:  milessabin

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Can or Box or something else

[Tony Morris]

When talking about data types "is" means "is congruent to" or "is
isomorphic to". You are not free to use "is" arbitrarily, since if you
are then Can "is" anything I want it to be.
Since equivalence can be broken into an implication both ways e.g. A
-> B and B -> A then it is quite easy to test if "Can is an Option".

def f[A](o: Option[A]): Can[A] // this should be total and bijective
def g[A](c: Can[A]): Option[A] // this should be total and bijective

The use of => in function signatures means logical implication. Does
Can imply Option? Yes (you can complete the g function). Does Option
imply Can? No (you cannot complete the f function). Therefore, Can is
not an Option. It was not even close (lack of totality in this test is
catastrophic).

If you want to try to save this notion of "Well Can is a something",
then I have already pointed out a suggestion. Try to think of others,
but do not say that Can is an Option - it is not, not even close. Poor
Oliver was all confuzzled when he popped this one to me the other day.

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

S, K and I ought to be enough for anybody.


Jorge Ortiz wrote:
> It depends on what the meaning of "is" is.
>
> If Option were not sealed, "Can" could be "implemented" as an
> Option... by adding Failure and Empty as subclasses of None. In
> this (OO) sense, a Can is an option.
>
> In the algebraic sense, then you're probably right that a Can is
> not an Option.
>
> --j
>
> On Tue, Jan 6, 2009 at 5:23 PM, Tony Morris  > wrote:
>
>
> No this is a mistake. Can is not an Option. Indeed it is (almost)
> impossible to write Can using Option (if you are familiar with
> Peano Arithmetic you will understand the need to qualify with
> almost). There is an arrow from forall A. Can[A] to Option[A] but
> not from forall A. Option[A] to Can[A] (easily) - try it for
> yourself. To suggest that Can is an Option (or "an Option with more
> features" or "an Either") is a mistake of misintegration (Peikoff
> DIM Hypothesis). Indeed the Can algebra has nothing to do with
> Option (except for the aforementioned function). There is no
> isomorphism between Can and Option - they are not the same, not
> even close.
>
> Here is a bit of code for fun. Note the bijective function using
> Either alone:
>
> sealed trait T[+A] { val e: Either[(String, T[Throwable],
> List[(String, Throwable)], Either[A, Unit]]
>
> // bijection to e val c: Can[A] = e match { case Left(m, e, c) =>
> Failure(m, e, // Can makes the mistake of using a data constructor
> as a type. // Unfortunately Scala permits this. c map toFailure)
> case Right(e) => e match { case Left(a) => Full(a) case Right(_) =>
> Empty } } }
>
> object T { // construct with Either or Can }
>
> -- Tony Morris http://tmorris.net/
>
> S, K and I ought to be enough for anybody.
>
>
> David Pollak wrote:
>> It's an Option.
>>
>> It contains a value or it doesn't. In the case that it does not
>> contain a value, it may contain out of band information. This is
>> not any different from None which contains information. It
>> contains the information that it lacks information.
>>
>> Sure, you can write Option[T] as Either[T, Nothing], but the
>> value of only having on type is lost.
>>
>> On Tue, Jan 6, 2009 at 2:59 PM, Tony Morris
> mailto:tonymor...@gmail.com>
>> >>
> wrote:
>>
>>
>> Right, that's what Oliver said and I was reinforcing it with
>> deductive reasoning. It is also not Option. It is something else
>> altogether. Nevertheless, an isomorphism can easily be written
> with
>> Either alone (ignoring bottoms). So in some loose sense "it is an
>>  Either".
>>
>> -- Tony Morris http://tmorris.net/
>>
>> S, K and I ought to be enough for anybody.
>>
>>
>> David Pollak wrote:
>>> Tony,
>>>
>>> Can (now Box) is not an Either.
>>>
>>> David
>>>
>>> On Tue, Jan 6, 2009 at 2:37 PM, Tony Morris
>> mailto:tonymor...@gmail.com>
> >
>>> 
> > wrote:
>>>
>>>
>>> Can is not an Option and to call it so in any way is an error
>>> of misintegration. Indeed it would be an error to "replace
>>> Option
>> with
>>> Can" - they are completely different algebras. Either is kinded
>>> * -> * -> * so cannot possible be isomorphic and cannot
>>> possibly
>> have
>>> map, flatMap etc (though it can have a bifunctor map being
>>> covariant in both type arguments). However,
>>> Either.LeftProjection and Either.RightProjection are kinded *
>>> -> * and are both
>> covariant
>>> functors and monads, hence map, flatMap etc. are available.
>>> e.g. for(x <- either.left) ... is valid, try it.
>>>
>>> Of mild interest, it is possible to construct an isomorphism
>> to Can
>>> using both Either and Option. Indeed, it is possible to
>>> construct an isomorphism to Option using Either e.g. forall A.
>>> Opt

[Lift] Re: Can or Box or something else

[Jorge Ortiz]

It depends on what the meaning of "is" is.

If Option were not sealed, "Can" could be "implemented" as an Option... by
adding Failure and Empty as subclasses of None. In this (OO) sense, a Can is
an option.

In the algebraic sense, then you're probably right that a Can is not an
Option.

--j

On Tue, Jan 6, 2009 at 5:23 PM, Tony Morris  wrote:

>
> No this is a mistake. Can is not an Option. Indeed it is (almost)
> impossible to write Can using Option (if you are familiar with Peano
> Arithmetic you will understand the need to qualify with almost). There
> is an arrow from forall A. Can[A] to Option[A] but not from forall A.
> Option[A] to Can[A] (easily) - try it for yourself. To suggest that
> Can is an Option (or "an Option with more features" or "an Either") is
> a mistake of misintegration (Peikoff DIM Hypothesis). Indeed the Can
> algebra has nothing to do with Option (except for the aforementioned
> function). There is no isomorphism between Can and Option - they are
> not the same, not even close.
>
> Here is a bit of code for fun. Note the bijective function using
> Either alone:
>
> sealed trait T[+A] {
> val e: Either[(String, T[Throwable], List[(String, Throwable)],
> Either[A, Unit]]
>
> // bijection to e
> val c: Can[A] = e match {
> case Left(m, e, c) => Failure(m, e,
> // Can makes the mistake of using a data constructor as a type.
> // Unfortunately Scala permits this.
> c map toFailure)
> case Right(e) => e match {
> case Left(a) => Full(a)
> case Right(_) => Empty
> }
> }
> }
>
> object T {
> // construct with Either or Can
> }
>
> --
> Tony Morris
> http://tmorris.net/
>
> S, K and I ought to be enough for anybody.
>
>
> David Pollak wrote:
> > It's an Option.
> >
> > It contains a value or it doesn't. In the case that it does not
> > contain a value, it may contain out of band information. This is
> > not any different from None which contains information. It
> > contains the information that it lacks information.
> >
> > Sure, you can write Option[T] as Either[T, Nothing], but the value
> > of only having on type is lost.
> >
> > On Tue, Jan 6, 2009 at 2:59 PM, Tony Morris  > > wrote:
> >
> >
> > Right, that's what Oliver said and I was reinforcing it with
> > deductive reasoning. It is also not Option. It is something else
> > altogether. Nevertheless, an isomorphism can easily be written with
> > Either alone (ignoring bottoms). So in some loose sense "it is an
> > Either".
> >
> > -- Tony Morris http://tmorris.net/
> >
> > S, K and I ought to be enough for anybody.
> >
> >
> > David Pollak wrote:
> >> Tony,
> >>
> >> Can (now Box) is not an Either.
> >>
> >> David
> >>
> >> On Tue, Jan 6, 2009 at 2:37 PM, Tony Morris
> > mailto:tonymor...@gmail.com>
> >> >>
> > wrote:
> >>
> >>
> >> Can is not an Option and to call it so in any way is an error of
> >> misintegration. Indeed it would be an error to "replace Option
> > with
> >> Can" - they are completely different algebras. Either is kinded *
> >> -> * -> * so cannot possible be isomorphic and cannot possibly
> > have
> >> map, flatMap etc (though it can have a bifunctor map being
> >> covariant in both type arguments). However, Either.LeftProjection
> >> and Either.RightProjection are kinded * -> * and are both
> > covariant
> >> functors and monads, hence map, flatMap etc. are available. e.g.
> >> for(x <- either.left) ... is valid, try it.
> >>
> >> Of mild interest, it is possible to construct an isomorphism
> > to Can
> >> using both Either and Option. Indeed, it is possible to construct
> >> an isomorphism to Option using Either e.g. forall A. Option[A] ≡
> >> Either [Unit, A] so it is possible using Either alone. I'll
> >> leave both as reader exercises.
> >>
> >>
> >> On Dec 21 2008, 5:15 am, Oliver Lambert  > 
> >> >> wrote:
> >>> Ok so Can is not either an Either or an Option, its a Can. I
> >> kind of
> >>> wondered when I first used Can, and it was described as an
> >> enhanced
> >>> Option, why it wasn't called something like Option+ with
> >> None, Some
> >>> and Failure.
> >>>
> >>> On 21/12/2008, at 5:47 AM, David Pollak wrote:
> >>>
>  Can has map, flatMap, filter etc. So it can be used in a for
>  comphrension. I don't believe Either has those methods.
> >> Further,
>  Can has a bunch of helpers to turn Empty into Failure
> >>>
>  On Dec 20, 2008 10:33 AM, "Oliver Lambert"  > 
> >> >> wrote:
> >>>
>  Is Can a little less like Option and more like scala.Either,
> >> where
>  the left side is used to indicate failure? On 21/12/2008, at
>  1:43 AM, David Pollak wrote: > Folks, > >
> >> Over the
>  year that Lift has had Can[T...
> >>
> >>
> >>
> >>
> >>
> >> -- Lift, the simply functional web framework http://liftweb.net
> >> Collaborative Task Managemen

[Lift] Re: Can or Box or something else

[Tony Morris]

No this is a mistake. Can is not an Option. Indeed it is (almost)
impossible to write Can using Option (if you are familiar with Peano
Arithmetic you will understand the need to qualify with almost). There
is an arrow from forall A. Can[A] to Option[A] but not from forall A.
Option[A] to Can[A] (easily) - try it for yourself. To suggest that
Can is an Option (or "an Option with more features" or "an Either") is
a mistake of misintegration (Peikoff DIM Hypothesis). Indeed the Can
algebra has nothing to do with Option (except for the aforementioned
function). There is no isomorphism between Can and Option - they are
not the same, not even close.

Here is a bit of code for fun. Note the bijective function using
Either alone:

sealed trait T[+A] {
val e: Either[(String, T[Throwable], List[(String, Throwable)],
Either[A, Unit]]

// bijection to e
val c: Can[A] = e match {
case Left(m, e, c) => Failure(m, e,
// Can makes the mistake of using a data constructor as a type.
// Unfortunately Scala permits this.
c map toFailure)
case Right(e) => e match {
case Left(a) => Full(a)
case Right(_) => Empty
}
}
}

object T {
// construct with Either or Can
}

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

S, K and I ought to be enough for anybody.


David Pollak wrote:
> It's an Option.
>
> It contains a value or it doesn't. In the case that it does not
> contain a value, it may contain out of band information. This is
> not any different from None which contains information. It
> contains the information that it lacks information.
>
> Sure, you can write Option[T] as Either[T, Nothing], but the value
> of only having on type is lost.
>
> On Tue, Jan 6, 2009 at 2:59 PM, Tony Morris  > wrote:
>
>
> Right, that's what Oliver said and I was reinforcing it with
> deductive reasoning. It is also not Option. It is something else
> altogether. Nevertheless, an isomorphism can easily be written with
> Either alone (ignoring bottoms). So in some loose sense "it is an
> Either".
>
> -- Tony Morris http://tmorris.net/
>
> S, K and I ought to be enough for anybody.
>
>
> David Pollak wrote:
>> Tony,
>>
>> Can (now Box) is not an Either.
>>
>> David
>>
>> On Tue, Jan 6, 2009 at 2:37 PM, Tony Morris
> mailto:tonymor...@gmail.com>
>> >>
> wrote:
>>
>>
>> Can is not an Option and to call it so in any way is an error of
>> misintegration. Indeed it would be an error to "replace Option
> with
>> Can" - they are completely different algebras. Either is kinded *
>> -> * -> * so cannot possible be isomorphic and cannot possibly
> have
>> map, flatMap etc (though it can have a bifunctor map being
>> covariant in both type arguments). However, Either.LeftProjection
>> and Either.RightProjection are kinded * -> * and are both
> covariant
>> functors and monads, hence map, flatMap etc. are available. e.g.
>> for(x <- either.left) ... is valid, try it.
>>
>> Of mild interest, it is possible to construct an isomorphism
> to Can
>> using both Either and Option. Indeed, it is possible to construct
>> an isomorphism to Option using Either e.g. forall A. Option[A] ≡
>> Either [Unit, A] so it is possible using Either alone. I'll
>> leave both as reader exercises.
>>
>>
>> On Dec 21 2008, 5:15 am, Oliver Lambert  
>> >> wrote:
>>> Ok so Can is not either an Either or an Option, its a Can. I
>> kind of
>>> wondered when I first used Can, and it was described as an
>> enhanced
>>> Option, why it wasn't called something like Option+ with
>> None, Some
>>> and Failure.
>>>
>>> On 21/12/2008, at 5:47 AM, David Pollak wrote:
>>>
 Can has map, flatMap, filter etc. So it can be used in a for
 comphrension. I don't believe Either has those methods.
>> Further,
 Can has a bunch of helpers to turn Empty into Failure
>>>
 On Dec 20, 2008 10:33 AM, "Oliver Lambert"  
>> >> wrote:
>>>
 Is Can a little less like Option and more like scala.Either,
>> where
 the left side is used to indicate failure? On 21/12/2008, at
 1:43 AM, David Pollak wrote: > Folks, > >
>> Over the
 year that Lift has had Can[T...
>>
>>
>>
>>
>>
>> -- Lift, the simply functional web framework http://liftweb.net
>> Collaborative Task Management http://much4.us Follow me:
>> http://twitter.com/dpp Git some: http://github.com/dpp
>>
>>>
>
>
>
>
>
>
>
>
> -- Lift, the simply functional web framework http://liftweb.net
> Collaborative Task Management http://much4.us Follow me:
> http://twitter.com/dpp Git some: http://github.com/dpp
>
> >




--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visi

[Lift] Re: Can or Box or something else

[David Pollak]

It's an Option.

It contains a value or it doesn't.  In the case that it does not contain a
value, it may contain out of band information.  This is not any different
from None which contains information.  It contains the information that it
lacks information.

Sure, you can write Option[T] as Either[T, Nothing], but the value of only
having on type is lost.

On Tue, Jan 6, 2009 at 2:59 PM, Tony Morris  wrote:

>
> Right, that's what Oliver said and I was reinforcing it with deductive
> reasoning. It is also not Option. It is something else altogether.
> Nevertheless, an isomorphism can easily be written with Either alone
> (ignoring bottoms). So in some loose sense "it is an Either".
>
> --
> Tony Morris
> http://tmorris.net/
>
> S, K and I ought to be enough for anybody.
>
>
> David Pollak wrote:
> > Tony,
> >
> > Can (now Box) is not an Either.
> >
> > David
> >
> > On Tue, Jan 6, 2009 at 2:37 PM, Tony Morris  > > wrote:
> >
> >
> > Can is not an Option and to call it so in any way is an error of
> > misintegration. Indeed it would be an error to "replace Option with
> > Can" - they are completely different algebras. Either is kinded *
> > -> * -> * so cannot possible be isomorphic and cannot possibly have
> > map, flatMap etc (though it can have a bifunctor map being
> > covariant in both type arguments). However, Either.LeftProjection
> > and Either.RightProjection are kinded * -> * and are both covariant
> > functors and monads, hence map, flatMap etc. are available. e.g.
> > for(x <- either.left) ... is valid, try it.
> >
> > Of mild interest, it is possible to construct an isomorphism to Can
> > using both Either and Option. Indeed, it is possible to construct
> > an isomorphism to Option using Either e.g. forall A. Option[A] ≡
> > Either [Unit, A] so it is possible using Either alone. I'll leave
> > both as reader exercises.
> >
> >
> > On Dec 21 2008, 5:15 am, Oliver Lambert  > > wrote:
> >> Ok so Can is not either an Either or an Option, its a Can. I
> > kind of
> >> wondered when I first used Can, and it was described as an
> > enhanced
> >> Option, why it wasn't called something like Option+ with
> > None, Some
> >> and Failure.
> >>
> >> On 21/12/2008, at 5:47 AM, David Pollak wrote:
> >>
> >>> Can has map, flatMap, filter etc. So it can be used in a for
> >>> comphrension. I don't believe Either has those methods.
> > Further,
> >>> Can has a bunch of helpers to turn Empty into Failure
> >>
> >>> On Dec 20, 2008 10:33 AM, "Oliver Lambert"  > > wrote:
> >>
> >>> Is Can a little less like Option and more like scala.Either,
> > where
> >>> the left side is used to indicate failure? On 21/12/2008, at
> >>> 1:43 AM, David Pollak wrote: > Folks, > >
> > Over the
> >>> year that Lift has had Can[T...
> >
> >
> >
> >
> >
> > -- Lift, the simply functional web framework http://liftweb.net
> > Collaborative Task Management http://much4.us Follow me:
> > http://twitter.com/dpp Git some: http://github.com/dpp
> >
> > >
>
>
>
>
> >
>


-- 
Lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Can or Box or something else

[Tony Morris]

Right, that's what Oliver said and I was reinforcing it with deductive
reasoning. It is also not Option. It is something else altogether.
Nevertheless, an isomorphism can easily be written with Either alone
(ignoring bottoms). So in some loose sense "it is an Either".

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

S, K and I ought to be enough for anybody.


David Pollak wrote:
> Tony,
>
> Can (now Box) is not an Either.
>
> David
>
> On Tue, Jan 6, 2009 at 2:37 PM, Tony Morris  > wrote:
>
>
> Can is not an Option and to call it so in any way is an error of
> misintegration. Indeed it would be an error to "replace Option with
> Can" - they are completely different algebras. Either is kinded *
> -> * -> * so cannot possible be isomorphic and cannot possibly have
> map, flatMap etc (though it can have a bifunctor map being
> covariant in both type arguments). However, Either.LeftProjection
> and Either.RightProjection are kinded * -> * and are both covariant
> functors and monads, hence map, flatMap etc. are available. e.g.
> for(x <- either.left) ... is valid, try it.
>
> Of mild interest, it is possible to construct an isomorphism to Can
> using both Either and Option. Indeed, it is possible to construct
> an isomorphism to Option using Either e.g. forall A. Option[A] ≡
> Either [Unit, A] so it is possible using Either alone. I'll leave
> both as reader exercises.
>
>
> On Dec 21 2008, 5:15 am, Oliver Lambert  > wrote:
>> Ok so Can is not either an Either or an Option, its a Can. I
> kind of
>> wondered when I first used Can, and it was described as an
> enhanced
>> Option, why it wasn't called something like Option+ with
> None, Some
>> and Failure.
>>
>> On 21/12/2008, at 5:47 AM, David Pollak wrote:
>>
>>> Can has map, flatMap, filter etc. So it can be used in a for
>>> comphrension. I don't believe Either has those methods.
> Further,
>>> Can has a bunch of helpers to turn Empty into Failure
>>
>>> On Dec 20, 2008 10:33 AM, "Oliver Lambert"  > wrote:
>>
>>> Is Can a little less like Option and more like scala.Either,
> where
>>> the left side is used to indicate failure? On 21/12/2008, at
>>> 1:43 AM, David Pollak wrote: > Folks, > >
> Over the
>>> year that Lift has had Can[T...
>
>
>
>
>
> -- Lift, the simply functional web framework http://liftweb.net
> Collaborative Task Management http://much4.us Follow me:
> http://twitter.com/dpp Git some: http://github.com/dpp
>
> >




--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Can or Box or something else

[David Pollak]

Tony,

Can (now Box) is not an Either.

David

On Tue, Jan 6, 2009 at 2:37 PM, Tony Morris  wrote:

>
> Can is not an Option and to call it so in any way is an error of
> misintegration. Indeed it would be an error to "replace Option with
> Can" - they are completely different algebras. Either is kinded * -> *
> -> * so cannot possible be isomorphic and cannot possibly have map,
> flatMap etc (though it can have a bifunctor map being covariant in
> both type arguments). However, Either.LeftProjection and
> Either.RightProjection are kinded * -> * and are both covariant
> functors and monads, hence map, flatMap etc. are available. e.g. for(x
> <- either.left) ... is valid, try it.
>
> Of mild interest, it is possible to construct an isomorphism to Can
> using both Either and Option. Indeed, it is possible to construct an
> isomorphism to Option using Either e.g. forall A. Option[A] ≡ Either
> [Unit, A] so it is possible using Either alone. I'll leave both as
> reader exercises.
>
>
> On Dec 21 2008, 5:15 am, Oliver Lambert  wrote:
> > Ok so Can is not either an Either or an Option, its a Can. I kind of
> > wondered when I first used Can, and it was described as an enhanced
> > Option,  why it wasn't called something like Option+ with None, Some
> > and Failure.
> >
> > On 21/12/2008, at 5:47 AM, David Pollak wrote:
> >
> > > Can has map, flatMap, filter etc. So it can be used in a for
> > > comphrension.  I don't believe Either has those methods. Further,
> > > Can has a bunch of helpers to turn Empty into Failure
> >
> > > On Dec 20, 2008 10:33 AM, "Oliver Lambert"  wrote:
> >
> > > Is Can a little less like Option and more like scala.Either, where
> > > the left side is used to indicate failure?
> > > On 21/12/2008, at 1:43 AM, David Pollak wrote: > Folks, > > Over the
> > > year that Lift has had Can[T...
>
> >
>


-- 
Lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Can or Box or something else

[Tony Morris]

Can is not an Option and to call it so in any way is an error of
misintegration. Indeed it would be an error to "replace Option with
Can" - they are completely different algebras. Either is kinded * -> *
-> * so cannot possible be isomorphic and cannot possibly have map,
flatMap etc (though it can have a bifunctor map being covariant in
both type arguments). However, Either.LeftProjection and
Either.RightProjection are kinded * -> * and are both covariant
functors and monads, hence map, flatMap etc. are available. e.g. for(x
<- either.left) ... is valid, try it.

Of mild interest, it is possible to construct an isomorphism to Can
using both Either and Option. Indeed, it is possible to construct an
isomorphism to Option using Either e.g. forall A. Option[A] ≡ Either
[Unit, A] so it is possible using Either alone. I'll leave both as
reader exercises.


On Dec 21 2008, 5:15 am, Oliver Lambert  wrote:
> Ok so Can is not either an Either or an Option, its a Can. I kind of  
> wondered when I first used Can, and it was described as an enhanced  
> Option,  why it wasn't called something like Option+ with None, Some  
> and Failure.
>
> On 21/12/2008, at 5:47 AM, David Pollak wrote:
>
> > Can has map, flatMap, filter etc. So it can be used in a for  
> > comphrension.  I don't believe Either has those methods. Further,  
> > Can has a bunch of helpers to turn Empty into Failure
>
> > On Dec 20, 2008 10:33 AM, "Oliver Lambert"  wrote:
>
> > Is Can a little less like Option and more like scala.Either, where  
> > the left side is used to indicate failure?
> > On 21/12/2008, at 1:43 AM, David Pollak wrote: > Folks, > > Over the  
> > year that Lift has had Can[T...

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Can or Box or something else

[Michael Campbell]

Josh Suereth wrote:
> In the spirit of LOLCode, I make the following proposal:

It's ok to love LOLCode, etc just don't *LOVE* LOLCode.

-- 
Twitter:  http://twitter.com/campbellmichael

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Can or Box or something else

[mbh.li...@gmail.com]

I know it's a fait accompli, but I just wanted to give a heads-up to
people who might eventually find themselves answering questions from
newcomers on whether or not Box deals with boxing/autoboxing/unboxing:

http://en.wikipedia.org/wiki/Object_type

I don't believe I saw this point mentioned in the ongoing discussion.

NB: F# has built-in functions "box" and "unbox":

http://tinyurl.com/9wqskd

(bottom of page 112).

---Matt

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Can or Box or something else

[stephen goldbaum]

Ah. Well, sorry I subjected you to that joke twice then (once was more
than enough)...  I'm glad a decision's been made.

-Stephen

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Can or Box or something else

[Jorge Ortiz]

"Promise" has a specific technical meaning in the context of concurrency.
See: http://en.wikipedia.org/wiki/Futures_and_promises

--j

On Sun, Dec 28, 2008 at 2:46 PM, stephen goldbaum <
stephen.goldb...@gmail.com> wrote:

>
> One last suggestion...  Promise with Fulfilled, Empty, and Broken (my
> other suggestion of Blond, Brunette and Redhead didn't seem to make
> it...).
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Can or Box or something else

[David Pollak]

On Sun, Dec 28, 2008 at 12:46 PM, stephen goldbaum <
stephen.goldb...@gmail.com> wrote:

>
> One last suggestion...  Promise with Fulfilled, Empty, and Broken


It's Box and it's done.


> (my
> other suggestion of Blond, Brunette and Redhead didn't seem to make
> it...).


New members are moderated.  This is for two reasons.  A long time back,
there were some inappropriate posts to the list (they were derogatory toward
certain religions) and there is an on-going problem of list spam (mostly
porn, but in some cases ads for computer equipment that's unrelated to Lift
or Scala.)

When I moderated your prior post, I didn't know if it was spam or real.
 Sorry for not posting it.


>
>
> >
>


-- 
Lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Can or Box or something else

[stephen goldbaum]

One last suggestion...  Promise with Fulfilled, Empty, and Broken (my
other suggestion of Blond, Brunette and Redhead didn't seem to make
it...).

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Can or Box or something else

[Josh Suereth]

First:

http://icanhascheezburger.com/2007/01/11/i-can-has-cheezburger-3/

Then:

http://lolcode.com/


Anyway, it's an internet meme that I found amusing.  Every time I'm writing
"Can" in lift, I have to fight the urge to right "has" afterwords.

On Sun, Dec 28, 2008 at 1:26 PM, Tim Perrett  wrote:

>
>
> lol - am I missing something josh? How does the "Box has x" semantic
> differ?
> (if its a joke, my apologies! Its been a long day!!)
>
> On 28/12/2008 15:46, "Josh Suereth"  wrote:
>
> > And all my hopes for "Can has x" are gone...
> >
> > Perhaps I'll make my own change in my lift app. :
> >
> > import {Box => Bukkit}
>
>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Can or Box or something else

[Tim Perrett]

lol - am I missing something josh? How does the "Box has x" semantic differ?
(if its a joke, my apologies! Its been a long day!!)

On 28/12/2008 15:46, "Josh Suereth"  wrote:

> And all my hopes for "Can has x" are gone...
> 
> Perhaps I'll make my own change in my lift app. :
> 
> import {Box => Bukkit}



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Can or Box or something else

[Josh Suereth]

And all my hopes for "Can has x" are gone...

Perhaps I'll make my own change in my lift app. :

import {Box => Bukkit}

On Sun, Dec 28, 2008 at 10:03 AM, David Pollak <
feeder.of.the.be...@gmail.com> wrote:

> Good points.  I'll make the changes today and check up the code.  It'll be
> massive code breakage... but for a good reason.
>
>
> On Sun, Dec 28, 2008 at 6:41 AM, Tim Perrett  wrote:
>
>>
>> I think this debate could go on for some time ;-)
>>
>> Being pragmatic, we have to look at the impact on the lift code base
>> and its users. Would a change to Box[MyClass] really improve user
>> understanding and lower the learning curve to a point where making
>> such a fundamental change in the lift API would be justified?
>>
>> This is really the question we should now be asking now.
>>
>> 
>>
>> Being english, the semantic of Box seems more logical, however, right
>> now im sitting on the fence on weather or not the change is justified.
>> Lets look at the dictionary:
>>
>> == Can
>>
>> 1 be able to
>> 2 be permitted to
>> 3 used to indicate that something is typically the case
>>
>> == Box
>>
>> noun
>> 1 a container with a flat base and sides, typically square or
>> rectangular and having a lid : a cereal box | a hat box.
>> 3 a small structure or building for a specific purpose, in particular
>> • a separate section or enclosed area within a larger building, esp.
>> one reserved for a group of people in a theater or sports ground or
>> for witnesses or the jury in a law court : a box at the opera | the
>> jury was now in the box.
>> 4 a protective casing for a piece of a mechanism.
>>
>> The fact that Box only really has a single meaning, is very attractive
>> from a cognitive point of view IMO
>>
>> 
>>
>> Realistically, what would the damage be API wise if we moved to box?
>> Have we any way of understanding the impact in real terms?
>>
>> Cheers, Tim
>>
>>
>>
>>
>>
>>
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Collaborative Task Management http://much4.us
> Follow me: http://twitter.com/dpp
> Git some: http://github.com/dpp
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Can or Box or something else

[Viktor Klang]

Wonderful :)

On Sun, Dec 28, 2008 at 4:03 PM, David Pollak  wrote:

> Good points.  I'll make the changes today and check up the code.  It'll be
> massive code breakage... but for a good reason.
>
>
> On Sun, Dec 28, 2008 at 6:41 AM, Tim Perrett  wrote:
>
>>
>> I think this debate could go on for some time ;-)
>>
>> Being pragmatic, we have to look at the impact on the lift code base
>> and its users. Would a change to Box[MyClass] really improve user
>> understanding and lower the learning curve to a point where making
>> such a fundamental change in the lift API would be justified?
>>
>> This is really the question we should now be asking now.
>>
>> 
>>
>> Being english, the semantic of Box seems more logical, however, right
>> now im sitting on the fence on weather or not the change is justified.
>> Lets look at the dictionary:
>>
>> == Can
>>
>> 1 be able to
>> 2 be permitted to
>> 3 used to indicate that something is typically the case
>>
>> == Box
>>
>> noun
>> 1 a container with a flat base and sides, typically square or
>> rectangular and having a lid : a cereal box | a hat box.
>> 3 a small structure or building for a specific purpose, in particular
>> • a separate section or enclosed area within a larger building, esp.
>> one reserved for a group of people in a theater or sports ground or
>> for witnesses or the jury in a law court : a box at the opera | the
>> jury was now in the box.
>> 4 a protective casing for a piece of a mechanism.
>>
>> The fact that Box only really has a single meaning, is very attractive
>> from a cognitive point of view IMO
>>
>> 
>>
>> Realistically, what would the damage be API wise if we moved to box?
>> Have we any way of understanding the impact in real terms?
>>
>> Cheers, Tim
>>
>>
>>
>>
>>
>>
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Collaborative Task Management http://much4.us
> Follow me: http://twitter.com/dpp
> Git some: http://github.com/dpp
>
> >
>


-- 
Viktor Klang
Senior Systems Analyst

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Can or Box or something else

[David Pollak]

Good points.  I'll make the changes today and check up the code.  It'll be
massive code breakage... but for a good reason.


On Sun, Dec 28, 2008 at 6:41 AM, Tim Perrett  wrote:

>
> I think this debate could go on for some time ;-)
>
> Being pragmatic, we have to look at the impact on the lift code base
> and its users. Would a change to Box[MyClass] really improve user
> understanding and lower the learning curve to a point where making
> such a fundamental change in the lift API would be justified?
>
> This is really the question we should now be asking now.
>
> 
>
> Being english, the semantic of Box seems more logical, however, right
> now im sitting on the fence on weather or not the change is justified.
> Lets look at the dictionary:
>
> == Can
>
> 1 be able to
> 2 be permitted to
> 3 used to indicate that something is typically the case
>
> == Box
>
> noun
> 1 a container with a flat base and sides, typically square or
> rectangular and having a lid : a cereal box | a hat box.
> 3 a small structure or building for a specific purpose, in particular
> • a separate section or enclosed area within a larger building, esp.
> one reserved for a group of people in a theater or sports ground or
> for witnesses or the jury in a law court : a box at the opera | the
> jury was now in the box.
> 4 a protective casing for a piece of a mechanism.
>
> The fact that Box only really has a single meaning, is very attractive
> from a cognitive point of view IMO
>
> 
>
> Realistically, what would the damage be API wise if we moved to box?
> Have we any way of understanding the impact in real terms?
>
> Cheers, Tim
>
>
>
>
> >
>


-- 
Lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Can or Box or something else

[Tim Perrett]

I think this debate could go on for some time ;-)

Being pragmatic, we have to look at the impact on the lift code base
and its users. Would a change to Box[MyClass] really improve user
understanding and lower the learning curve to a point where making
such a fundamental change in the lift API would be justified?

This is really the question we should now be asking now.



Being english, the semantic of Box seems more logical, however, right
now im sitting on the fence on weather or not the change is justified.
Lets look at the dictionary:

== Can

1 be able to
2 be permitted to
3 used to indicate that something is typically the case

== Box

noun
1 a container with a flat base and sides, typically square or
rectangular and having a lid : a cereal box | a hat box.
3 a small structure or building for a specific purpose, in particular
• a separate section or enclosed area within a larger building, esp.
one reserved for a group of people in a theater or sports ground or
for witnesses or the jury in a law court : a box at the opera | the
jury was now in the box.
4 a protective casing for a piece of a mechanism.

The fact that Box only really has a single meaning, is very attractive
from a cognitive point of view IMO



Realistically, what would the damage be API wise if we moved to box?
Have we any way of understanding the impact in real terms?

Cheers, Tim




--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Can or Box or something else

[Kris Nuttycombe]

If we all get a say, I vote for "Trit" - after all, with Full, Empty and
Failure, aren't we talking about ternary logic?

Or does suggesting that make me a Twit?

Kris

On Sat, Dec 27, 2008 at 5:08 PM, Oliver Lambert  wrote:

> Ha :), I really think you've let the Can out of the Box by raising this
> thread. Don't we all get a vote? After reading all the threads -
> +1 Box
>
>
> On 27/12/2008, at 10:06 AM, David Pollak wrote:
>
>
>
> 2008/12/26 Alex Boisvert 
>
>> Just brainstorming here...  not sure if we're beating a dead horse... but
>> about Option3 to signify it has 3 states?  (i.e. Some3, None3, Error3)
>>
>> It's uglier but could be easier to explain and understand.
>
>
> Personally, it took me a lot to get the concept of Option... mainly because
> to me, an Option is this or that, not some or none.  Optional would have
> been a better choice as is Maybe.  In fact, it wasn't until I was playing
> around with Haskell and the Maybe monad, that I finally "got" Options.  I
> would despise the idea of perpetuating what I consider to be one of Scala's
> weakest naming schemes.
>
> It's going to stay "Can", but if I had it to do all over, I'd call it Box.
>
> Thanks for all your respective thoughts on the subject.
>
> David
>
> PS -- The code is pretty much frozen for Lift.  There'll be a few last
> minute minor changes between now and Jan 2 (or whenever 2.7.3 goes final) at
> which time we'll release Lift 0.10 and start on the Lift 1.0-SNAPSHOT
> version.  We're expecting to ship Lift 1.0 on the 2 year anniversary of the
> project.
>
>
>>
>>
>> alex
>>
>>
>> On Fri, Dec 26, 2008 at 3:29 AM, Mateusz Fiołka > > wrote:
>>
>>> If Maybe should be not used because of possible name clash in Scala
>>> library then how about considering synonyms: Possible and Perhaps?
>>>
>>>
>>> On Fri, Dec 26, 2008 at 10:31 AM, Caoyuan  wrote:
>>>

 and "Pack" ?

 On Fri, Dec 26, 2008 at 8:35 AM, Marc Boschma 
 >
 wrote:
 >
 > I know David has resigned to keeping 'Can', but wouldn't 'Jar' be an
 > alternative? That way Empty and Full still make sense...
 >
 > Initially I thought 'Tin' sounded better but I recognise that term
 > wouldn't be as universal.
 >
 > Marc
 >
 > On 26/12/2008, at 4:14 AM, Michael Campbell wrote:
 >
 >>
 >> David Pollak wrote:
 >>> Folks,
 >>>
 >>> Over the year that Lift has had Can[T] as a replacement for Scala's
 >>> Option[T], the name "Can" has required a lot of explaining.
 >>
 >>
 >> I've never liked "Can" as a name; always thinking that the opposite
 >> of one
 >> should be a "Can't".   I'm sure it's my own issue to solve, but it's
 >> cognitively dissonant to me.
 >>
 >> Any other container name works better for me, although of the ones
 >> you listed,
 >> I like "Box".
 >>
 >>
 >> --
 >> Twitter:  http://twitter.com/campbellmichael
 >>
 >> >
 >
 >
 > >
 >



>>>
>>>
>>>
>>
>>
>>
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Collaborative Task Management http://much4.us
> Follow me: http://twitter.com/dpp
> Git some: http://github.com/dpp
>
>
>
>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Can or Box or something else

[Oliver Lambert]

Ha :), I really think you've let the Can out of the Box by raising  
this thread. Don't we all get a vote?
After reading all the threads -
+1 Box

On 27/12/2008, at 10:06 AM, David Pollak wrote:

>
>
> 2008/12/26 Alex Boisvert 
> Just brainstorming here...  not sure if we're beating a dead  
> horse... but about Option3 to signify it has 3 states?  (i.e. Some3,  
> None3, Error3)
>
> It's uglier but could be easier to explain and understand.
>
> Personally, it took me a lot to get the concept of Option... mainly  
> because to me, an Option is this or that, not some or none.   
> Optional would have been a better choice as is Maybe.  In fact, it  
> wasn't until I was playing around with Haskell and the Maybe monad,  
> that I finally "got" Options.  I would despise the idea of  
> perpetuating what I consider to be one of Scala's weakest naming  
> schemes.
>
> It's going to stay "Can", but if I had it to do all over, I'd call  
> it Box.
>
> Thanks for all your respective thoughts on the subject.
>
> David
>
> PS -- The code is pretty much frozen for Lift.  There'll be a few  
> last minute minor changes between now and Jan 2 (or whenever 2.7.3  
> goes final) at which time we'll release Lift 0.10 and start on the  
> Lift 1.0-SNAPSHOT version.  We're expecting to ship Lift 1.0 on the  
> 2 year anniversary of the project.
>
>
>
> alex
>
>
> On Fri, Dec 26, 2008 at 3:29 AM, Mateusz Fiołka  m> wrote:
> If Maybe should be not used because of possible name clash in Scala  
> library then how about considering synonyms: Possible and Perhaps?
>
>
> On Fri, Dec 26, 2008 at 10:31 AM, Caoyuan  wrote:
>
> and "Pack" ?
>
> On Fri, Dec 26, 2008 at 8:35 AM, Marc Boschma  +lift...@boschma.cx> wrote:
> >
> > I know David has resigned to keeping 'Can', but wouldn't 'Jar' be an
> > alternative? That way Empty and Full still make sense...
> >
> > Initially I thought 'Tin' sounded better but I recognise that term
> > wouldn't be as universal.
> >
> > Marc
> >
> > On 26/12/2008, at 4:14 AM, Michael Campbell wrote:
> >
> >>
> >> David Pollak wrote:
> >>> Folks,
> >>>
> >>> Over the year that Lift has had Can[T] as a replacement for  
> Scala's
> >>> Option[T], the name "Can" has required a lot of explaining.
> >>
> >>
> >> I've never liked "Can" as a name; always thinking that the opposite
> >> of one
> >> should be a "Can't".   I'm sure it's my own issue to solve, but  
> it's
> >> cognitively dissonant to me.
> >>
> >> Any other container name works better for me, although of the ones
> >> you listed,
> >> I like "Box".
> >>
> >>
> >> --
> >> Twitter:  http://twitter.com/campbellmichael
> >>
> >> >
> >
> >
> > >
> >
>
>
>
>
>
>
>
>
>
>
>
> -- 
> Lift, the simply functional web framework http://liftweb.net
> Collaborative Task Management http://much4.us
> Follow me: http://twitter.com/dpp
> Git some: http://github.com/dpp
>
> >


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Can or Box or something else

[Charles F. Munat]

Summer solstice? SUMMER solstice? You hemisphere bigot! There you go 
again, insulting half the planet...

(Back to the lawyers again... :-)

Chas.

Marc Boschma wrote:
> Funny thing is the first thought that came to mind here was a Cricket  
> Box :) (and not the KFC variety)
> 
> To close the season and thread with some humour:
> 
> I wanted to send some sort of Christmas (whoops I mean) holiday  
> greeting to my friends, but it is so difficult in today's world to  
> know exactly what to say without offending someone. So I met with my  
> lawyer yesterday, and on his advice I wish to say the following to  
> you, my dear friends throughout the world:
> 
> Please accept with no obligation, implied or implicit, my best wishes  
> for an environmentally conscious, socially responsible, low stress,  
> non-addictive, gender neutral celebration of the Summer solstice  
> holiday, practised with the most enjoyable traditions of religious  
> persuasion or secular practices of your choice with respect for the  
> religious/secular persuasions and/or traditions of others, or their  
> choice not to practice religious or secular traditions at all.
> 
> I also wish you a fiscally successful, personally fulfilling and  
> medically uncomplicated recognition of the onset of the generally  
> accepted calendar year 2009, but not without due respect for the  
> calendars of choice of other cultures whose contributions to society  
> have helped make our country great (not to imply that Australia is  
> necessarily greater than any other country) and without regard to the  
> race, creed, colour, age, physical ability, religious faith or sexual  
> preference of the wishees.
> 
> By accepting this greeting, you are accepting these terms:
> 
> This greeting is subject to clarification or withdrawal. It is freely  
> transferable with no alteration to the original greeting. It implies  
> no promise by the wisher to actually implement any of the wishes for  
> her/himself or others and is void where prohibited by law, and is  
> revocable at the sole discretion of the wisher.
> 
> This wish is warranted to perform as expected within the usual  
> application of good tidings for a period of one year or until the  
> issuance of a subsequent holiday greeting, whichever comes first, and  
> warranty is limited to replacement of this wish or issuance of a new  
> wish at the sole discretion of the wisher.
> 
> Disclaimer: No trees were harmed in the sending of this message;  
> however, a significant number of electrons were slightly inconvenienced.
> 
> On 27/12/2008, at 2:25 AM, Viktor Klang wrote:
> 
>> "Bin"
>> "Slot"
>> "Ref"
>>
>> Though, "Box" is short, self-explanatory and fills the other  
>> criterias aswell.
>>
>> Merry Christmas
>> /Viktor
>>
> 
> > 

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Can or Box or something else

[David Pollak]

2008/12/26 Alex Boisvert 

> Just brainstorming here...  not sure if we're beating a dead horse... but
> about Option3 to signify it has 3 states?  (i.e. Some3, None3, Error3)
>
> It's uglier but could be easier to explain and understand.


Personally, it took me a lot to get the concept of Option... mainly because
to me, an Option is this or that, not some or none.  Optional would have
been a better choice as is Maybe.  In fact, it wasn't until I was playing
around with Haskell and the Maybe monad, that I finally "got" Options.  I
would despise the idea of perpetuating what I consider to be one of Scala's
weakest naming schemes.

It's going to stay "Can", but if I had it to do all over, I'd call it Box.

Thanks for all your respective thoughts on the subject.

David

PS -- The code is pretty much frozen for Lift.  There'll be a few last
minute minor changes between now and Jan 2 (or whenever 2.7.3 goes final) at
which time we'll release Lift 0.10 and start on the Lift 1.0-SNAPSHOT
version.  We're expecting to ship Lift 1.0 on the 2 year anniversary of the
project.


>
>
> alex
>
>
> On Fri, Dec 26, 2008 at 3:29 AM, Mateusz Fiołka 
> wrote:
>
>> If Maybe should be not used because of possible name clash in Scala
>> library then how about considering synonyms: Possible and Perhaps?
>>
>>
>> On Fri, Dec 26, 2008 at 10:31 AM, Caoyuan  wrote:
>>
>>>
>>> and "Pack" ?
>>>
>>> On Fri, Dec 26, 2008 at 8:35 AM, Marc Boschma 
>>> >
>>> wrote:
>>> >
>>> > I know David has resigned to keeping 'Can', but wouldn't 'Jar' be an
>>> > alternative? That way Empty and Full still make sense...
>>> >
>>> > Initially I thought 'Tin' sounded better but I recognise that term
>>> > wouldn't be as universal.
>>> >
>>> > Marc
>>> >
>>> > On 26/12/2008, at 4:14 AM, Michael Campbell wrote:
>>> >
>>> >>
>>> >> David Pollak wrote:
>>> >>> Folks,
>>> >>>
>>> >>> Over the year that Lift has had Can[T] as a replacement for Scala's
>>> >>> Option[T], the name "Can" has required a lot of explaining.
>>> >>
>>> >>
>>> >> I've never liked "Can" as a name; always thinking that the opposite
>>> >> of one
>>> >> should be a "Can't".   I'm sure it's my own issue to solve, but it's
>>> >> cognitively dissonant to me.
>>> >>
>>> >> Any other container name works better for me, although of the ones
>>> >> you listed,
>>> >> I like "Box".
>>> >>
>>> >>
>>> >> --
>>> >> Twitter:  http://twitter.com/campbellmichael
>>> >>
>>> >> >
>>> >
>>> >
>>> > >
>>> >
>>>
>>>
>>>
>>
>>
>>
>
> >
>


-- 
Lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Can or Box or something else

[Marc Boschma]

Funny thing is the first thought that came to mind here was a Cricket  
Box :) (and not the KFC variety)

To close the season and thread with some humour:

I wanted to send some sort of Christmas (whoops I mean) holiday  
greeting to my friends, but it is so difficult in today's world to  
know exactly what to say without offending someone. So I met with my  
lawyer yesterday, and on his advice I wish to say the following to  
you, my dear friends throughout the world:

Please accept with no obligation, implied or implicit, my best wishes  
for an environmentally conscious, socially responsible, low stress,  
non-addictive, gender neutral celebration of the Summer solstice  
holiday, practised with the most enjoyable traditions of religious  
persuasion or secular practices of your choice with respect for the  
religious/secular persuasions and/or traditions of others, or their  
choice not to practice religious or secular traditions at all.

I also wish you a fiscally successful, personally fulfilling and  
medically uncomplicated recognition of the onset of the generally  
accepted calendar year 2009, but not without due respect for the  
calendars of choice of other cultures whose contributions to society  
have helped make our country great (not to imply that Australia is  
necessarily greater than any other country) and without regard to the  
race, creed, colour, age, physical ability, religious faith or sexual  
preference of the wishees.

By accepting this greeting, you are accepting these terms:

This greeting is subject to clarification or withdrawal. It is freely  
transferable with no alteration to the original greeting. It implies  
no promise by the wisher to actually implement any of the wishes for  
her/himself or others and is void where prohibited by law, and is  
revocable at the sole discretion of the wisher.

This wish is warranted to perform as expected within the usual  
application of good tidings for a period of one year or until the  
issuance of a subsequent holiday greeting, whichever comes first, and  
warranty is limited to replacement of this wish or issuance of a new  
wish at the sole discretion of the wisher.

Disclaimer: No trees were harmed in the sending of this message;  
however, a significant number of electrons were slightly inconvenienced.

On 27/12/2008, at 2:25 AM, Viktor Klang wrote:

> "Bin"
> "Slot"
> "Ref"
>
> Though, "Box" is short, self-explanatory and fills the other  
> criterias aswell.
>
> Merry Christmas
> /Viktor
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Can or Box or something else

[Alex Boisvert]

Just brainstorming here...  not sure if we're beating a dead horse... but
about Option3 to signify it has 3 states?  (i.e. Some3, None3, Error3)

It's uglier but could be easier to explain and understand.

alex

On Fri, Dec 26, 2008 at 3:29 AM, Mateusz Fiołka wrote:

> If Maybe should be not used because of possible name clash in Scala library
> then how about considering synonyms: Possible and Perhaps?
>
>
> On Fri, Dec 26, 2008 at 10:31 AM, Caoyuan  wrote:
>
>>
>> and "Pack" ?
>>
>> On Fri, Dec 26, 2008 at 8:35 AM, Marc Boschma 
>> >
>> wrote:
>> >
>> > I know David has resigned to keeping 'Can', but wouldn't 'Jar' be an
>> > alternative? That way Empty and Full still make sense...
>> >
>> > Initially I thought 'Tin' sounded better but I recognise that term
>> > wouldn't be as universal.
>> >
>> > Marc
>> >
>> > On 26/12/2008, at 4:14 AM, Michael Campbell wrote:
>> >
>> >>
>> >> David Pollak wrote:
>> >>> Folks,
>> >>>
>> >>> Over the year that Lift has had Can[T] as a replacement for Scala's
>> >>> Option[T], the name "Can" has required a lot of explaining.
>> >>
>> >>
>> >> I've never liked "Can" as a name; always thinking that the opposite
>> >> of one
>> >> should be a "Can't".   I'm sure it's my own issue to solve, but it's
>> >> cognitively dissonant to me.
>> >>
>> >> Any other container name works better for me, although of the ones
>> >> you listed,
>> >> I like "Box".
>> >>
>> >>
>> >> --
>> >> Twitter:  http://twitter.com/campbellmichael
>> >>
>> >> >
>> >
>> >
>> > >
>> >
>>
>>
>>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Can or Box or something else

[Mateusz Fiołka]

If Maybe should be not used because of possible name clash in Scala library
then how about considering synonyms: Possible and Perhaps?


On Fri, Dec 26, 2008 at 10:31 AM, Caoyuan  wrote:

>
> and "Pack" ?
>
> On Fri, Dec 26, 2008 at 8:35 AM, Marc Boschma 
> >
> wrote:
> >
> > I know David has resigned to keeping 'Can', but wouldn't 'Jar' be an
> > alternative? That way Empty and Full still make sense...
> >
> > Initially I thought 'Tin' sounded better but I recognise that term
> > wouldn't be as universal.
> >
> > Marc
> >
> > On 26/12/2008, at 4:14 AM, Michael Campbell wrote:
> >
> >>
> >> David Pollak wrote:
> >>> Folks,
> >>>
> >>> Over the year that Lift has had Can[T] as a replacement for Scala's
> >>> Option[T], the name "Can" has required a lot of explaining.
> >>
> >>
> >> I've never liked "Can" as a name; always thinking that the opposite
> >> of one
> >> should be a "Can't".   I'm sure it's my own issue to solve, but it's
> >> cognitively dissonant to me.
> >>
> >> Any other container name works better for me, although of the ones
> >> you listed,
> >> I like "Box".
> >>
> >>
> >> --
> >> Twitter:  http://twitter.com/campbellmichael
> >>
> >> >
> >
> >
> > >
> >
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Can or Box or something else

[Viktor Klang]

"Bin"
"Slot"
"Ref"

Though, "Box" is short, self-explanatory and fills the other criterias
aswell.

Merry Christmas
/Viktor
On Fri, Dec 26, 2008 at 10:31 AM, Caoyuan  wrote:

>
> and "Pack" ?
>
> On Fri, Dec 26, 2008 at 8:35 AM, Marc Boschma 
> >
> wrote:
> >
> > I know David has resigned to keeping 'Can', but wouldn't 'Jar' be an
> > alternative? That way Empty and Full still make sense...
> >
> > Initially I thought 'Tin' sounded better but I recognise that term
> > wouldn't be as universal.
> >
> > Marc
> >
> > On 26/12/2008, at 4:14 AM, Michael Campbell wrote:
> >
> >>
> >> David Pollak wrote:
> >>> Folks,
> >>>
> >>> Over the year that Lift has had Can[T] as a replacement for Scala's
> >>> Option[T], the name "Can" has required a lot of explaining.
> >>
> >>
> >> I've never liked "Can" as a name; always thinking that the opposite
> >> of one
> >> should be a "Can't".   I'm sure it's my own issue to solve, but it's
> >> cognitively dissonant to me.
> >>
> >> Any other container name works better for me, although of the ones
> >> you listed,
> >> I like "Box".
> >>
> >>
> >> --
> >> Twitter:  http://twitter.com/campbellmichael
> >>
> >> >
> >
> >
> > >
> >
>
> >
>


-- 
Viktor Klang
Senior Systems Analyst

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Can or Box or something else

[Caoyuan]

and "Pack" ?

On Fri, Dec 26, 2008 at 8:35 AM, Marc Boschma  wrote:
>
> I know David has resigned to keeping 'Can', but wouldn't 'Jar' be an
> alternative? That way Empty and Full still make sense...
>
> Initially I thought 'Tin' sounded better but I recognise that term
> wouldn't be as universal.
>
> Marc
>
> On 26/12/2008, at 4:14 AM, Michael Campbell wrote:
>
>>
>> David Pollak wrote:
>>> Folks,
>>>
>>> Over the year that Lift has had Can[T] as a replacement for Scala's
>>> Option[T], the name "Can" has required a lot of explaining.
>>
>>
>> I've never liked "Can" as a name; always thinking that the opposite
>> of one
>> should be a "Can't".   I'm sure it's my own issue to solve, but it's
>> cognitively dissonant to me.
>>
>> Any other container name works better for me, although of the ones
>> you listed,
>> I like "Box".
>>
>>
>> --
>> Twitter:  http://twitter.com/campbellmichael
>>
>> >
>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Can or Box or something else

[Marc Boschma]

I know David has resigned to keeping 'Can', but wouldn't 'Jar' be an  
alternative? That way Empty and Full still make sense...

Initially I thought 'Tin' sounded better but I recognise that term  
wouldn't be as universal.

Marc

On 26/12/2008, at 4:14 AM, Michael Campbell wrote:

>
> David Pollak wrote:
>> Folks,
>>
>> Over the year that Lift has had Can[T] as a replacement for Scala's
>> Option[T], the name "Can" has required a lot of explaining.
>
>
> I've never liked "Can" as a name; always thinking that the opposite  
> of one
> should be a "Can't".   I'm sure it's my own issue to solve, but it's
> cognitively dissonant to me.
>
> Any other container name works better for me, although of the ones  
> you listed,
> I like "Box".
>
>
> -- 
> Twitter:  http://twitter.com/campbellmichael
>
> >


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Can or Box or something else

[Michael Campbell]

David Pollak wrote:
> Folks,
> 
> Over the year that Lift has had Can[T] as a replacement for Scala's 
> Option[T], the name "Can" has required a lot of explaining.


I've never liked "Can" as a name; always thinking that the opposite of one 
should be a "Can't".   I'm sure it's my own issue to solve, but it's 
cognitively dissonant to me.

Any other container name works better for me, although of the ones you listed, 
I like "Box".


-- 
Twitter:  http://twitter.com/campbellmichael

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Can or Box or something else

[saemgh...@gmail.com]

Can isn't bad. On the one hand, it's a container, on the other hand
it's "can I do something", and in fact both work, barring the name of
Full and Empty.

It still feels weird. In my opinion it's trying to concretize
something abstract. Honestly, the best name for it might be something
like 'Maybe', it's not all that concrete, even in language. Full,
Empty, might be 'Yes', and 'No' respectively?

On Dec 22, 1:38 pm, Alex Cruise  wrote:
> Josh Suereth wrote:
> > In the spirit of LOLCode, I make the following proposal:
>
> > Can becomes Bukkit
>
> Just think though, a bit of pimping and...
>
> object Can {
>   ...
>   def has[T](t: T) = Full(t)
>
> }
>
> val gotz = Can has "cheezburger"
>
> ... which constitutes my vote for "keep Can" -- it's a comedic noun and
> also a semantically relevant verb. :)
>
> -0xe1a
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Can or Box or something else

[Alex Cruise]

Josh Suereth wrote:
> In the spirit of LOLCode, I make the following proposal:
>
> Can becomes Bukkit
Just think though, a bit of pimping and...

object Can {
  ...
  def has[T](t: T) = Full(t)
}

val gotz = Can has "cheezburger"

... which constitutes my vote for "keep Can" -- it's a comedic noun and 
also a semantically relevant verb. :)

-0xe1a

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Can or Box or something else

[Josh Suereth]

In the spirit of LOLCode, I make the following proposal:

Can becomes Bukkit
Full becomes BukkitOf  (or "Bukkit of" via some DSL like syntax)
Empty becomes Noob   (or "Bukkit of Noob" via some DSL like syntax)
Failure becomes WTF?

val x : Bukkit[String] = WTF?(new RuntimeException("O NOES!"))
val y : Bukkit[String] = Noob
val z = BukkitOf("Cheezburger")

Trust me, every time you need to use a bukkit, you'll ROFL (without the ROF)
to yourself.


On Sun, Dec 21, 2008 at 4:20 PM, Tim Perrett  wrote:

>
> IMO, and echo'ing jorge's comments, I *really* dont think using ? is a
> good idea.
>
> The rational of this being:
>  - Code that's littered with Can[MyType] is readable, compared with ?
> [MyType] which would be confusing and non-obvious for new-commers.
>  - Using operands for such common operations / idioms I would be
> strongly against, as its not the usual case.
>
> Im down with Box[MyType] however... either way, if we move to Box, or
> stick with Can, more documentation / examples is a must.
>
> Cheers, Tim
>
>
> On Dec 21, 8:07 pm, "Charles F. Munat"  wrote:
> > I, too, like ?, but I agree that others may not. Could mean too many
> > things. But what about ??? instead? Or just two (??)? Or why not steal
> > Haskell's thunder and use Maybe?
> >
> > Chas.
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Can or Box or something else

[Tim Perrett]

IMO, and echo'ing jorge's comments, I *really* dont think using ? is a
good idea.

The rational of this being:
 - Code that's littered with Can[MyType] is readable, compared with ?
[MyType] which would be confusing and non-obvious for new-commers.
 - Using operands for such common operations / idioms I would be
strongly against, as its not the usual case.

Im down with Box[MyType] however... either way, if we move to Box, or
stick with Can, more documentation / examples is a must.

Cheers, Tim


On Dec 21, 8:07 pm, "Charles F. Munat"  wrote:
> I, too, like ?, but I agree that others may not. Could mean too many
> things. But what about ??? instead? Or just two (??)? Or why not steal
> Haskell's thunder and use Maybe?
>
> Chas.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Can or Box or something else

[Charles F. Munat]

I, too, like ?, but I agree that others may not. Could mean too many 
things. But what about ??? instead? Or just two (??)? Or why not steal 
Haskell's thunder and use Maybe?

Chas.

Marius wrote:
> Personally I kind of like ? name ... although I feel many people will
> not. Going further having Full and Empty extending ? may "lift"quite a
> few eyebrows :)
> 
> BTW I totally agree that Result is not ok.
> 
> Br's,
> Marius
> 
> On Dec 21, 7:45 pm, "David Bernard" 
> wrote:
>> current signature :
>>   def doStuff(arg1 : Can[Foo], arg2 : Toto) : Can[Bar]
>>
>> With Result:
>>   def doStuff(arg1 : Result[Foo], arg2 : Toto) : Result[Bar]
>> Result could be good but is not, when used for argument and not for "result"
>>
>> more I think about it, more I thought ? was not so wrong/joke. In the
>> Nice language (a old competitor to scala) ? was used to mark value to
>> be potentially null
>>
>> var myVar1 : ?String //myVar1 could be null
>> var myVar2 : String //myVar2 is never null
>>
>> With ?:
>>   def doStuff(arg1 : ?[Foo], arg2 : Toto) : ?[Bar]
>>
>> On Sun, Dec 21, 2008 at 17:42, Mateusz Fiołka  
>> wrote:
>>> Result +1
>>> Quite short, only one selfexplaining imo and describes the purpose it serves
>>> well. The only downsides of this name is +3 characters and the fact that the
>>> class could be used also as non result but for other purpose.
>>> On Sun, Dec 21, 2008 at 3:32 PM, Derek Chen-Becker 
>>> wrote:
 I think that the previously mentioned "Box" would be the only other thing
 that has
 The same semantic meaning of "container". Well, as Tim pointed out this is
 a US thing for Can...
 The same brevity. I agree with David that commonly used constructs should
 be short
 If it was going to change at all, this would be it.
 Derek
 On Sat, Dec 20, 2008 at 11:13 PM, Josh Suereth 
 wrote:
> On Sat, Dec 20, 2008 at 2:37 PM, Oliver Lambert  wrote:
>> Yup, when you chose the original name, you did a good job - why second
>> guess yourself now. Can we just leave it the way it is.
> Pun intended
> As to my vote (if I'm allowed one)...
> Can was slightly confusing, but looking at it vs Option makes a lot of
> sense.  Option is also slightly confusing, because I expected it to behave
> like Either.   Either is a great name, as you can tell what it's doing.
> Result seems ok, but I would vote for something more like Storage.   Can
> is pretty succinct, and once you know how to use it, it's not hard to
> remember the convention.
> So I'd swing on the side of sticking with Can unless a really good name
> is discovered.
> > 

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Can or Box or something else

[Jorge Ortiz]

If you want to use ? in your own code, you can always do:

  type ?[T] = Can[T]

  var s: ?[String] = Empty
  s = Full("Hello, world!")

You can put it somewhere and import it anywhere you want to use it.

That said, I think it'd be a really bad idea to do this in Lift's source.
Scala gets enough crap about operators already, we shouldn't be adding any
more, especially not one for something so widely used as Can.

--j

2008/12/21 Marius 

>
> Personally I kind of like ? name ... although I feel many people will
> not. Going further having Full and Empty extending ? may "lift"quite a
> few eyebrows :)
>
> BTW I totally agree that Result is not ok.
>
> Br's,
> Marius
>
> On Dec 21, 7:45 pm, "David Bernard" 
> wrote:
> > current signature :
> >   def doStuff(arg1 : Can[Foo], arg2 : Toto) : Can[Bar]
> >
> > With Result:
> >   def doStuff(arg1 : Result[Foo], arg2 : Toto) : Result[Bar]
> > Result could be good but is not, when used for argument and not for
> "result"
> >
> > more I think about it, more I thought ? was not so wrong/joke. In the
> > Nice language (a old competitor to scala) ? was used to mark value to
> > be potentially null
> >
> > var myVar1 : ?String //myVar1 could be null
> > var myVar2 : String //myVar2 is never null
> >
> > With ?:
> >   def doStuff(arg1 : ?[Foo], arg2 : Toto) : ?[Bar]
> >
> > On Sun, Dec 21, 2008 at 17:42, Mateusz Fiołka 
> wrote:
> > > Result +1
> >
> > > Quite short, only one selfexplaining imo and describes the purpose it
> serves
> > > well. The only downsides of this name is +3 characters and the fact
> that the
> > > class could be used also as non result but for other purpose.
> >
> > > On Sun, Dec 21, 2008 at 3:32 PM, Derek Chen-Becker <
> dchenbec...@gmail.com>
> > > wrote:
> >
> > >> I think that the previously mentioned "Box" would be the only other
> thing
> > >> that has
> >
> > >> The same semantic meaning of "container". Well, as Tim pointed out
> this is
> > >> a US thing for Can...
> > >> The same brevity. I agree with David that commonly used constructs
> should
> > >> be short
> >
> > >> If it was going to change at all, this would be it.
> >
> > >> Derek
> >
> > >> On Sat, Dec 20, 2008 at 11:13 PM, Josh Suereth <
> joshua.suer...@gmail.com>
> > >> wrote:
> >
> > >>> On Sat, Dec 20, 2008 at 2:37 PM, Oliver Lambert 
> wrote:
> >
> >  Yup, when you chose the original name, you did a good job - why
> second
> >  guess yourself now. Can we just leave it the way it is.
> >
> > >>> Pun intended
> >
> > >>> As to my vote (if I'm allowed one)...
> >
> > >>> Can was slightly confusing, but looking at it vs Option makes a lot
> of
> > >>> sense.  Option is also slightly confusing, because I expected it to
> behave
> > >>> like Either.   Either is a great name, as you can tell what it's
> doing.
> >
> > >>> Result seems ok, but I would vote for something more like Storage.
> Can
> > >>> is pretty succinct, and once you know how to use it, it's not hard to
> > >>> remember the convention.
> >
> > >>> So I'd swing on the side of sticking with Can unless a really good
> name
> > >>> is discovered.
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Can or Box or something else

[Marius]

Personally I kind of like ? name ... although I feel many people will
not. Going further having Full and Empty extending ? may "lift"quite a
few eyebrows :)

BTW I totally agree that Result is not ok.

Br's,
Marius

On Dec 21, 7:45 pm, "David Bernard" 
wrote:
> current signature :
>   def doStuff(arg1 : Can[Foo], arg2 : Toto) : Can[Bar]
>
> With Result:
>   def doStuff(arg1 : Result[Foo], arg2 : Toto) : Result[Bar]
> Result could be good but is not, when used for argument and not for "result"
>
> more I think about it, more I thought ? was not so wrong/joke. In the
> Nice language (a old competitor to scala) ? was used to mark value to
> be potentially null
>
> var myVar1 : ?String //myVar1 could be null
> var myVar2 : String //myVar2 is never null
>
> With ?:
>   def doStuff(arg1 : ?[Foo], arg2 : Toto) : ?[Bar]
>
> On Sun, Dec 21, 2008 at 17:42, Mateusz Fiołka  
> wrote:
> > Result +1
>
> > Quite short, only one selfexplaining imo and describes the purpose it serves
> > well. The only downsides of this name is +3 characters and the fact that the
> > class could be used also as non result but for other purpose.
>
> > On Sun, Dec 21, 2008 at 3:32 PM, Derek Chen-Becker 
> > wrote:
>
> >> I think that the previously mentioned "Box" would be the only other thing
> >> that has
>
> >> The same semantic meaning of "container". Well, as Tim pointed out this is
> >> a US thing for Can...
> >> The same brevity. I agree with David that commonly used constructs should
> >> be short
>
> >> If it was going to change at all, this would be it.
>
> >> Derek
>
> >> On Sat, Dec 20, 2008 at 11:13 PM, Josh Suereth 
> >> wrote:
>
> >>> On Sat, Dec 20, 2008 at 2:37 PM, Oliver Lambert  wrote:
>
>  Yup, when you chose the original name, you did a good job - why second
>  guess yourself now. Can we just leave it the way it is.
>
> >>> Pun intended
>
> >>> As to my vote (if I'm allowed one)...
>
> >>> Can was slightly confusing, but looking at it vs Option makes a lot of
> >>> sense.  Option is also slightly confusing, because I expected it to behave
> >>> like Either.   Either is a great name, as you can tell what it's doing.
>
> >>> Result seems ok, but I would vote for something more like Storage.   Can
> >>> is pretty succinct, and once you know how to use it, it's not hard to
> >>> remember the convention.
>
> >>> So I'd swing on the side of sticking with Can unless a really good name
> >>> is discovered.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Can or Box or something else

[David Bernard]

current signature :
  def doStuff(arg1 : Can[Foo], arg2 : Toto) : Can[Bar]

With Result:
  def doStuff(arg1 : Result[Foo], arg2 : Toto) : Result[Bar]
Result could be good but is not, when used for argument and not for "result"

more I think about it, more I thought ? was not so wrong/joke. In the
Nice language (a old competitor to scala) ? was used to mark value to
be potentially null

var myVar1 : ?String //myVar1 could be null
var myVar2 : String //myVar2 is never null

With ?:
  def doStuff(arg1 : ?[Foo], arg2 : Toto) : ?[Bar]


On Sun, Dec 21, 2008 at 17:42, Mateusz Fiołka  wrote:
> Result +1
>
> Quite short, only one selfexplaining imo and describes the purpose it serves
> well. The only downsides of this name is +3 characters and the fact that the
> class could be used also as non result but for other purpose.
>
> On Sun, Dec 21, 2008 at 3:32 PM, Derek Chen-Becker 
> wrote:
>>
>> I think that the previously mentioned "Box" would be the only other thing
>> that has
>>
>> The same semantic meaning of "container". Well, as Tim pointed out this is
>> a US thing for Can...
>> The same brevity. I agree with David that commonly used constructs should
>> be short
>>
>> If it was going to change at all, this would be it.
>>
>> Derek
>>
>> On Sat, Dec 20, 2008 at 11:13 PM, Josh Suereth 
>> wrote:
>>>
>>>
>>> On Sat, Dec 20, 2008 at 2:37 PM, Oliver Lambert  wrote:

 Yup, when you chose the original name, you did a good job - why second
 guess yourself now. Can we just leave it the way it is.
>>>
>>> Pun intended
>>>
>>>
>>> As to my vote (if I'm allowed one)...
>>>
>>> Can was slightly confusing, but looking at it vs Option makes a lot of
>>> sense.  Option is also slightly confusing, because I expected it to behave
>>> like Either.   Either is a great name, as you can tell what it's doing.
>>>
>>> Result seems ok, but I would vote for something more like Storage.   Can
>>> is pretty succinct, and once you know how to use it, it's not hard to
>>> remember the convention.
>>>
>>> So I'd swing on the side of sticking with Can unless a really good name
>>> is discovered.
>>>
>>>
>>
>>
>>
>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Can or Box or something else

[Mateusz Fiołka]

Result +1

Quite short, only one selfexplaining imo and describes the purpose it serves
well. The only downsides of this name is +3 characters and the fact that the
class could be used also as non result but for other purpose.

On Sun, Dec 21, 2008 at 3:32 PM, Derek Chen-Becker wrote:

> I think that the previously mentioned "Box" would be the only other thing
> that has
>
>1. The same semantic meaning of "container". Well, as Tim pointed out
>this is a US thing for Can...
>2. The same brevity. I agree with David that commonly used constructs
>should be short
>
> If it was going to change at all, this would be it.
>
> Derek
>
>
> On Sat, Dec 20, 2008 at 11:13 PM, Josh Suereth 
> wrote:
>
>>
>>
>> On Sat, Dec 20, 2008 at 2:37 PM, Oliver Lambert  wrote:
>>
>>> Yup, when you chose the original name, you did a good job - why second
>>> guess yourself now. Can we just leave it the way it is.
>>>
>>
>> Pun intended
>>
>>
>> As to my vote (if I'm allowed one)...
>>
>> Can was slightly confusing, but looking at it vs Option makes a lot of
>> sense.  Option is also slightly confusing, because I expected it to behave
>> like Either.   Either is a great name, as you can tell what it's doing.
>>
>> Result seems ok, but I would vote for something more like Storage.   Can
>> is pretty succinct, and once you know how to use it, it's not hard to
>> remember the convention.
>>
>> So I'd swing on the side of sticking with Can unless a really good name is
>> discovered.
>>
>>
>>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Can or Box or something else

[Derek Chen-Becker]

I think that the previously mentioned "Box" would be the only other thing
that has

   1. The same semantic meaning of "container". Well, as Tim pointed out
   this is a US thing for Can...
   2. The same brevity. I agree with David that commonly used constructs
   should be short

If it was going to change at all, this would be it.

Derek

On Sat, Dec 20, 2008 at 11:13 PM, Josh Suereth wrote:

>
>
> On Sat, Dec 20, 2008 at 2:37 PM, Oliver Lambert  wrote:
>
>> Yup, when you chose the original name, you did a good job - why second
>> guess yourself now. Can we just leave it the way it is.
>>
>
> Pun intended
>
>
> As to my vote (if I'm allowed one)...
>
> Can was slightly confusing, but looking at it vs Option makes a lot of
> sense.  Option is also slightly confusing, because I expected it to behave
> like Either.   Either is a great name, as you can tell what it's doing.
>
> Result seems ok, but I would vote for something more like Storage.   Can is
> pretty succinct, and once you know how to use it, it's not hard to remember
> the convention.
>
> So I'd swing on the side of sticking with Can unless a really good name is
> discovered.
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Can or Box or something else

[Josh Suereth]

On Sat, Dec 20, 2008 at 2:37 PM, Oliver Lambert  wrote:

> Yup, when you chose the original name, you did a good job - why second
> guess yourself now. Can we just leave it the way it is.
>

Pun intended


As to my vote (if I'm allowed one)...

Can was slightly confusing, but looking at it vs Option makes a lot of
sense.  Option is also slightly confusing, because I expected it to behave
like Either.   Either is a great name, as you can tell what it's doing.

Result seems ok, but I would vote for something more like Storage.   Can is
pretty succinct, and once you know how to use it, it's not hard to remember
the convention.

So I'd swing on the side of sticking with Can unless a really good name is
discovered.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Can or Box or something else

[David Pollak]

It took me a long time to understand what an Option what.  Personally, Maybe
(Haskell) makes more sense to me.  Perpetuating Option as a name is, IMHO,
less than optimal.

On Sat, Dec 20, 2008 at 1:08 PM, David Bernard
wrote:

>
> If you want 3 letters "Opt" to show the relation with Option
> If you want less  "?" (question mark) but it's already used by
> i18n/resourses bundles (but it could be changed from ?("my sentence
> key") to $("my sentence key")). I'm haunted by Tony ;)
>
> my 2 cents useless contribution
>
>
> On Sat, Dec 20, 2008 at 21:49, Matt Harrington 
> wrote:
> >
> > On Sat, Dec 20, 2008 at 7:13 AM, TylerWeir  wrote:
> >>
> >> Once people get Can, I think it makes sense, so I think we can leave
> >> it.
> >>
> >> As a replacement, I can't think of a good real-life example of a thing
> >> with a failure indicator that fits the bill. :)
> >>
> >> What about OptionWithFailure, OptionWF, OptWithF?
> >> It's more typing, but it's accurate.
> >>
> >> FailureIndicatingOption?  FIOption?
> >>
> >
> > These are pretty much my thoughts on the issue also.  I like
> > OptionWithFailure the best, but of the suggestions for very short
> > names, Can is a reasonable choice once you see an explanation.
> >
> > Matt
> >
> > >
> >
>
> >
>


-- 
Lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Can or Box or something else

[David Bernard]

If you want 3 letters "Opt" to show the relation with Option
If you want less  "?" (question mark) but it's already used by
i18n/resourses bundles (but it could be changed from ?("my sentence
key") to $("my sentence key")). I'm haunted by Tony ;)

my 2 cents useless contribution


On Sat, Dec 20, 2008 at 21:49, Matt Harrington  wrote:
>
> On Sat, Dec 20, 2008 at 7:13 AM, TylerWeir  wrote:
>>
>> Once people get Can, I think it makes sense, so I think we can leave
>> it.
>>
>> As a replacement, I can't think of a good real-life example of a thing
>> with a failure indicator that fits the bill. :)
>>
>> What about OptionWithFailure, OptionWF, OptWithF?
>> It's more typing, but it's accurate.
>>
>> FailureIndicatingOption?  FIOption?
>>
>
> These are pretty much my thoughts on the issue also.  I like
> OptionWithFailure the best, but of the suggestions for very short
> names, Can is a reasonable choice once you see an explanation.
>
> Matt
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Can or Box or something else

[David Pollak]

If I had it to do over, I'd call it Box... but the cost of change seems to
outweigh the benefit of change... Can it is.
Thanks for your input.

On Sat, Dec 20, 2008 at 12:49 PM, Matt Harrington wrote:

>
> On Sat, Dec 20, 2008 at 7:13 AM, TylerWeir  wrote:
> >
> > Once people get Can, I think it makes sense, so I think we can leave
> > it.
> >
> > As a replacement, I can't think of a good real-life example of a thing
> > with a failure indicator that fits the bill. :)
> >
> > What about OptionWithFailure, OptionWF, OptWithF?
> > It's more typing, but it's accurate.
> >
> > FailureIndicatingOption?  FIOption?
> >
>
> These are pretty much my thoughts on the issue also.  I like
> OptionWithFailure the best, but of the suggestions for very short
> names, Can is a reasonable choice once you see an explanation.
>
> Matt
>
> >
>


-- 
Lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Can or Box or something else

[Matt Harrington]

On Sat, Dec 20, 2008 at 7:13 AM, TylerWeir  wrote:
>
> Once people get Can, I think it makes sense, so I think we can leave
> it.
>
> As a replacement, I can't think of a good real-life example of a thing
> with a failure indicator that fits the bill. :)
>
> What about OptionWithFailure, OptionWF, OptWithF?
> It's more typing, but it's accurate.
>
> FailureIndicatingOption?  FIOption?
>

These are pretty much my thoughts on the issue also.  I like
OptionWithFailure the best, but of the suggestions for very short
names, Can is a reasonable choice once you see an explanation.

Matt

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Can or Box or something else

[Oliver Lambert]

Perhaps we should rename Can to Option and get the Scala guys to  
rename theirs, OptionWithoutFailure :)

On 21/12/2008, at 6:50 AM, Charles F. Munat wrote:

> OptionWithFailure


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Can or Box or something else

[Charles F. Munat]

Generally, I agree, but not at the expense of understandability. And 
about the only time I have to type it is as a result type when it can't 
be inferred. The rest of the time I'm using Full() or Empty, which are 
nice and short. Even Box, which I think is much better, requires 
explaining. OptionWithFailure probably does not.

And with an IDE and code completion, it's not an issue. I'm more 
interested in reducing boilerplate than forcing type names to the 
shortest possible length.

Just my opinion...

Chas.

David Pollak wrote:
> Because Can is three letters and OptionPlus is 11 and a frequently used 
> construct should be easy on the fingers.
> 
> On Dec 20, 2008 11:15 AM, "Oliver Lambert"  > wrote:
> 
> Ok so Can is not either an Either or an Option, its a Can. I kind of
> wondered when I first used Can, and it was described as an enhanced
> Option,  why it wasn't called something like Option+ with None, Some
> and Failure.
> 
> On 21/12/2008, at 5:47 AM, David Pollak wrote: > Can has map,
> flatMap, filter etc. So it can be u...
> 
> You received this message because you are subscribed to the Google
> Groups "Lift" group. To post to ...
> 
> 
> 
> > 

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Can or Box or something else

[Charles F. Munat]

I agree. I think Box is more cross-cultural and has no confusing 
meanings (e.g. can = possible). But Tyler makes a good point. Really, it 
should be called something like OptionWithFailure. And we should stop 
trying to abbreviate everything (*maybe* OptionWFailure). After all, how 
often do you actually write out "Can"? Usually it's Full() or Empty.

IMO, things should be self-explanatory and documentation should only be 
a fall back. It's generally a bad idea in my experience to rely on 
documentation.

Frankly, I, too, found Can quite confusing, even though I already knew 
what Option did.

Chas.

Marius wrote:
> Between Can, Cup and Box ...Box makes most sense to me ... (I'm not
> going to suggest Bottle :) ...)
> 
> Br's,
> Marius
> 
> On 20 Dec, 18:19, Tim Perrett  wrote:
>> Speaking from personal experience, what I didn't realize to begin with  
>> was that the can was what we in England call a tin, and the  
>> connotation of "you can do something" is conceptually very different  
>> to "a can (tin) contains x" if you follow my meaning...
>>
>> I think the problem can be solved by better docs, and a paper that  
>> explains the rational of can as a container - this would fix the curve  
>> of understanding IMO. What usually happens when noobies ask about can,  
>> is that people are pointed in the direction of Option, but if your new  
>> to scala, that is fairly meaningless also as those comming from java  
>> et al are using to checking for null so don't see why you need a  
>> container.
>>
>> Just my two pence
>>
>> Cheers, Tim
>>
>> Sent from my iPhone
>>
>> On 20 Dec 2008, at 14:43, "David Pollak"  
>>
>>  wrote:
>>> Folks,
>>> Over the year that Lift has had Can[T] as a replacement for Scala's  
>>> Option[T], the name "Can" has required a lot of explaining.
>>> As we make the final push into freezing Lift's APIs, do we want to  
>>> change the name of Can to something else or should we leave it as  
>>> Can.  Alternatives are:
>>> Cup
>>> Box
>>> Both of which can be Full/Empty.
>>> Thanks,
>>> David
>>> PS -- The Scala collections classes are getting a redo for 2.8.  
>>> I've been gently pestering Martin to expand Option to have a Failure  
>>> case.  If this happens (it's not really likely for a couple of  
>>> reasons), Can will be orphaned.
>>> --
>>> Lift, the simply functional web frameworkhttp://liftweb.net
>>> Collaborative Task Managementhttp://much4.us
>>> Follow me:http://twitter.com/dpp
>>> Git some:http://github.com/dpp
> > 

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Can or Box or something else

[Charles F. Munat]

Yes, but which is it: half empty or half full? You'd think at this stage 
of development we could at least answer that old question.

Chas.

Derek Chen-Becker wrote:
> What about renaming it Glass? Then we could add:
> 
> case class HalfFull[T](data : T) extends Glass[T]
> type HalfEmpty[T] = HalfFull[T]
> 
> ;)
> 
> Derek
> 
> On Sat, Dec 20, 2008 at 8:13 AM, TylerWeir  > wrote:
> 
> 
> Once people get Can, I think it makes sense, so I think we can leave
> it.
> 
> As a replacement, I can't think of a good real-life example of a thing
> with a failure indicator that fits the bill. :)
> 
> What about OptionWithFailure, OptionWF, OptWithF?
> It's more typing, but it's accurate.
> 
> FailureIndicatingOption?  FIOption?
> 
> 
> 
> On Dec 20, 9:43 am, "David Pollak"  >
> wrote:
>  > Folks,
>  >
>  > Over the year that Lift has had Can[T] as a replacement for Scala's
>  > Option[T], the name "Can" has required a lot of explaining.
>  >
>  > As we make the final push into freezing Lift's APIs, do we want
> to change
>  > the name of Can to something else or should we leave it as Can.
>  > Alternatives are:
>  >
>  >- Cup
>  >- Box
>  >
>  > Both of which can be Full/Empty.
>  >
>  > Thanks,
>  >
>  > David
>  >
>  > PS -- The Scala collections classes are getting a redo for 2.8.
>  I've been
>  > gently pestering Martin to expand Option to have a Failure case.
>  If this
>  > happens (it's not really likely for a couple of reasons), Can will be
>  > orphaned.
>  >
>  > --
>  > Lift, the simply functional web frameworkhttp://liftweb.net
> 
>  > Collaborative Task Managementhttp://much4.us 
>  > Follow me:http://twitter.com/dpp
>  > Git some:http://github.com/dpp
> 
> 
> 
> > 

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Can or Box or something else

[Oliver Lambert]

Yup, when you chose the original name, you did a good job - why second  
guess yourself now. Can we just leave it the way it is.

On 21/12/2008, at 6:25 AM, David Pollak wrote:

> Because Can is three letters and OptionPlus is 11 and a frequently  
> used construct should be easy on the fingers.
>
>
> On Dec 20, 2008 11:15 AM, "Oliver Lambert"  wrote:
>
> Ok so Can is not either an Either or an Option, its a Can. I kind of  
> wondered when I first used Can, and it was described as an enhanced  
> Option,  why it wasn't called something like Option+ with None, Some  
> and Failure.
> On 21/12/2008, at 5:47 AM, David Pollak wrote: > Can has map,  
> flatMap, filter etc. So it can be u...
>
> You received this message because you are subscribed to the Google  
> Groups "Lift" group. To post to ...
>
>
>
>
> >


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Can or Box or something else

[Alex Boisvert]

How about Result?  e.g. something like,

sealed trait Result[+T]
case class Expected(t: T) extends Result[T]
case class Failure[T](msg: String) extends Result[T]
case object Empty extends Result[Nothing]

alex

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Can or Box or something else

[David Pollak]

Because Can is three letters and OptionPlus is 11 and a frequently used
construct should be easy on the fingers.

On Dec 20, 2008 11:15 AM, "Oliver Lambert"  wrote:

Ok so Can is not either an Either or an Option, its a Can. I kind of
wondered when I first used Can, and it was described as an enhanced Option,
 why it wasn't called something like Option+ with None, Some and Failure.

On 21/12/2008, at 5:47 AM, David Pollak wrote: > Can has map, flatMap,
filter etc. So it can be u...

You received this message because you are subscribed to the Google Groups
"Lift" group. To post to ...

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Can or Box or something else

[Oliver Lambert]

Ok so Can is not either an Either or an Option, its a Can. I kind of  
wondered when I first used Can, and it was described as an enhanced  
Option,  why it wasn't called something like Option+ with None, Some  
and Failure.

On 21/12/2008, at 5:47 AM, David Pollak wrote:

> Can has map, flatMap, filter etc. So it can be used in a for  
> comphrension.  I don't believe Either has those methods. Further,  
> Can has a bunch of helpers to turn Empty into Failure
>
>
> On Dec 20, 2008 10:33 AM, "Oliver Lambert"  wrote:
>
> Is Can a little less like Option and more like scala.Either, where  
> the left side is used to indicate failure?
> On 21/12/2008, at 1:43 AM, David Pollak wrote: > Folks, > > Over the  
> year that Lift has had Can[T...
>
> >


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Can or Box or something else

[David Pollak]

Can has map, flatMap, filter etc. So it can be used in a for comphrension.
I don't believe Either has those methods. Further, Can has a bunch of
helpers to turn Empty into Failure

On Dec 20, 2008 10:33 AM, "Oliver Lambert"  wrote:

Is Can a little less like Option and more like scala.Either, where the left
side is used to indicate failure?

On 21/12/2008, at 1:43 AM, David Pollak wrote: > Folks, > > Over the year
that Lift has had Can[T...

--~--~-~--~~~---~--~~ You received this
message because you are subs...

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Can or Box or something else

[Marius]

Can is more like Option but richer. Not much like Either.

On 20 Dec, 20:33, Oliver Lambert  wrote:
> Is Can a little less like Option and more like scala.Either, where the  
> left side is used to indicate failure?
>
> On 21/12/2008, at 1:43 AM, David Pollak wrote:
>
> > Folks,
>
> > Over the year that Lift has had Can[T] as a replacement for Scala's  
> > Option[T], the name "Can" has required a lot of explaining.
>
> > As we make the final push into freezing Lift's APIs, do we want to  
> > change the name of Can to something else or should we leave it as  
> > Can.  Alternatives are:
> > Cup
> > Box
> > Both of which can be Full/Empty.
>
> > Thanks,
>
> > David
>
> > PS -- The Scala collections classes are getting a redo for 2.8.  
> > I've been gently pestering Martin to expand Option to have a Failure  
> > case.  If this happens (it's not really likely for a couple of  
> > reasons), Can will be orphaned.
>
> > --
> > Lift, the simply functional web frameworkhttp://liftweb.net
> > Collaborative Task Managementhttp://much4.us
> > Follow me:http://twitter.com/dpp
> > Git some:http://github.com/dpp
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Can or Box or something else

[Marius]

Between Can, Cup and Box ...Box makes most sense to me ... (I'm not
going to suggest Bottle :) ...)

Br's,
Marius

On 20 Dec, 18:19, Tim Perrett  wrote:
> Speaking from personal experience, what I didn't realize to begin with  
> was that the can was what we in England call a tin, and the  
> connotation of "you can do something" is conceptually very different  
> to "a can (tin) contains x" if you follow my meaning...
>
> I think the problem can be solved by better docs, and a paper that  
> explains the rational of can as a container - this would fix the curve  
> of understanding IMO. What usually happens when noobies ask about can,  
> is that people are pointed in the direction of Option, but if your new  
> to scala, that is fairly meaningless also as those comming from java  
> et al are using to checking for null so don't see why you need a  
> container.
>
> Just my two pence
>
> Cheers, Tim
>
> Sent from my iPhone
>
> On 20 Dec 2008, at 14:43, "David Pollak"  
>
>  wrote:
> > Folks,
>
> > Over the year that Lift has had Can[T] as a replacement for Scala's  
> > Option[T], the name "Can" has required a lot of explaining.
>
> > As we make the final push into freezing Lift's APIs, do we want to  
> > change the name of Can to something else or should we leave it as  
> > Can.  Alternatives are:
> > Cup
> > Box
> > Both of which can be Full/Empty.
>
> > Thanks,
>
> > David
>
> > PS -- The Scala collections classes are getting a redo for 2.8.  
> > I've been gently pestering Martin to expand Option to have a Failure  
> > case.  If this happens (it's not really likely for a couple of  
> > reasons), Can will be orphaned.
>
> > --
> > Lift, the simply functional web frameworkhttp://liftweb.net
> > Collaborative Task Managementhttp://much4.us
> > Follow me:http://twitter.com/dpp
> > Git some:http://github.com/dpp
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Can or Box or something else

[Tim Perrett]

Speaking from personal experience, what I didn't realize to begin with  
was that the can was what we in England call a tin, and the  
connotation of "you can do something" is conceptually very different  
to "a can (tin) contains x" if you follow my meaning...

I think the problem can be solved by better docs, and a paper that  
explains the rational of can as a container - this would fix the curve  
of understanding IMO. What usually happens when noobies ask about can,  
is that people are pointed in the direction of Option, but if your new  
to scala, that is fairly meaningless also as those comming from java  
et al are using to checking for null so don't see why you need a  
container.

Just my two pence

Cheers, Tim

Sent from my iPhone

On 20 Dec 2008, at 14:43, "David Pollak"  
 wrote:

> Folks,
>
> Over the year that Lift has had Can[T] as a replacement for Scala's  
> Option[T], the name "Can" has required a lot of explaining.
>
> As we make the final push into freezing Lift's APIs, do we want to  
> change the name of Can to something else or should we leave it as  
> Can.  Alternatives are:
> Cup
> Box
> Both of which can be Full/Empty.
>
> Thanks,
>
> David
>
> PS -- The Scala collections classes are getting a redo for 2.8.   
> I've been gently pestering Martin to expand Option to have a Failure  
> case.  If this happens (it's not really likely for a couple of  
> reasons), Can will be orphaned.
>
> -- 
> Lift, the simply functional web framework http://liftweb.net
> Collaborative Task Management http://much4.us
> Follow me: http://twitter.com/dpp
> Git some: http://github.com/dpp
>
> >

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Can or Box or something else

[David Pollak]

Funny boy.  :-)

On Dec 20, 2008 7:39 AM, "Derek Chen-Becker"  wrote:

What about renaming it Glass? Then we could add:

case class HalfFull[T](data : T) extends Glass[T]
type HalfEmpty[T] = HalfFull[T]

;)

Derek

On Sat, Dec 20, 2008 at 8:13 AM, TylerWeir  wrote: > >
> Once people get Can...

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Can or Box or something else

[Derek Chen-Becker]

What about renaming it Glass? Then we could add:

case class HalfFull[T](data : T) extends Glass[T]
type HalfEmpty[T] = HalfFull[T]

;)

Derek

On Sat, Dec 20, 2008 at 8:13 AM, TylerWeir  wrote:

>
> Once people get Can, I think it makes sense, so I think we can leave
> it.
>
> As a replacement, I can't think of a good real-life example of a thing
> with a failure indicator that fits the bill. :)
>
> What about OptionWithFailure, OptionWF, OptWithF?
> It's more typing, but it's accurate.
>
> FailureIndicatingOption?  FIOption?
>
>
>
> On Dec 20, 9:43 am, "David Pollak" 
> wrote:
> > Folks,
> >
> > Over the year that Lift has had Can[T] as a replacement for Scala's
> > Option[T], the name "Can" has required a lot of explaining.
> >
> > As we make the final push into freezing Lift's APIs, do we want to change
> > the name of Can to something else or should we leave it as Can.
> > Alternatives are:
> >
> >- Cup
> >- Box
> >
> > Both of which can be Full/Empty.
> >
> > Thanks,
> >
> > David
> >
> > PS -- The Scala collections classes are getting a redo for 2.8.  I've
> been
> > gently pestering Martin to expand Option to have a Failure case.  If this
> > happens (it's not really likely for a couple of reasons), Can will be
> > orphaned.
> >
> > --
> > Lift, the simply functional web frameworkhttp://liftweb.net
> > Collaborative Task Managementhttp://much4.us
> > Follow me:http://twitter.com/dpp
> > Git some:http://github.com/dpp
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---

[Lift] Re: Can or Box or something else

[TylerWeir]

Once people get Can, I think it makes sense, so I think we can leave
it.

As a replacement, I can't think of a good real-life example of a thing
with a failure indicator that fits the bill. :)

What about OptionWithFailure, OptionWF, OptWithF?
It's more typing, but it's accurate.

FailureIndicatingOption?  FIOption?



On Dec 20, 9:43 am, "David Pollak" 
wrote:
> Folks,
>
> Over the year that Lift has had Can[T] as a replacement for Scala's
> Option[T], the name "Can" has required a lot of explaining.
>
> As we make the final push into freezing Lift's APIs, do we want to change
> the name of Can to something else or should we leave it as Can.
> Alternatives are:
>
>    - Cup
>    - Box
>
> Both of which can be Full/Empty.
>
> Thanks,
>
> David
>
> PS -- The Scala collections classes are getting a redo for 2.8.  I've been
> gently pestering Martin to expand Option to have a Failure case.  If this
> happens (it's not really likely for a couple of reasons), Can will be
> orphaned.
>
> --
> Lift, the simply functional web frameworkhttp://liftweb.net
> Collaborative Task Managementhttp://much4.us
> Follow me:http://twitter.com/dpp
> Git some:http://github.com/dpp
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---