This page is no longer maintained — Please continue to the home page at www.scala-lang.org

As long as the collections classes are changing for 2.8

27 replies
David Pollak
Joined: 2008-12-16,
User offline. Last seen 42 years 45 weeks ago.
What do you guys think of:
reduceLeft(f: (A, A) => A): Option[A]
That way, if there are no elements to reduce, the result is None.
Thanks,
David... who is liking exceptions less and less every day

--
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
loverdos
Joined: 2008-11-18,
User offline. Last seen 2 years 27 weeks ago.
Re: As long as the collections classes are changing for 2.8
+1

On Wed, Jan 14, 2009 at 1:57 AM, David Pollak <feeder [dot] of [dot] the [dot] bears [at] gmail [dot] com> wrote:
What do you guys think of:
reduceLeft(f: (A, A) => A): Option[A]
That way, if there are no elements to reduce, the result is None.
Thanks,
David... who is liking exceptions less and less every day

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



--
 __~O
-\ <,       Christos KK Loverdos
(*)/ (*)      http://ckkloverdos.com
hrj
Joined: 2008-09-23,
User offline. Last seen 4 years 3 weeks ago.
Re: As long as the collections classes are changing for 2.8

+10

Have been burned by that particular exception much too often

David Pollak wrote:

> What do you guys think of:
> reduceLeft(f: (A, A) => A): Option[A]
>
> That way, if there are no elements to reduce, the result is None.
>
> Thanks,
>
> David... who is liking exceptions less and less every day
>

Viktor Klang
Joined: 2008-12-17,
User offline. Last seen 1 year 27 weeks ago.
Re: Re: As long as the collections classes are changing for 2.
+ Long.MAX_VALUE

On Wed, Jan 14, 2009 at 11:13 AM, Harshad <harshad [dot] rj [at] gmail [dot] com> wrote:
+10

Have been burned by that particular exception much too often

David Pollak wrote:

> What do you guys think of:
> reduceLeft(f: (A, A) => A): Option[A]
>
> That way, if there are no elements to reduce, the result is None.
>
> Thanks,
>
> David... who is liking exceptions less and less every day
>





--
Viktor Klang
Senior Systems Analyst
hrj
Joined: 2008-09-23,
User offline. Last seen 4 years 3 weeks ago.
Re: As long as the collections classes are changing for 2.8

Actually, it is not just a matter of getting hit by exceptions; I think returning an Option will make reduceLeft much more composable.

entities flatMap (_.attributes reduceLeft (...))

instead of

entities flatMap (e => if (e.attributes.length > 0) Some(e.attributes.reduceLeft(...)) else None)

I will file an enhancement ticket if nobody objects.

I was also not able to define an implicit conversion to help with this. Any help appreciated:

$> cat reduce.scala
implicit def list2pimped[T](l:List[T]) = new {
def reduceLeftO[B>:T](f:(B,T=>B)) = if(l.length>0) Some(l.reduceLeft(f)) else None
}

val l = List(1,2,3)
l reduceLeftO (_ + _)

$> scala reduce.scala
(fragment of reduce.scala):2: error: type mismatch;
found : (B, (T) => B)
required: (?, T) => ?
Note: implicit method list2pimped is not applicable here
because it comes after the application point and it lacks an explicit result type
def reduceLeftO[B>:T](f:(B,T=>B)) = if(l.length>0) Some(l.reduceLeft(f)) else None
^
(fragment of reduce.scala):6: error: missing parameter type for expanded function ((x$1, x$2) => x$1.$plus(x$2))
l reduceLeftO (_ + _)
^
(fragment of reduce.scala):6: error: missing parameter type for expanded function ((x$1: , x$2) => x$1.$plus(x$2))
l reduceLeftO (_ + _)

Harshad

David Pollak wrote:

> What do you guys think of:
> reduceLeft(f: (A, A) => A): Option[A]
>
> That way, if there are no elements to reduce, the result is None.
>
> Thanks,
>
> David... who is liking exceptions less and less every day
>

Iulian Dragos
Joined: 2008-12-18,
User offline. Last seen 42 years 45 weeks ago.
Re: Re: As long as the collections classes are changing for 2.8

Why not use 'foldLeft' when the list might be empty, and 'reduceLeft'
when you're sure it has at least one element? The same way maps have
apply, which throws an error, and 'get', which returns an Option.

Cheers,
Iulian

On Sat, Jan 17, 2009 at 8:51 AM, Harshad wrote:
> Actually, it is not just a matter of getting hit by exceptions; I think returning an Option will make reduceLeft much more composable.
>
> entities flatMap (_.attributes reduceLeft (...))
>
> instead of
>
> entities flatMap (e => if (e.attributes.length > 0) Some(e.attributes.reduceLeft(...)) else None)
>
> I will file an enhancement ticket if nobody objects.
>
> I was also not able to define an implicit conversion to help with this. Any help appreciated:
>
> $> cat reduce.scala
> implicit def list2pimped[T](l:List[T]) = new {
> def reduceLeftO[B>:T](f:(B,T=>B)) = if(l.length>0) Some(l.reduceLeft(f)) else None
> }
>
> val l = List(1,2,3)
> l reduceLeftO (_ + _)
>
> $> scala reduce.scala
> (fragment of reduce.scala):2: error: type mismatch;
> found : (B, (T) => B)
> required: (?, T) => ?
> Note: implicit method list2pimped is not applicable here
> because it comes after the application point and it lacks an explicit result type
> def reduceLeftO[B>:T](f:(B,T=>B)) = if(l.length>0) Some(l.reduceLeft(f)) else None
> ^
> (fragment of reduce.scala):6: error: missing parameter type for expanded function ((x$1, x$2) => x$1.$plus(x$2))
> l reduceLeftO (_ + _)
> ^
> (fragment of reduce.scala):6: error: missing parameter type for expanded function ((x$1: , x$2) => x$1.$plus(x$2))
> l reduceLeftO (_ + _)
>
>
> Harshad
>
>
> David Pollak wrote:
>
>> What do you guys think of:
>> reduceLeft(f: (A, A) => A): Option[A]
>>
>> That way, if there are no elements to reduce, the result is None.
>>
>> Thanks,
>>
>> David... who is liking exceptions less and less every day
>>
>
>
>

hrj
Joined: 2008-09-23,
User offline. Last seen 4 years 3 weeks ago.
Re: Re: As long as the collections classes are changing for 2.8

Iulian Dragos wrote:

> Why not use 'foldLeft' when the list might be empty, and 'reduceLeft'
> when you're sure it has at least one element? The same way maps have
> apply, which throws an error, and 'get', which returns an Option.

foldLeft can be used in lieu of reduceLeft only when there is an identity element available for the operation done by reduceLeft.

For example,
listIntegers foldLeft (0) (_ + _)

instead of

listIntegers reduceLeft (_ + _)

Here, 0 is an identity element for addition.

But, consider other operations where such identity elements are difficult to construct or unknown (or impossible). For example, parser combinators (I have my own library of these for which identity elements are difficult to pin down).

Option[T] fits the fill perfectly and saves a lot of trouble.

hrj
Joined: 2008-09-23,
User offline. Last seen 4 years 3 weeks ago.
Re: Re: As long as the collections classes are changing for 2.8

Harshad wrote:
> Option[T] fits the fill perfectly and saves a lot of trouble.

Oops. I meant "fits the bill".

odersky
Joined: 2008-07-29,
User offline. Last seen 45 weeks 6 days ago.
Re: Re: Re: As long as the collections classes are changing fo

I don't think we can change the meaning of reduceLeft. We will change
the collection libraries but we will try to avoid giving different
meanig and types to existing methods. But we could add another method
with the desired functionality. I am looking for propositions what
name to give it.
reduceLeftOrNone? reduceLeftOption?

Cheers

Derek Chen-Becker
Joined: 2008-12-16,
User offline. Last seen 42 years 45 weeks ago.
Re: Re: As long as the collections classes are changing for 2.

Harshad wrote:
> Actually, it is not just a matter of getting hit by exceptions; I think returning an Option will make reduceLeft much more composable.

I agree. I think that with the Option class available, operations on an
empty collection generally shouldn't throw exceptions. If you truly want
an exception to be thrown I would use something like

require(myCollection.length > 0)

which will throw an illegal argument exception if the collection is
empty. My main reasoning for this usage in Scala is that because Scala
uses unchecked exceptions, it can be too easy to miss handling a
collection exception. Changing the return type to Option is a different
approach to making the handling explicit, and with all of Option's
ancillary methods (map, foreach, etc.), definitely allows for more
concise processing than a regular exception would.

Derek

David Pollak
Joined: 2008-12-16,
User offline. Last seen 42 years 45 weeks ago.
Re: Re: Re: As long as the collections classes are changing for


On Sat, Jan 17, 2009 at 4:08 AM, martin odersky <martin [dot] odersky [at] epfl [dot] ch> wrote:
I don't think we can change the meaning of reduceLeft. We will change
the collection libraries but we will try to avoid giving different
meanig and types to existing methods. But we could add another method
with the desired functionality. I am looking for propositions what
name to give it.
reduceLeftOrNone? reduceLeftOption?

How about something less verbose?  optReduceLeft?
Also, how about deprecating reduceLeft?
On a separate note, it'd be great to add a get method to PartialFunction to about the double-cost of performing the test and then performing the action (which has to perform the test again).  This has some significant benefits for PartialFunctions that are chained via orElse.
Thanks,
David

 


Cheers

 -- Martin


On Sat, Jan 17, 2009 at 12:27 PM, Harshad <harshad [dot] rj [at] gmail [dot] com> wrote:
> Iulian Dragos wrote:
>
>> Why not use 'foldLeft' when the list might be empty, and 'reduceLeft'
>> when you're sure it has at least one element? The same way maps have
>> apply, which throws an error, and 'get', which returns an Option.
>
> foldLeft can be used in lieu of reduceLeft only when there is an identity element available for the operation done by reduceLeft.
>
> For example,
> listIntegers foldLeft (0) (_ + _)
>
> instead of
>
> listIntegers reduceLeft (_ + _)
>
> Here, 0 is an identity element for addition.
>
> But, consider other operations where such identity elements are difficult to construct or unknown (or impossible). For example, parser combinators (I have my own library of these for which identity elements are difficult to pin down).
>
> Option[T] fits the fill perfectly and saves a lot of trouble.
>
>



--
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
DRMacIver
Joined: 2008-09-02,
User offline. Last seen 42 years 45 weeks ago.
Re: Re: Re: As long as the collections classes are changing fo
On Sat, Jan 17, 2009 at 11:00 PM, David Pollak <feeder [dot] of [dot] the [dot] bears [at] gmail [dot] com> wrote:


On Sat, Jan 17, 2009 at 4:08 AM, martin odersky <martin [dot] odersky [at] epfl [dot] ch> wrote:
I don't think we can change the meaning of reduceLeft. We will change
the collection libraries but we will try to avoid giving different
meanig and types to existing methods. But we could add another method
with the desired functionality. I am looking for propositions what
name to give it.
reduceLeftOrNone? reduceLeftOption?

How about something less verbose?  optReduceLeft?
Also, how about deprecating reduceLeft?

How about not. It's a perfectly valid function, and the last thing Iterable needs is yet more useful functionality deprecated because someone had philosophical objections to it.
David Pollak
Joined: 2008-12-16,
User offline. Last seen 42 years 45 weeks ago.
Re: Re: Re: As long as the collections classes are changing for


On Sat, Jan 17, 2009 at 3:13 PM, David MacIver <david [dot] maciver [at] gmail [dot] com> wrote:
On Sat, Jan 17, 2009 at 11:00 PM, David Pollak <feeder [dot] of [dot] the [dot] bears [at] gmail [dot] com> wrote:


On Sat, Jan 17, 2009 at 4:08 AM, martin odersky <martin [dot] odersky [at] epfl [dot] ch> wrote:
I don't think we can change the meaning of reduceLeft. We will change
the collection libraries but we will try to avoid giving different
meanig and types to existing methods. But we could add another method
with the desired functionality. I am looking for propositions what
name to give it.
reduceLeftOrNone? reduceLeftOption?

How about something less verbose?  optReduceLeft?
Also, how about deprecating reduceLeft?

How about not. It's a perfectly valid function, and the last thing Iterable needs is yet more useful functionality deprecated because someone had philosophical objections to it.

David,
reduceLeft's exception on invalid result is inconsistent with Scala's trend toward returning options rather than throwing exceptions when a result cannot be calculated.  I have spent a lot of time with Scala's libraries over the last month (why?  you'll find out next week, but it'll be a positive thing for the Scala community).  I've seen some inconsistencies.  I'm flagging them.  Martin and his team will make the final decisions.
On the style side of things, why are my philosophical objections any less valid than your opinions to the contrary?  We have both been around Scala for a while.  We've both contributed to the community.  We've got different backgrounds, but we've each been doing computing-related stuff for quite a while.  I respect your opinion, even when I disagree with it.  I would appreciate it if you would should the same courtesies to me and my opinions.
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
odersky
Joined: 2008-07-29,
User offline. Last seen 45 weeks 6 days ago.
Re: Re: Re: As long as the collections classes are changing fo

On Sun, Jan 18, 2009 at 3:59 PM, David Pollak
wrote:
>
>
> On Sat, Jan 17, 2009 at 3:13 PM, David MacIver
> wrote:
>>
>> On Sat, Jan 17, 2009 at 11:00 PM, David Pollak
>> wrote:
>>>
>>>
>>> On Sat, Jan 17, 2009 at 4:08 AM, martin odersky
>>> wrote:
>>>>
>>>> I don't think we can change the meaning of reduceLeft. We will change
>>>> the collection libraries but we will try to avoid giving different
>>>> meanig and types to existing methods. But we could add another method
>>>> with the desired functionality. I am looking for propositions what
>>>> name to give it.
>>>> reduceLeftOrNone? reduceLeftOption?
>>>
>>> How about something less verbose? optReduceLeft?
>>> Also, how about deprecating reduceLeft?
>>
>> How about not. It's a perfectly valid function, and the last thing
>> Iterable needs is yet more useful functionality deprecated because someone
>> had philosophical objections to it.
>
> David,
> reduceLeft's exception on invalid result is inconsistent with Scala's trend
> toward returning options rather than throwing exceptions when a result
> cannot be calculated. I have spent a lot of time with Scala's libraries
> over the last month (why? you'll find out next week, but it'll be a
> positive thing for the Scala community). I've seen some inconsistencies.
> I'm flagging them. Martin and his team will make the final decisions.
> On the style side of things, why are my philosophical objections any less
> valid than your opinions to the contrary? We have both been around Scala
> for a while. We've both contributed to the community. We've got different
> backgrounds, but we've each been doing computing-related stuff for quite a
> while. I respect your opinion, even when I disagree with it. I would
> appreciate it if you would should the same courtesies to me and my opinions.
> Thanks,
> David
>
My reason for not deprecating reduceLeft is that it's pretty standard
the way it is. Both ML and Haskell have it AFAIK. So we really should
add another method, and leave reduceLeft alone.

Cheers

DRMacIver
Joined: 2008-09-02,
User offline. Last seen 42 years 45 weeks ago.
Re: Re: Re: As long as the collections classes are changing fo
On Sun, Jan 18, 2009 at 2:59 PM, David Pollak <feeder [dot] of [dot] the [dot] bears [at] gmail [dot] com> wrote:
How about not. It's a perfectly valid function, and the last thing Iterable needs is yet more useful functionality deprecated because someone had philosophical objections to it.

reduceLeft's exception on invalid result is inconsistent with Scala's trend toward returning options rather than throwing exceptions when a result cannot be calculated.  I have spent a lot of time with Scala's libraries over the last

I don't see any evidence that Scala has that trend. In fact it seems much more common for Scala to offer an alternate version which throws an exception whenever it offers a version that returns Option. e.g. Map.get/Map.apply, List.headOption/List.head.
 
There are additionally lots of examples where scala does not provide an Option version and does provide a version which simply fails. Consider Seq.apply, List.tail, Iterable.max/min...

Just because something can fail is not a reason for it to return Option. Particularly when it specifies the contract of when it fails very precisely. Not everything needs to document its failure conditions in the type signature - that way lies the horror of Java's checked exceptions.


On the style side of things, why are my philosophical objections any less valid than your opinions to the contrary?  We

Because yours involve deprecating useful and perfectly working functionality because you don't like it. Further, this isn't the first time this has happened to Iterable: Observe the annoyances with take. The functionality is there, totally standard across languages and works as is. There's no good reason to get rid of it even if you'd prefer to also have an Option version.
Naftoli Gugenheim
Joined: 2008-12-17,
User offline. Last seen 42 years 45 weeks ago.
Re: Re: Re: As long as the collections classes are changing for

If reduceLeftOption is too verbose, how about reduceLeftOpt instead of optReduceLeft?(One advantage is that code completion can help you remember that both exist because you see them together)

David Pollak
Joined: 2008-12-16,
User offline. Last seen 42 years 45 weeks ago.
Re: Re: Re: As long as the collections classes are changing for


On Sun, Jan 18, 2009 at 7:31 AM, martin odersky <martin [dot] odersky [at] epfl [dot] ch> wrote:
On Sun, Jan 18, 2009 at 3:59 PM, David Pollak
<feeder [dot] of [dot] the [dot] bears [at] gmail [dot] com> wrote:
>
>
> On Sat, Jan 17, 2009 at 3:13 PM, David MacIver <david [dot] maciver [at] gmail [dot] com>
> wrote:
>>
>> On Sat, Jan 17, 2009 at 11:00 PM, David Pollak
>> <feeder [dot] of [dot] the [dot] bears [at] gmail [dot] com> wrote:
>>>
>>>
>>> On Sat, Jan 17, 2009 at 4:08 AM, martin odersky <martin [dot] odersky [at] epfl [dot] ch>
>>> wrote:
>>>>
>>>> I don't think we can change the meaning of reduceLeft. We will change
>>>> the collection libraries but we will try to avoid giving different
>>>> meanig and types to existing methods. But we could add another method
>>>> with the desired functionality. I am looking for propositions what
>>>> name to give it.
>>>> reduceLeftOrNone? reduceLeftOption?
>>>
>>> How about something less verbose?  optReduceLeft?
>>> Also, how about deprecating reduceLeft?
>>
>> How about not. It's a perfectly valid function, and the last thing
>> Iterable needs is yet more useful functionality deprecated because someone
>> had philosophical objections to it.
>
> David,
> reduceLeft's exception on invalid result is inconsistent with Scala's trend
> toward returning options rather than throwing exceptions when a result
> cannot be calculated.  I have spent a lot of time with Scala's libraries
> over the last month (why?  you'll find out next week, but it'll be a
> positive thing for the Scala community).  I've seen some inconsistencies.
>  I'm flagging them.  Martin and his team will make the final decisions.
> On the style side of things, why are my philosophical objections any less
> valid than your opinions to the contrary?  We have both been around Scala
> for a while.  We've both contributed to the community.  We've got different
> backgrounds, but we've each been doing computing-related stuff for quite a
> while.  I respect your opinion, even when I disagree with it.  I would
> appreciate it if you would should the same courtesies to me and my opinions.
> Thanks,
> David
>
My reason for not deprecating reduceLeft is that it's pretty standard
the way it is. Both ML and Haskell have it AFAIK. So we really should
add another method, and leave reduceLeft alone.

Cool.  Thanks! 


Cheers

 -- Martin



--
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
David Pollak
Joined: 2008-12-16,
User offline. Last seen 42 years 45 weeks ago.
Re: Re: Re: As long as the collections classes are changing for


On Sun, Jan 18, 2009 at 11:09 AM, David MacIver <david [dot] maciver [at] gmail [dot] com> wrote:


On the style side of things, why are my philosophical objections any less valid than your opinions to the contrary?  We

Because yours involve deprecating useful and perfectly working functionality because you don't like it. Further, this isn't the first time this has happened to Iterable: Observe the annoyances with take. The functionality is there, totally standard across languages and works as is. There's no good reason to get rid of it even if you'd prefer to also have an Option version.

There's a difference between substance (deprecate a method or not to) and how the argument is presented.
The way you present your responses to my suggestions indicate that you think my suggestions are the nattering of a fool.  So be it.
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
Chris Twiner
Joined: 2008-12-17,
User offline. Last seen 42 years 45 weeks ago.
Re: Re: Re: As long as the collections classes are changing for

On 1/18/09, David Pollak wrote:
>
>
> On Sun, Jan 18, 2009 at 11:09 AM, David MacIver
> wrote:
> >
> >
> >
> >
> >
> > >
> > >
> > >
> > > On the style side of things, why are my philosophical objections any
> less valid than your opinions to the contrary? We
> >
> >
> > Because yours involve deprecating useful and perfectly working
> functionality because you don't like it. Further, this isn't the first time
> this has happened to Iterable: Observe the annoyances with take. The
> functionality is there, totally standard across languages and works as is.
> There's no good reason to get rid of it even if you'd prefer to also have an
> Option version.
>
> There's a difference between substance (deprecate a method or not to) and
> how the argument is presented.
>
> The way you present your responses to my suggestions indicate that you think
> my suggestions are the nattering of a fool. So be it.
>
> David
>

Not to stir the pot but IMO neither of David Ms replies in this thread
doesn't seem to warrant this interpretation.

ounos
Joined: 2008-12-29,
User offline. Last seen 3 years 44 weeks ago.
Re: Re: Re: As long as the collections classes are changing for

I would suggest 'tryReduceLeft'. Option is already in the signature, no
real gain by repeating that, while 'try' gives a very concise notice of
the fact that you only try to reduceLeft, without really knowing it
won't fail (failure as in returning None). But if there is an already
established naming convention for dual methods (exception throwing and
Option returning), it should be followed.

O/H Naftoli Gugenheim έγραψε:
> If reduceLeftOption is too verbose, how about reduceLeftOpt instead of
> optReduceLeft?
> (One advantage is that code completion can help you remember that both
> exist because you see them together)

Viktor Klang
Joined: 2008-12-17,
User offline. Last seen 1 year 27 weeks ago.
Re: Re: Re: As long as the collections classes are changing fo
I'm rooting for: reduceLeftFingersCrossed or the more T.Morrisish "<---/?"

On Sun, Jan 18, 2009 at 11:01 PM, Dimitris Andreou <jim [dot] andreou [at] gmail [dot] com> wrote:
I would suggest 'tryReduceLeft'. Option is already in the signature, no real gain by repeating that, while 'try' gives a very concise notice of the fact that you only try to reduceLeft, without really knowing it won't fail (failure as in returning None). But if there is an already established naming convention for dual methods (exception throwing and Option returning), it should be followed.

O/H Naftoli Gugenheim έγραψε:
If reduceLeftOption is too verbose, how about reduceLeftOpt instead of optReduceLeft?
(One advantage is that code completion can help you remember that both exist because you see them together)




--
Viktor Klang
Senior Systems Analyst
ounos
Joined: 2008-12-29,
User offline. Last seen 3 years 44 weeks ago.
Re: Re: Re: As long as the collections classes are changing fo

That might cause readers to merely cross their _left_ hand's fingers. Or
reduce the crossed fingers of their left hand, crossing fewer and fewer
until the have none crossed.

O/H Viktor Klang έγραψε:
> I'm rooting for: reduceLeftFingersCrossed or the more T.Morrisish "<---/?"
>
> On Sun, Jan 18, 2009 at 11:01 PM, Dimitris Andreou
> > wrote:
>
> I would suggest 'tryReduceLeft'. Option is already in the
> signature, no real gain by repeating that, while 'try' gives a
> very concise notice of the fact that you only try to reduceLeft,
> without really knowing it won't fail (failure as in returning
> None). But if there is an already established naming convention
> for dual methods (exception throwing and Option returning), it
> should be followed.
>
> O/H Naftoli Gugenheim ������:
>
> If reduceLeftOption is too verbose, how about reduceLeftOpt
> instead of optReduceLeft?
> (One advantage is that code completion can help you remember
> that both exist because you see them together)
>
>
>
>
>

Ricky Clarkson
Joined: 2008-12-19,
User offline. Last seen 3 years 2 weeks ago.
Re: Re: Re: As long as the collections classes are changing fo
How about reduceLeftTheTypesMakeItFrickinObviousThisCanFailButLetsEmbedThatInTheMethodNameAnyway?

How do the types make it obvious that it can fail?  Well, we all know List[T] can have 0 elements, so anything on List that returns a T that doesn't take a T must, for a 0 element list, do one of:
* Throw an exception
* Hang
* Abort
* Blow up the planet
* Return null
* Use reflection to instantiate a T (but look, there's no Manifest)

2009/1/19 Dimitris Andreou <jim [dot] andreou [at] gmail [dot] com>
That might cause readers to merely cross their _left_ hand's fingers. Or reduce the crossed fingers of their left hand, crossing fewer and fewer until the have none crossed.

O/H Viktor Klang έγραψε:
I'm rooting for: reduceLeftFingersCrossed or the more T.Morrisish "<---/?"

On Sun, Jan 18, 2009 at 11:01 PM, Dimitris Andreou <jim [dot] andreou [at] gmail [dot] com <mailto:jim [dot] andreou [at] gmail [dot] com>> wrote:

   I would suggest 'tryReduceLeft'. Option is already in the
   signature, no real gain by repeating that, while 'try' gives a
   very concise notice of the fact that you only try to reduceLeft,
   without really knowing it won't fail (failure as in returning
   None). But if there is an already established naming convention
   for dual methods (exception throwing and Option returning), it
   should be followed.

   O/H Naftoli Gugenheim ������:

       If reduceLeftOption is too verbose, how about reduceLeftOpt
       instead of optReduceLeft?
       (One advantage is that code completion can help you remember
       that both exist because you see them together)





Arthur Peters
Joined: 2009-01-09,
User offline. Last seen 42 years 45 weeks ago.
Re: Re: Re: As long as the collections classes are changing fo

I'm not all that well versed in Scala theory, but just to throw out an idea.
..

What about an adapter that catches exceptions and returns None in the
exception case or Some(...) in the success case?

If could be called like: optionAdapter(list.reduceLeft(_+_))

An adapter could be created to go the other way too if such was useful.

Also it seems to me that no matter how this discussion is finalized
the library needs to be standardized. As a user I really don't want to
have to look at the docs (or at least type signature) to know how a
given function handles errors. It seems like it should either be all
exceptions or all Options (or all both but that seams like a lot of
overhead). Just my penny worth of thoughts.

-Arthur

On Mon, Jan 19, 2009 at 9:23 AM, Ricky Clarkson
wrote:
> How about
> reduceLeftTheTypesMakeItFrickinObviousThisCanFailButLetsEmbedThatInTheMethodNameAnyway?
>
> How do the types make it obvious that it can fail? Well, we all know
> List[T] can have 0 elements, so anything on List that returns a T that
> doesn't take a T must, for a 0 element list, do one of:
> * Throw an exception
> * Hang
> * Abort
> * Blow up the planet
> * Return null
> * Use reflection to instantiate a T (but look, there's no Manifest)
>
> 2009/1/19 Dimitris Andreou
>>
>> That might cause readers to merely cross their _left_ hand's fingers. Or
>> reduce the crossed fingers of their left hand, crossing fewer and fewer
>> until the have none crossed.
>>
>> O/H Viktor Klang έγραψε:
>>>
>>> I'm rooting for: reduceLeftFingersCrossed or the more T.Morrisish
>>> "<---/?"
>>>
>>> On Sun, Jan 18, 2009 at 11:01 PM, Dimitris Andreou >> > wrote:
>>>
>>> I would suggest 'tryReduceLeft'. Option is already in the
>>> signature, no real gain by repeating that, while 'try' gives a
>>> very concise notice of the fact that you only try to reduceLeft,
>>> without really knowing it won't fail (failure as in returning
>>> None). But if there is an already established naming convention
>>> for dual methods (exception throwing and Option returning), it
>>> should be followed.
>>>
>>> O/H Naftoli Gugenheim ������:
>>>
>>> If reduceLeftOption is too verbose, how about reduceLeftOpt
>>> instead of optReduceLeft?
>>> (One advantage is that code completion can help you remember
>>> that both exist because you see them together)
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Viktor Klang
>>> Senior Systems Analyst
>>
>
>

Ricky Clarkson
Joined: 2008-12-19,
User offline. Last seen 3 years 2 weeks ago.
Re: Re: Re: As long as the collections classes are changing fo
All Options disallows Option.get.
All exceptions makes the typesystem less useful.

You should have to look at the types to work out how a method handles errors.  That's *exactly* where to look.

2009/1/20 Arthur Peters <arthur [dot] peters [at] gmail [dot] com>
I'm not all that well versed in Scala theory, but just to throw out an idea.

What about an adapter that catches exceptions and returns None in the
exception case or Some(...) in the success case?

If could be called like: optionAdapter(list.reduceLeft(_+_))

An adapter could be created to go the other way too if such was useful.

Also it seems to me that no matter how this discussion is finalized
the library needs to be standardized. As a user I really don't want to
have to look at the docs (or at least type signature) to know how a
given function handles errors. It seems like it should either be all
exceptions or all Options (or all both but that seams like a lot of
overhead). Just my penny worth of thoughts.

-Arthur



On Mon, Jan 19, 2009 at 9:23 AM, Ricky Clarkson
<ricky [dot] clarkson [at] gmail [dot] com> wrote:
> How about
> reduceLeftTheTypesMakeItFrickinObviousThisCanFailButLetsEmbedThatInTheMethodNameAnyway?
>
> How do the types make it obvious that it can fail?  Well, we all know
> List[T] can have 0 elements, so anything on List that returns a T that
> doesn't take a T must, for a 0 element list, do one of:
> * Throw an exception
> * Hang
> * Abort
> * Blow up the planet
> * Return null
> * Use reflection to instantiate a T (but look, there's no Manifest)
>
> 2009/1/19 Dimitris Andreou <jim [dot] andreou [at] gmail [dot] com>
>>
>> That might cause readers to merely cross their _left_ hand's fingers. Or
>> reduce the crossed fingers of their left hand, crossing fewer and fewer
>> until the have none crossed.
>>
>> O/H Viktor Klang έγραψε:
>>>
>>> I'm rooting for: reduceLeftFingersCrossed or the more T.Morrisish
>>> "<---/?"
>>>
>>> On Sun, Jan 18, 2009 at 11:01 PM, Dimitris Andreou <jim [dot] andreou [at] gmail [dot] com
>>> <mailto:jim [dot] andreou [at] gmail [dot] com>> wrote:
>>>
>>>    I would suggest 'tryReduceLeft'. Option is already in the
>>>    signature, no real gain by repeating that, while 'try' gives a
>>>    very concise notice of the fact that you only try to reduceLeft,
>>>    without really knowing it won't fail (failure as in returning
>>>    None). But if there is an already established naming convention
>>>    for dual methods (exception throwing and Option returning), it
>>>    should be followed.
>>>
>>>    O/H Naftoli Gugenheim ������:
>>>
>>>        If reduceLeftOption is too verbose, how about reduceLeftOpt
>>>        instead of optReduceLeft?
>>>        (One advantage is that code completion can help you remember
>>>        that both exist because you see them together)
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Viktor Klang
>>> Senior Systems Analyst
>>
>
>

Tony Morris
Joined: 2008-12-19,
User offline. Last seen 30 weeks 4 days ago.
Re: Re: Re: As long as the collections classes are changing fo

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Arthur Peters wrote:
> I'm not all that well versed in Scala theory, but just to throw out
> an idea. ..
>
> What about an adapter that catches exceptions and returns None in
> the exception case or Some(...) in the success case?
scala.Either would be more appropriate for this. It was proposed but
rejected - it is just a function after all. Instead it lives in the
Scalaz library where it is made good use of regularly.

>
> If could be called like: optionAdapter(list.reduceLeft(_+_))

Scala is not a total language. The type signature tells a lie: forall
A. List[A] => (A => A => A) => A is not a theorem (try it out on paper).
Functions for which an element of the domain does not correspond to an
element in the codomain will exist for longer than you and I in a
non-total language. Sorry to be the bearer of such news :)

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

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJduvOmnpgrYe6r60RAuGJAJ4pesshEa+V1y6rNnTgFe28NaDs/QCaA2q8
iuX22u75w1vrmv2HUG8hlH0=
=6q9L
-----END PGP SIGNATURE-----

Ricky Clarkson
Joined: 2008-12-19,
User offline. Last seen 3 years 2 weeks ago.
Re: Re: Re: As long as the collections classes are changing fo
When you consider that null is part of all types, forall A. List[A] => (A => A => A) => A can be implemented.

Insidious, isn't it?

2009/1/21 Tony Morris <tmorris [at] tmorris [dot] net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Arthur Peters wrote:
> I'm not all that well versed in Scala theory, but just to throw out
> an idea. ..
>
> What about an adapter that catches exceptions and returns None in
> the exception case or Some(...) in the success case?
scala.Either would be more appropriate for this. It was proposed but
rejected - it is just a function after all. Instead it lives in the
Scalaz library where it is made good use of regularly.

>
> If could be called like: optionAdapter(list.reduceLeft(_+_))

Scala is not a total language. The type signature tells a lie: forall
A. List[A] => (A => A => A) => A is not a theorem (try it out on paper).
Functions for which an element of the domain does not correspond to an
element in the codomain will exist for longer than you and I in a
non-total language. Sorry to be the bearer of such news :)

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

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJduvOmnpgrYe6r60RAuGJAJ4pesshEa+V1y6rNnTgFe28NaDs/QCaA2q8
iuX22u75w1vrmv2HUG8hlH0=
=6q9L
-----END PGP SIGNATURE-----


James Iry
Joined: 2008-08-19,
User offline. Last seen 1 year 23 weeks ago.
Re: Re: Re: As long as the collections classes are changing fo
Null doesn't do it because Null isn't a subtype of all types.  Or at least, it shouldn't :-)

scala> def reduce[A](lst : List[A], f : (A => A => A)) : A = null        
<console>:4: error: type mismatch;

Nothing does it.  Literally.

scala> def anythingAtAll[A] : A = anythingAtAll                
anythingAtAll: [A]A


Logically anythingAtAll has type forall A . A.  It's a proof of anything you want.
With that the type checker will happily prove a the proposition forall A . List[A] => (A => A => A) => A without using null or exceptions

scala> def reduce[A](lst : List[A], f : (A => A => A)) : A = anythingAtAll
reduce: [A](List[A],(A) => (A) => A)A

This hole in the type system exists in every Turing complete language even if it doesn't have null or exceptions.  As Tony says, Scala is not a total language so the types have to be taken with a grain of salt.

But yes, null is insidious.

On Wed, Jan 21, 2009 at 1:56 AM, Ricky Clarkson <ricky [dot] clarkson [at] gmail [dot] com> wrote:
When you consider that null is part of all types, forall A. List[A] => (A => A => A) => A can be implemented.

Insidious, isn't it?

2009/1/21 Tony Morris <tmorris [at] tmorris [dot] net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Arthur Peters wrote:
> I'm not all that well versed in Scala theory, but just to throw out
> an idea. ..
>
> What about an adapter that catches exceptions and returns None in
> the exception case or Some(...) in the success case?
scala.Either would be more appropriate for this. It was proposed but
rejected - it is just a function after all. Instead it lives in the
Scalaz library where it is made good use of regularly.

>
> If could be called like: optionAdapter(list.reduceLeft(_+_))

Scala is not a total language. The type signature tells a lie: forall
A. List[A] => (A => A => A) => A is not a theorem (try it out on paper).
Functions for which an element of the domain does not correspond to an
element in the codomain will exist for longer than you and I in a
non-total language. Sorry to be the bearer of such news :)

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

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJduvOmnpgrYe6r60RAuGJAJ4pesshEa+V1y6rNnTgFe28NaDs/QCaA2q8
iuX22u75w1vrmv2HUG8hlH0=
=6q9L
-----END PGP SIGNATURE-----



Copyright © 2012 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland