Pure dynamic casts?

Jeremie Pelletier jeremiep at gmail.com
Wed Sep 23 07:43:53 PDT 2009


Daniel Keep wrote:
> Jeremie Pelletier wrote:
>> I myself couldn't live without threads or references, but I agree that
>> mixing the two can lead to interesting scenarios to debug. Just try and
>> code a responsive GUI without using threads, the application will "hang"
>> everytime you're not going back to the main loop every few milliseconds.
>> Or doing network I/O without bringing your program to a crawl, of course
>> you could use async I/O but where is that I/O gonna run without a
>> background thread to support it :)
> 
> <rant>
> 
> See, people equate "parallel execution" with "threads" these days which
> is half the problem.  Threads are a TERRIBLE abstraction, because they
> don't.  There's no protection.  Almost every time I express the opinion
> that threads are broken, people automatically assume I think we should
> all go back to single-core machines and cooperative multitasking.
> 
> It's like if I said I don't like Coke that I'm somehow against all
> beverages.
> 
> A while ago, I was playing with a toy language design which used value
> semantics for everything.  The one exception was references, but they
> had two big differences from how, for example, D implements them:
> 
> 1. They could only point to the heap, and could not point to any
> pre-existing value.  If you, for example, took a ref to an array, it
> would actually copy the array to the heap.
> 
> 2. Refs to mutable values could only be dereferenced by their "owning"
> thread; other threads couldn't even look at the contents.  A thread
> could transfer ownership of a ref to another thread, or disown it
> entirely at which point it became globally immutable.
> 
> Because of this, threads in the language couldn't even see each other's
> mutable data (there were no process-globals, only thread-global); they
> had to communicate via message passing.
> 
> In something like that, you don't need to worry about threads
> interacting badly, because they can't interact except at specific points
> in the program.
> 
> For something like a GUI, you'd have the GUI in one thread and do the
> processing in another.  Instead of having to worry about locking and
> synchronising, you just send the other thread a "do this" message.
> 
> Of course, something like that would never get into D.  Oh well.  :)
> 
> Where was I?
> 
> </rant>
> 
>> Besides, the upcoming shared qualifier is there to address those issues.
>>
>> You might want to look at this article, I came across it a few months
>> ago and found it rather insightful, it just could change your view on
>> references:
>> http://blogs.msdn.com/ericlippert/archive/2009/02/17/references-are-not-addresses.aspx
> 
> I've read it before.  It doesn't apply because we're talking about D,
> not C#.  Conceptually, it's correct, but D is a systems programming
> language.  If you're going to deal with things like the definition of
> purity, then you HAVE to know what a reference really is and how it
> works.  If you just use pure, you don't care.
> 
> It's like how if you're working on the CLR itself, you'd need to know
> how references are implemented.  If you're USING the CLR, it's
> immaterial in most cases.
> 
> In C#, if you talk about "Beethoven", then it's always the same
> Beethoven.  The only way the definition of Beethoven would change is if
> everyone in the universe forgot who he was first.
> 
> But in D, that's not entirely true.  You can hit the GC over the head
> with a "delete" and it'll forget.  Sometimes it'll forget because you
> accidentally stored the only remaining reference in a malloc'ed struct
> RIGHT when some other thread triggered a collect and oh dear.
> 
> I would like to clarify, however, that I think it is fairly reasonable
> to expect this optimisation to work.  It's just that I've been bitten by
> threading issues so very many times that I work on the basis that given
> half a chance, threading will completely screw your program.
> 
> That said, I think I'm getting too ranty, so I'll just leave it at that.

I dont believe there's such a thing as "too ranty", your post was quite 
insightful.

I understand your views on threading, ownership I believe is a feature 
planned for D3, but it wouldn't be that hard to implement on a custom 
runtime (i myself am still unsure about whether to do it or not yet). 
I've read Bartosz's entry about ownership, and I've looked at libraries 
using it (such as Qt). I think its a neat idea in itself, but I would 
rather see shared than ownership, or only using ownership on shared 
objects to keep things fast.

The thing is, you can share any piece of data, not just objects, 
therefore enforcing the ownership model would limit sharable data to 
objects, which is too limiting for many of us.

You're right about concurrency being a different concept than threading, 
  but I wouldn't give threading away for a pure concurrent model either. 
I believe D is aiming at giving programmers a choice of the tools they 
wish to use. I could see uses of both a concurrent model with message 
passing and a threading model with shared data used at once in a 
program. Shared data is always faster than message passing so you could 
implement real time code with it, and use messsage passing for other 
parts such as delegating GUI messages from the main loop.

Shared data being harder to manage than message passing does not make it 
a bad thing, it just means you can have two different models for two 
different usages.

I know the link I gave is for C# and this is D, but these are concepts 
not bound to any particular languages. I just wanted to point out that 
references in themselves aren't a bad idea, I find them much more 
convenient than pointers for objects and arrays, I just wish you had 
means to explicitly separate an object pointer from its data instead of 
only being able to use the reference which doesn't make the difference 
between the two syntactically.

Jeremie



More information about the Digitalmars-d mailing list