Walter Bright wrote:
I can expound on the huge advantages immutability and purity offer, if
you want.
Yes, I'd like to hear about this. You can leave away the things that are
not going to be implemented (like memorization of pure return values),
are only micro-optimizations (common sub-expres
Walter Bright Wrote:
> Yigal Chripun wrote:
> > But that doesn't mean the idea itself isn't valid. Perhaps a different
> > language with different goals in mind can provide a much simpler non
> > convoluted implementation and semantics for the same idea?
> > You've shown in the past that you're
On 22/12/2009 5:24 p.m., Walter Bright wrote:
Andrei Alexandrescu wrote:
That definition is what was discussed in this thread and alleged to be
anything but beautiful.
I've been in museums in europe where they proudly display ornate swords
and armor as "beautiful". I always kinda thought other
float func1(float[2] v) { return v[0]; }
float func1(float[3] v) { return v[0]; }
template Test (size_t S) {
float func2(float[S] v) { return v[0]; }
}
mixin Test!(2);
mixin Test!(3);
void main() {
float[2] a2;
func1(a2);
func2(a2);
}
Here the call to func1 is
Yigal Chripun wrote:
On 22/12/2009 05:22, Walter Bright wrote:
Kevin Bealer wrote:
The performance / impl-hiding conflict is a fundamental problem -- if
the user's compiler can't see the template method definitions, then
it can't optimize them very well. If it can, then the user can too.
Any me
grauzone wrote:
Walter Bright wrote:
I believe that D's template constraint feature fills the bill, it does
everything Concepts purported to do, and more, in a simple and easily
explained manner, except check the template body against the constraint.
The latter is, in my not-so-humble opinion
On 22/12/2009 05:22, Walter Bright wrote:
Kevin Bealer wrote:
The performance / impl-hiding conflict is a fundamental problem -- if
the user's compiler can't see the template method definitions, then
it can't optimize them very well. If it can, then the user can too.
Any method of compiling them
On 21/12/2009 22:41, Kevin Bealer wrote:
dsimcha Wrote:
== Quote from Yigal Chripun (yigal...@gmail.com)'s article
but even more frustrating is the fact that template compilation
bugs will also happen at the client. There's a whole range of
designs for this and related issues and IMO the C++ d
On 22/12/2009 1:16 p.m., Nick Sabalausky wrote:
"Tim Matthews" wrote in message
news:hgp10e$2sj...@digitalmars.com...
On 21/12/2009 8:57 p.m., Don wrote:
retard wrote:
Sun, 20 Dec 2009 16:44:03 +0100, Don wrote:
downs wrote:
according to
http://www.mail-archive.com/haskell-cafe%40haskell.o
Andrei Alexandrescu wrote:
That definition is what was discussed in this thread and alleged to be
anything but beautiful.
I've been in museums in europe where they proudly display ornate swords
and armor as "beautiful". I always kinda thought otherwise, because all
that decoration and encrust
On 2009-12-21 20:56:37 -0500, zsxxsz said:
I have another idea about the gc and memroy management: each
thread use it's own memory slice pool with using thread local storage, which
can avoiding the global lock on system memory management.
This is a pretty good idea, which happen to have been
Walter Bright wrote:
Yigal Chripun wrote:
But that doesn't mean the idea itself isn't valid. Perhaps a different
language with different goals in mind can provide a much simpler non
convoluted implementation and semantics for the same idea?
You've shown in the past that you're willing to break
Kevin Bealer wrote:
The performance / impl-hiding conflict is a fundamental problem -- if
the user's compiler can't see the template method definitions, then
it can't optimize them very well. If it can, then the user can too.
Any method of compiling them that preserves enough info for the
compil
Yigal Chripun wrote:
But that doesn't mean the idea itself isn't valid. Perhaps a different
language with different goals in mind can provide a much simpler non
convoluted implementation and semantics for the same idea?
You've shown in the past that you're willing to break backward
compatibilit
Tim Matthews wrote:
On 21/12/2009 8:57 p.m., Don wrote:
retard wrote:
Sun, 20 Dec 2009 16:44:03 +0100, Don wrote:
downs wrote:
according to
http://www.mail-archive.com/haskell-cafe%40haskell.org/msg63381.html
I'll let this speak for itself.
import Data.Array.Base (unsafeRead, unsafeWrite)
Pelle Månsson wrote:
On 12/22/2009 01:16 AM, Nick Sabalausky wrote:
It's already been pointed out in a number of places that that's not
quicksort. Quicksort is in-place and doesn't use the head as the pivot.
Besides "It probably performs like a bitch" defeats the whole point of
quicksort, doesn'
Some days before, someone talked about the D's performance in multicore
system. dsimcha gave one suggestion that in gc using spinlock maybe better
than mutexlock. I have another idea about the gc and memroy management: each
thread use it's own memory slice pool with using thread local storage, whic
On 12/22/2009 01:16 AM, Nick Sabalausky wrote:
It's already been pointed out in a number of places that that's not
quicksort. Quicksort is in-place and doesn't use the head as the pivot.
Besides "It probably performs like a bitch" defeats the whole point of
quicksort, doesn't it? And, going along
"Tim Matthews" wrote in message
news:hgp10e$2sj...@digitalmars.com...
> On 21/12/2009 8:57 p.m., Don wrote:
>> retard wrote:
>>> Sun, 20 Dec 2009 16:44:03 +0100, Don wrote:
>>>
downs wrote:
> according to
> http://www.mail-archive.com/haskell-cafe%40haskell.org/msg63381.html
>
>>
On Mon, 21 Dec 2009 14:01:23 -0500, Walter Bright
wrote:
retard wrote:
Agreed. Will be fixed later. Keep in mind that D is older language than
Scala - now tell me what mystruct.tupleof.stringof does - where's the
documentation? From the top of my head I can imagine at least 200
differen
On 21/12/2009 8:57 p.m., Don wrote:
retard wrote:
Sun, 20 Dec 2009 16:44:03 +0100, Don wrote:
downs wrote:
according to
http://www.mail-archive.com/haskell-cafe%40haskell.org/msg63381.html
I'll let this speak for itself.
import Data.Array.Base (unsafeRead, unsafeWrite)
[snip]
Brilliant.
Andrei Alexandrescu:
> This is a great example that I don't have the time to look into now.
It's a nice example, and I know you don't have a lot of time to implement it
now.
> Currently Phobos doesn't have the means to compute the cross-product of
> ranges.
The idea is to have standard means
This is a great example that I don't have the time to look into now. In
essence the task is to generate all numbers of the form 2^^a*3^^b*5^^c
where a, b, and c are natural numbers.
Currently Phobos doesn't have the means to compute the cross-product of
ranges. I encourage people to think abou
S:
>This isn't a bug. This is how it is template code is supposed to work.<
It's not a bug, but a smarter compiler can try to reduce binary size conflating
parts of asm code that are equal, to reduce the size of the resulting binary.
It's a way to reduce one of the disadvantages of C++/D-style
Hello Yigal,
On 20/12/2009 03:11, BCS wrote:
I don't know how it does it but there has to be more to it in C#
because they allow you to do thing to the objects that Object doesn't
support. For that to happen, the objects have to be wrapped or tagged
or something so that the generics code can m
"Andrei Alexandrescu" wrote in message
news:4b2fcf53.9050...@erdani.org...
> Walter Bright wrote:
>> retard wrote:
>>> I have several imperative language programming books and instead of
>>> qsort they introduce the reader to the wonderful world of bubble sort!
>>
>> Bubble sort should be part o
Walter Bright Wrote:
> dsimcha wrote:
> > == Quote from Walter Bright (newshou...@digitalmars.com)'s article
> >> qsort (x:xs) = qsort (filter (< x) xs) ++ [x] ++ qsort (filter (>= x) xs)
> >> prominently featured in Haskell's official introduction page:
> >> http://www.haskell.org/haskellwiki/Int
On Tue, 22 Dec 2009 00:10:44 +0300, Jérôme M. Berger
wrote:
Andrei Alexandrescu wrote:
Walter Bright wrote:
retard wrote:
I have several imperative language programming books and instead of
qsort they introduce the reader to the wonderful world of bubble sort!
Bubble sort should be part
On 2009-12-18 17:07:57 -0800, bearophile said:
Yigal Chripun:
.Net generics for example work by creating an instantiation for each
value type (same as c++ templates) and one instantiation for all
reference types since at the binary level all reference types are simply
addresses. C++ can't do
yigal chripun Wrote:
> of the three above I think option 3 is the worst design and option 2 is my
> favorite design. I think that in reality you'll almost always want to define
> such an interface and I really can't think of any useful use cases for an
> unrestricted template parameter as in C+
"retard" wrote in message
news:hgnlug$45...@digitalmars.com...
> Mon, 21 Dec 2009 04:05:01 -0700, Rainer Deyke wrote:
>
>> yigal chripun wrote:
>>> Rainer Deyke Wrote:
I prefer to think of option 2 as explicitly typed while option 3 uses
type inference. Type inference is a good thing.
Andrei Alexandrescu wrote:
Walter Bright wrote:
retard wrote:
I have several imperative language programming books and instead of
qsort they introduce the reader to the wonderful world of bubble sort!
Bubble sort should be part of an introductory programming course, if
only because:
1. it'
On 21/12/2009 19:53, Walter Bright wrote:
Don wrote:
The problem is, I'm not sure that it's feasible in general. At least,
it's not obvious how to do it.
C++0x Concepts tried to do it in a limited form, and it got so
complicated nobody could figure out how it was supposed to work and it
capsiz
dsimcha Wrote:
> == Quote from Yigal Chripun (yigal...@gmail.com)'s article
> > but even more frustrating is the fact that
> > template compilation bugs will also happen at the client.
> > There's a whole range of designs for this and related issues and IMO the
> > C++ design is by far the worst o
All,
I created a new patched druntime that prevents array stomping and at the
same time increases append performance for thread-local array appending.
The patch is attached to bugzilla entry 3637. (
http://d.puremagic.com/issues/show_bug.cgi?id=3637 )
For those of you unfamiliar with arra
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s
> I fail to see how in D you'd be hard pressed to think in terms of lower
> level abstractions.
> Andrei
Devil's advocate since I mostly agree:
Conservative GC?
retard wrote:
Mon, 21 Dec 2009 12:13:48 -0600, Andrei Alexandrescu wrote:
Daniel de Kok wrote:
On 2009-12-19 21:04:32 +0100, Andrei Alexandrescu
said:
"This code is shown for its elegance rather than its efficiency. Using
++ in this way is not generally considered good programming practice."
Walter Bright wrote:
retard wrote:
I have several imperative language programming books and instead of
qsort they introduce the reader to the wonderful world of bubble sort!
Bubble sort should be part of an introductory programming course, if
only because:
1. it's an algorithm that gets rei
On 2009-12-21 14:34:39 -0500, Michel Fortin said:
I have an annoying problem where writing to the output stream with
writeln and other similar functions crash with an null dereference, but
it appear to depend on the order the modules are compiled or linked. I
wasn't able to reduce it to a
I
I have an annoying problem where writing to the output stream with
writeln and other similar functions crash with an null dereference, but
it appear to depend on the order the modules are compiled or linked. I
wasn't able to reduce it to a
I've found a workaround. I can add this at the beginni
retard wrote:
I have several imperative language programming books and instead of qsort
they introduce the reader to the wonderful world of bubble sort!
Bubble sort should be part of an introductory programming course, if
only because:
1. it's an algorithm that gets reinvented if one is not
Mon, 21 Dec 2009 12:13:48 -0600, Andrei Alexandrescu wrote:
> Daniel de Kok wrote:
>> On 2009-12-19 21:04:32 +0100, Andrei Alexandrescu
>> said:
>>> "This code is shown for its elegance rather than its efficiency. Using
>>> ++ in this way is not generally considered good programming practice."
>>
Mon, 21 Dec 2009 20:04:05 +0100, Lutger wrote:
> retard wrote:
>
>> Mon, 21 Dec 2009 18:54:19 +0100, Daniel de Kok wrote:
>>
>>> On 2009-12-19 21:04:32 +0100, Andrei Alexandrescu
>>> said:
"This code is shown for its elegance rather than its efficiency.
Using ++ in this way is not gen
retard wrote:
> Mon, 21 Dec 2009 18:54:19 +0100, Daniel de Kok wrote:
>
>> On 2009-12-19 21:04:32 +0100, Andrei Alexandrescu
>> said:
>>> "This code is shown for its elegance rather than its efficiency. Using
>>> ++ in this way is not generally considered good programming practice."
>>>
>>> So
retard wrote:
Agreed. Will be fixed later. Keep in mind that D is older language than
Scala - now tell me what mystruct.tupleof.stringof does - where's the
documentation? From the top of my head I can imagine at least 200
different cases where the D/Phobos's documentation sucks.
I would appre
Mon, 21 Dec 2009 18:01:29 +0100, Daniel de Kok wrote:
> On 2009-12-18 18:02:28 +0100, retard said:
>> I've only seen how Scala solves problems elegantly. These are from some
>> biased blog posts etc. Can you show one example that looks uglier in
>> Scala, but looks decent in D or some other langu
Mon, 21 Dec 2009 18:54:19 +0100, Daniel de Kok wrote:
> On 2009-12-19 21:04:32 +0100, Andrei Alexandrescu
> said:
>> "This code is shown for its elegance rather than its efficiency. Using
>> ++ in this way is not generally considered good programming practice."
>>
>> So if the code is inefficien
On 20/12/2009 03:11, BCS wrote:
Hello Yigal,
On 18/12/2009 17:34, dsimcha wrote:
I think variadics, static if and alias parameters qualify more as a
"better design" than fixing "minor issues".
actually they qualify as - "even worse design". duplicating the syntax
like that is butt ugly.
Daniel de Kok wrote:
On 2009-12-19 21:04:32 +0100, Andrei Alexandrescu
said:
"This code is shown for its elegance rather than its efficiency. Using
++ in this way is not generally considered good programming practice."
So if the code is inefficient and in poor programming practice, how in
th
Daniel de Kok wrote:
On 2009-12-18 20:39:08 +0100, Walter Bright
said:
Ain't that cool? But look closer. The advantage of quicksort is that
it is an *in-place* sort. The Haskell one creates new arrays for every
state in the sort.
But it does have one nice property: due to laziness, the n-th
Don wrote:
The problem is, I'm not sure that it's feasible in general. At least,
it's not obvious how to do it.
C++0x Concepts tried to do it in a limited form, and it got so
complicated nobody could figure out how it was supposed to work and it
capsized and sank.
I don't think it's possibl
On 2009-12-19 21:04:32 +0100, Andrei Alexandrescu
said:
"This code is shown for its elegance rather than its efficiency. Using
++ in this way is not generally considered good programming practice."
So if the code is inefficient and in poor programming practice, how in
this blessed world could
On 2009-12-18 20:39:08 +0100, Walter Bright said:
Ain't that cool? But look closer. The advantage of quicksort is that it
is an *in-place* sort. The Haskell one creates new arrays for every
state in the sort.
But it does have one nice property: due to laziness, the n-th elements
of the sorte
Ary Borenszweig wrote:
Ary Borenszweig wrote:
retard wrote:
Tue, 01 Dec 2009 03:16:47 -0800, Walter Bright wrote:
Ary Borenszweig wrote:
Can you show examples of points 2, 3 and 4?
Have opDispatch look up the string in an associative array that returns
an associated delegate, then call the
On 2009-12-18 18:02:28 +0100, retard said:
I've only seen how Scala solves problems elegantly. These are from some
biased blog posts etc. Can you show one example that looks uglier in
Scala, but looks decent in D or some other language?
I can not paste any of this particular code ($WORK). From
Don Wrote:
> yigal chripun wrote:
> > Don Wrote:
> >>> The way I see it we have three options:
> >>>
> >>> assume we have these definitions:
> >>> interface I {...}
> >>> class Foo : I {...}
> >>> class Bar {...} // structurally compatible to I
> >>>
> >>> template tp (I) {...}
> >>>
> >>> 1) .Net
Don, el 21 de diciembre a las 09:20 me escribiste:
> >http://en.wikipedia.org/wiki/Duck_typing#Structural_type_systems
>
> That Wikipedia page doesn't any make sense to me. Is that *really*
> what duck typing is? If so, it's a complete misnomer. Because it's
> totally different to "if it looks lik
alkor:
> anybody see the 64-bit version of dmd compiler?
I can't see it. It must be absent.
Bye,
bearophile
retard wrote:
Thanks for links, that should help.
Mon, 21 Dec 2009 12:25:35 +0100, Lutger wrote:
> Don wrote:
>
>> Lutger wrote:
> ...
>>> http://en.wikipedia.org/wiki/Duck_typing#Structural_type_systems
>>
>> That Wikipedia page doesn't any make sense to me. Is that *really* what
>> duck typing is? If so, it's a complete misnomer. Because it's
anybody see the 64-bit version of dmd compiler?
Don wrote:
> Lutger wrote:
...
>> http://en.wikipedia.org/wiki/Duck_typing#Structural_type_systems
>
> That Wikipedia page doesn't any make sense to me. Is that *really* what
> duck typing is? If so, it's a complete misnomer. Because it's totally
> different to "if it looks like a duck, quacks li
Mon, 21 Dec 2009 04:05:01 -0700, Rainer Deyke wrote:
> yigal chripun wrote:
>> Rainer Deyke Wrote:
>>> I prefer to think of option 2 as explicitly typed while option 3 uses
>>> type inference. Type inference is a good thing.
>
>> You might prefer that but it's incorrect.
>
> It's not incorrect,
yigal chripun wrote:
> Rainer Deyke Wrote:
>> I prefer to think of option 2 as explicitly typed while option 3 uses
>> type inference. Type inference is a good thing.
> You might prefer that but it's incorrect.
It's not incorrect, it's another way of looking at the same thing.
Structural type in
yigal chripun wrote:
Don Wrote:
The way I see it we have three options:
assume we have these definitions:
interface I {...}
class Foo : I {...}
class Bar {...} // structurally compatible to I
template tp (I) {...}
1) .Net nominative typing:
tp!(Foo) // OK
tp!(Bar) //not OK
2) structural typi
Rainer Deyke Wrote:
> yigal chripun wrote:
> > 2) structural typing (similllar to Go?)
> > tp!(Foo) // OK
> > tp!(Bar) // also OK
> >
> > 3) C++ style templates where the compatibility check is against the
> > *body* of the template.
> >
> > If you think of templates as functions the compiler ex
yigal chripun wrote:
> 2) structural typing (similllar to Go?)
> tp!(Foo) // OK
> tp!(Bar) // also OK
>
> 3) C++ style templates where the compatibility check is against the
> *body* of the template.
>
> If you think of templates as functions the compiler executes, the
> difference between the la
Don Wrote:
> > The way I see it we have three options:
> >
> > assume we have these definitions:
> > interface I {...}
> > class Foo : I {...}
> > class Bar {...} // structurally compatible to I
> >
> > template tp (I) {...}
> >
> > 1) .Net nominative typing:
> > tp!(Foo) // OK
> > tp!(Bar) //no
yigal chripun wrote:
Lutger Wrote:
Yigal Chripun wrote:
On 19/12/2009 01:31, Lutger wrote:
Yigal Chripun wrote:
On 18/12/2009 02:49, Tim Matthews wrote:
In a reddit reply: "The concept of templates in D is exactly the same
as in C++. There are minor technical differences, syntactic
differ
Lutger wrote:
Nick Sabalausky wrote:
"Lutger" wrote in message
news:hgl440$tl...@digitalmars.com...
Yigal Chripun wrote:
The .Net implementation isn't perfect of course and has a few issues
that should be resolved, one of these is the problem with using
operators. requiring interfaces by its
Lutger Wrote:
> Yigal Chripun wrote:
>
> > On 19/12/2009 01:31, Lutger wrote:
> >> Yigal Chripun wrote:
> >>
> >>> On 18/12/2009 02:49, Tim Matthews wrote:
> In a reddit reply: "The concept of templates in D is exactly the same
> as in C++. There are minor technical differences, syntact
retard wrote:
Sun, 20 Dec 2009 16:44:03 +0100, Don wrote:
downs wrote:
according to
http://www.mail-archive.com/haskell-cafe%40haskell.org/msg63381.html
I'll let this speak for itself.
import Data.Array.Base (unsafeRead, unsafeWrite)
[snip]
Brilliant.
What is so brilliant? Referential tr
72 matches
Mail list logo
