[Lift] Re: Can or Box or something else
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 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). 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 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
Warren Henning wrote: On Tue, Jan 6, 2009 at 3:49 PM, Tony Morris tonymor...@gmail.com 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
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 tonymor...@gmail.com 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
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 tonymor...@gmail.com 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 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). 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 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
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... --~--~-~--~~~---~--~~ 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, Can (now Box) is not an Either. David On Tue, Jan 6, 2009 at 2:37 PM, Tony Morris 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 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... -- 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
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 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 tonymor...@gmail.com 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 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 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
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
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
tonymor...@gmail.com mailto:tonymor...@gmail.com
mailto:tonymor...@gmail.com 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 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
mailto:ola...@gmail.com mailto: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...
-- 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
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 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
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
tonymor...@gmail.com mailto:tonymor...@gmail.com
mailto:tonymor...@gmail.com 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 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
mailto:ola...@gmail.com mailto: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...
-- 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:
[Lift] Re: Can or Box or something else
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
mailto: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 mailto:tonymor...@gmail.com
mailto:tonymor...@gmail.com 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
tonymor...@gmail.com mailto:tonymor...@gmail.com
mailto:tonymor...@gmail.com mailto:tonymor...@gmail.com
mailto:tonymor...@gmail.com mailto:tonymor...@gmail.com
mailto:tonymor...@gmail.com 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 ola...@gmail.com
mailto:ola...@gmail.com
[Lift] Re: Can or Box or something else
On Tue, Jan 6, 2009 at 11:23 PM, Tony Morris 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). 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
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
mailto: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 mailto:tonymor...@gmail.com
mailto:tonymor...@gmail.com 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
tonymor...@gmail.com mailto:tonymor...@gmail.com
mailto:tonymor...@gmail.com mailto:tonymor...@gmail.com
mailto:tonymor...@gmail.com mailto:tonymor...@gmail.com
mailto:tonymor...@gmail.com 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
[Lift] Re: Can or Box or something else
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 jorge.or...@gmail.com 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
mailto: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 mailto:tonymor...@gmail.com
mailto:tonymor...@gmail.com 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
tonymor...@gmail.com mailto:tonymor...@gmail.com
mailto:tonymor...@gmail.com mailto:tonymor...@gmail.com
mailto:tonymor...@gmail.com mailto:tonymor...@gmail.com
mailto:tonymor...@gmail.com 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
[Lift] Re: Can or Box or something else
On Tue, Jan 6, 2009 at 5:27 PM, Josh Suereth joshua.suer...@gmail.comwrote:
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 jorge.or...@gmail.com 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
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/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
mailto: tonymor...@gmail.comtonymor...@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/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.comtonymor...@gmail.com mailto:tonymor...@gmail.com
tonymor...@gmail.com
mailto: tonymor...@gmail.comtonymor...@gmail.com
mailto: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 http://tmorris.net/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
[Lift] Re: Can or Box or something else
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
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
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 --~--~-~--~~~---~--~~ 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
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 he...@timperrett.com 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. 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 -- 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
Wonderful :) On Sun, Dec 28, 2008 at 4:03 PM, 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 he...@timperrett.com 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. 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 -- 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
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 he...@timperrett.com 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.
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
--
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
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 joshua.suer...@gmail.com 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
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 he...@timperrett.com 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 joshua.suer...@gmail.com 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
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
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
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 boisv...@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. alex On Fri, Dec 26, 2008 at 3:29 AM, Mateusz Fiołka mateusz.fio...@gmail.co 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 dcaoy...@gmail.com wrote: and Pack ? On Fri, Dec 26, 2008 at 8:35 AM, Marc Boschma marc +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
and Pack ? On Fri, Dec 26, 2008 at 8:35 AM, Marc Boschma marc+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 --~--~-~--~~~---~--~~ 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 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
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
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 acru...@gmail.com 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
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 joshua.suer...@gmail.comwrote: 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. --~--~-~--~~~---~--~~ 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
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.comwrote: 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 joshua.suer...@gmail.comwrote: 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. --~--~-~--~~~---~--~~ 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
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 he...@timperrett.com 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 c...@munat.com 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
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.w...@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 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
Funny boy. :-) On Dec 20, 2008 7:39 AM, Derek Chen-Becker dchenbec...@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.w...@gmail.com 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
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 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
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 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
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... --~--~-~--~~~---~--~~ 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
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 ... --~--~-~--~~~---~--~~ 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
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
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 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 ... --~--~-~--~~~---~--~~ 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
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.w...@gmail.com mailto:tyler.w...@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 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
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 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 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
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
On Sat, Dec 20, 2008 at 7:13 AM, TylerWeir tyler.w...@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 --~--~-~--~~~---~--~~ 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
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 mbh.li...@gmail.comwrote: On Sat, Dec 20, 2008 at 7:13 AM, TylerWeir tyler.w...@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 -- 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
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 mbh.li...@gmail.com wrote: On Sat, Dec 20, 2008 at 7:13 AM, TylerWeir tyler.w...@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 --~--~-~--~~~---~--~~ 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
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. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
