Scala future, Sing#

2009-08-22 Thread bearophile
As Sing# (http://en.wikipedia.org/wiki/Sing_sharp ) and Chapel, Scala is one of the languages to be followed more, because they share some of future purposes of D2/D3. A small presentation about the close future of Scala (it's not a general introduction to Scala): "Scala -- The Next 5 Years" by

Re: Scala future, Sing#

2009-08-24 Thread Jari-Matti Mäkelä
bearophile wrote: > As Sing# (http://en.wikipedia.org/wiki/Sing_sharp ) and Chapel, Scala is > one of the languages to be followed more, because they share some of > future purposes of D2/D3. > > A small presentation about the close future of Scala (it's not a general > introduction to Scala): "S

Re: Scala future, Sing#

2009-08-24 Thread bearophile
Jari-Matti M.: >There are certainly truckloads of features that could be taken from Scala to >D.< But D2 is already quite complex, so it's better to add things carefully. For example patterm matching is useful, but it adds a lot of complexity too. >But I'm afraid that the desire to have famil

Re: Scala future, Sing#

2009-08-24 Thread Walter Bright
Jari-Matti Mäkelä wrote: bearophile wrote: As Sing# (http://en.wikipedia.org/wiki/Sing_sharp ) and Chapel, Scala is one of the languages to be followed more, because they share some of future purposes of D2/D3. A small presentation about the close future of Scala (it's not a general introducti

Re: Scala future, Sing#

2009-08-24 Thread Ary Borenszweig
Walter Bright escribió: Jari-Matti Mäkelä wrote: bearophile wrote: - OOP: Scala supports dynamic OOP optimizations unlike D (unless a VM is used). Do you mean knowing a class or virtual method has no descendants? Sure, you need to know the whole program to do that, or just declare it as fina

Re: Scala future, Sing#

2009-08-24 Thread Walter Bright
Ary Borenszweig wrote: Walter Bright escribió: Jari-Matti Mäkelä wrote: bearophile wrote: - OOP: Scala supports dynamic OOP optimizations unlike D (unless a VM is used). Do you mean knowing a class or virtual method has no descendants? Sure, you need to know the whole program to do that, or

Re: Scala future, Sing#

2009-08-25 Thread Jari-Matti Mäkelä
Walter Bright wrote: > Ary Borenszweig wrote: >> Walter Bright escribió: >>> Jari-Matti Mäkelä wrote: bearophile wrote: - OOP: Scala supports dynamic OOP optimizations unlike D (unless a VM is used). >>> >>> Do you mean knowing a class or virtual method has no descendants? >>> Sure,

Re: Scala future, Sing#

2009-08-25 Thread Walter Bright
Jari-Matti Mäkelä wrote: I meant this "Another important example of this kind of optimization is class-hierarchy- based optimization. A virtual method invocation, for example, involves looking at the class of the receiver object for the call to discover which actual target implements the virtu

Re: Scala future, Sing#

2009-08-25 Thread Jari-Matti Mäkelä
Walter Bright wrote: > Jari-Matti Mäkelä wrote: >> - bloat: Scala is more lightweight. I've heard Walter say that he doesn't >> like e.g. library defined control structures - > > Actually, you can do them with "lazy" function arguments. There was an > example somewhere of doing control structure

Re: Scala future, Sing#

2009-08-25 Thread bearophile
Walter Bright: >Actually, you can do them with "lazy" function arguments. There was an example >somewhere of doing control structures with it.< There are some problems with this: - Are current (especially LDC) compilers able to inline those lazy delegates? Scala compiler contains some parts to

Re: Scala future, Sing#

2009-08-25 Thread Andrei Alexandrescu
Jari-Matti Mäkelä wrote: bearophile wrote: As Sing# (http://en.wikipedia.org/wiki/Sing_sharp ) and Chapel, Scala is one of the languages to be followed more, because they share some of future purposes of D2/D3. A small presentation about the close future of Scala (it's not a general introducti

Re: Scala future, Sing#

2009-08-25 Thread Jari-Matti Mäkelä
Andrei Alexandrescu Wrote: > Jari-Matti Mäkelä wrote: > > bearophile wrote: > > > >> As Sing# (http://en.wikipedia.org/wiki/Sing_sharp ) and Chapel, Scala is > >> one of the languages to be followed more, because they share some of > >> future purposes of D2/D3. > >> > >> A small presentation abo

Re: Scala future, Sing#

2009-08-25 Thread Walter Bright
Jari-Matti Mäkelä wrote: Agreed, you /can/ do something similar. But in Scala it's the standard way of doing things. If you compare the grammars of both languages, you'll see that Scala is a bit lighter than D (see http://www.scala- lang.org/sites/default/files/linuxsoft_archives/docu/files/Sca

Re: Scala future, Sing#

2009-08-25 Thread Walter Bright
bearophile wrote: Walter Bright: Actually, you can do them with "lazy" function arguments. There was an example somewhere of doing control structures with it.< There are some problems with this: - Are current (especially LDC) compilers able to inline those lazy delegates? No, but it's not a

Re: Scala future, Sing#

2009-08-25 Thread Andrei Alexandrescu
Walter Bright wrote: Especially the array literal type inference is really naive. How should it be done? You shouldn't use the type of the first given element when constructing the type of the array. If you have [ e_1, ..., e_n ], the type of the literal is unify(type_of_e_1, ..., type_of_e

Re: Scala future, Sing#

2009-08-25 Thread Jari-Matti Mäkelä
bearophile Wrote: > Walter Bright: > > >Actually, you can do them with "lazy" function arguments. There was an > >example somewhere of doing control structures with it.< > > There are some problems with this: > - Are current (especially LDC) compilers able to inline those lazy delegates? > Sca

Re: Scala future, Sing#

2009-08-25 Thread Bill Baxter
On Tue, Aug 25, 2009 at 11:47 AM, Andrei Alexandrescu wrote: > Walter Bright wrote: > > Especially the array literal type inference is really naive. How should it be done? >>> >>> You shouldn't use the type of the first given element when constructing >>> the type of the array. If

Re: Scala future, Sing#

2009-08-25 Thread bearophile
Walter Bright: >No, but it's not a technical issue, just more of no demand for it. But this >would not be a reason to use Scala, as one doesn't use Scala for performance >oriented programs.< The usage of higher-order functions is pervasive in Scala, and they use delegates. So optimiizing those

Re: Scala future, Sing#

2009-08-25 Thread Danny Wilson
Op Wed, 26 Aug 2009 02:04:18 +0200 schreef bearophile : Note: LTO isn't done automatically yet by LDC, so to do it you have to input 3 different commands. Ask (to me, for example) if you want to know them. Well I do :-)

Re: Scala future, Sing#

2009-08-25 Thread Walter Bright
bearophile wrote: Walter Bright: No, but it's not a technical issue, just more of no demand for it. But this would not be a reason to use Scala, as one doesn't use Scala for performance oriented programs.< The usage of higher-order functions is pervasive in Scala, and they use delegates. So o