Can or Box or something else

[David Pollak]

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

[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" <feeder.of.the.be...@gmail.com>
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

[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

[David Pollak]

Funny boy.  :-)

On Dec 20, 2008 7:39 AM, "Derek Chen-Becker" <dchen...@gmail.com> 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 <tyler...@gmail.com> wrote: > > > Once people get Can...

[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

[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 <he...@timperrett.com> 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"  
>

> <feeder.of.the.be...@gmail.com> 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

[Oliver Lambert]

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

[Marius]

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

On 20 Dec, 20:33, Oliver Lambert <ola...@gmail.com> 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

[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" <ola...@gmail.com> 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...

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

[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" <ola...@gmail.com> 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 ...

[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

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

[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 <tyler...@gmail.com
> <mailto:tyler...@gmail.com>> 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" <feeder.of.the.be...@gmail.com

> <mailto:feeder.of.the.be...@gmail.com>>

> 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
> <http://liftweb.net>

> > Collaborative Task Managementhttp://much4.us <http://much4.us>

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

[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" <ola...@gmail.com

[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

[Matt Harrington]

On Sat, Dec 20, 2008 at 7:13 AM, TylerWeir <tyler...@gmail.com> 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

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

--

Lift, the simply functional web framework http://liftweb.net

Collaborative Task Management http://much4.us

[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

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

--

Lift, the simply functional web framework http://liftweb.net

Collaborative Task Management http://much4.us

[Josh Suereth]

On Sat, Dec 20, 2008 at 2:37 PM, Oliver Lambert <ola...@gmail.com> 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.

[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

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

[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]

[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" <david.bernard...@gmail.com>
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 <mateusz.fio...@gmail.com> 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>

[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 <marius...@gmail.com>

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

[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

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

[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

[saem...@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?

[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

[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

[Caoyuan]

and "Pack" ?

[Viktor Klang]

"Bin"
"Slot"
"Ref"

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

Merry Christmas
/Viktor

--
Viktor Klang
Senior Systems Analyst

[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 <dcao...@gmail.com> wrote:

[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

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

[David Pollak]

2008/12/26 Alex Boisvert <bois...@intalio.com>

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.

[Charles F. Munat]

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

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

Chas.

[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

[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

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

<personal_opinion>

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

</personal_opinion>

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

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

[Viktor Klang]

Wonderful :)

[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}

[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!!)

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

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

[David Pollak]

On Sun, Dec 28, 2008 at 12:46 PM, stephen goldbaum <stephen....@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.

 

[Jorge Ortiz]

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

--j

[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

[mbh....@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

[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

[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 <ola...@gmail.com> 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" <ola...@gmail.com> 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...

[David Pollak]

Tony,

Can (now Box) is not an Either.

David

[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 <tonym...@gmail.com
> <mailto:tonym...@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 <ola...@gmail.com

> <mailto:ola...@gmail.com>> 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" <ola...@gmail.com

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

[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

>> <mailto:tonym...@gmail.com <mailto:tonym...@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 <ola...@gmail.com
> <mailto:ola...@gmail.com>

>> <mailto:ola...@gmail.com <mailto:ola...@gmail.com>>> 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" <ola...@gmail.com
> <mailto:ola...@gmail.com>

[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

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

[Miles Sabin]

On Tue, Jan 6, 2009 at 11:23 PM, Tony Morris <tonym...@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).

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

[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

[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 :)

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

[David Pollak]

On Tue, Jan 6, 2009 at 5:27 PM, Josh Suereth <joshua....@gmail.com> 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.

[Warren Henning]

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

Who cares?

[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]

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]

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

[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

[Jorge Ortiz]

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

--j

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

[David Pollak]

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.