[Lift] Re: Can or Box or something else

[Warren Henning]

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

Who cares?

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

[Lift] Re: accessing the attributes of the XML node associated with a FuncBindParam in bind(...)

[Marc Boschma]

Cool code! Works nicely...

Would it make sense to also add something similar to this from S.attr ?

   def apply[T](what: String, f: String => T, default: => T): T =  
apply(what).map(f) openOr default

ie maybe:

   def apply[T](prefix: String, key: String, f: String => T):  
Option[T] = apply(prefix, key).map(f)
   def apply[T](key: String, f: String => T): Option[T] =  
apply(key).map(f)

to BindHelpers.attr ?

Thinking about it should the applys of the two attr objects be aligned  
(Option verses Box, etc) ? It would make the crafting of snippets and  
bind functions in terms of access to attributes the same, dropping a  
potential barrier to learning lift...

ie Maybe BindHelpers.attr should have applys with the following  
signatures...

 def apply(key: String): Box[String]
 def apply(prefix: String,  key: String): Box[String]

 def apply(key: String, default: => String): String
 def apply(prefix: String, key: String, default: => String): String

 def apply[T](key: String, f: String => T, default: => T): T
 def apply[T](prefix: String, key: String, f: String => T,  
default: => T): T

Lastly, and maybe I am missing something here, but I take it for a  
snippet a prefixed attribute isn't accessible via S.attr ???

Regards,

Marc



On 07/01/2009, at 6:54 AM, David Pollak wrote:

>
>
> On Tue, Jan 6, 2009 at 11:16 AM, Marius   
> wrote:
>
> Ok ... i just committed some changes:
>
> 1. Renamed curAttr to attr
> 2. The BindHelpers vals are now private but we expose two functions
> currentNode and bindNodes
>
> Cool beans!
>
>
>
> Br's,
> Marius
>
> On Jan 6, 8:37 pm, "David Pollak" 
> wrote:
> > On Tue, Jan 6, 2009 at 10:28 AM, Marius   
> wrote:
> >
> > > On Jan 6, 7:15 pm, "David Pollak" 
> > > wrote:
> > > > I also added
> > > > BindHelpers.attr("tag"): Option[NodeSeq]
> > > > so you can do something like:
> >
> > > > ...
> >
> > > > and:
> > > > BindHelpers.attr("prefix", "tag")
> >
> > > I think it is committed to curAttr which personally I'm not a  
> fan ...
> > > Doyou mind if I change it to attr or nodeAttr ?
> >
> > Go for it.
> >
> >
> >
> > > > Thanks,
> >
> > > > David
> >
> > > > On Tue, Jan 6, 2009 at 9:13 AM, Marius  
>  wrote:
> >
> > > > > Very cool Dave !
> >
> > > > > thx,
> > > > > Marius
> >
> > > > > On Jan 6, 4:36 pm, "David Pollak"  
> 
> > > > > wrote:
> > > > > > Folks,
> >
> > > > > > I'm about to commit up a non-breaking solution.
> >
> > > > > > In bind, you can call:
> > > > > > BindHelpers.bindNodes.value: List[NodeSeq]
> > > > > > BindHelpers.currentNode.value: Elem
> >
> > > > > > bindNodes is a list of the nodes that were passed into  
> bind with the
> > > more
> > > > > > current node at the head of the list.  If you're doing  
> hierarchical
> > > > > binding,
> > > > > > you can see all the nodes that were passed into bind this  
> was.
> >
> > > > > > currentNode is available to the BindParam and it contains  
> the parent
> > > Elem
> > > > > to
> > > > > > the NodeSeq that was passed into your BindParam.  You can  
> inspect
> > > > > attributes
> > > > > > to your heart's content.
> >
> > > > > > Give it an hour or two for these changes to make their way  
> through
> > > > > Hudson.
> >
> > > > > > Thanks,
> >
> > > > > > David
> >
> > > > > > On Tue, Jan 6, 2009 at 4:50 AM, Marc Boschma
> > > > > >  <
> > > marc%2blift...@boschma.cx ><
> > > > > marc%2blift...@boschma.cx  <
> > > marc%252blift...@boschma.cx >>
> >
> > > > > > > wrote:
> >
> > > > > > > I've just had a thought as to how to make it not a  
> breaking change.
> >
> > > > > > > Leave your change "calcValue(s.child) I just call  
> calcValue(s)"
> >
> > > > > > > change:
> > > > > > >   case class FuncBindParam(name: String, value: NodeSeq  
> => NodeSeq)
> > > > > > > extends Tuple2(name, value) with BindParam {
> > > > > > > def calcValue(in: NodeSeq): NodeSeq = value(in)
> > > > > > >   }
> >
> > > > > > > to:
> > > > > > >   case class FuncBindParam(name: String, value: NodeSeq  
> => NodeSeq)
> > > > > > > extends Tuple2(name, value) with BindParam {
> > > > > > > def calcValue(in: NodeSeq): NodeSeq = value(in.child)
> > > > > > >   }
> >
> > > > > > > That should prevent old code breaking... which would be  
> a good
> > > > > > > thing(tm) given the amount of code that uses bind(...)
> >
> > > > > > > then create something like:
> >
> > > > > > >   case class FuncMetaDataBindParam(name: String, value:  
> (MetaData,
> > > > > > > NodeSeq) => NodeSeq) extends Tuple2(name, value) with  
> BindParam {
> > > > > > > def calcValue(in: NodeSeq): NodeSeq =  
> value(in.attributes,
> > > > > > > in.child)
> > > > > > >   }
> >
> > > > > > > along with adding to class SuperArrowAssoc...
> > > > > > >   def ->(in: (MetaData, NodeSeq) => NodeSeq) =
> > > > > > > FuncMetaDataBindParam(name, in)
> >
> > > > > > > That would be fairly clean...
> >
> > > > > > > -
> >
> > > > > > > Maybe for those that actually want the full node add:
> >
> > > > > > >   case class 

[Lift] Re: Does memcache fit in here somewhere?

[Randall R Schulz]

On Tuesday 06 January 2009 20:15, David Pollak wrote:
> Bob,
> memcached is failure.  ...
>
> Please look at this presentation.

That's rather elliptic. Is there something less terse to go with it? 
Some more detailed paper or exposition of its thesis, perhaps?


> Thanks,
>
> David


Randall Schulz

--~--~-~--~~~---~--~~
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] Does memcache fit in here somewhere?

[Bob Eastbrook]

I'm keeping my eye on Lift, but I'm primarily a PHP guy as far as
paying the bills goes.  I've got a slightly better high-level
understanding of things now versus a month or so ago, but I'm not sure
where caching fits into the picture.  In the LAMP world, it's standard
practice to put memcache in front of your database server.  It's
pretty much a "cache everything" philosophy.  Is this not encouraged
with Lift?  I assume there are more caching choices in the Java world
such as ehcache, but I don't see them mentioned on the list.

Bob

--~--~-~--~~~---~--~~
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: Flot Widget

[TylerWeir]

Awesome, I just looked at the Flot+Comet stuff, some cool stuff could
be done with that.

Nice stuff Dave and Francois!

On Jan 6, 8:15 pm, "David Pollak" 
wrote:
> Folks,
>
> I've just updated the Flot widget (which is pretty cool) to be more
> Lift-like.
>
> I've changed Option to Box to be consistent with Lift's use of Box unless
> there's a compelling reason to use Option.
>
> I've changed the code so it uses Lift's JavaScript helpers rather than doing
> manual string generation.
>
> I've also fixed the Flot example code so that it works.
>
> Thanks,
>
> David
>
> --
> 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

[David Pollak]

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

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

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

There's an implicit conversion from Box to Option.


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

[Lift] Re: Can or Box or something else

[Josh Suereth]

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

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

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

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

[Lift] Flot Widget

[David Pollak]

Folks,

I've just updated the Flot widget (which is pretty cool) to be more
Lift-like.

I've changed Option to Box to be consistent with Lift's use of Box unless
there's a compelling reason to use Option.

I've changed the code so it uses Lift's JavaScript helpers rather than doing
manual string generation.

I've also fixed the Flot example code so that it works.

Thanks,

David

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

[Jorge Ortiz]

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

--j

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

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

[Lift] Re: Can or Box or something else

[Miles Sabin]

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

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

To prove the point, here,

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

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

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

Cheers,


Miles

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

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

[Lift] Re: Can or Box or something else

[Tony Morris]

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

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

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

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

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

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


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

[Lift] Re: Can or Box or something else

[Jorge Ortiz]

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

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

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

--j

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

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

[Lift] Re: Can or Box or something else

[Tony Morris]

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

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

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

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

object T {
// construct with Either or Can
}

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

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


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




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

[Lift] Re: Can or Box or something else

[David Pollak]

It's an Option.

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

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

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

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


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

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

[Lift] Re: Can or Box or something else

[Tony Morris]

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

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

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


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




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

[Lift] Re: Can or Box or something else

[David Pollak]

Tony,

Can (now Box) is not an Either.

David

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

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


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

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

[Lift] Re: Can or Box or something else

[Tony Morris]

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

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


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

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

[Lift] Re: accessing the attributes of the XML node associated with a FuncBindParam in bind(...)

[David Pollak]

On Tue, Jan 6, 2009 at 11:16 AM, Marius  wrote:

>
> Ok ... i just committed some changes:
>
> 1. Renamed curAttr to attr
> 2. The BindHelpers vals are now private but we expose two functions
> currentNode and bindNodes


Cool beans!


>
>
> Br's,
> Marius
>
> On Jan 6, 8:37 pm, "David Pollak" 
> wrote:
> > On Tue, Jan 6, 2009 at 10:28 AM, Marius  wrote:
> >
> > > On Jan 6, 7:15 pm, "David Pollak" 
> > > wrote:
> > > > I also added
> > > > BindHelpers.attr("tag"): Option[NodeSeq]
> > > > so you can do something like:
> >
> > > > ...
> >
> > > > and:
> > > > BindHelpers.attr("prefix", "tag")
> >
> > > I think it is committed to curAttr which personally I'm not a fan ...
> > > Doyou mind if I change it to attr or nodeAttr ?
> >
> > Go for it.
> >
> >
> >
> > > > Thanks,
> >
> > > > David
> >
> > > > On Tue, Jan 6, 2009 at 9:13 AM, Marius 
> wrote:
> >
> > > > > Very cool Dave !
> >
> > > > > thx,
> > > > > Marius
> >
> > > > > On Jan 6, 4:36 pm, "David Pollak" 
> > > > > wrote:
> > > > > > Folks,
> >
> > > > > > I'm about to commit up a non-breaking solution.
> >
> > > > > > In bind, you can call:
> > > > > > BindHelpers.bindNodes.value: List[NodeSeq]
> > > > > > BindHelpers.currentNode.value: Elem
> >
> > > > > > bindNodes is a list of the nodes that were passed into bind with
> the
> > > more
> > > > > > current node at the head of the list.  If you're doing
> hierarchical
> > > > > binding,
> > > > > > you can see all the nodes that were passed into bind this was.
> >
> > > > > > currentNode is available to the BindParam and it contains the
> parent
> > > Elem
> > > > > to
> > > > > > the NodeSeq that was passed into your BindParam.  You can inspect
> > > > > attributes
> > > > > > to your heart's content.
> >
> > > > > > Give it an hour or two for these changes to make their way
> through
> > > > > Hudson.
> >
> > > > > > Thanks,
> >
> > > > > > David
> >
> > > > > > On Tue, Jan 6, 2009 at 4:50 AM, Marc Boschma
> > > > > >  <
> marc%2blift...@boschma.cx > <
> > > marc%2blift...@boschma.cx  <
> marc%252blift...@boschma.cx >><
> > > > > marc%2blift...@boschma.cx  <
> marc%252blift...@boschma.cx > <
> > > marc%252blift...@boschma.cx  <
> marc%25252blift...@boschma.cx >>>
> >
> > > > > > > wrote:
> >
> > > > > > > I've just had a thought as to how to make it not a breaking
> change.
> >
> > > > > > > Leave your change "calcValue(s.child) I just call calcValue(s)"
> >
> > > > > > > change:
> > > > > > >   case class FuncBindParam(name: String, value: NodeSeq =>
> NodeSeq)
> > > > > > > extends Tuple2(name, value) with BindParam {
> > > > > > > def calcValue(in: NodeSeq): NodeSeq = value(in)
> > > > > > >   }
> >
> > > > > > > to:
> > > > > > >   case class FuncBindParam(name: String, value: NodeSeq =>
> NodeSeq)
> > > > > > > extends Tuple2(name, value) with BindParam {
> > > > > > > def calcValue(in: NodeSeq): NodeSeq = value(in.child)
> > > > > > >   }
> >
> > > > > > > That should prevent old code breaking... which would be a good
> > > > > > > thing(tm) given the amount of code that uses bind(...)
> >
> > > > > > > then create something like:
> >
> > > > > > >   case class FuncMetaDataBindParam(name: String, value:
> (MetaData,
> > > > > > > NodeSeq) => NodeSeq) extends Tuple2(name, value) with BindParam
> {
> > > > > > > def calcValue(in: NodeSeq): NodeSeq = value(in.attributes,
> > > > > > > in.child)
> > > > > > >   }
> >
> > > > > > > along with adding to class SuperArrowAssoc...
> > > > > > >   def ->(in: (MetaData, NodeSeq) => NodeSeq) =
> > > > > > > FuncMetaDataBindParam(name, in)
> >
> > > > > > > That would be fairly clean...
> >
> > > > > > > -
> >
> > > > > > > Maybe for those that actually want the full node add:
> >
> > > > > > >   case class FuncBoxBindParam(name: String, value: Box(NodeSeq)
> =>
> > > > > > > NodeSeq) extends Tuple2(name, value) with BindParam {
> > > > > > > def calcValue(in: NodeSeq): NodeSeq = value(Full(in))
> > > > > > >   }
> >
> > > > > > > and you could go nuts and:
> >
> > > > > > >   case class FuncPrefixAndLabelBindParam(name: String, value:
> > > > > > > (String, String, NodeSeq) => NodeSeq) extends Tuple2(name,
> value)
> > > with
> > > > > > > BindParam {
> > > > > > > def calcValue(in: NodeSeq): NodeSeq = value(in.prefix,
> > > in.label,
> > > > > > > in.child)
> > > > > > >   }
> >
> > > > > > > etc...
> >
> > > > > > > On 06/01/2009, at 10:51 PM, Marc Boschma wrote:
> >
> > > > > > > > (you can tel I'm sleeping well :/ - too hot)
> >
> > > > > > > > The toList function is one of David's (todo example app). I
> do
> > > love
> > > > > > > > the ability to curry :)
> >
> > > > > > > > Marc
> > > > > > > > On 06/01/2009, at 9:51 PM, Marius wrote:
> >
> > > > > > > >> On Jan 6, 12:47 pm, Marc Boschma 
> > > > > > > >> 
> >
> > >  <
> marc%252blift...@boschma.cx >>
> > > > >  <
> marc%252blift...@boschma.cx > <
> > > marc%252blift...@boschma.cx  <
> marc%25252blift...@boschma.cx 
> > > > > > > wrote:
> > > > > > > >>> A quick just be

[Lift] Re: accessing the attributes of the XML node associated with a FuncBindParam in bind(...)

[Marius]

Ok ... i just committed some changes:

1. Renamed curAttr to attr
2. The BindHelpers vals are now private but we expose two functions
currentNode and bindNodes

Br's,
Marius

On Jan 6, 8:37 pm, "David Pollak" 
wrote:
> On Tue, Jan 6, 2009 at 10:28 AM, Marius  wrote:
>
> > On Jan 6, 7:15 pm, "David Pollak" 
> > wrote:
> > > I also added
> > > BindHelpers.attr("tag"): Option[NodeSeq]
> > > so you can do something like:
>
> > > ...
>
> > > and:
> > > BindHelpers.attr("prefix", "tag")
>
> > I think it is committed to curAttr which personally I'm not a fan ...
> > Doyou mind if I change it to attr or nodeAttr ?
>
> Go for it.
>
>
>
> > > Thanks,
>
> > > David
>
> > > On Tue, Jan 6, 2009 at 9:13 AM, Marius  wrote:
>
> > > > Very cool Dave !
>
> > > > thx,
> > > > Marius
>
> > > > On Jan 6, 4:36 pm, "David Pollak" 
> > > > wrote:
> > > > > Folks,
>
> > > > > I'm about to commit up a non-breaking solution.
>
> > > > > In bind, you can call:
> > > > > BindHelpers.bindNodes.value: List[NodeSeq]
> > > > > BindHelpers.currentNode.value: Elem
>
> > > > > bindNodes is a list of the nodes that were passed into bind with the
> > more
> > > > > current node at the head of the list.  If you're doing hierarchical
> > > > binding,
> > > > > you can see all the nodes that were passed into bind this was.
>
> > > > > currentNode is available to the BindParam and it contains the parent
> > Elem
> > > > to
> > > > > the NodeSeq that was passed into your BindParam.  You can inspect
> > > > attributes
> > > > > to your heart's content.
>
> > > > > Give it an hour or two for these changes to make their way through
> > > > Hudson.
>
> > > > > Thanks,
>
> > > > > David
>
> > > > > On Tue, Jan 6, 2009 at 4:50 AM, Marc Boschma
> > > > >  <
> > marc%2blift...@boschma.cx ><
> > > > marc%2blift...@boschma.cx  <
> > marc%252blift...@boschma.cx >>
>
> > > > > > wrote:
>
> > > > > > I've just had a thought as to how to make it not a breaking change.
>
> > > > > > Leave your change "calcValue(s.child) I just call calcValue(s)"
>
> > > > > > change:
> > > > > >   case class FuncBindParam(name: String, value: NodeSeq => NodeSeq)
> > > > > > extends Tuple2(name, value) with BindParam {
> > > > > >     def calcValue(in: NodeSeq): NodeSeq = value(in)
> > > > > >   }
>
> > > > > > to:
> > > > > >   case class FuncBindParam(name: String, value: NodeSeq => NodeSeq)
> > > > > > extends Tuple2(name, value) with BindParam {
> > > > > >     def calcValue(in: NodeSeq): NodeSeq = value(in.child)
> > > > > >   }
>
> > > > > > That should prevent old code breaking... which would be a good
> > > > > > thing(tm) given the amount of code that uses bind(...)
>
> > > > > > then create something like:
>
> > > > > >   case class FuncMetaDataBindParam(name: String, value: (MetaData,
> > > > > > NodeSeq) => NodeSeq) extends Tuple2(name, value) with BindParam {
> > > > > >     def calcValue(in: NodeSeq): NodeSeq = value(in.attributes,
> > > > > > in.child)
> > > > > >   }
>
> > > > > > along with adding to class SuperArrowAssoc...
> > > > > >   def ->(in: (MetaData, NodeSeq) => NodeSeq) =
> > > > > > FuncMetaDataBindParam(name, in)
>
> > > > > > That would be fairly clean...
>
> > > > > > -
>
> > > > > > Maybe for those that actually want the full node add:
>
> > > > > >   case class FuncBoxBindParam(name: String, value: Box(NodeSeq) =>
> > > > > > NodeSeq) extends Tuple2(name, value) with BindParam {
> > > > > >     def calcValue(in: NodeSeq): NodeSeq = value(Full(in))
> > > > > >   }
>
> > > > > > and you could go nuts and:
>
> > > > > >   case class FuncPrefixAndLabelBindParam(name: String, value:
> > > > > > (String, String, NodeSeq) => NodeSeq) extends Tuple2(name, value)
> > with
> > > > > > BindParam {
> > > > > >     def calcValue(in: NodeSeq): NodeSeq = value(in.prefix,
> > in.label,
> > > > > > in.child)
> > > > > >   }
>
> > > > > > etc...
>
> > > > > > On 06/01/2009, at 10:51 PM, Marc Boschma wrote:
>
> > > > > > > (you can tel I'm sleeping well :/ - too hot)
>
> > > > > > > The toList function is one of David's (todo example app). I do
> > love
> > > > > > > the ability to curry :)
>
> > > > > > > Marc
> > > > > > > On 06/01/2009, at 9:51 PM, Marius wrote:
>
> > > > > > >> On Jan 6, 12:47 pm, Marc Boschma 
> > > > > > >> 
> > >
> > > >  <
> > marc%252blift...@boschma.cx >>>
> > > > > > wrote:
> > > > > > >>> A quick just before going to bed reaction is that your change
> > would
> > > > > > >>> solve the issue.
>
> > > > > > >> Yeah it would ... (I mean it worked fine in my tests)
>
> > > > > > >>> It is interesting you focused on the "exclude" and not the
> > > > > > >>> "list" (which is what I have been playing with). I actually
> > missed
> > > > > > >>> it
> > > > > > >>> was a similar case...
>
> > > > > > >> I just picked it randomly :) ... I've seen that you're using a
> > > > > > >> partially applied function doList ... (which I assume it is a
> > > > curried
> > > > > > >> function):)
>
> > > > > > >>> Regards,
>
> > > > > > >>> Marc
>
> > > >

[Lift] Re: accessing the attributes of the XML node associated with a FuncBindParam in bind(...)

[David Pollak]

On Tue, Jan 6, 2009 at 10:28 AM, Marius  wrote:

>
>
>
> On Jan 6, 7:15 pm, "David Pollak" 
> wrote:
> > I also added
> > BindHelpers.attr("tag"): Option[NodeSeq]
> > so you can do something like:
> >
> > ...
> >
> > and:
> > BindHelpers.attr("prefix", "tag")
>
> I think it is committed to curAttr which personally I'm not a fan ...
> Doyou mind if I change it to attr or nodeAttr ?


Go for it.


>
>
> >
> > Thanks,
> >
> > David
> >
> > On Tue, Jan 6, 2009 at 9:13 AM, Marius  wrote:
> >
> > > Very cool Dave !
> >
> > > thx,
> > > Marius
> >
> > > On Jan 6, 4:36 pm, "David Pollak" 
> > > wrote:
> > > > Folks,
> >
> > > > I'm about to commit up a non-breaking solution.
> >
> > > > In bind, you can call:
> > > > BindHelpers.bindNodes.value: List[NodeSeq]
> > > > BindHelpers.currentNode.value: Elem
> >
> > > > bindNodes is a list of the nodes that were passed into bind with the
> more
> > > > current node at the head of the list.  If you're doing hierarchical
> > > binding,
> > > > you can see all the nodes that were passed into bind this was.
> >
> > > > currentNode is available to the BindParam and it contains the parent
> Elem
> > > to
> > > > the NodeSeq that was passed into your BindParam.  You can inspect
> > > attributes
> > > > to your heart's content.
> >
> > > > Give it an hour or two for these changes to make their way through
> > > Hudson.
> >
> > > > Thanks,
> >
> > > > David
> >
> > > > On Tue, Jan 6, 2009 at 4:50 AM, Marc Boschma
> > > >  <
> marc%2blift...@boschma.cx ><
> > > marc%2blift...@boschma.cx  <
> marc%252blift...@boschma.cx >>
> >
> > > > > wrote:
> >
> > > > > I've just had a thought as to how to make it not a breaking change.
> >
> > > > > Leave your change "calcValue(s.child) I just call calcValue(s)"
> >
> > > > > change:
> > > > >   case class FuncBindParam(name: String, value: NodeSeq => NodeSeq)
> > > > > extends Tuple2(name, value) with BindParam {
> > > > > def calcValue(in: NodeSeq): NodeSeq = value(in)
> > > > >   }
> >
> > > > > to:
> > > > >   case class FuncBindParam(name: String, value: NodeSeq => NodeSeq)
> > > > > extends Tuple2(name, value) with BindParam {
> > > > > def calcValue(in: NodeSeq): NodeSeq = value(in.child)
> > > > >   }
> >
> > > > > That should prevent old code breaking... which would be a good
> > > > > thing(tm) given the amount of code that uses bind(...)
> >
> > > > > then create something like:
> >
> > > > >   case class FuncMetaDataBindParam(name: String, value: (MetaData,
> > > > > NodeSeq) => NodeSeq) extends Tuple2(name, value) with BindParam {
> > > > > def calcValue(in: NodeSeq): NodeSeq = value(in.attributes,
> > > > > in.child)
> > > > >   }
> >
> > > > > along with adding to class SuperArrowAssoc...
> > > > >   def ->(in: (MetaData, NodeSeq) => NodeSeq) =
> > > > > FuncMetaDataBindParam(name, in)
> >
> > > > > That would be fairly clean...
> >
> > > > > -
> >
> > > > > Maybe for those that actually want the full node add:
> >
> > > > >   case class FuncBoxBindParam(name: String, value: Box(NodeSeq) =>
> > > > > NodeSeq) extends Tuple2(name, value) with BindParam {
> > > > > def calcValue(in: NodeSeq): NodeSeq = value(Full(in))
> > > > >   }
> >
> > > > > and you could go nuts and:
> >
> > > > >   case class FuncPrefixAndLabelBindParam(name: String, value:
> > > > > (String, String, NodeSeq) => NodeSeq) extends Tuple2(name, value)
> with
> > > > > BindParam {
> > > > > def calcValue(in: NodeSeq): NodeSeq = value(in.prefix,
> in.label,
> > > > > in.child)
> > > > >   }
> >
> > > > > etc...
> >
> > > > > On 06/01/2009, at 10:51 PM, Marc Boschma wrote:
> >
> > > > > > (you can tel I'm sleeping well :/ - too hot)
> >
> > > > > > The toList function is one of David's (todo example app). I do
> love
> > > > > > the ability to curry :)
> >
> > > > > > Marc
> > > > > > On 06/01/2009, at 9:51 PM, Marius wrote:
> >
> > > > > >> On Jan 6, 12:47 pm, Marc Boschma 
> > > > > >> 
> >
> > >  <
> marc%252blift...@boschma.cx >>>
> > > > > wrote:
> > > > > >>> A quick just before going to bed reaction is that your change
> would
> > > > > >>> solve the issue.
> >
> > > > > >> Yeah it would ... (I mean it worked fine in my tests)
> >
> > > > > >>> It is interesting you focused on the "exclude" and not the
> > > > > >>> "list" (which is what I have been playing with). I actually
> missed
> > > > > >>> it
> > > > > >>> was a similar case...
> >
> > > > > >> I just picked it randomly :) ... I've seen that you're using a
> > > > > >> partially applied function doList ... (which I assume it is a
> > > curried
> > > > > >> function):)
> >
> > > > > >>> Regards,
> >
> > > > > >>> Marc
> >
> > > > > >>> On 06/01/2009, at 9:24 PM, Marius wrote:
> >
> > > > >  I just did a minor modification to the lift code so the actual
> > > > >  node it
> > > > >  is passed to the BindParam and not its child. Now having:
> >
> > > > >  bind("todo", html,
> > > > > "exclude" ->  {node:NodeSeq =>ajaxCheckbox
> > > > > >>

[Lift] Re: accessing the attributes of the XML node associated with a FuncBindParam in bind(...)

[Marius]

On Jan 6, 7:15 pm, "David Pollak" 
wrote:
> I also added
> BindHelpers.attr("tag"): Option[NodeSeq]
> so you can do something like:
>
> ...
>
> and:
> BindHelpers.attr("prefix", "tag")

I think it is committed to curAttr which personally I'm not a fan ...
Doyou mind if I change it to attr or nodeAttr ?

>
> Thanks,
>
> David
>
> On Tue, Jan 6, 2009 at 9:13 AM, Marius  wrote:
>
> > Very cool Dave !
>
> > thx,
> > Marius
>
> > On Jan 6, 4:36 pm, "David Pollak" 
> > wrote:
> > > Folks,
>
> > > I'm about to commit up a non-breaking solution.
>
> > > In bind, you can call:
> > > BindHelpers.bindNodes.value: List[NodeSeq]
> > > BindHelpers.currentNode.value: Elem
>
> > > bindNodes is a list of the nodes that were passed into bind with the more
> > > current node at the head of the list.  If you're doing hierarchical
> > binding,
> > > you can see all the nodes that were passed into bind this was.
>
> > > currentNode is available to the BindParam and it contains the parent Elem
> > to
> > > the NodeSeq that was passed into your BindParam.  You can inspect
> > attributes
> > > to your heart's content.
>
> > > Give it an hour or two for these changes to make their way through
> > Hudson.
>
> > > Thanks,
>
> > > David
>
> > > On Tue, Jan 6, 2009 at 4:50 AM, Marc Boschma
> > > <
> > marc%2blift...@boschma.cx >
>
> > > > wrote:
>
> > > > I've just had a thought as to how to make it not a breaking change.
>
> > > > Leave your change "calcValue(s.child) I just call calcValue(s)"
>
> > > > change:
> > > >   case class FuncBindParam(name: String, value: NodeSeq => NodeSeq)
> > > > extends Tuple2(name, value) with BindParam {
> > > >     def calcValue(in: NodeSeq): NodeSeq = value(in)
> > > >   }
>
> > > > to:
> > > >   case class FuncBindParam(name: String, value: NodeSeq => NodeSeq)
> > > > extends Tuple2(name, value) with BindParam {
> > > >     def calcValue(in: NodeSeq): NodeSeq = value(in.child)
> > > >   }
>
> > > > That should prevent old code breaking... which would be a good
> > > > thing(tm) given the amount of code that uses bind(...)
>
> > > > then create something like:
>
> > > >   case class FuncMetaDataBindParam(name: String, value: (MetaData,
> > > > NodeSeq) => NodeSeq) extends Tuple2(name, value) with BindParam {
> > > >     def calcValue(in: NodeSeq): NodeSeq = value(in.attributes,
> > > > in.child)
> > > >   }
>
> > > > along with adding to class SuperArrowAssoc...
> > > >   def ->(in: (MetaData, NodeSeq) => NodeSeq) =
> > > > FuncMetaDataBindParam(name, in)
>
> > > > That would be fairly clean...
>
> > > > -
>
> > > > Maybe for those that actually want the full node add:
>
> > > >   case class FuncBoxBindParam(name: String, value: Box(NodeSeq) =>
> > > > NodeSeq) extends Tuple2(name, value) with BindParam {
> > > >     def calcValue(in: NodeSeq): NodeSeq = value(Full(in))
> > > >   }
>
> > > > and you could go nuts and:
>
> > > >   case class FuncPrefixAndLabelBindParam(name: String, value:
> > > > (String, String, NodeSeq) => NodeSeq) extends Tuple2(name, value) with
> > > > BindParam {
> > > >     def calcValue(in: NodeSeq): NodeSeq = value(in.prefix, in.label,
> > > > in.child)
> > > >   }
>
> > > > etc...
>
> > > > On 06/01/2009, at 10:51 PM, Marc Boschma wrote:
>
> > > > > (you can tel I'm sleeping well :/ - too hot)
>
> > > > > The toList function is one of David's (todo example app). I do love
> > > > > the ability to curry :)
>
> > > > > Marc
> > > > > On 06/01/2009, at 9:51 PM, Marius wrote:
>
> > > > >> On Jan 6, 12:47 pm, Marc Boschma 
> > > > >> 
> > >>
> > > > wrote:
> > > > >>> A quick just before going to bed reaction is that your change would
> > > > >>> solve the issue.
>
> > > > >> Yeah it would ... (I mean it worked fine in my tests)
>
> > > > >>> It is interesting you focused on the "exclude" and not the
> > > > >>> "list" (which is what I have been playing with). I actually missed
> > > > >>> it
> > > > >>> was a similar case...
>
> > > > >> I just picked it randomly :) ... I've seen that you're using a
> > > > >> partially applied function doList ... (which I assume it is a
> > curried
> > > > >> function):)
>
> > > > >>> Regards,
>
> > > > >>> Marc
>
> > > > >>> On 06/01/2009, at 9:24 PM, Marius wrote:
>
> > > >  I just did a minor modification to the lift code so the actual
> > > >  node it
> > > >  is passed to the BindParam and not its child. Now having:
>
> > > >  bind("todo", html,
> > > >                     "exclude" ->  {node:NodeSeq =>ajaxCheckbox
> > > >  (QueryNotDone, v => {QueryNotDone(v); reDraw})}
> > > >  ... )
>
> > > >  and the markup 
>
> > > >  The node parameter to the anonymous function will be the
> > > >   node and not its children. So now you can access
> > the
> > > >  "param" attribute from node. The change was in in_bind function so
> > > >  instead of calling calcValue(s.child) I just call calcValue(s)
>
> > > >  Looking at the existent BindParams this change does not seem to
> > > >  cau

[Lift] Re: accessing the attributes of the XML node associated with a FuncBindParam in bind(...)

[David Pollak]

I also added
BindHelpers.attr("tag"): Option[NodeSeq]
so you can do something like:

...

and:
BindHelpers.attr("prefix", "tag")

Thanks,

David

On Tue, Jan 6, 2009 at 9:13 AM, Marius  wrote:

>
> Very cool Dave !
>
> thx,
> Marius
>
> On Jan 6, 4:36 pm, "David Pollak" 
> wrote:
> > Folks,
> >
> > I'm about to commit up a non-breaking solution.
> >
> > In bind, you can call:
> > BindHelpers.bindNodes.value: List[NodeSeq]
> > BindHelpers.currentNode.value: Elem
> >
> > bindNodes is a list of the nodes that were passed into bind with the more
> > current node at the head of the list.  If you're doing hierarchical
> binding,
> > you can see all the nodes that were passed into bind this was.
> >
> > currentNode is available to the BindParam and it contains the parent Elem
> to
> > the NodeSeq that was passed into your BindParam.  You can inspect
> attributes
> > to your heart's content.
> >
> > Give it an hour or two for these changes to make their way through
> Hudson.
> >
> > Thanks,
> >
> > David
> >
> > On Tue, Jan 6, 2009 at 4:50 AM, Marc Boschma
> > <
> marc%2blift...@boschma.cx >
> >
> >
> >
> > > wrote:
> >
> > > I've just had a thought as to how to make it not a breaking change.
> >
> > > Leave your change "calcValue(s.child) I just call calcValue(s)"
> >
> > > change:
> > >   case class FuncBindParam(name: String, value: NodeSeq => NodeSeq)
> > > extends Tuple2(name, value) with BindParam {
> > > def calcValue(in: NodeSeq): NodeSeq = value(in)
> > >   }
> >
> > > to:
> > >   case class FuncBindParam(name: String, value: NodeSeq => NodeSeq)
> > > extends Tuple2(name, value) with BindParam {
> > > def calcValue(in: NodeSeq): NodeSeq = value(in.child)
> > >   }
> >
> > > That should prevent old code breaking... which would be a good
> > > thing(tm) given the amount of code that uses bind(...)
> >
> > > then create something like:
> >
> > >   case class FuncMetaDataBindParam(name: String, value: (MetaData,
> > > NodeSeq) => NodeSeq) extends Tuple2(name, value) with BindParam {
> > > def calcValue(in: NodeSeq): NodeSeq = value(in.attributes,
> > > in.child)
> > >   }
> >
> > > along with adding to class SuperArrowAssoc...
> > >   def ->(in: (MetaData, NodeSeq) => NodeSeq) =
> > > FuncMetaDataBindParam(name, in)
> >
> > > That would be fairly clean...
> >
> > > -
> >
> > > Maybe for those that actually want the full node add:
> >
> > >   case class FuncBoxBindParam(name: String, value: Box(NodeSeq) =>
> > > NodeSeq) extends Tuple2(name, value) with BindParam {
> > > def calcValue(in: NodeSeq): NodeSeq = value(Full(in))
> > >   }
> >
> > > and you could go nuts and:
> >
> > >   case class FuncPrefixAndLabelBindParam(name: String, value:
> > > (String, String, NodeSeq) => NodeSeq) extends Tuple2(name, value) with
> > > BindParam {
> > > def calcValue(in: NodeSeq): NodeSeq = value(in.prefix, in.label,
> > > in.child)
> > >   }
> >
> > > etc...
> >
> > > On 06/01/2009, at 10:51 PM, Marc Boschma wrote:
> >
> > > > (you can tel I'm sleeping well :/ - too hot)
> >
> > > > The toList function is one of David's (todo example app). I do love
> > > > the ability to curry :)
> >
> > > > Marc
> > > > On 06/01/2009, at 9:51 PM, Marius wrote:
> >
> > > >> On Jan 6, 12:47 pm, Marc Boschma 
> > > >> 
> >>
> > > wrote:
> > > >>> A quick just before going to bed reaction is that your change would
> > > >>> solve the issue.
> >
> > > >> Yeah it would ... (I mean it worked fine in my tests)
> >
> > > >>> It is interesting you focused on the "exclude" and not the
> > > >>> "list" (which is what I have been playing with). I actually missed
> > > >>> it
> > > >>> was a similar case...
> >
> > > >> I just picked it randomly :) ... I've seen that you're using a
> > > >> partially applied function doList ... (which I assume it is a
> curried
> > > >> function):)
> >
> > > >>> Regards,
> >
> > > >>> Marc
> >
> > > >>> On 06/01/2009, at 9:24 PM, Marius wrote:
> >
> > >  I just did a minor modification to the lift code so the actual
> > >  node it
> > >  is passed to the BindParam and not its child. Now having:
> >
> > >  bind("todo", html,
> > > "exclude" ->  {node:NodeSeq =>ajaxCheckbox
> > >  (QueryNotDone, v => {QueryNotDone(v); reDraw})}
> > >  ... )
> >
> > >  and the markup 
> >
> > >  The node parameter to the anonymous function will be the
> > >   node and not its children. So now you can access
> the
> > >  "param" attribute from node. The change was in in_bind function so
> > >  instead of calling calcValue(s.child) I just call calcValue(s)
> >
> > >  Looking at the existent BindParams this change does not seem to
> > >  cause
> > >  side effects since the calcValue 'in' parameter is used only for
> > >  FuncXXXBindParam-s. The impact is that the user's function would
> > >  now
> > >  get the actual node (from which now he can extract attributes) and
> > >  not
> > >  the child nodes. But child nodes 

[Lift] Re: accessing the attributes of the XML node associated with a FuncBindParam in bind(...)

[Marius]

Very cool Dave !

thx,
Marius

On Jan 6, 4:36 pm, "David Pollak" 
wrote:
> Folks,
>
> I'm about to commit up a non-breaking solution.
>
> In bind, you can call:
> BindHelpers.bindNodes.value: List[NodeSeq]
> BindHelpers.currentNode.value: Elem
>
> bindNodes is a list of the nodes that were passed into bind with the more
> current node at the head of the list.  If you're doing hierarchical binding,
> you can see all the nodes that were passed into bind this was.
>
> currentNode is available to the BindParam and it contains the parent Elem to
> the NodeSeq that was passed into your BindParam.  You can inspect attributes
> to your heart's content.
>
> Give it an hour or two for these changes to make their way through Hudson.
>
> Thanks,
>
> David
>
> On Tue, Jan 6, 2009 at 4:50 AM, Marc Boschma
> 
>
>
>
> > wrote:
>
> > I've just had a thought as to how to make it not a breaking change.
>
> > Leave your change "calcValue(s.child) I just call calcValue(s)"
>
> > change:
> >   case class FuncBindParam(name: String, value: NodeSeq => NodeSeq)
> > extends Tuple2(name, value) with BindParam {
> >     def calcValue(in: NodeSeq): NodeSeq = value(in)
> >   }
>
> > to:
> >   case class FuncBindParam(name: String, value: NodeSeq => NodeSeq)
> > extends Tuple2(name, value) with BindParam {
> >     def calcValue(in: NodeSeq): NodeSeq = value(in.child)
> >   }
>
> > That should prevent old code breaking... which would be a good
> > thing(tm) given the amount of code that uses bind(...)
>
> > then create something like:
>
> >   case class FuncMetaDataBindParam(name: String, value: (MetaData,
> > NodeSeq) => NodeSeq) extends Tuple2(name, value) with BindParam {
> >     def calcValue(in: NodeSeq): NodeSeq = value(in.attributes,
> > in.child)
> >   }
>
> > along with adding to class SuperArrowAssoc...
> >   def ->(in: (MetaData, NodeSeq) => NodeSeq) =
> > FuncMetaDataBindParam(name, in)
>
> > That would be fairly clean...
>
> > -
>
> > Maybe for those that actually want the full node add:
>
> >   case class FuncBoxBindParam(name: String, value: Box(NodeSeq) =>
> > NodeSeq) extends Tuple2(name, value) with BindParam {
> >     def calcValue(in: NodeSeq): NodeSeq = value(Full(in))
> >   }
>
> > and you could go nuts and:
>
> >   case class FuncPrefixAndLabelBindParam(name: String, value:
> > (String, String, NodeSeq) => NodeSeq) extends Tuple2(name, value) with
> > BindParam {
> >     def calcValue(in: NodeSeq): NodeSeq = value(in.prefix, in.label,
> > in.child)
> >   }
>
> > etc...
>
> > On 06/01/2009, at 10:51 PM, Marc Boschma wrote:
>
> > > (you can tel I'm sleeping well :/ - too hot)
>
> > > The toList function is one of David's (todo example app). I do love
> > > the ability to curry :)
>
> > > Marc
> > > On 06/01/2009, at 9:51 PM, Marius wrote:
>
> > >> On Jan 6, 12:47 pm, Marc Boschma 
> > >> >
> > wrote:
> > >>> A quick just before going to bed reaction is that your change would
> > >>> solve the issue.
>
> > >> Yeah it would ... (I mean it worked fine in my tests)
>
> > >>> It is interesting you focused on the "exclude" and not the
> > >>> "list" (which is what I have been playing with). I actually missed
> > >>> it
> > >>> was a similar case...
>
> > >> I just picked it randomly :) ... I've seen that you're using a
> > >> partially applied function doList ... (which I assume it is a curried
> > >> function):)
>
> > >>> Regards,
>
> > >>> Marc
>
> > >>> On 06/01/2009, at 9:24 PM, Marius wrote:
>
> >  I just did a minor modification to the lift code so the actual
> >  node it
> >  is passed to the BindParam and not its child. Now having:
>
> >  bind("todo", html,
> >                     "exclude" ->  {node:NodeSeq =>ajaxCheckbox
> >  (QueryNotDone, v => {QueryNotDone(v); reDraw})}
> >  ... )
>
> >  and the markup 
>
> >  The node parameter to the anonymous function will be the
> >   node and not its children. So now you can access the
> >  "param" attribute from node. The change was in in_bind function so
> >  instead of calling calcValue(s.child) I just call calcValue(s)
>
> >  Looking at the existent BindParams this change does not seem to
> >  cause
> >  side effects since the calcValue 'in' parameter is used only for
> >  FuncXXXBindParam-s. The impact is that the user's function would
> >  now
> >  get the actual node (from which now he can extract attributes) and
> >  not
> >  the child nodes. But child nodes from the actual node are trivial
> >  to
> >  obtain.
>
> >  I did not commit this change as I'd like to see other opinions to
> >  see
> >  if there is something that I missed somehow. If we get general
> >  consensus of this change I can commit it right away and announce
> >  it as
> >  a "breaking change".
>
> >  Thoughts?
>
> >  Br's,
> >  Marius
>
> >  On Jan 6, 12:02 pm, Marius  wrote:
> > > A nice alternative would have been :
>
> > > bind("todo", html,
> > >  

[Lift] Re: accessing the attributes of the XML node associated with a FuncBindParam in bind(...)

[David Pollak]

Folks,

I'm about to commit up a non-breaking solution.

In bind, you can call:
BindHelpers.bindNodes.value: List[NodeSeq]
BindHelpers.currentNode.value: Elem

bindNodes is a list of the nodes that were passed into bind with the more
current node at the head of the list.  If you're doing hierarchical binding,
you can see all the nodes that were passed into bind this was.

currentNode is available to the BindParam and it contains the parent Elem to
the NodeSeq that was passed into your BindParam.  You can inspect attributes
to your heart's content.

Give it an hour or two for these changes to make their way through Hudson.

Thanks,

David

On Tue, Jan 6, 2009 at 4:50 AM, Marc Boschma

> wrote:

>
> I've just had a thought as to how to make it not a breaking change.
>
> Leave your change "calcValue(s.child) I just call calcValue(s)"
>
> change:
>   case class FuncBindParam(name: String, value: NodeSeq => NodeSeq)
> extends Tuple2(name, value) with BindParam {
> def calcValue(in: NodeSeq): NodeSeq = value(in)
>   }
>
> to:
>   case class FuncBindParam(name: String, value: NodeSeq => NodeSeq)
> extends Tuple2(name, value) with BindParam {
> def calcValue(in: NodeSeq): NodeSeq = value(in.child)
>   }
>
> That should prevent old code breaking... which would be a good
> thing(tm) given the amount of code that uses bind(...)
>
> then create something like:
>
>   case class FuncMetaDataBindParam(name: String, value: (MetaData,
> NodeSeq) => NodeSeq) extends Tuple2(name, value) with BindParam {
> def calcValue(in: NodeSeq): NodeSeq = value(in.attributes,
> in.child)
>   }
>
> along with adding to class SuperArrowAssoc...
>   def ->(in: (MetaData, NodeSeq) => NodeSeq) =
> FuncMetaDataBindParam(name, in)
>
> That would be fairly clean...
>
> -
>
> Maybe for those that actually want the full node add:
>
>   case class FuncBoxBindParam(name: String, value: Box(NodeSeq) =>
> NodeSeq) extends Tuple2(name, value) with BindParam {
> def calcValue(in: NodeSeq): NodeSeq = value(Full(in))
>   }
>
> and you could go nuts and:
>
>   case class FuncPrefixAndLabelBindParam(name: String, value:
> (String, String, NodeSeq) => NodeSeq) extends Tuple2(name, value) with
> BindParam {
> def calcValue(in: NodeSeq): NodeSeq = value(in.prefix, in.label,
> in.child)
>   }
>
> etc...
>
>
> On 06/01/2009, at 10:51 PM, Marc Boschma wrote:
>
> >
> > (you can tel I'm sleeping well :/ - too hot)
> >
> > The toList function is one of David's (todo example app). I do love
> > the ability to curry :)
> >
> > Marc
> > On 06/01/2009, at 9:51 PM, Marius wrote:
> >
> >>
> >>
> >>
> >> On Jan 6, 12:47 pm, Marc Boschma 
> >> >
> wrote:
> >>> A quick just before going to bed reaction is that your change would
> >>> solve the issue.
> >>
> >> Yeah it would ... (I mean it worked fine in my tests)
> >>
> >>>
> >>> It is interesting you focused on the "exclude" and not the
> >>> "list" (which is what I have been playing with). I actually missed
> >>> it
> >>> was a similar case...
> >>
> >> I just picked it randomly :) ... I've seen that you're using a
> >> partially applied function doList ... (which I assume it is a curried
> >> function):)
> >>
> >>>
> >>> Regards,
> >>>
> >>> Marc
> >>>
> >>> On 06/01/2009, at 9:24 PM, Marius wrote:
> >>>
> >>>
> >>>
>  I just did a minor modification to the lift code so the actual
>  node it
>  is passed to the BindParam and not its child. Now having:
> >>>
>  bind("todo", html,
> "exclude" ->  {node:NodeSeq =>ajaxCheckbox
>  (QueryNotDone, v => {QueryNotDone(v); reDraw})}
>  ... )
> >>>
>  and the markup 
> >>>
>  The node parameter to the anonymous function will be the
>   node and not its children. So now you can access the
>  "param" attribute from node. The change was in in_bind function so
>  instead of calling calcValue(s.child) I just call calcValue(s)
> >>>
>  Looking at the existent BindParams this change does not seem to
>  cause
>  side effects since the calcValue 'in' parameter is used only for
>  FuncXXXBindParam-s. The impact is that the user's function would
>  now
>  get the actual node (from which now he can extract attributes) and
>  not
>  the child nodes. But child nodes from the actual node are trivial
>  to
>  obtain.
> >>>
>  I did not commit this change as I'd like to see other opinions to
>  see
>  if there is something that I missed somehow. If we get general
>  consensus of this change I can commit it right away and announce
>  it as
>  a "breaking change".
> >>>
>  Thoughts?
> >>>
>  Br's,
>  Marius
> >>>
>  On Jan 6, 12:02 pm, Marius  wrote:
> > A nice alternative would have been :
> >>>
> > bind("todo", html,
> > "exclude" ->  {node:NodeSeq =>ajaxCheckbox
> > (QueryNotDone, v => {QueryNotDone(v); reDraw})}
> >  ... )
> >>>
> > But here the node impersonates the childNodes not the

[Lift] Re: accessing the attributes of the XML node associated with a FuncBindParam in bind(...)

[Marius]

On Jan 6, 2:50 pm, Marc Boschma  wrote:
> I've just had a thought as to how to make it not a breaking change.
>
> Leave your change "calcValue(s.child) I just call calcValue(s)"
>
> change:
>    case class FuncBindParam(name: String, value: NodeSeq => NodeSeq)  
> extends Tuple2(name, value) with BindParam {
>      def calcValue(in: NodeSeq): NodeSeq = value(in)
>    }
>
> to:
>    case class FuncBindParam(name: String, value: NodeSeq => NodeSeq)  
> extends Tuple2(name, value) with BindParam {
>      def calcValue(in: NodeSeq): NodeSeq = value(in.child)
>    }
>
> That should prevent old code breaking... which would be a good  
> thing(tm) given the amount of code that uses bind(...)

bind(..) is used a lot but I don't think that many people uses bind
with FuncBindParam though. And I don't think this would be a major
breaking change.

>
> then create something like:
>
>    case class FuncMetaDataBindParam(name: String, value: (MetaData,  
> NodeSeq) => NodeSeq) extends Tuple2(name, value) with BindParam {
>      def calcValue(in: NodeSeq): NodeSeq = value(in.attributes,  
> in.child)
>    }
>
> along with adding to class SuperArrowAssoc...
>    def ->(in: (MetaData, NodeSeq) => NodeSeq) =  
> FuncMetaDataBindParam(name, in)
>
> That would be fairly clean...


It would but personally I prefer the initial proposal of providing the
full node and not just its childs. With this we don't need to add any
more code.

>
> -
>
> Maybe for those that actually want the full node add:
>
>    case class FuncBoxBindParam(name: String, value: Box(NodeSeq) =>  
> NodeSeq) extends Tuple2(name, value) with BindParam {
>      def calcValue(in: NodeSeq): NodeSeq = value(Full(in))
>    }
>
> and you could go nuts and:
>
>    case class FuncPrefixAndLabelBindParam(name: String, value:  
> (String, String, NodeSeq) => NodeSeq) extends Tuple2(name, value) with  
> BindParam {
>      def calcValue(in: NodeSeq): NodeSeq = value(in.prefix, in.label,  
> in.child)
>    }
>
> etc...

Sorry man, I like the initial proposal better as with minimal changes
we achieve quite a lot and no need for new code. However this is just
my preference, maybe DPP and others would like your proposal best so
it will be materializes in git master. But I still vote for simplicity
even if this imply a breaking change but IMHO this is a very minor
breaking change (unless I'm missing something here).

>
> On 06/01/2009, at 10:51 PM, Marc Boschma wrote:
>
>
>
> > (you can tel I'm sleeping well :/ - too hot)
>
> > The toList function is one of David's (todo example app). I do love
> > the ability to curry :)
>
> > Marc
> > On 06/01/2009, at 9:51 PM, Marius wrote:
>
> >> On Jan 6, 12:47 pm, Marc Boschma  wrote:
> >>> A quick just before going to bed reaction is that your change would
> >>> solve the issue.
>
> >> Yeah it would ... (I mean it worked fine in my tests)
>
> >>> It is interesting you focused on the "exclude" and not the
> >>> "list" (which is what I have been playing with). I actually missed  
> >>> it
> >>> was a similar case...
>
> >> I just picked it randomly :) ... I've seen that you're using a
> >> partially applied function doList ... (which I assume it is a curried
> >> function):)
>
> >>> Regards,
>
> >>> Marc
>
> >>> On 06/01/2009, at 9:24 PM, Marius wrote:
>
>  I just did a minor modification to the lift code so the actual
>  node it
>  is passed to the BindParam and not its child. Now having:
>
>  bind("todo", html,
>                     "exclude" ->  {node:NodeSeq =>ajaxCheckbox
>  (QueryNotDone, v => {QueryNotDone(v); reDraw})}
>  ... )
>
>  and the markup 
>
>  The node parameter to the anonymous function will be the
>   node and not its children. So now you can access the
>  "param" attribute from node. The change was in in_bind function so
>  instead of calling calcValue(s.child) I just call calcValue(s)
>
>  Looking at the existent BindParams this change does not seem to
>  cause
>  side effects since the calcValue 'in' parameter is used only for
>  FuncXXXBindParam-s. The impact is that the user's function would  
>  now
>  get the actual node (from which now he can extract attributes) and
>  not
>  the child nodes. But child nodes from the actual node are trivial  
>  to
>  obtain.
>
>  I did not commit this change as I'd like to see other opinions to
>  see
>  if there is something that I missed somehow. If we get general
>  consensus of this change I can commit it right away and announce
>  it as
>  a "breaking change".
>
>  Thoughts?
>
>  Br's,
>  Marius
>
>  On Jan 6, 12:02 pm, Marius  wrote:
> > A nice alternative would have been :
>
> > bind("todo", html,
> >                     "exclude" ->  {node:NodeSeq =>ajaxCheckbox
> > (QueryNotDone, v => {QueryNotDone(v); reDraw})}
> >  ... )
>
> > But here the node impersonates the childNodes not the original
> > node.
> >>>

[Lift] Re: accessing the attributes of the XML node associated with a FuncBindParam in bind(...)

[Marc Boschma]

I've just had a thought as to how to make it not a breaking change.

Leave your change "calcValue(s.child) I just call calcValue(s)"

change:
   case class FuncBindParam(name: String, value: NodeSeq => NodeSeq)  
extends Tuple2(name, value) with BindParam {
 def calcValue(in: NodeSeq): NodeSeq = value(in)
   }

to:
   case class FuncBindParam(name: String, value: NodeSeq => NodeSeq)  
extends Tuple2(name, value) with BindParam {
 def calcValue(in: NodeSeq): NodeSeq = value(in.child)
   }

That should prevent old code breaking... which would be a good  
thing(tm) given the amount of code that uses bind(...)

then create something like:

   case class FuncMetaDataBindParam(name: String, value: (MetaData,  
NodeSeq) => NodeSeq) extends Tuple2(name, value) with BindParam {
 def calcValue(in: NodeSeq): NodeSeq = value(in.attributes,  
in.child)
   }

along with adding to class SuperArrowAssoc...
   def ->(in: (MetaData, NodeSeq) => NodeSeq) =  
FuncMetaDataBindParam(name, in)

That would be fairly clean...

-

Maybe for those that actually want the full node add:

   case class FuncBoxBindParam(name: String, value: Box(NodeSeq) =>  
NodeSeq) extends Tuple2(name, value) with BindParam {
 def calcValue(in: NodeSeq): NodeSeq = value(Full(in))
   }

and you could go nuts and:

   case class FuncPrefixAndLabelBindParam(name: String, value:  
(String, String, NodeSeq) => NodeSeq) extends Tuple2(name, value) with  
BindParam {
 def calcValue(in: NodeSeq): NodeSeq = value(in.prefix, in.label,  
in.child)
   }

etc...


On 06/01/2009, at 10:51 PM, Marc Boschma wrote:

>
> (you can tel I'm sleeping well :/ - too hot)
>
> The toList function is one of David's (todo example app). I do love
> the ability to curry :)
>
> Marc
> On 06/01/2009, at 9:51 PM, Marius wrote:
>
>>
>>
>>
>> On Jan 6, 12:47 pm, Marc Boschma  wrote:
>>> A quick just before going to bed reaction is that your change would
>>> solve the issue.
>>
>> Yeah it would ... (I mean it worked fine in my tests)
>>
>>>
>>> It is interesting you focused on the "exclude" and not the
>>> "list" (which is what I have been playing with). I actually missed  
>>> it
>>> was a similar case...
>>
>> I just picked it randomly :) ... I've seen that you're using a
>> partially applied function doList ... (which I assume it is a curried
>> function):)
>>
>>>
>>> Regards,
>>>
>>> Marc
>>>
>>> On 06/01/2009, at 9:24 PM, Marius wrote:
>>>
>>>
>>>
 I just did a minor modification to the lift code so the actual
 node it
 is passed to the BindParam and not its child. Now having:
>>>
 bind("todo", html,
"exclude" ->  {node:NodeSeq =>ajaxCheckbox
 (QueryNotDone, v => {QueryNotDone(v); reDraw})}
 ... )
>>>
 and the markup 
>>>
 The node parameter to the anonymous function will be the
  node and not its children. So now you can access the
 "param" attribute from node. The change was in in_bind function so
 instead of calling calcValue(s.child) I just call calcValue(s)
>>>
 Looking at the existent BindParams this change does not seem to
 cause
 side effects since the calcValue 'in' parameter is used only for
 FuncXXXBindParam-s. The impact is that the user's function would  
 now
 get the actual node (from which now he can extract attributes) and
 not
 the child nodes. But child nodes from the actual node are trivial  
 to
 obtain.
>>>
 I did not commit this change as I'd like to see other opinions to
 see
 if there is something that I missed somehow. If we get general
 consensus of this change I can commit it right away and announce
 it as
 a "breaking change".
>>>
 Thoughts?
>>>
 Br's,
 Marius
>>>
 On Jan 6, 12:02 pm, Marius  wrote:
> A nice alternative would have been :
>>>
> bind("todo", html,
> "exclude" ->  {node:NodeSeq =>ajaxCheckbox
> (QueryNotDone, v => {QueryNotDone(v); reDraw})}
>  ... )
>>>
> But here the node impersonates the childNodes not the original
> node.
> So you still can not access the param attribute below
>>>
> 
>>>
> but you can do it like:
>>>
> 
>>>
> and you have full access to the meta node as it is a child of
> todo:exclude. Hence you can pass state.
>>>
> I know, it is not ideal but should be workable until snippet  
> child-
> node attributes are exposed in one way or another.
>>>
> Br's,
> Marius
>>>
> Marc Boschma wrote:
>> I have been playing with the ToDo example application and having
>> fun
>> in manipulating XML.
>>>
>> With the  node I thought it would be good if the  
>> XHTML
>> designer could pass in some guidance to the doList(...) method
>> used in
>> bind(..). ie. ...
>>>
>> Looking over the bind code I noticed that the attributes are not
>> accessible without ending up changing the calcValue method's
>> signature. I did initially try 

[Lift] Re: accessing the attributes of the XML node associated with a FuncBindParam in bind(...)

[Marc Boschma]

(you can tel I'm sleeping well :/ - too hot)

The toList function is one of David's (todo example app). I do love  
the ability to curry :)

Marc
On 06/01/2009, at 9:51 PM, Marius wrote:

>
>
>
> On Jan 6, 12:47 pm, Marc Boschma  wrote:
>> A quick just before going to bed reaction is that your change would
>> solve the issue.
>
> Yeah it would ... (I mean it worked fine in my tests)
>
>>
>> It is interesting you focused on the "exclude" and not the
>> "list" (which is what I have been playing with). I actually missed it
>> was a similar case...
>
> I just picked it randomly :) ... I've seen that you're using a
> partially applied function doList ... (which I assume it is a curried
> function):)
>
>>
>> Regards,
>>
>> Marc
>>
>> On 06/01/2009, at 9:24 PM, Marius wrote:
>>
>>
>>
>>> I just did a minor modification to the lift code so the actual  
>>> node it
>>> is passed to the BindParam and not its child. Now having:
>>
>>> bind("todo", html,
>>> "exclude" ->  {node:NodeSeq =>ajaxCheckbox
>>> (QueryNotDone, v => {QueryNotDone(v); reDraw})}
>>>  ... )
>>
>>> and the markup 
>>
>>> The node parameter to the anonymous function will be the
>>>  node and not its children. So now you can access the
>>> "param" attribute from node. The change was in in_bind function so
>>> instead of calling calcValue(s.child) I just call calcValue(s)
>>
>>> Looking at the existent BindParams this change does not seem to  
>>> cause
>>> side effects since the calcValue 'in' parameter is used only for
>>> FuncXXXBindParam-s. The impact is that the user's function would now
>>> get the actual node (from which now he can extract attributes) and  
>>> not
>>> the child nodes. But child nodes from the actual node are trivial to
>>> obtain.
>>
>>> I did not commit this change as I'd like to see other opinions to  
>>> see
>>> if there is something that I missed somehow. If we get general
>>> consensus of this change I can commit it right away and announce  
>>> it as
>>> a "breaking change".
>>
>>> Thoughts?
>>
>>> Br's,
>>> Marius
>>
>>> On Jan 6, 12:02 pm, Marius  wrote:
 A nice alternative would have been :
>>
  bind("todo", html,
  "exclude" ->  {node:NodeSeq =>ajaxCheckbox
 (QueryNotDone, v => {QueryNotDone(v); reDraw})}
   ... )
>>
 But here the node impersonates the childNodes not the original  
 node.
 So you still can not access the param attribute below
>>
 
>>
 but you can do it like:
>>
 
>>
 and you have full access to the meta node as it is a child of
 todo:exclude. Hence you can pass state.
>>
 I know, it is not ideal but should be workable until snippet child-
 node attributes are exposed in one way or another.
>>
 Br's,
 Marius
>>
 Marc Boschma wrote:
> I have been playing with the ToDo example application and having  
> fun
> in manipulating XML.
>>
> With the  node I thought it would be good if the XHTML
> designer could pass in some guidance to the doList(...) method
> used in
> bind(..). ie. ...
>>
> Looking over the bind code I noticed that the attributes are not
> accessible without ending up changing the calcValue method's
> signature. I did initially try to knock up a
>>
>case class FuncWithAttrBindParam(name: String, value: (NodeSeq,
> MetaData) => NodeSeq) extends Tuple2(name, value) with BindParam
>>
> and a corresponding
>>
>case Some(ns : FuncWithAttrBindParam) =>
>>
> in in_bind(...), but it all looks like a huge kludge.
>>
> It strikes me as a little deficient to be able to utilise  
> attributes
> within the context of a snippet and yet not within a bind. I know
> bind
> is quite embedded in lift now, but I think that this difference
> might
> prove a little frustrating. I know one solution is to just  
> create a
> bind("todo", html,
>  "exclude" ->
> ajaxCheckbox(QueryNotDone, v => {QueryNotDone(v); reDraw}),
>  "list" -> doList(reDraw, false)  
> _,
>"list_singular" -> doList(reDraw, true)
> _)
>>
> But I think from the XHtml designer's perspective that is counter
> intuitive...
>>
> Thoughts?
>>
> --
>>
> It should be noted that this is different to the case class
> FuncAttrBindParam(name: String, value: NodeSeq => NodeSeq,  
> newAttr:
> String) extends BindParam with BindWithAttr. Which interesting
> enough
> has no corresponding SuperArrowAssoc -> method match. Maybe
>>
>def ->(t: Tuple2[String, NodeSeq]) = AttrBindParam(name, t._2,
> t._1)
>def ->(t: Tuple2[String, NodeSeq => NodeSeq]) =
> FuncAttrBindParam(name, t._2, t._1)
>>
> And maybe even...
>>
>def ->[T](t: Tuple2[String, T]) = FuncAttrBindParam(name, (name
> ->
> t._2).calcValue _, t._1)
>>
> or
>>
>def ->[T](t: 

[Lift] Re: accessing the attributes of the XML node associated with a FuncBindParam in bind(...)

[Marius]

On Jan 6, 12:47 pm, Marc Boschma  wrote:
> A quick just before going to bed reaction is that your change would  
> solve the issue.

Yeah it would ... (I mean it worked fine in my tests)

>
> It is interesting you focused on the "exclude" and not the  
> "list" (which is what I have been playing with). I actually missed it  
> was a similar case...

I just picked it randomly :) ... I've seen that you're using a
partially applied function doList ... (which I assume it is a curried
function):)

>
> Regards,
>
> Marc
>
> On 06/01/2009, at 9:24 PM, Marius wrote:
>
>
>
> > I just did a minor modification to the lift code so the actual node it
> > is passed to the BindParam and not its child. Now having:
>
> > bind("todo", html,
> >                     "exclude" ->  {node:NodeSeq =>ajaxCheckbox
> > (QueryNotDone, v => {QueryNotDone(v); reDraw})}
> >  ... )
>
> > and the markup 
>
> > The node parameter to the anonymous function will be the
> >  node and not its children. So now you can access the
> > "param" attribute from node. The change was in in_bind function so
> > instead of calling calcValue(s.child) I just call calcValue(s)
>
> > Looking at the existent BindParams this change does not seem to cause
> > side effects since the calcValue 'in' parameter is used only for
> > FuncXXXBindParam-s. The impact is that the user's function would now
> > get the actual node (from which now he can extract attributes) and not
> > the child nodes. But child nodes from the actual node are trivial to
> > obtain.
>
> > I did not commit this change as I'd like to see other opinions to see
> > if there is something that I missed somehow. If we get general
> > consensus of this change I can commit it right away and announce it as
> > a "breaking change".
>
> > Thoughts?
>
> > Br's,
> > Marius
>
> > On Jan 6, 12:02 pm, Marius  wrote:
> >> A nice alternative would have been :
>
> >>  bind("todo", html,
> >>                      "exclude" ->  {node:NodeSeq =>ajaxCheckbox
> >> (QueryNotDone, v => {QueryNotDone(v); reDraw})}
> >>   ... )
>
> >> But here the node impersonates the childNodes not the original node.
> >> So you still can not access the param attribute below
>
> >> 
>
> >> but you can do it like:
>
> >> 
>
> >> and you have full access to the meta node as it is a child of
> >> todo:exclude. Hence you can pass state.
>
> >> I know, it is not ideal but should be workable until snippet child-
> >> node attributes are exposed in one way or another.
>
> >> Br's,
> >> Marius
>
> >> Marc Boschma wrote:
> >>> I have been playing with the ToDo example application and having fun
> >>> in manipulating XML.
>
> >>> With the  node I thought it would be good if the XHTML
> >>> designer could pass in some guidance to the doList(...) method  
> >>> used in
> >>> bind(..). ie. ...
>
> >>> Looking over the bind code I noticed that the attributes are not
> >>> accessible without ending up changing the calcValue method's
> >>> signature. I did initially try to knock up a
>
> >>>    case class FuncWithAttrBindParam(name: String, value: (NodeSeq,
> >>> MetaData) => NodeSeq) extends Tuple2(name, value) with BindParam
>
> >>> and a corresponding
>
> >>>    case Some(ns : FuncWithAttrBindParam) =>
>
> >>> in in_bind(...), but it all looks like a huge kludge.
>
> >>> It strikes me as a little deficient to be able to utilise attributes
> >>> within the context of a snippet and yet not within a bind. I know  
> >>> bind
> >>> is quite embedded in lift now, but I think that this difference  
> >>> might
> >>> prove a little frustrating. I know one solution is to just create a
> >>> bind("todo", html,
> >>>                                  "exclude" ->
> >>> ajaxCheckbox(QueryNotDone, v => {QueryNotDone(v); reDraw}),
> >>>                                  "list" -> doList(reDraw, false) _,
> >>>                            "list_singular" -> doList(reDraw, true)  
> >>> _)
>
> >>> But I think from the XHtml designer's perspective that is counter
> >>> intuitive...
>
> >>> Thoughts?
>
> >>> --
>
> >>> It should be noted that this is different to the case class
> >>> FuncAttrBindParam(name: String, value: NodeSeq => NodeSeq, newAttr:
> >>> String) extends BindParam with BindWithAttr. Which interesting  
> >>> enough
> >>> has no corresponding SuperArrowAssoc -> method match. Maybe
>
> >>>    def ->(t: Tuple2[String, NodeSeq]) = AttrBindParam(name, t._2,  
> >>> t._1)
> >>>    def ->(t: Tuple2[String, NodeSeq => NodeSeq]) =
> >>> FuncAttrBindParam(name, t._2, t._1)
>
> >>> And maybe even...
>
> >>>    def ->[T](t: Tuple2[String, T]) = FuncAttrBindParam(name, (name  
> >>> ->
> >>> t._2).calcValue _, t._1)
>
> >>> or
>
> >>>    def ->[T](t: Tuple2[String, T]) = FuncAttrBindParam(name, (t._1  
> >>> ->
> >>> t._2).calcValue _, t._1)
>
> >>> I'm not sure which is better on the last two... Just a thought.
>
> >>> Marc
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Lif

[Lift] Re: accessing the attributes of the XML node associated with a FuncBindParam in bind(...)

[Marc Boschma]

A quick just before going to bed reaction is that your change would  
solve the issue.

It is interesting you focused on the "exclude" and not the  
"list" (which is what I have been playing with). I actually missed it  
was a similar case...

Regards,

Marc

On 06/01/2009, at 9:24 PM, Marius wrote:

>
> I just did a minor modification to the lift code so the actual node it
> is passed to the BindParam and not its child. Now having:
>
> bind("todo", html,
> "exclude" ->  {node:NodeSeq =>ajaxCheckbox
> (QueryNotDone, v => {QueryNotDone(v); reDraw})}
>  ... )
>
> and the markup 
>
> The node parameter to the anonymous function will be the
>  node and not its children. So now you can access the
> "param" attribute from node. The change was in in_bind function so
> instead of calling calcValue(s.child) I just call calcValue(s)
>
> Looking at the existent BindParams this change does not seem to cause
> side effects since the calcValue 'in' parameter is used only for
> FuncXXXBindParam-s. The impact is that the user's function would now
> get the actual node (from which now he can extract attributes) and not
> the child nodes. But child nodes from the actual node are trivial to
> obtain.
>
> I did not commit this change as I'd like to see other opinions to see
> if there is something that I missed somehow. If we get general
> consensus of this change I can commit it right away and announce it as
> a "breaking change".
>
> Thoughts?
>
> Br's,
> Marius
>
>
>
> On Jan 6, 12:02 pm, Marius  wrote:
>> A nice alternative would have been :
>>
>>  bind("todo", html,
>>  "exclude" ->  {node:NodeSeq =>ajaxCheckbox
>> (QueryNotDone, v => {QueryNotDone(v); reDraw})}
>>   ... )
>>
>> But here the node impersonates the childNodes not the original node.
>> So you still can not access the param attribute below
>>
>> 
>>
>> but you can do it like:
>>
>> 
>>
>> and you have full access to the meta node as it is a child of
>> todo:exclude. Hence you can pass state.
>>
>> I know, it is not ideal but should be workable until snippet child-
>> node attributes are exposed in one way or another.
>>
>> Br's,
>> Marius
>>
>> Marc Boschma wrote:
>>> I have been playing with the ToDo example application and having fun
>>> in manipulating XML.
>>
>>> With the  node I thought it would be good if the XHTML
>>> designer could pass in some guidance to the doList(...) method  
>>> used in
>>> bind(..). ie. ...
>>
>>> Looking over the bind code I noticed that the attributes are not
>>> accessible without ending up changing the calcValue method's
>>> signature. I did initially try to knock up a
>>
>>>case class FuncWithAttrBindParam(name: String, value: (NodeSeq,
>>> MetaData) => NodeSeq) extends Tuple2(name, value) with BindParam
>>
>>> and a corresponding
>>
>>>case Some(ns : FuncWithAttrBindParam) =>
>>
>>> in in_bind(...), but it all looks like a huge kludge.
>>
>>> It strikes me as a little deficient to be able to utilise attributes
>>> within the context of a snippet and yet not within a bind. I know  
>>> bind
>>> is quite embedded in lift now, but I think that this difference  
>>> might
>>> prove a little frustrating. I know one solution is to just create a
>>> bind("todo", html,
>>>  "exclude" ->
>>> ajaxCheckbox(QueryNotDone, v => {QueryNotDone(v); reDraw}),
>>>  "list" -> doList(reDraw, false) _,
>>>"list_singular" -> doList(reDraw, true)  
>>> _)
>>
>>> But I think from the XHtml designer's perspective that is counter
>>> intuitive...
>>
>>> Thoughts?
>>
>>> --
>>
>>> It should be noted that this is different to the case class
>>> FuncAttrBindParam(name: String, value: NodeSeq => NodeSeq, newAttr:
>>> String) extends BindParam with BindWithAttr. Which interesting  
>>> enough
>>> has no corresponding SuperArrowAssoc -> method match. Maybe
>>
>>>def ->(t: Tuple2[String, NodeSeq]) = AttrBindParam(name, t._2,  
>>> t._1)
>>>def ->(t: Tuple2[String, NodeSeq => NodeSeq]) =
>>> FuncAttrBindParam(name, t._2, t._1)
>>
>>> And maybe even...
>>
>>>def ->[T](t: Tuple2[String, T]) = FuncAttrBindParam(name, (name  
>>> ->
>>> t._2).calcValue _, t._1)
>>
>>> or
>>
>>>def ->[T](t: Tuple2[String, T]) = FuncAttrBindParam(name, (t._1  
>>> ->
>>> t._2).calcValue _, t._1)
>>
>>> I'm not sure which is better on the last two... Just a thought.
>>
>>> Marc
> >


--~--~-~--~~~---~--~~
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: accessing the attributes of the XML node associated with a FuncBindParam in bind(...)

[Marius]

I just did a minor modification to the lift code so the actual node it
is passed to the BindParam and not its child. Now having:

 bind("todo", html,
 "exclude" ->  {node:NodeSeq =>ajaxCheckbox
(QueryNotDone, v => {QueryNotDone(v); reDraw})}
  ... )

and the markup 

The node parameter to the anonymous function will be the
 node and not its children. So now you can access the
"param" attribute from node. The change was in in_bind function so
instead of calling calcValue(s.child) I just call calcValue(s)

Looking at the existent BindParams this change does not seem to cause
side effects since the calcValue 'in' parameter is used only for
FuncXXXBindParam-s. The impact is that the user's function would now
get the actual node (from which now he can extract attributes) and not
the child nodes. But child nodes from the actual node are trivial to
obtain.

I did not commit this change as I'd like to see other opinions to see
if there is something that I missed somehow. If we get general
consensus of this change I can commit it right away and announce it as
a "breaking change".

Thoughts?

Br's,
Marius



On Jan 6, 12:02 pm, Marius  wrote:
> A nice alternative would have been :
>
>  bind("todo", html,
>                      "exclude" ->  {node:NodeSeq =>ajaxCheckbox
> (QueryNotDone, v => {QueryNotDone(v); reDraw})}
>   ... )
>
> But here the node impersonates the childNodes not the original node.
> So you still can not access the param attribute below
>
> 
>
> but you can do it like:
>
> 
>
> and you have full access to the meta node as it is a child of
> todo:exclude. Hence you can pass state.
>
> I know, it is not ideal but should be workable until snippet child-
> node attributes are exposed in one way or another.
>
> Br's,
> Marius
>
> Marc Boschma wrote:
> > I have been playing with the ToDo example application and having fun
> > in manipulating XML.
>
> > With the  node I thought it would be good if the XHTML
> > designer could pass in some guidance to the doList(...) method used in
> > bind(..). ie. ...
>
> > Looking over the bind code I noticed that the attributes are not
> > accessible without ending up changing the calcValue method's
> > signature. I did initially try to knock up a
>
> >    case class FuncWithAttrBindParam(name: String, value: (NodeSeq,
> > MetaData) => NodeSeq) extends Tuple2(name, value) with BindParam
>
> > and a corresponding
>
> >    case Some(ns : FuncWithAttrBindParam) =>
>
> > in in_bind(...), but it all looks like a huge kludge.
>
> > It strikes me as a little deficient to be able to utilise attributes
> > within the context of a snippet and yet not within a bind. I know bind
> > is quite embedded in lift now, but I think that this difference might
> > prove a little frustrating. I know one solution is to just create a
> > bind("todo", html,
> >                                  "exclude" ->
> > ajaxCheckbox(QueryNotDone, v => {QueryNotDone(v); reDraw}),
> >                                  "list" -> doList(reDraw, false) _,
> >                            "list_singular" -> doList(reDraw, true) _)
>
> > But I think from the XHtml designer's perspective that is counter
> > intuitive...
>
> > Thoughts?
>
> > --
>
> > It should be noted that this is different to the case class
> > FuncAttrBindParam(name: String, value: NodeSeq => NodeSeq, newAttr:
> > String) extends BindParam with BindWithAttr. Which interesting enough
> > has no corresponding SuperArrowAssoc -> method match. Maybe
>
> >    def ->(t: Tuple2[String, NodeSeq]) = AttrBindParam(name, t._2, t._1)
> >    def ->(t: Tuple2[String, NodeSeq => NodeSeq]) =
> > FuncAttrBindParam(name, t._2, t._1)
>
> > And maybe even...
>
> >    def ->[T](t: Tuple2[String, T]) = FuncAttrBindParam(name, (name ->
> > t._2).calcValue _, t._1)
>
> > or
>
> >    def ->[T](t: Tuple2[String, T]) = FuncAttrBindParam(name, (t._1 ->
> > t._2).calcValue _, t._1)
>
> > I'm not sure which is better on the last two... Just a thought.
>
> > Marc
--~--~-~--~~~---~--~~
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: accessing the attributes of the XML node associated with a FuncBindParam in bind(...)

[Marius]

A nice alternative would have been :


 bind("todo", html,
 "exclude" ->  {node:NodeSeq =>ajaxCheckbox
(QueryNotDone, v => {QueryNotDone(v); reDraw})}
  ... )

But here the node impersonates the childNodes not the original node.
So you still can not access the param attribute below



but you can do it like:



and you have full access to the meta node as it is a child of
todo:exclude. Hence you can pass state.

I know, it is not ideal but should be workable until snippet child-
node attributes are exposed in one way or another.

Br's,
Marius

Marc Boschma wrote:
> I have been playing with the ToDo example application and having fun
> in manipulating XML.
>
> With the  node I thought it would be good if the XHTML
> designer could pass in some guidance to the doList(...) method used in
> bind(..). ie. ...
>
> Looking over the bind code I noticed that the attributes are not
> accessible without ending up changing the calcValue method's
> signature. I did initially try to knock up a
>
>   case class FuncWithAttrBindParam(name: String, value: (NodeSeq,
> MetaData) => NodeSeq) extends Tuple2(name, value) with BindParam
>
> and a corresponding
>
>   case Some(ns : FuncWithAttrBindParam) =>
>
> in in_bind(...), but it all looks like a huge kludge.
>
> It strikes me as a little deficient to be able to utilise attributes
> within the context of a snippet and yet not within a bind. I know bind
> is quite embedded in lift now, but I think that this difference might
> prove a little frustrating. I know one solution is to just create a
> bind("todo", html,
>  "exclude" ->
> ajaxCheckbox(QueryNotDone, v => {QueryNotDone(v); reDraw}),
>  "list" -> doList(reDraw, false) _,
>   "list_singular" -> doList(reDraw, true) _)
>
> But I think from the XHtml designer's perspective that is counter
> intuitive...
>
> Thoughts?
>
> --
>
> It should be noted that this is different to the case class
> FuncAttrBindParam(name: String, value: NodeSeq => NodeSeq, newAttr:
> String) extends BindParam with BindWithAttr. Which interesting enough
> has no corresponding SuperArrowAssoc -> method match. Maybe
>
>   def ->(t: Tuple2[String, NodeSeq]) = AttrBindParam(name, t._2, t._1)
>   def ->(t: Tuple2[String, NodeSeq => NodeSeq]) =
> FuncAttrBindParam(name, t._2, t._1)
>
> And maybe even...
>
>   def ->[T](t: Tuple2[String, T]) = FuncAttrBindParam(name, (name ->
> t._2).calcValue _, t._1)
>
> or
>
>   def ->[T](t: Tuple2[String, T]) = FuncAttrBindParam(name, (t._1 ->
> t._2).calcValue _, t._1)
>
> I'm not sure which is better on the last two... Just a thought.
>
> Marc
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---