www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Migrating to Shared

reply Walter Bright <newshound1 digitalmars.com> writes:
I wrote a brief article which should help:

http://www.digitalmars.com/d/2.0/migrate-to-shared.html
May 12 2009
next sibling parent reply The Anh Tran <trtheanh gmail.com> writes:
Walter Bright wrote:

 I wrote a brief article which should help:
 
 http://www.digitalmars.com/d/2.0/migrate-to-shared.html


Sir,

So immutable is an alias of invariant?
D now has 3 keywords that have somewhat similar meaning: const invariant 
immutable.

Thx.
May 12 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
The Anh Tran wrote:

 So immutable is an alias of invariant?
 D now has 3 keywords that have somewhat similar meaning: const invariant 
 immutable.


By popular demand, the invariant keyword was replaced with immutable. 
Invariant will eventually go away.
May 12 2009
parent reply Leandro Lucarella <llucax gmail.com> writes:
Walter Bright, el 12 de mayo a las 10:59 me escribiste:

 The Anh Tran wrote:

So immutable is an alias of invariant?
D now has 3 keywords that have somewhat similar meaning: const invariant 
immutable.


 
 By popular demand, the invariant keyword was replaced with immutable.
 Invariant will eventually go away.


Better sooner than later. At least it would be nice if a deprecation
warning is issued if invariant is used when immutable should go.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
May 12 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Leandro Lucarella wrote:

 At least it would be nice if a deprecation
 warning is issued if invariant is used when immutable should go.


That'll happen.
May 12 2009
parent Leandro Lucarella <llucax gmail.com> writes:
Walter Bright, el 12 de mayo a las 11:19 me escribiste:

 Leandro Lucarella wrote:

At least it would be nice if a deprecation
warning is issued if invariant is used when immutable should go.


 
 That'll happen.


Great! =)

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
May 12 2009
prev sibling next sibling parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Tue, May 12, 2009 at 1:47 PM, Walter Bright
<newshound1 digitalmars.com> wrote:

 I wrote a brief article which should help:

 http://www.digitalmars.com/d/2.0/migrate-to-shared.html


A couple typos:

// should be immutable int[3], no?
immutable table[3] x = [6, 123, 0x87];

// no type
__gshared x;
May 12 2009
next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Jarrett Billingsley wrote:

 A couple typos:


Fixed.
May 12 2009
prev sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Jarrett Billingsley wrote:

 // should be immutable int[3], no?
 immutable table[3] x = [6, 123, 0x87];


Really shouldn't that be enum, unless you mysteriously needed to take 
the address of it?
May 12 2009
parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
Robert Fraser wrote:


 Jarrett Billingsley wrote:

 // should be immutable int[3], no?
 immutable table[3] x = [6, 123, 0x87];


 Really shouldn't that be enum, unless you mysteriously needed to take  
 the address of it?


Seeing as how the example is for immutable, I'd say enum wouldn't be
quite right.

--
  Simen
May 13 2009
prev sibling next sibling parent reply Brian Palmer <d brian.codekitchen.net> writes:
Walter Bright Wrote:


 I wrote a brief article which should help:
 
 http://www.digitalmars.com/d/2.0/migrate-to-shared.html


I like this development, the only thing that makes me wary is the implied TLS
behavior. I think I'd personally prefer it if tls was a keyword as well, and
all globals had to have either tls or shared (or __gshared) in their type,
rather than defaulting to tls if none is specified. So we'd force the
programmer to explicitly define the level of sharing. 

Some might view that as too verbose though?
May 12 2009
parent reply BCS <none anon.com> writes:
Hello Brian,



 I like this development, the only thing that makes me wary is the
 implied TLS behavior. I think I'd personally prefer it if tls was a
 keyword as well, and all globals had to have either tls or shared (or
 __gshared) in their type, rather than defaulting to tls if none is
 specified. So we'd force the programmer to explicitly define the level
 of sharing.



I'm fine with the implicit but I'd like to see the explicit form as well 
(so they wouldn't pop up from -vtls).
May 12 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
BCS wrote:

 I'm fine with the implicit but I'd like to see the explicit form as well 
 (so they wouldn't pop up from -vtls).


You can do it explicitly with ___thread, though I was planning on 
deprecating that.
May 12 2009
parent BCS <none anon.com> writes:
Hello Walter,


 BCS wrote:
 

 I'm fine with the implicit but I'd like to see the explicit form as
 well (so they wouldn't pop up from -vtls).
 


 You can do it explicitly with ___thread, though I was planning on
 deprecating that.
 


not soon I hope.
May 12 2009
prev sibling next sibling parent Derek Parnell <derek psych.ward> writes:
On Tue, 12 May 2009 10:47:02 -0700, Walter Bright wrote:


 I wrote a brief article which should help:
 
 http://www.digitalmars.com/d/2.0/migrate-to-shared.html


Good article. This is an exciting enhancment to an already exciting
programming language. 

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
May 12 2009
prev sibling next sibling parent reply Kagamin <spam here.lot> writes:
And shared(int) is neither subtype nor supertype of int?
May 13 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
Kagamin wrote:

 And shared(int) is neither subtype nor supertype of int?


It's like const(int) and immutable(int).
May 13 2009
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 12 May 2009 13:47:02 -0400, Walter Bright  
<newshound1 digitalmars.com> wrote:


 I wrote a brief article which should help:

 http://www.digitalmars.com/d/2.0/migrate-to-shared.html


Regarding making globals immutable, one other option that was not  
identified was making it an enum.

Most of the time, I would think you'd want manifest constants versus  
immutable globals, as they take up no static space.

(not any more comments yet, still reading...)

-Steve
May 14 2009
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 14 May 2009 08:54:21 -0400, Steven Schveighoffer  
<schveiguy yahoo.com> wrote:


 On Tue, 12 May 2009 13:47:02 -0400, Walter Bright  
 <newshound1 digitalmars.com> wrote:


 I wrote a brief article which should help:

 http://www.digitalmars.com/d/2.0/migrate-to-shared.html


 Regarding making globals immutable, one other option that was not  
 identified was making it an enum.

 Most of the time, I would think you'd want manifest constants versus  
 immutable globals, as they take up no static space.

 (not any more comments yet, still reading...)



OK, I think there's another thread talking about this, but I was looking  
for the same thing...

There doesn't seem to be a way to convert shared data into a form (call it  
"locked-shared") that then can be used in a function as if it were local  
data.

For example, given that shared is a type constructor, I have to mark  
methods on a class shared in order to call them on a shared class  
instance.  But if there was a way to lock the instance so it temporarly  
became local, then I could call any method (as long as it didn't squirrel  
away a pointer to this).  Are there plans to be able to do something like  
this?  It couldn't be simply marked local, because you don't want to be  
able to squirrel away a pointer to it.  It would have to be marked  
something else...

Then comes the notion of deep locking: if you lock simply the this  
pointer, then it becomes tail-shared as you mentioned -- all the  
references the object contains are still shared.  You'd almost have to  
recursively lock everything, and then what if something has a cycle...

I'm thinking this shared thing is going to be only good for small POD, as  
it's going to be almost untennable to deal with repeating all  
implementation just because something is shared or not.  And even then,  
you probably want to copy the POD to non-shared form so you can pass it  
around.  I don't anticipate anyone making much more than a shared int.

-Steve
May 14 2009
parent Sean Kelly <sean invisibleduck.org> writes:
Steven Schveighoffer wrote:

 
 I'm thinking this shared thing is going to be only good for small POD, 
 as it's going to be almost untennable to deal with repeating all 
 implementation just because something is shared or not.  And even then, 
 you probably want to copy the POD to non-shared form so you can pass it 
 around.  I don't anticipate anyone making much more than a shared int.


Personally, I anticipate using shared for large global containers almost 
exclusively.  I've never considered the "interconnected web of shared 
objects" idea to be a good one, and building shared into the language 
doesn't change that.  For containers, a range returned by a shared 
container will probably have to hold the lock on that container until it 
is destroyed or shared won't be terribly useful.  I haven't thought 
about this very thoroughly, but that's my initial take on the idea.
May 14 2009
prev sibling parent reply bobef <bobef abv-nospam.bg> writes:
Walter Bright Wrote:


 I wrote a brief article which should help:
 
 http://www.digitalmars.com/d/2.0/migrate-to-shared.html



__gshared, __etc. These look ugly IMHO. :)
May 14 2009
next sibling parent reply BCS <none anon.com> writes:
Hello bobef,


 Walter Bright Wrote:
 

 I wrote a brief article which should help:
 
 http://www.digitalmars.com/d/2.0/migrate-to-shared.html
 


 __gshared, __etc. These look ugly IMHO. :)
 


I think that's the point: they look ugly because they are ugly.
May 14 2009
parent reply Leandro Lucarella <llucax gmail.com> writes:
BCS, el 14 de mayo a las 16:48 me escribiste:

 Hello bobef,
 

Walter Bright Wrote:

I wrote a brief article which should help:
http://www.digitalmars.com/d/2.0/migrate-to-shared.html


__gshared, __etc. These look ugly IMHO. :)


 
 I think that's the point: they look ugly because they are ugly.


I prefer normal keywords for standard things (keywords or symbols starting
with __ are historically reserved for compiler specific features or even
private stuff in Python). For __gshared I agree that it's something ugly
and it's fine if it looks ugly.

But __traits?! Come on! __traits is beutiful, it deserves a beutiful
keyword ;)

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
May 14 2009
next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Leandro Lucarella (llucax gmail.com)'s article

 BCS, el 14 de mayo a las 16:48 me escribiste:

 Hello bobef,


Walter Bright Wrote:

I wrote a brief article which should help:
http://www.digitalmars.com/d/2.0/migrate-to-shared.html


__gshared, __etc. These look ugly IMHO. :)


 I think that's the point: they look ugly because they are ugly.


 I prefer normal keywords for standard things (keywords or symbols starting
 with __ are historically reserved for compiler specific features or even
 private stuff in Python). For __gshared I agree that it's something ugly
 and it's fine if it looks ugly.
 But __traits?! Come on! __traits is beutiful, it deserves a beutiful
 keyword ;)


True.  I think I subconsciously avoid anything with an __ in front of it because
to me the connotation of an __ is "Only works if the stars align just right.
We're trying to scare you away from this feature for a reason.  Here be
monsters."
 If traits, excuse me, __traits, is stable enough not to deserve this
connotation,
then it absolutely deserves its own keyword.
May 14 2009
parent reply BCS <ao pathlink.com> writes:
Reply to dsimcha,


 True.  I think I subconsciously avoid anything with an __ in front of
 it because to me the connotation of an __ is "Only works if the stars
 align just right. We're trying to scare you away from this feature for 
 a reason.  Here be monsters."


like __gshared? <g>


 If traits, excuse me, __traits, is stable enough not to deserve this
 connotation, then it absolutely deserves its own keyword.


I think traits should get first class treatment as it really isn't being 
used as the backdoor hack that the __ implies.
May 14 2009
parent dsimcha <dsimcha yahoo.com> writes:
== Quote from BCS (ao pathlink.com)'s article

 Reply to dsimcha,

 True.  I think I subconsciously avoid anything with an __ in front of
 it because to me the connotation of an __ is "Only works if the stars
 align just right. We're trying to scare you away from this feature for
 a reason.  Here be monsters."


 like __gshared? <g>


Exactly, except __gshared deserves this treatment.
May 14 2009
prev sibling parent Rainer Deyke <rainerd eldwood.com> writes:
Leandro Lucarella wrote:

 I prefer normal keywords for standard things (keywords or symbols starting
 with __ are historically reserved for compiler specific features or even
 private stuff in Python). For __gshared I agree that it's something ugly
 and it's fine if it looks ugly.
 
 But __traits?! Come on! __traits is beutiful, it deserves a beutiful
 keyword ;)


I like the idea of using __ for temporary, transitional, and
experimental keywords.  Using __ has several advantages here:
  - It's unlikely to collide with existing identifiers.
  - You can create as many of them as you want without worrying about
namespace pollution.
  - It's ugly as a reminder that the feature is temporary, transitional,
or experimental.
  - It's easy to search for and easy to globally replace with a real
keyword.

Eventually all features using __ keywords should be removed, renamed, or
modified in such as way that they do not require a keyword at all.


-- 
Rainer Deyke - rainerd eldwood.com
May 14 2009
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
bobef wrote:

 __gshared, __etc. These look ugly IMHO. :)


They're only allowed in safe mode, and are meant to inspire people to 
use them only when there's no other choice. Hence the unattractiveness <g>
May 14 2009
parent Don <nospam nospam.com> writes:
Walter Bright wrote:

 bobef wrote:

 __gshared, __etc. These look ugly IMHO. :)


 
 They're only allowed in safe mode, and are meant to inspire people to 
 use them only when there's no other choice. Hence the unattractiveness <g>


Agreed. Yet as others have said, __traits deserves a beautiful keyword.
May 15 2009