Nabble - Scala - Debate

Re: inline classes

2009-11-24T06:11:11Z

You could just blow up a caravan.

2009/11/24 Razvan Cojocaru <razie@...>:

>
> Got it... don't pump the brakes any more - the ABS supposedly does it better
> than me. Tx.
>
> I'm a control freak then ... or just want to have some fun, a la "Top
> Gear"... :)
>
>
> Ricky Clarkson wrote:
>>
>> I would suggest leaving performance hints out of a language that you
>> would like to be readable.
>>
>> Investigate the state of the art in the VM instead.
>>
>
>
> -----
> Razvan Cojocaru,
> Work: http://www.sigma-systems.com
> Me: http://feeds.razie.com/RazvanTech
> --
> View this message in context: http://old.nabble.com/inline-classes-tp26488946p26496426.html
> Sent from the Scala - Debate mailing list archive at Nabble.com.
>
>

--
Ricky Clarkson
Java and Scala Programmer, AD Holdings
+44 1565 770804
Skype: ricky_clarkson
Google Talk: ricky.clarkson@...
Google Wave: ricky.clarkson@...

Re: inline classes

2009-11-24T06:03:12Z

Got it... don't pump the brakes any more - the ABS supposedly does it better than me. Tx.

I'm a control freak then ... or just want to have some fun, a la "Top Gear"... :)

Ricky Clarkson wrote:

I would suggest leaving performance hints out of a language that you
would like to be readable.

Investigate the state of the art in the VM instead.

Razvan Cojocaru,
Work: http://www.sigma-systems.com
Me: http://feeds.razie.com/RazvanTech

Re: inline classes

2009-11-23T22:39:16Z

I would suggest leaving performance hints out of a language that you
would like to be readable.

Investigate the state of the art in the VM instead.

2009/11/24 Randall R Schulz <rschulz@...>:

> On Monday November 23 2009, Razvan Cojocaru wrote:
>> do you mean "is" or "should be" ? Indeed, it could at least make sure
>> the classes are allocated on the stack not heap or something...
>
> Is. Would be. Whatever.
>
> In my opinion, it's entirely inappropriate to bake hints of this sort
> into the language.
>
>
>> Randall Schulz wrote:
>> > This is really just a hint to the copmiler and / or the runtime
>> > about use patterns for the class(es) in question. It's better to
>> > let the compiler and / or the runtime decide when such
>> > optimizations are applicable.
>>
>> -----
>> Razvan Cojocaru
>
>
> Randall Schulz
>

--
Ricky Clarkson
Java and Scala Programmer, AD Holdings
+44 1565 770804
Skype: ricky_clarkson
Google Talk: ricky.clarkson@...
Google Wave: ricky.clarkson@...

Re: inline classes

2009-11-23T21:34:40Z

On Monday November 23 2009, Razvan Cojocaru wrote:
> do you mean "is" or "should be" ? Indeed, it could at least make sure
> the classes are allocated on the stack not heap or something...

Is. Would be. Whatever.

In my opinion, it's entirely inappropriate to bake hints of this sort
into the language.

> Randall Schulz wrote:
> > This is really just a hint to the copmiler and / or the runtime
> > about use patterns for the class(es) in question. It's better to
> > let the compiler and / or the runtime decide when such
> > optimizations are applicable.
>
> -----
> Razvan Cojocaru

Randall Schulz

Re: inline classes

2009-11-23T21:07:52Z

do you mean "is" or "should be" ? Indeed, it could at least make sure the classes are allocated on the stack not heap or something...

Randall Schulz wrote:

This is really just a hint to the copmiler and / or the runtime about
use patterns for the class(es) in question. It's better to let the
compiler and / or the runtime decide when such optimizations are
applicable.

Randall Schulz

Razvan Cojocaru,
Work: http://www.sigma-systems.com
Me: http://feeds.razie.com/RazvanTech

Re: inline classes

2009-11-23T17:23:32Z

On Monday November 23 2009, Razvan Cojocaru wrote:
> There's been this debate about the cost of Some(x) vs null.
>
> Can we have inline classes? Basically the inline keyword applied to a
> class indicates that the compiler should avoid creating instances of
> the class.

This is really just a hint to the copmiler and / or the runtime about
use patterns for the class(es) in question. It's better to let the
compiler and / or the runtime decide when such optimizations are
applicable.

> ...
> Razvan Cojocaru,

Randall Schulz

Re: inline classes

2009-11-23T17:12:58Z

Didn't include a solution...

A possibility is to simply change the generated signature of the class's methods to prepend the primary constructor parameters (class parameters?):

inline class ServiceHandle (val loc:AgentHandle, val name:String) {
def action (method:String, args:AttrAccess*) =

basically generates the "static" method
def action (loc:AgentHandle, val name:String, method:String, args:AttrAccess*) =

and then streamlines the calling sequence

new ServiceHandle (l, n) action (m, a) into just action (l,n,m,a)

Razvan Cojocaru,
Work: http://www.sigma-systems.com
Me: http://feeds.razie.com/RazvanTech

inline classes

2009-11-23T17:06:18Z

There's been this debate about the cost of Some(x) vs null.

Can we have inline classes? Basically the inline keyword applied to a class indicates that the compiler should avoid creating instances of the class.

I see myself using this pattern quite often to add functionality to existing code or to create nice DSL-like syntax - however, the extra classes are most often not neccessary:

object Service {
def apply (location:AgentHandle, name:String) : ServiceHandle =
new ServiceHandle (location, name)
}

inline class ServiceHandle (val loc:AgentHandle, val name:String) {
def action (method:String, args:AttrAccess*) =
if (loc == Agents.me)
new ServiceActionToInvoke(name, AI(method), args:_*)
else
new ServiceActionToInvoke(loc.url, name, AI(method), args:_*)
}

so that you can write Service("console") action ("writeln", ...)

It would be great if i could mark the ServiceHandle class as inline...I don't actually need instances created.

Likewise about implicit and RichInt or RichString etc...it's basically.

It may apply to Some as well and end that debate :)

Sorry if this has been suggested before, search "inline class" didn't return anything.

Razvan Cojocaru,
Work: http://www.sigma-systems.com
Me: http://feeds.razie.com/RazvanTech

Re: Only setting a field is forbidden

2009-11-23T07:39:18Z

It does. Feel free to make the getter private.

2009/11/23 Elazar Leibovich <elazarl@...>:

> I believe the Esser knew that, but wondered why wouldn't the spec. allow
> set-only field of an object (for internal use only).
>
> On Mon, Nov 23, 2009 at 3:02 PM, Daniel Sobral <dcsobral@...> wrote:
>>
>> Setter syntax only works if there's a getter of the same name. It's in the
>> specification.
>>
>> On Mon, Nov 23, 2009 at 8:50 AM, f.esser <esser.friedrich@...>
>> wrote:
>>>
>>> Is there a reason, why the last line is an error (Scala 2.8), if
>>> def foo= f
>>> is not present.
>>>
>>> class Foo {
>>> private var f: String= _
>>> // def foo= f
>>> def foo_= (s: String) = f= s
>>> }
>>>
>>> object SnippetTest {
>>>
>>> def main(args: Array[String]) = {
>>> val f= new Foo
>>> f.foo_=("oha") // ok!
>>> f.foo= "oha" // error without: def foo= f
>>> }
>>> }
>>> --
>>> View this message in context:
>>> http://old.nabble.com/Only-setting-a-field-is-forbidden-tp26475135p26475135.html
>>> Sent from the Scala - Debate mailing list archive at Nabble.com.
>>>
>>
>>
>>
>> --
>> Daniel C. Sobral
>>
>> Veni, vidi, veterni.
>
>

--
Ricky Clarkson
Java and Scala Programmer, AD Holdings
+44 1565 770804
Skype: ricky_clarkson
Google Talk: ricky.clarkson@...
Google Wave: ricky.clarkson@...

Re: Only setting a field is forbidden

2009-11-23T07:34:27Z

I believe the Esser knew that, but wondered why wouldn't the spec. allow set-only field of an object (for internal use only).

On Mon, Nov 23, 2009 at 3:02 PM, Daniel Sobral <dcsobral@...> wrote:

Setter syntax only works if there's a getter of the same name. It's in the specification.

On Mon, Nov 23, 2009 at 8:50 AM, f.esser <esser.friedrich@...> wrote:

Is there a reason, why the last line is an error (Scala 2.8), if
def foo= f
is not present.

class Foo {
private var f: String= _
// def foo= f
def foo_= (s: String) = f= s
}

object SnippetTest {

def main(args: Array[String]) = {
val f= new Foo
f.foo_=("oha") // ok!
f.foo= "oha" // error without: def foo= f
}
}
--
View this message in context: http://old.nabble.com/Only-setting-a-field-is-forbidden-tp26475135p26475135.html
Sent from the Scala - Debate mailing list archive at Nabble.com.

--
Daniel C. Sobral

Veni, vidi, veterni.

Re: Only setting a field is forbidden

2009-11-23T05:02:46Z

Setter syntax only works if there's a getter of the same name. It's in the specification.

On Mon, Nov 23, 2009 at 8:50 AM, f.esser <esser.friedrich@...> wrote:

Is there a reason, why the last line is an error (Scala 2.8), if
def foo= f
is not present.

class Foo {
private var f: String= _
// def foo= f
def foo_= (s: String) = f= s
}

object SnippetTest {

def main(args: Array[String]) = {
val f= new Foo
f.foo_=("oha") // ok!
f.foo= "oha" // error without: def foo= f
}
}
--
View this message in context: http://old.nabble.com/Only-setting-a-field-is-forbidden-tp26475135p26475135.html
Sent from the Scala - Debate mailing list archive at Nabble.com.

--
Daniel C. Sobral

Veni, vidi, veterni.

Only setting a field is forbidden

2009-11-23T02:50:44Z

Is there a reason, why the last line is an error (Scala 2.8), if
def foo= f
is not present.

class Foo {
private var f: String= _
// def foo= f
def foo_= (s: String) = f= s
}

object SnippetTest {

def main(args: Array[String]) = {
val f= new Foo
f.foo_=("oha") // ok!
f.foo= "oha" // error without: def foo= f
}
}

Re: Binary Literals and underscore numbers in Scala?

2009-11-22T11:42:52Z

On Sat, Nov 21, 2009 at 13:38, Landei <Daniel.Gronau@...> wrote:
>
> The binary literal and underscore number "coins" just hit the last Java7
> milestone. Are there any plans to add these features in Scala? I guess it
> wouldn't be too complicated to implement (but probably too complicated to
> me).

Language complication from these features is more then utility (in
Java 7 too). Moreover, it is time to remove features from Scala.

S.

> Cheers,
> Daniel
> --
> View this message in context: http://old.nabble.com/Binary-Literals-and-underscore-numbers-in-Scala--tp26454692p26454692.html
> Sent from the Scala - Debate mailing list archive at Nabble.com.
>
>

Re: Re: Option and NotNull

2009-11-22T08:31:53Z

On Sun, Nov 22, 2009 at 18:24, Daniel Sobral <dcsobral@...> wrote:
> But it can appear on a 2.8.1, for instance, which might not be as far as all
> that.

I hope, 2.8.x releases will contain bugfixes only.

S.

> On Sun, Nov 22, 2009 at 1:09 PM, David Flemström <david.flemstrom@...>
> wrote:
>>
>> I would have liked to see it in 2.8. Who knows when 2.9 or even 3.0 will
>> come
>> out? It will probably be a year or more until then.
>>
>> On Sunday 22 November 2009 15:24:33 Jesper Nordenberg wrote:
>> > Martin just wrote it will be worked on after the 2.8 release, which is
>> > certainly more important than NotNull at this time. But I agree that it
>> > should be fixed in a not too distant future.
>> >
>> > /Jesper Nordenberg
>> >
>> > David Flemström wrote:
>> > > It's sad that this has such a low priority; about 50% of the bugs I
>> > > get
>> > > when doing Java inter-operation come from NPE's, or the lack thereof
>> > > as
>> > > the case may be.
>> > >
>> > > I would personally really have preferred if there wasn't a null in
>> > > Scala
>> > > at all, and if Java methods would have thrown a NullException when
>> > > they
>> > > return null (The null check for the exception throw would be optimized
>> > > away for the case when a special method "toOption(javaMethod())" (or
>> > > similarly named) was used)
>> > >
>> > > On Saturday 21 November 2009 17:55:51 martin odersky wrote:
>> > >> NotNull is very much work in progress (or should I say: in
>> > >> suspension?). We'll get back to it sometimes after 2.8 is released.
>> > >>
>> > >> Cheers
>> > >>
>> > >> -- Martin
>> > >>
>> > >>
>> > >>
>> > >> On Sat, Nov 21, 2009 at 2:50 PM, Erik Engbrecht
>> > >>
>> > >> <erik.engbrecht@...> wrote:
>> > >>> That's different than what I'm suggesting. That would be:
>> > >>> trait Option[+T <: NotNull]
>> > >>> so that object contained by the Option can't be null. What I'm
>> > >>> suggesting is:
>> > >>> trait Option[+T] with NotNull
>> > >>> so that the compiler will enforce that a reference to an Option is
>> > >>> not
>> > >>> null. The option would still be allowed to contain null.
>> > >>> On Sat, Nov 21, 2009 at 8:42 AM, Kevin Wright
>> > >>>
>> > >>> <kev.lee.wright@...> wrote:
>> > >>>> There's a lovely boundary condition when fetching i.e. the 5th item
>> > >>>> from a list
>> > >>>> None => The list doesn't have a 5th item
>> > >>>> Some(xxx) => The 5th item exists and contains the value xxx
>> > >>>> Some(null) => The 5th item exists and was explicitly populated with
>> > >>>> null
>> > >>>>
>> > >>>> On Sat, Nov 21, 2009 at 1:25 PM, Francois <fanf42@...> wrote:
>> > >>>>> On 21/11/2009 13:53, Erik Engbrecht wrote:
>> > >>>>>> I haven't dug into this much, so I could be completely off base,
>> > >>>>>> but
>> > >>>>>> why doesn't Option extend NotNull?
>> > >>>>>
>> > >>>>> I believe that it was already discussed in (a, don't remember
>> > >>>>> which)
>> > >>>>> mailing list and that some corner cases make that modification
>> > >>>>> rather
>> > >>>>> disruptive for existing code. Or impossible.
>> > >>>>>
>> > >>>>> A mailing list archive digging may be helpful here.
>> > >>>>>
>> > >>>>>
>> > >>>>> --
>> > >>>>> Francois ARMAND
>> > >>>>> http://fanf42.blogspot.com
>> > >>>
>> > >>> --
>> > >>> http://erikengbrecht.blogspot.com/
>> >
>
>
>
> --
> Daniel C. Sobral
>
> Veni, vidi, veterni.
>

Re: Re: Option and NotNull

2009-11-22T07:24:54Z

But it can appear on a 2.8.1, for instance, which might not be as far as all that.

On Sun, Nov 22, 2009 at 1:09 PM, David Flemström <david.flemstrom@...> wrote:

I would have liked to see it in 2.8. Who knows when 2.9 or even 3.0 will come
out? It will probably be a year or more until then.

On Sunday 22 November 2009 15:24:33 Jesper Nordenberg wrote:
> Martin just wrote it will be worked on after the 2.8 release, which is
> certainly more important than NotNull at this time. But I agree that it
> should be fixed in a not too distant future.
>
> /Jesper Nordenberg
>
> David Flemström wrote:
> > It's sad that this has such a low priority; about 50% of the bugs I get
> > when doing Java inter-operation come from NPE's, or the lack thereof as
> > the case may be.
> >
> > I would personally really have preferred if there wasn't a null in Scala
> > at all, and if Java methods would have thrown a NullException when they
> > return null (The null check for the exception throw would be optimized
> > away for the case when a special method "toOption(javaMethod())" (or
> > similarly named) was used)
> >
> > On Saturday 21 November 2009 17:55:51 martin odersky wrote:
> >> NotNull is very much work in progress (or should I say: in
> >> suspension?). We'll get back to it sometimes after 2.8 is released.
> >>
> >> Cheers
> >>
> >> -- Martin
> >>
> >>
> >>
> >> On Sat, Nov 21, 2009 at 2:50 PM, Erik Engbrecht
> >>
> >> <erik.engbrecht@...> wrote:
> >>> That's different than what I'm suggesting. That would be:
> >>> trait Option[+T <: NotNull]
> >>> so that object contained by the Option can't be null. What I'm
> >>> suggesting is:
> >>> trait Option[+T] with NotNull
> >>> so that the compiler will enforce that a reference to an Option is not
> >>> null. The option would still be allowed to contain null.
> >>> On Sat, Nov 21, 2009 at 8:42 AM, Kevin Wright
> >>>
> >>> <kev.lee.wright@...> wrote:
> >>>> There's a lovely boundary condition when fetching i.e. the 5th item
> >>>> from a list
> >>>> None => The list doesn't have a 5th item
> >>>> Some(xxx) => The 5th item exists and contains the value xxx
> >>>> Some(null) => The 5th item exists and was explicitly populated with
> >>>> null
> >>>>
> >>>> On Sat, Nov 21, 2009 at 1:25 PM, Francois <fanf42@...> wrote:
> >>>>> On 21/11/2009 13:53, Erik Engbrecht wrote:
> >>>>>> I haven't dug into this much, so I could be completely off base, but
> >>>>>> why doesn't Option extend NotNull?
> >>>>>
> >>>>> I believe that it was already discussed in (a, don't remember which)
> >>>>> mailing list and that some corner cases make that modification rather
> >>>>> disruptive for existing code. Or impossible.
> >>>>>
> >>>>> A mailing list archive digging may be helpful here.
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Francois ARMAND
> >>>>> http://fanf42.blogspot.com
> >>>
> >>> --
> >>> http://erikengbrecht.blogspot.com/
>

--
Daniel C. Sobral

Veni, vidi, veterni.

Re: Re: Option and NotNull

2009-11-22T07:09:36Z

I would have liked to see it in 2.8. Who knows when 2.9 or even 3.0 will come
out? It will probably be a year or more until then.

On Sunday 22 November 2009 15:24:33 Jesper Nordenberg wrote:

> Martin just wrote it will be worked on after the 2.8 release, which is
> certainly more important than NotNull at this time. But I agree that it
> should be fixed in a not too distant future.
>
> /Jesper Nordenberg
>
> David Flemström wrote:
> > It's sad that this has such a low priority; about 50% of the bugs I get
> > when doing Java inter-operation come from NPE's, or the lack thereof as
> > the case may be.
> >
> > I would personally really have preferred if there wasn't a null in Scala
> > at all, and if Java methods would have thrown a NullException when they
> > return null (The null check for the exception throw would be optimized
> > away for the case when a special method "toOption(javaMethod())" (or
> > similarly named) was used)
> >
> > On Saturday 21 November 2009 17:55:51 martin odersky wrote:
> >> NotNull is very much work in progress (or should I say: in
> >> suspension?). We'll get back to it sometimes after 2.8 is released.
> >>
> >> Cheers
> >>
> >> -- Martin
> >>
> >>
> >>
> >> On Sat, Nov 21, 2009 at 2:50 PM, Erik Engbrecht
> >>
> >> <erik.engbrecht@...> wrote:
> >>> That's different than what I'm suggesting. That would be:
> >>> trait Option[+T <: NotNull]
> >>> so that object contained by the Option can't be null. What I'm
> >>> suggesting is:
> >>> trait Option[+T] with NotNull
> >>> so that the compiler will enforce that a reference to an Option is not
> >>> null. The option would still be allowed to contain null.
> >>> On Sat, Nov 21, 2009 at 8:42 AM, Kevin Wright
> >>>
> >>> <kev.lee.wright@...> wrote:
> >>>> There's a lovely boundary condition when fetching i.e. the 5th item
> >>>> from a list
> >>>> None => The list doesn't have a 5th item
> >>>> Some(xxx) => The 5th item exists and contains the value xxx
> >>>> Some(null) => The 5th item exists and was explicitly populated with
> >>>> null
> >>>>
> >>>> On Sat, Nov 21, 2009 at 1:25 PM, Francois <fanf42@...> wrote:
> >>>>> On 21/11/2009 13:53, Erik Engbrecht wrote:
> >>>>>> I haven't dug into this much, so I could be completely off base, but
> >>>>>> why doesn't Option extend NotNull?
> >>>>>
> >>>>> I believe that it was already discussed in (a, don't remember which)
> >>>>> mailing list and that some corner cases make that modification rather
> >>>>> disruptive for existing code. Or impossible.
> >>>>>
> >>>>> A mailing list archive digging may be helpful here.
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Francois ARMAND
> >>>>> http://fanf42.blogspot.com
> >>>
> >>> --
> >>> http://erikengbrecht.blogspot.com/
>

Re: Option and NotNull

2009-11-22T06:24:33Z

Martin just wrote it will be worked on after the 2.8 release, which is
certainly more important than NotNull at this time. But I agree that it
should be fixed in a not too distant future.

/Jesper Nordenberg

David Flemström wrote:

> It's sad that this has such a low priority; about 50% of the bugs I get when
> doing Java inter-operation come from NPE's, or the lack thereof as the case
> may be.
>
> I would personally really have preferred if there wasn't a null in Scala at
> all, and if Java methods would have thrown a NullException when they return
> null (The null check for the exception throw would be optimized away for the
> case when a special method "toOption(javaMethod())" (or similarly named) was
> used)
>
> On Saturday 21 November 2009 17:55:51 martin odersky wrote:
>> NotNull is very much work in progress (or should I say: in
>> suspension?). We'll get back to it sometimes after 2.8 is released.
>>
>> Cheers
>>
>> -- Martin
>>
>>
>>
>> On Sat, Nov 21, 2009 at 2:50 PM, Erik Engbrecht
>>
>> <erik.engbrecht@...> wrote:
>>> That's different than what I'm suggesting. That would be:
>>> trait Option[+T <: NotNull]
>>> so that object contained by the Option can't be null. What I'm
>>> suggesting is:
>>> trait Option[+T] with NotNull
>>> so that the compiler will enforce that a reference to an Option is not
>>> null. The option would still be allowed to contain null.
>>> On Sat, Nov 21, 2009 at 8:42 AM, Kevin Wright
>>>
>>> <kev.lee.wright@...> wrote:
>>>> There's a lovely boundary condition when fetching i.e. the 5th item from
>>>> a list
>>>> None => The list doesn't have a 5th item
>>>> Some(xxx) => The 5th item exists and contains the value xxx
>>>> Some(null) => The 5th item exists and was explicitly populated with null
>>>>
>>>> On Sat, Nov 21, 2009 at 1:25 PM, Francois <fanf42@...> wrote:
>>>>> On 21/11/2009 13:53, Erik Engbrecht wrote:
>>>>>> I haven't dug into this much, so I could be completely off base, but
>>>>>> why doesn't Option extend NotNull?
>>>>> I believe that it was already discussed in (a, don't remember which)
>>>>> mailing list and that some corner cases make that modification rather
>>>>> disruptive for existing code. Or impossible.
>>>>>
>>>>> A mailing list archive digging may be helpful here.
>>>>>
>>>>>
>>>>> --
>>>>> Francois ARMAND
>>>>> http://fanf42.blogspot.com
>>> --
>>> http://erikengbrecht.blogspot.com/
>

Re: Option and NotNull

2009-11-21T12:28:04Z

It's sad that this has such a low priority; about 50% of the bugs I get when
doing Java inter-operation come from NPE's, or the lack thereof as the case
may be.

I would personally really have preferred if there wasn't a null in Scala at
all, and if Java methods would have thrown a NullException when they return
null (The null check for the exception throw would be optimized away for the
case when a special method "toOption(javaMethod())" (or similarly named) was
used)

On Saturday 21 November 2009 17:55:51 martin odersky wrote:

> NotNull is very much work in progress (or should I say: in
> suspension?). We'll get back to it sometimes after 2.8 is released.
>
> Cheers
>
> -- Martin
>
>
>
> On Sat, Nov 21, 2009 at 2:50 PM, Erik Engbrecht
>
> <erik.engbrecht@...> wrote:
> > That's different than what I'm suggesting. That would be:
> > trait Option[+T <: NotNull]
> > so that object contained by the Option can't be null. What I'm
> > suggesting is:
> > trait Option[+T] with NotNull
> > so that the compiler will enforce that a reference to an Option is not
> > null. The option would still be allowed to contain null.
> > On Sat, Nov 21, 2009 at 8:42 AM, Kevin Wright
> >
> > <kev.lee.wright@...> wrote:
> >> There's a lovely boundary condition when fetching i.e. the 5th item from
> >> a list
> >> None => The list doesn't have a 5th item
> >> Some(xxx) => The 5th item exists and contains the value xxx
> >> Some(null) => The 5th item exists and was explicitly populated with null
> >>
> >> On Sat, Nov 21, 2009 at 1:25 PM, Francois <fanf42@...> wrote:
> >>> On 21/11/2009 13:53, Erik Engbrecht wrote:
> >>>> I haven't dug into this much, so I could be completely off base, but
> >>>> why doesn't Option extend NotNull?
> >>>
> >>> I believe that it was already discussed in (a, don't remember which)
> >>> mailing list and that some corner cases make that modification rather
> >>> disruptive for existing code. Or impossible.
> >>>
> >>> A mailing list archive digging may be helpful here.
> >>>
> >>>
> >>> --
> >>> Francois ARMAND
> >>> http://fanf42.blogspot.com
> >
> > --
> > http://erikengbrecht.blogspot.com/
>

Re: Opening request for debate: the "requires" clause...

2009-11-21T11:09:23Z

I was surprised that nobody else picked up on this one.

It just makes so much sense to me. The "requires" syntax does portray very well one of the main characteristics of this language, which is working on the small and the large.

On Fri, Nov 20, 2009 at 10:11 PM, Dave Griffith <dave.l.griffith@...> wrote:

I strongly advocate the resurrection of the "requires" syntax. Clean,
evocative, precise, giving an exact indication of the normal usage. That it
was yanked due to griping from the JML community (??!?!WTF??!!!?) was a
ridiculous inversion of importance.

--Dave Griffith
--
View this message in context: http://old.nabble.com/Opening-request-for-debate%3A-the-%22requires%22-clause...-tp26453515p26453643.html
Sent from the Scala - Debate mailing list archive at Nabble.com.

Re: Option and NotNull

2009-11-21T08:55:51Z

NotNull is very much work in progress (or should I say: in
suspension?). We'll get back to it sometimes after 2.8 is released.

Cheers

-- Martin

On Sat, Nov 21, 2009 at 2:50 PM, Erik Engbrecht
<erik.engbrecht@...> wrote:

> That's different than what I'm suggesting. That would be:
> trait Option[+T <: NotNull]
> so that object contained by the Option can't be null. What I'm suggesting
> is:
> trait Option[+T] with NotNull
> so that the compiler will enforce that a reference to an Option is not null.
> The option would still be allowed to contain null.
> On Sat, Nov 21, 2009 at 8:42 AM, Kevin Wright
> <kev.lee.wright@...> wrote:
>>
>> There's a lovely boundary condition when fetching i.e. the 5th item from a
>> list
>> None => The list doesn't have a 5th item
>> Some(xxx) => The 5th item exists and contains the value xxx
>> Some(null) => The 5th item exists and was explicitly populated with null
>>
>> On Sat, Nov 21, 2009 at 1:25 PM, Francois <fanf42@...> wrote:
>>>
>>> On 21/11/2009 13:53, Erik Engbrecht wrote:
>>>>
>>>> I haven't dug into this much, so I could be completely off base, but why
>>>> doesn't Option extend NotNull?
>>>
>>> I believe that it was already discussed in (a, don't remember which)
>>> mailing list and that some corner cases make that modification rather
>>> disruptive for existing code. Or impossible.
>>>
>>> A mailing list archive digging may be helpful here.
>>>
>>>
>>> --
>>> Francois ARMAND
>>> http://fanf42.blogspot.com
>>>
>>
>
>
>
> --
> http://erikengbrecht.blogspot.com/
>

Mailing list reminder: Scala-debate

2009-11-21T06:32:02Z

Welcome to the "Scala-debate" mailing list.

This automatic reminder is sent once a month to the list,
to keep subscribers up-to-date with the mailing list services,
and to help keeping the list on topic.

-------------------------------------------------------------------

The "Scala-debate" mailing list:

This list is a more relaxed forum for Scala discussions
that would probably be off-topic or too convoluted for
the other lists, but that may still be quite interesting
to follow for a selected readership.

In particular, the following are appropriate:

* threads that evolved beyond their initial topic,
and have become too long or convoluted to be
of interest to most readers
* threads discussing extremely specialized topics
* threads that are mostly speculative in nature,
out-of-the-box thinking, philosophical views
(as long as they are still somehow related
to Scala)
* debates (of course)

The "Scala-debate" list is the natural destination of all
the threads that start on other mailing lists, but are no
longer on topic on their original list, or have turned
into an in-depth debate about something.

-------------------------------------------------------------------

Other information:

There are several Scala lists devoted to individual topics (and
more may be created in the future). For the full list, please
see: http://www.scala-lang.org/node/199

Try to avoid cross-posting whenever possible. If you can, select
the list that is closer to your topic and post in that list only.
In any case, never cross-post replies.

If you ever want to unsubscribe from this list, just follow the
instructions on this page:
http://listes.epfl.ch/doc_en.cgi?liste=scala-debate

Thank you!
The Scala Team

Re: Option and NotNull

2009-11-21T05:50:08Z

That's different than what I'm suggesting. That would be:

trait Option[+T <: NotNull]

so that object contained by the Option can't be null. What I'm suggesting is:

trait Option[+T] with NotNull

so that the compiler will enforce that a reference to an Option is not null. The option would still be allowed to contain null.

On Sat, Nov 21, 2009 at 8:42 AM, Kevin Wright <kev.lee.wright@...> wrote:

There's a lovely boundary condition when fetching i.e. the 5th item from a list

None => The list doesn't have a 5th item
Some(xxx) => The 5th item exists and contains the value xxx

Some(null) => The 5th item exists and was explicitly populated with null

On Sat, Nov 21, 2009 at 1:25 PM, Francois <fanf42@...> wrote:

On 21/11/2009 13:53, Erik Engbrecht wrote:

I haven't dug into this much, so I could be completely off base, but why
doesn't Option extend NotNull?

I believe that it was already discussed in (a, don't remember which) mailing list and that some corner cases make that modification rather disruptive for existing code. Or impossible.

A mailing list archive digging may be helpful here.

--
Francois ARMAND
http://fanf42.blogspot.com

--
http://erikengbrecht.blogspot.com/

Re: Option and NotNull

2009-11-21T05:42:28Z

There's a lovely boundary condition when fetching i.e. the 5th item from a list

None => The list doesn't have a 5th item

Some(xxx) => The 5th item exists and contains the value xxx

Some(null) => The 5th item exists and was explicitly populated with null

On Sat, Nov 21, 2009 at 1:25 PM, Francois <fanf42@...> wrote:

On 21/11/2009 13:53, Erik Engbrecht wrote:

I haven't dug into this much, so I could be completely off base, but why
doesn't Option extend NotNull?

I believe that it was already discussed in (a, don't remember which) mailing list and that some corner cases make that modification rather disruptive for existing code. Or impossible.

A mailing list archive digging may be helpful here.

--
Francois ARMAND
http://fanf42.blogspot.com

Re: Option and NotNull

2009-11-21T05:25:30Z

On 21/11/2009 13:53, Erik Engbrecht wrote:
> I haven't dug into this much, so I could be completely off base, but why
> doesn't Option extend NotNull?

I believe that it was already discussed in (a, don't remember which)
mailing list and that some corner cases make that modification rather
disruptive for existing code. Or impossible.

A mailing list archive digging may be helpful here.

--
Francois ARMAND
http://fanf42.blogspot.com

Option and NotNull

2009-11-21T04:53:48Z

I haven't dug into this much, so I could be completely off base, but why doesn't Option extend NotNull?

Here's an interpreter sessions showing usage of NotNull for reference. It seems to me that having a null where one would expect an Option is just plain evil, and if there's compiler support that can be enlisted to prevent it, it should be enlisted.

scala> def foo(x: String with NotNull) = "Hello, " + x + "!"

foo: (String with NotNull)java.lang.String

scala> foo(null)

<console>:6: error: type mismatch;

found : Null(null)

required: String with NotNull

foo(null)

scala> val x = "world"

x: java.lang.String = world

scala> foo(x)

<console>:7: error: type mismatch;

found : java.lang.String

required: String with NotNull

foo(x)

scala> val y: String with NotNull = "world"

y: String with NotNull = world

scala> foo(y)

res2: java.lang.String = Hello, world!

scala> def bar(x: String) = "Hello, " + x + "!"

bar: (String)java.lang.String

scala> bar(null)

res3: java.lang.String = Hello, null!

scala> foo("world")

res4: java.lang.String = Hello, world!

scala>

Binary Literals and underscore numbers in Scala?

2009-11-21T02:38:40Z

Hi!

The binary literal and underscore number "coins" just hit the last Java7 milestone. Are there any plans to add these features in Scala? I guess it wouldn't be too complicated to implement (but probably too complicated to me).

Cheers,
Daniel

Re: Opening request for debate: the "requires" clause...

2009-11-20T20:11:27Z

I strongly advocate the resurrection of the "requires" syntax. Clean, evocative, precise, giving an exact indication of the normal usage. That it was yanked due to griping from the JML community (??!?!WTF??!!!?) was a ridiculous inversion of importance.

--Dave Griffith

Opening request for debate: the "requires" clause...

2009-11-20T19:39:16Z

Hello All,

I am wondering how people few about this, but I am all for the return of the "requires" syntax as an option to define selftypes.

That syntax is much more intuitive when you are implementing system modules as traits and defining the dependencies of those modules using selftypes.

From the Programming in Scala book, where SimpleRecipes uses fruits defined in SimpleFoods, this is how one would define the dependency of SimpleRecipes on SimpleFoods with the selftype syntax in Scala 2.7:

trait SimpleRecipes {

this: SimpleFoods => // expresses the dependency by having SimpleFoods as the selftype

object FruitSalad extends Recipe("Fruit Salad", List(Apple, Pear)) // Apple and Pear are in scope.

...

}

The syntax above is probably more precise than the "requires" syntax in earlier versions of Scala, but from the context of combining system's modules (which is what SimpleRecipes and SimpleFoods are in this example; they are part of a larger system of Recipes), the "requires" syntax is so much more intuitive:

trait SimpleRecipes requires SimpleFoods {

object FruitSalad extends Recipe("Fruit Salad", List(Apple, Pear))

}

I would love it to come back even if optional.

- Quenio

Re: Closures make it into Java 7

2009-11-19T12:38:27Z

I would suggest that, for example, () => println("hello"), would be
better typed to match its context, rather than automatically being a
Function0[Unit] (and then maybe implicitly converted to a Runnable).

Without a new language construct. Does this break any code?

2009/11/19 Philip Köster <philip.koester@...>:

>> The whole point of Scala's language features is that better Java interop
>> is "just a library".
>
> Of course this is what makes Scala so appealing: that it would let you
> design advanced libraries that are both pleasant to use and read. And
> pleasant to design, even! As for automatic ``closure conversion," as Ricky
> called it, we would of course need a new construct in the language, which
> should be easy to implement as well as easy to understand and adopt. Groovy
> users have come to love this feature. In Scala, once you have implicit
> conversions to do the job for `Runnable', you might need the same for
> `Callable', and then, while you're at it, for `Future', `RunnableFuture' and
> what have you. This will easily bloat your collection of implicit defs anf
> force you to write boilerplate.
>
> While it is true what you wrote and while I agree this to be a good thing, a
> second point of Scala is to avoid boilerplate. This is not just a matter of
> design or taste---code that comprises less boilerplate is easier to review,
> which directly increases robustness and security.
>
> Best
> ---Ph.
>

--
Ricky Clarkson
Java and Scala Programmer, AD Holdings
+44 1565 770804
Skype: ricky_clarkson
Google Talk: ricky.clarkson@...
Google Wave: ricky.clarkson@...

Re: Closures make it into Java 7

2009-11-19T11:42:58Z

Kris Nuttycombe wrote:

> Much better in my opinion would
> be:
>
> implicit def f2richF[T](f: Function0[T]): RichFunction0[T] = RichFunction0(f)
>
> case class RichFunction0[T](f: Function0[T]) {
> def runnable = new Runnable {
> def run: Unit = f()
> }
> }

What is improved this way? I'm asking because I don't see it at first
glance.

> Closure conversion seems like it'd obscure a whole lot of potentially
> important type information, particularly if a closure was being
> converted in a place where all the types are inferred.

Mind to share an example? What is lost, and in which direction? Of
course I don't want to be able to reconstruct all of my type signatures
when Java answers me. My thoughts concentrate on the way Scala to Java
only, and how that could be simplified. Now ``closure conversion," where
I would prefer the term ``function conversion (to Java interfaces)" is
nothing new and already implemented in other languages such as Groovy.

---Phil

Re: Closures make it into Java 7

2009-11-19T11:38:33Z

Jorge Ortiz wrote:

> I guess I don't see boilerplate in the -library- as that big of a
> problem, as long as user code is fairly clean.

As much as I agree that the burden should always be taken by the
designer of a library, not by its users, library designers are
themselves users, namely users of the language. The more they are forced
to repeat themselves, the more likely mistakes are to sneak in. It is
the same as with prose: the author might need weeks, months, or years
even to write a short story that the audience is supposed to read in an
hour or less.

> Yes, Java has a lot of
> cases/classes that need to be handled (tragic what Java resorted to for
> lack of a Function interface!), but such are the perils of interop with
> Java.

I don't understand what you mean. Java's lack of a `Function' interface
is not an explanation or justification why I need implicit defs for each
and every interface I need to deal with. `Runnable' was only one
example---it could easily be transferred to every Java interface I need
to deliver.

And we haven't even talked about duck typing yet. One could argue, ``if
my class has a `run' method taking no args, I want to be able to pass it
as a `Runnable' to the Java world."

---Ph.

Re: Closures make it into Java 7

2009-11-19T11:24:59Z

I guess I don't see boilerplate in the -library- as that big of a problem, as long as user code is fairly clean. Yes, Java has a lot of cases/classes that need to be handled (tragic what Java resorted to for lack of a Function interface!), but such are the perils of interop with Java.

--j

On Thu, Nov 19, 2009 at 10:34 AM, Philip Köster <philip.koester@...> wrote:

The whole point of Scala's language features is that better Java interop is "just a library".

Of course this is what makes Scala so appealing: that it would let you design advanced libraries that are both pleasant to use and read. And pleasant to design, even! As for automatic ``closure conversion," as Ricky called it, we would of course need a new construct in the language, which should be easy to implement as well as easy to understand and adopt. Groovy users have come to love this feature. In Scala, once you have implicit conversions to do the job for `Runnable', you might need the same for `Callable', and then, while you're at it, for `Future', `RunnableFuture' and what have you. This will easily bloat your collection of implicit defs anf force you to write boilerplate.

While it is true what you wrote and while I agree this to be a good thing, a second point of Scala is to avoid boilerplate. This is not just a matter of design or taste---code that comprises less boilerplate is easier to review, which directly increases robustness and security.

Best
---Ph.

Re: Closures make it into Java 7

2009-11-19T11:02:46Z

On Thu, Nov 19, 2009 at 11:34 AM, Philip Köster <philip.koester@...> wrote:

There's boilerplate, and then there's obfuscating the types. I'm very
wary of implicit conversions which perform conversions like Function0
=> Runnable without a syntactic cue. Much better in my opinion would
be:

implicit def f2richF[T](f: Function0[T]): RichFunction0[T] = RichFunction0(f)

case class RichFunction0[T](f: Function0[T]) {
def runnable = new Runnable {
def run: Unit = f()
}
}

Closure conversion seems like it'd obscure a whole lot of potentially
important type information, particularly if a closure was being
converted in a place where all the types are inferred.

Kris

Re: Closures make it into Java 7

2009-11-19T10:34:15Z

> The whole point of Scala's language features is that better Java interop
> is "just a library".

Of course this is what makes Scala so appealing: that it would let you
design advanced libraries that are both pleasant to use and read. And
pleasant to design, even! As for automatic ``closure conversion," as
Ricky called it, we would of course need a new construct in the
language, which should be easy to implement as well as easy to
understand and adopt. Groovy users have come to love this feature. In
Scala, once you have implicit conversions to do the job for `Runnable',
you might need the same for `Callable', and then, while you're at it,
for `Future', `RunnableFuture' and what have you. This will easily bloat
your collection of implicit defs anf force you to write boilerplate.

While it is true what you wrote and while I agree this to be a good
thing, a second point of Scala is to avoid boilerplate. This is not just
a matter of design or taste---code that comprises less boilerplate is
easier to review, which directly increases robustness and security.

Best
---Ph.

Re: Design by contract, inline unit testing

2009-11-19T10:27:38Z

> 1. I've seen Design by contract in D and Eiffel (inline with the class
> and method definitions, as it ought to be), and I really like it;
> however, I've never had the leisure of being able to _use_ such a
> language for a _real project_. I'm sure I could invent some Scala

please also see JML under ESC/Java

http://kind.ucd.ie/products/opensource/ESCJava2/