On Monday, 29 October 2012 at 17:56:26 UTC, Andrei Alexandrescu
wrote:
We will not add C++ concepts or typeclasses to D.
Ok. There is no point continuing this discussion then.
Andrei Alexandrescu:
For those who wouldn't know how to search the Net, these indeed
are quite appropriate.
People are often a bit lazy in clicking on links present in
newsgroup messages, and they are even more lazy in searching
things. So I've seen numerous times that if you give them links
On 10/29/12 2:16 PM, bearophile wrote:
Andrei Alexandrescu:
Yes, but what gets ignored here is that typeclasses have a large
cognitive cost to everyone involved.
Such costs are an interesting discussion topic :-)
To put people up to speed a bit:
http://en.wikipedia.org/wiki/Type_class
A bit
Andrei Alexandrescu:
Yes, but what gets ignored here is that typeclasses have a
large cognitive cost to everyone involved.
Such costs are an interesting discussion topic :-)
To put people up to speed a bit:
http://en.wikipedia.org/wiki/Type_class
A bit of explanations regarding Rust ones:
ht
On 10/29/12 12:21 PM, Peter Alexander wrote:
On Monday, 29 October 2012 at 15:48:11 UTC, Andrei Alexandrescu wrote:
On 10/28/12 8:28 AM, Peter Alexander wrote:
For example, here's what happened with bug 8900 mentioned in the OP:
std.range.zip creates a Zip object, which has a Tuple member. Tup
On Monday, 29 October 2012 at 15:48:11 UTC, Andrei Alexandrescu
wrote:
On 10/28/12 8:28 AM, Peter Alexander wrote:
For example, here's what happened with bug 8900 mentioned in
the OP:
std.range.zip creates a Zip object, which has a Tuple member.
Tuple has
a toString function, which calls form
On Monday, 29 October 2012 at 14:47:37 UTC, Don Clugston wrote:
One fairly non-disruptive thing we could do: implement code
coverage for templates. Currently, templates get no code
coverage numbers.
We could do a code-coverage equivalent for templates: which
lines actually got instantiated?
I
On 10/28/12 8:28 AM, Peter Alexander wrote:
On Saturday, 27 October 2012 at 13:06:09 UTC, Andrei Alexandrescu wrote:
On 10/27/12 8:23 AM, Peter Alexander wrote:
Retrofitting some sort of structure to templates will be a Herculean
task, but I think it has to happen. It is clear to me that the
de
On 27/10/12 00:45, H. S. Teoh wrote:
http://d.puremagic.com/issues/show_bug.cgi?id=8900
:-(
(The code there is called cartesianProd but it's the reduced code, so it
doesn't really compute the cartesian product. But that's where it's
from.)
So far, the outstanding blockers for cartesianProduct
On Saturday, 27 October 2012 at 16:19:43 UTC, H. S. Teoh wrote:
[snip]
I think there is some merit to being able to declare concepts;
for
example:
// This concept matches any type that has fields that satisfy
// what's specified inside the body.
concept InputRange(T) {
On Friday, 26 October 2012 at 22:43:44 UTC, H. S. Teoh wrote:
This is inadequate.
The best we can get are users like you that take the time to
report ;)
Thanks.
On Sunday, 28 October 2012 at 14:11:41 UTC, monarch_dodra wrote:
...[keyboar died]
Yeah, sorry. I was saying that by just doing unit tests that do
nothing more than declare the templates, you can get some very
good compile coverage.
It is not optimal, but it gives a good "bang for the buck",
On Sunday, 28 October 2012 at 12:28:23 UTC, Peter Alexander wrote:
Before pull request 880, walkLength accepted infinite ranges
and just returned size_t.max.
Actually, before 880, you had an infinite loop, as "size_t.max"
was a magic number that meant "walk to end"...
I've found recent
On Saturday, 27 October 2012 at 13:06:09 UTC, Andrei Alexandrescu
wrote:
On 10/27/12 8:23 AM, Peter Alexander wrote:
Retrofitting some sort of structure to templates will be a
Herculean
task, but I think it has to happen. It is clear to me that the
development process we use now (write the temp
Am Sat, 27 Oct 2012 12:20:51 +0200
schrieb "Peter Alexander" :
> On Friday, 26 October 2012 at 22:43:44 UTC, H. S. Teoh wrote:
> > I'm getting a bit frustrated with the Phobos bugs related to
> > ranges and
> > std.algorithm. I think we need to increase the number of
> > unittests. And
> > by th
On Sat, Oct 27, 2012 at 09:06:11AM -0400, Andrei Alexandrescu wrote:
> On 10/27/12 8:23 AM, Peter Alexander wrote:
> >Yeah, it's certainly not going to be easy. It's unfortunate that D
> >adopted the whole C++ style "glorified macros" approach to templates
> >-- it makes it very difficult to reason
On 10/27/12 8:23 AM, Peter Alexander wrote:
Yeah, it's certainly not going to be easy. It's unfortunate that D
adopted the whole C++ style "glorified macros" approach to templates --
it makes it very difficult to reason about (or automate reasoning about)
the semantics of your code.
I think D h
On 10/26/12 6:45 PM, H. S. Teoh wrote:
http://d.puremagic.com/issues/show_bug.cgi?id=8900
:-(
(The code there is called cartesianProd but it's the reduced code, so it
doesn't really compute the cartesian product. But that's where it's
from.)
So far, the outstanding blockers for cartesianProduc
On 10/27/12 6:20 AM, Peter Alexander wrote:
On Friday, 26 October 2012 at 22:43:44 UTC, H. S. Teoh wrote:
I'm getting a bit frustrated with the Phobos bugs related to ranges and
std.algorithm. I think we need to increase the number of unittests. And
by that I mean, GREATLY increase the number of
On Saturday, 27 October 2012 at 11:41:07 UTC, bearophile wrote:
Peter Alexander:
void foo(ForwardRange Range)(Range r)
{
r.popBack();
}
And *immediately* get a type error without having to
instantiate it with a variety of different range types.
It's not an easy problem. To solve it the R
Peter Alexander:
void foo(ForwardRange Range)(Range r)
{
r.popBack();
}
And *immediately* get a type error without having to
instantiate it with a variety of different range types.
It's not an easy problem. To solve it the Rust language uses
typeclasses adapted from Haskell. But unlike
On Friday, 26 October 2012 at 22:43:44 UTC, H. S. Teoh wrote:
I'm getting a bit frustrated with the Phobos bugs related to
ranges and
std.algorithm. I think we need to increase the number of
unittests. And
by that I mean, GREATLY increase the number of unittests. Most
of the
current tests are
On Friday, October 26, 2012 15:45:48 H. S. Teoh wrote:
> (Jonathan had a pull request with a Phobos workaround for this, which I
> _think_ is already merged, but the autotester is still failing at this
> point. :-/)
It hasn't been merged yet:
https://github.com/D-Programming-Language/phobos/pull/
On Sat, Oct 27, 2012 at 01:58:14AM +0200, Andrej Mitrovic wrote:
> On 10/27/12, H. S. Teoh wrote:
> > Here's a start:
>
> - Move the tests outside the implementation modules
>
> I do not want to see another std.datetime in Phobos. :)
Good idea. That way we can do cross-module testing as well.
http://d.puremagic.com/issues/show_bug.cgi?id=8900
:-(
(The code there is called cartesianProd but it's the reduced code, so it
doesn't really compute the cartesian product. But that's where it's
from.)
So far, the outstanding blockers for cartesianProduct are:
1) Compiler bug which causes unitt
25 matches
Mail list logo