I have posted a blog about the state-of-the-art results in uniqueness. I
discuss the paper by Haller/Odersky, where they present an extension to Scala.
I would appreciate your vote on reddit:
http://www.reddit.com/r/programming/comments/acsg8/unique_objects/
Steven Schveighoffer Wrote:
The danger is that it's easy to miss accidental sharing and it's very
hard to test for it.
I think this danger is rare, and it's easy to search for (just search for
~= in your code, I did it with Tango). I think it can be very well
defined in a tutorial
Denis Koroskin Wrote:
I think RefCounted should be flexible enough to re-usable for other data
structures, too (e.g. so that it could be part of Phobos).
I agree. However this code goes into core, so it can't use Phobos.
By the way, your code has a bug:
Tid tid; // or release() and
I don't think you need opAssign. The compiler will automatically use bitblit
and postblit.
Here's my implementation of a reference counted thread id structure for
comparison:
struct Tid
{
this(HANDLE h)
{
_h = h;
Counter * cnt = cast(Counter *)
Walter Bright Wrote:
Steven Schveighoffer wrote:
As long as the spec says changing length may expand the array to hold
enough space, the optimizer can't, because the optimization would
change the side effects of the function. An optimizer should not
change the outcome or side effects of
Andrei Alexandrescu Wrote:
Bartosz Milewski wrote:
Andrei Alexandrescu Wrote:
How about creating a struct Value!T that transforms T (be it an
array or a class) into a value type? Then if you use Value!(int[]),
you're effectively dealing with values throughout (even though
internally
otherwise.
Bartosz Milewski Wrote:
The problem here is that the guy is sort of right. Indeed quote() expands
the slice before overwriting it and that requires re-allocation to avoid
stomping over the original buffer. There is however a boundary case, when
the whole buffer matches
Steven Schveighoffer Wrote:
As long as the spec says changing length may expand the array to hold enough
space, the optimizer can't, because the optimization would change the side
effects of the function. An optimizer should not change the outcome or side
effects of a function. It's not
Steven Schveighoffer Wrote:
Bartosz Milewski Wrote:
Steven Schveighoffer Wrote:
Bottom line: if a function isn't supposed to change the buffer, the
signature should be const for that parameter. It's one of the principles
of const, and why it's in D2 in the first place
Andrei Alexandrescu Wrote:
Bartosz Milewski wrote:
Steven Schveighoffer Wrote:
As long as the spec says changing length may expand the array to hold
enough space, the optimizer can't, because the optimization would change
the side effects of the function. An optimizer should
Andrei Alexandrescu Wrote:
How about creating a struct Value!T that transforms T (be it an array or
a class) into a value type? Then if you use Value!(int[]), you're
effectively dealing with values throughout (even though internally they
might be COWed). Sometimes I also see a need for
Andrei Alexandrescu Wrote:
sharing for ~=. Also I am not ruling out the possibility that we can
guarantee a ~= that never keeps sharing with existing arrays. (One idea
I discussed with Walter was encoding uniqueness of arrays in a bit
stored with the array limits.)
I've been thinking the
It's hard to argue whether something is or isn't bug prone and how severe the
bugs could be. An experienced programmer knows all the gotchas so he or she
will never introduce such bugs. A more bug-prone person will be afraid to speak
up in public so as not to appear stupid or be bullied away.
Andrei Alexandrescu Wrote:
Array may include a field
bool sliceExtracted;
that is set to true whenever you take a slice from the array and set to
false whenever the array's data is reallocated. The array's
documentation could mention that ~= is amortized constant if there are
no
Steven Schveighoffer Wrote:
Imagine you're reviewing this code written by a relative newbee:
char[] quote(char[] word) {
word.length += 2;
word[length-1] = '';
for(int i = word.length-2; i 0; --i)
word[i] = word[i - 1];
word[0] = '';
return word;
}
void
Steven Schveighoffer Wrote:
On Tue, 24 Nov 2009 16:52:52 -0500, Bartosz Milewski
bartosz-nos...@relisoft.com wrote:
Steven Schveighoffer Wrote:
Imagine you're reviewing this code written by a relative newbee:
char[] quote(char[] word) {
word.length += 2;
word[length-1
Steven Schveighoffer Wrote:
Bottom line: if a function isn't supposed to change the buffer, the
signature should be const for that parameter. It's one of the principles
of const, and why it's in D2 in the first place. I'd explain to the coder
that he is wrong to expect that modifying
Andrei Alexandrescu Wrote:
Some of the points are in my message from Sat, 05:19 pm. Especially
this point: Can a conforming implementation simply re-allocate on
every expansion? You make it sound like that would violate some
performance guarantees but there are no specifics.
I don't
Andrei Alexandrescu Wrote:
I'm not sure I figure what the issue is, and I'd appreciate a rehash of
the few other issues brought up. (I thought they had been responded to.)
Some of the points are in my message from Sat, 05:19 pm. Especially this point:
Can a conforming implementation simply
int[] a = [0];
auto b = a;
a ~= 1;
b ~= 2;
What is a[1]?
Is this considered stomping and requiring a re-allocation?
Can this question be answered without the recourse to implementation, and the
MRU cache in particular?
I thought about an abstract definition of stomping.Something like
dsimcha Wrote:
Furthermore, the purpose of language design is to create a usable language
first
and foremost, and then figure out how to specify it formally and abstractly,
not
to create a perfectly bulletproof specification first and foremost and then
hope
that results in a usable
Ali Cehreli Wrote:
Neither 'a' nor 'b' own the elements; in that sense, if one is a slice then
the other is a slice... In D, slices have discretionary sharing semantics.
Any slice may leave the sharing contract as it sees unfit.
So is your answer different from that of dsimcha? I'm sitting
Andrei Alexandrescu Wrote:
I think one aspect that tends to be forgotten is that built-in arrays
are the lowest abstraction - really just one small step above pointers.
Efficiency lost there is lost forever. That's why I consider the current
design adequate and the proposed designs less so.
Steven Schveighoffer Wrote:
In fact, even after reading 4.1.9 I don't know what to expect in some
cases. Here's an example:
int[] a = [0];
auto b = a;
a ~= 1;
b ~= 2;
What is a[1]?
Is this considered stomping and requiring a re-allocation?
a[1] would be 1 if an MRU cache
Steven Schveighoffer Wrote:
I wonder what your expert opinion is: Is something like unique possible
without introducing all the other type modifiers (like 'lent', etc.)? If
not, what are the minimum type modifiers you'd need to get unique to
work? I really like the unique concept,
Andrei Alexandrescu Wrote:
My concern is the semantics of the language. As it is defined right now, a
conforming implementation is free to use a quantum random number generator to
decide whether to re-allocate or not. Is it likely? I don't think so; but the
non-determinism is part of the
Andrei Alexandrescu Wrote:
Leandro Lucarella wrote:
Andrei Alexandrescu, el 17 de noviembre a las 18:45 me escribiste:
3. If you **really** care about performance, you should only append when
you
don't know the length in advance. If you know the length, you should
always
Andrei Alexandrescu Wrote:
One thing that Bartosz didn't mention is that this unique is different
than the other unique, which I think reveals the half-bakedness of the
proposal. The other unique that was intensively discussed before is
transitive, meaning that the root reference points
dsimcha Wrote:
The one thing that I think has been missing from this discussion is, what
would be
the alternative if we didn't have this non-deterministic reallocation? How
else
could you **efficiently** implement dynamic arrays?
In the long run (D3), I proposed using the unique type
Walter Bright Wrote:
BCS wrote:
would you agree that it is not something the programer can predict in
advance?
He can, but it is not reasonable to expect him to. But it's still
deterministic.
I've been following this discussion about determinism and I think it addresses
the problem
I read Andrei's chapter on arrays and there's one thing that concerns me. When
a slice is extended, the decision to re-allocate, and therefore to cut its
connection to other slices, is non-deterministic. How does that influence
program testing and can it be exploited to attack a buggy system?
dsimcha Wrote:
void main() {
condition = new Condition( new Mutex() );
auto T = new Thread(waitThenPrint);
T.start();
condition.notify(); // Never wakes up and prints FOO.
}
Your program terminates immediately after sending the notification. You need to
stall the exit
Andrei Alexandrescu Wrote:
this() { myCount = count++; } // ERROR
It's worse than that. Try this:
struct foo {
this(int dummy = 0) { writeln(Default constructor);}
}
foo x = foo();
Nothing gets printed. If default constructors are disallowed, so should
constructors with all
This means that no non-trivial invariant may be defined for a struct. In most
cases it doesn't matter, but it might be a problem with the smart pointer
family.
For instance, refcounted may not assume that the shared refcount pointer has
been allocated. Without this invariant all refcounted
dsimcha Wrote:
Bartosz, since you're a threading guru, could you please write a simple test
program using core.sync.condition and see if it works, and if not either file
a
bug report or let me know?
Conditions were implemented by Sean Kelly, so he's the guru. The file
condition.d in
bearophile Wrote:
Jeremie Pelletier:
I vote for a 'lent' qualifier to be implemented in the compiler.
You may be right, and Bartosz has explained me why and how to use lent. It
sounds like a nice idea, but it has some costs too (in language complexity,
for example). But I need to use
bearophile Wrote:
it's hard for me to subscribe to the good enough philosophy (as long as
it's better that C++, it's fine for D).
D language is largely grown, and not designed. D is not Scala or Haskell.
...
So I think some of the design mistakes of D2 will be fixed in D3 :-)
With
Nick B Wrote:
Could you give us _any_ kind of test case (even if it's enormous)?
Bartosz - are you able to provide a test case as requested by Don ?
Then it might be possible, to get this bug fixed.
Nick B.
I can send you the files I have checked out.
The problem was in core.thread.
Nick B Wrote:
Nick B wrote:
Andrei Alexandrescu wrote:
bearophile wrote:
Andrei Alexandrescu:
Unfortunately, Bartosz has declined to contribute.
I have read a good amount of his interesting blog posts, he has shown
me many things I didn't know about. And he was very happy about
Sean Kelly Wrote:
It would be trivial to implement spawn on top of the Thread object.
Not so trivial, as I would like the spawn function to be a variadic template.
And
the reverse would work as well, though it would be less practical. After
all, some data must be used to represent a
Walter Bright Wrote:
http://www.reddit.com/r/programming/comments/8z3wm/whats_wrong_with_the_thread_object/
The bottom line of this post is that the current Thread object in D should be
abandoned and replaced by a more primitive spawn function. If there are no
serious objections, we are going
Why don't you wait for part 3 (coming this week) which talks about templates.
You'll find it simpler than you'd expect. Let's not fight the strawman. I'm
also working on the tutorial.
Jason House Wrote:
I see, you're a hardcore lockfree programmer. All you can expect from D is
Sequential Consistency--nothing fancy like C++ weak atomics. But that's for
the better.
Far from it! I'm stumbling through in an attempt to teach myself the black
art. I'm probably in my
This is the missing second reply to Andrei. I'm posting parts of it because it
my help understand my position better.
I wouldn't dismiss Scala out of hand. The main threading model in Scala is
(library-supported) actor model. Isn't that what you're proposing for D? Except
that Scala has much
Andrei Alexandrescu Wrote:
Scala doesn't know what to do about threads.
That's my impression too, although Scala's support for actors leaves D in the
dust.
The trend I'm seeing is
that functional languages are getting increasing attention, and that's
exactly because they never share
Jason House Wrote:
Bartosz Milewski Wrote:
My hobby project is a multi-threaded game-playing AI. My current scheme uses
a shared search tree using lockless updates with search results. Besides
general ability to use your scheme for what I've already done, I'm also
interested in how
Can you believe it? I was convinced that my response was lost because the
stupid news reader on Digital Mars web site returned an error (twice, hence two
posts). I diligently rewrote the riposte from scratch and tried to post it. It
flunked again! Now I'm not sure if it won't appear in the
I don't think the item-by-item pingpong works well in the newsgroup. Let's
separate our discussion into separate threads. One philosophical, about the
future of concurrency. Another about the immediate future of concurrency in D2.
And a separate one about my proposed system in the parallel
Andrei Alexandrescu Wrote:
Second, there is no regard to language integration. Bartosz says syntax
doesn't matter and that he's flexible, but what that really means is
that no attention has been paid to language integration. There is more
to language integration than just syntax (and then
Leandro Lucarella Wrote:
BCS, el 28 de mayo a las 15:57 me escribiste:
Maybe, I'm just saying why I don't comment on D2 concurrency model. I find
it too complex for my needs (i.e. for what I know, I won't give my opinion
about things I don't know/use).
Probably the majority of users
You pretty much nailed it. The ownership scheme will be explained in more
detail in the next two installments, which are almost ready.
The post is back, rewritten and with some code teasers.
Nick B Wrote:
Hi
It seems that Bartosz's latest post, dated April 26 th is missing from
his blog.
See :
http://bartoszmilewski.wordpress.com/
Nick B.
Since I'm working on the concurrency model for D, I have to re-read several
articles. I decided to combine this task with blogging--it always helps the
understanding if you have to relate the topic to others. We are interested in
designing a type system that would prevent, or at least minimize,
bearophile Wrote:
Now, back to the topic: putting arguments into a single () or {} instead of a
(){ return ;} (or with the = of C#) helps the eye see a single visual object
isntead of two, this helps the human parsing of the code, improving visual
chunking and reducing noise.
I also
My point is that it's a redundant check. Whether it is there or not, the result
is the same--the program will halt. Maybe the error message form enforce will
look nicer, but that's about it.
Brad Roberts Wrote:
Bartosz Milewski wrote:
Of course, enforce(mdgt); is there only
. Which ties nicely with the
discussion of nullable types.
Christopher Wright Wrote:
Denis Koroskin wrote:
On Mon, 09 Feb 2009 11:24:09 +0300, Bartosz Milewski
bart...@relisoft.com wrote:
My point is that it's a redundant check. Whether it is there or not,
the result is the same
I also believe that non-null should be the default. Most references in a
typical program are assumed to be non-null.
Like for every default, there should be an escape mechanism from it. However,
adding nullable to the type system might be controversial, especially because
it requires special
Shows you what a beginner in Java I am. Again and again I keep reinventing the
wheel. That settles it--we have to have it in D!
Robert Fraser Wrote:
Bartosz Milewski wrote:
I also found out that Java's editor, Eclipse, enforces DII--a very useful
feature that paid off for me in the first
references in D, but I'm still on the
fence about how we should accomplish that.
Denis Koroskin Wrote:
On Mon, 09 Feb 2009 01:19:55 +0300, Bartosz Milewski bart...@relisoft.com
wrote:
I also believe that non-null should be the default. Most references in a
typical program are assumed
Of course, enforce(mdgt); is there only for documentation purposes. Just like
null dereference, it halts the program, right?
60 matches
Mail list logo
