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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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 :-)
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
20 matches
Mail list logo