Re: AST Macros?

On 01/06/12 21:37, Jacob Carlborg wrote: On 2012-06-01 17:47, Gor Gyolchanyan wrote: Where can I read more about Bartosz's race-free type system and if there are some specific ideas already, AST macros for D as well? AST macros have been mentioned in the newsgroups several times. There was a

Re: synchronized (this[.classinfo]) in druntime and phobos

Am 31.05.2012 17:05, schrieb Regan Heath: > .. but, hang on, can a thread actually lock a and then b? If 'a' cannot > participate in a synchronized statement (which it can't under this > proposal) then no, there is no way to lock 'a' except by calling a > member. So, provided 'a' does not have a

Re: synchronized (this[.classinfo]) in druntime and phobos

On Monday, June 04, 2012 10:51:08 mta`chrono wrote: > Am 31.05.2012 17:05, schrieb Regan Heath: > > .. but, hang on, can a thread actually lock a and then b? If 'a' cannot > > participate in a synchronized statement (which it can't under this > > proposal) then no, there is no way to lock 'a' exce

Re: AST Macros?

Le 01/06/2012 21:37, Jacob Carlborg a écrit : On 2012-06-01 17:47, Gor Gyolchanyan wrote: Where can I read more about Bartosz's race-free type system and if there are some specific ideas already, AST macros for D as well? AST macros have been mentioned in the newsgroups several times. There w

Re: synchronized (this[.classinfo]) in druntime and phobos

Le 04/06/2012 10:56, Jonathan M Davis a écrit : On Monday, June 04, 2012 10:51:08 mta`chrono wrote: Am 31.05.2012 17:05, schrieb Regan Heath: .. but, hang on, can a thread actually lock a and then b? If 'a' cannot participate in a synchronized statement (which it can't under this proposal) the

Making generalized Trie type in D

Cross-posting from my GSOC list as I think we had a lack of D rox posts lately :) I rarely am surprised by generic code flexibility and power these days. But once I fleshed out last bits of generalized Trie I was amazed. In short: it allows something like "make a multistage integer lookup tabl

Re: [Proposal] Additional operator overloadings for multidimentional indexing and slicing

On 03/06/12 19:31, tn wrote: On Friday, 1 June 2012 at 01:57:36 UTC, kenji hara wrote: I'd like to propose a new language feature to D community. ... This patch is an additional enhancement of opDollar (issue 3474 and #442). Sounds awesome. However, the name opDollar should be changed to some

Re: [Proposal] Additional operator overloadings for multidimentional indexing and slicing

On 04.06.2012 13:57, Don Clugston wrote: On 03/06/12 19:31, tn wrote: On Friday, 1 June 2012 at 01:57:36 UTC, kenji hara wrote: I'd like to propose a new language feature to D community. ... This patch is an additional enhancement of opDollar (issue 3474 and #442). Sounds awesome. However, t

Re: [Proposal] Additional operator overloadings for multidimentional indexing and slicing

On Monday, June 04, 2012 14:00:18 Dmitry Olshansky wrote: > On 04.06.2012 13:57, Don Clugston wrote: > > On 03/06/12 19:31, tn wrote: > >> On Friday, 1 June 2012 at 01:57:36 UTC, kenji hara wrote: > >>> I'd like to propose a new language feature to D community. > >>> ... > >>> This patch is an addi

Re: runtime hook for Crash on Error

On 01/06/12 12:26, Walter Bright wrote: On 6/1/2012 1:48 AM, Dmitry Olshansky wrote: On 01.06.2012 5:16, Walter Bright wrote: On 5/31/2012 3:22 AM, Dmitry Olshansky wrote: On 31.05.2012 13:06, deadalnix wrote: This is called failing gracefully. And this highly recommended, and you KNOW that t

Re: Exception/Error division in D

On 01/06/12 22:35, Walter Bright wrote: On 6/1/2012 11:14 AM, deadalnix wrote: We are talking about runing scope statement and finally when unwiding the stack, not trying to continue the execution of the program. Which will be running arbitrary code not anticipated by the assert failure, and c

Re: [Proposal] Additional operator overloadings for multidimentional indexing and slicing

On Monday, 4 June 2012 at 10:07:38 UTC, Jonathan M Davis wrote: TDPL already lists opDollar, and it's overloading the $ operator, so I would dispute that a better name _could_ exist. That would be like saying that opEquals would be better if it were renamed to opDoubleEqualSign. Actually, I'd

Re: [Proposal] Additional operator overloadings for multidimentional indexing and slicing

On Monday, 4 June 2012 at 10:00:20 UTC, Dmitry Olshansky wrote: On 04.06.2012 13:57, Don Clugston wrote: On 03/06/12 19:31, tn wrote: On Friday, 1 June 2012 at 01:57:36 UTC, kenji hara wrote: I'd like to propose a new language feature to D community. ... This patch is an additional enhancement

More synchronized ideas

After trying to make sense of the thread "synchronized (this[.classinfo]) in druntime and phobos", I had to write my opinion on all this somewhere that wouldn't be instantly lost in a bazilion of posts. It turned out into something quite elaborate.

Re: Making generalized Trie type in D

04.06.2012 13:46, Dmitry Olshansky написал: enum keywords = [ "abstract", "alias", "align", //... all of them, except @ ones "__traits" ]; A nitpick: constant arrays should be defined as `immutable` instead of `enum`. `enum

Re: More synchronized ideas

On Monday, 4 June 2012 at 11:17:45 UTC, Michel Fortin wrote: After trying to make sense of the thread "synchronized (this[.classinfo]) in druntime and phobos", I had to write my opinion on all this somewhere that wouldn't be instantly lost in a bazilion of posts. It turned out into something qu

Re: [Proposal] Additional operator overloadings for multidimentional indexing and slicing

David Nadlinger: Actually, I'd say its the other way round – opDollar rather corresponds to opDoubleEqualSign, as it simply describes the character used. I agree. It's the opposite of the semantic names of the original operator overloading set. Bye, bearophile

Re: Making generalized Trie type in D

On 6/4/12 4:46 AM, Dmitry Olshansky wrote: Cross-posting from my GSOC list as I think we had a lack of D rox posts lately :) [snip] I think it would be great if you converted this post into an article. Andrei

Re: [Proposal] Additional operator overloadings for multidimentional indexing and slicing

On 04/06/12 15:38, bearophile wrote: David Nadlinger: Actually, I'd say its the other way round – opDollar rather corresponds to opDoubleEqualSign, as it simply describes the character used. I agree. It's the opposite of the semantic names of the original operator overloading set. You mean

Re: [Proposal] Additional operator overloadings for multidimentional indexing and slicing

Don Clugston: You mean like the old opStar() (which meant deref), or like opBinary("+") ? I meant the even older ones :-) Bye, barophile

Re: Making generalized Trie type in D

On 04.06.2012 18:19, Andrei Alexandrescu wrote: On 6/4/12 4:46 AM, Dmitry Olshansky wrote: Cross-posting from my GSOC list as I think we had a lack of D rox posts lately :) [snip] I think it would be great if you converted this post into an article. Andrei Sounds good, will do once I fix f

[ offtopic ] About the "C++ Compilation Speed" article on DrDobbs

Walter: On this publication from 2010 http://www.drdobbs.com/blogs/cpp/228701711 you gave some insight and promised a follow up on what design decisions are important to make a compiler fast. Did you happen to have written it?

Re: Same _exact_ code in C and D give different results — why?

On 6/4/12, Mehrdad wrote: > (@Andrej Mitrovic, mainly) > > So I was using your library :) and this happened: > > http://stackoverflow.com/questions/10878586 > > Any ideas? > I'm not sure where it went wrong for you. I've made a test folder inside the samples dir, pasted your snippet to test.d and

Re: Phobos pull 613

On Sun, Jun 3, 2012 at 4:49 PM, Brad Anderson wrote: > This pull [1] adds std.net.curl to the Windows makefiles (it has been > missing for the last couple of releases). It'd be great if this could be > merged before the next release. Denis figured out what was preventing the > autotester from wor

Re: Same _exact_ code in C and D give different results — why?

On Monday, 4 June 2012 at 13:58:22 UTC, Mehrdad wrote: (@Andrej Mitrovic, mainly) So I was using your library :) and this happened: http://stackoverflow.com/questions/10878586 Any ideas? You need to specify subsystem 4.0 or something like that, google for .def file docs on dmc site.

Re: [ offtopic ] About the "C++ Compilation Speed" article on DrDobbs

On Monday, 4 June 2012 at 16:03:34 UTC, Victor Vicente de Carvalho wrote: Walter: On this publication from 2010 http://www.drdobbs.com/blogs/cpp/228701711 you gave some insight and promised a follow up on what design decisions are important to make a compiler fast. Did you happen to have wri

Re: Same _exact_ code in C and D give different results — why?

On Monday, 4 June 2012 at 13:58:22 UTC, Mehrdad wrote: Any ideas? Optlink says HI!

Re: Making generalized Trie type in D

On 04.06.2012 16:15, Denis Shelomovskij wrote: 04.06.2012 13:46, Dmitry Olshansky написал: enum keywords = [ "abstract", "alias", "align", //... all of them, except @ ones "__traits" ]; A nitpick: constant arrays should be defined as `immutable` instead of `enum`. `enum` means every time `keyw

Re: More synchronized ideas

On 2012-06-04 13:15:57 +, "Jason House" said: The example about current D seems a bit lacking. You change behavior because it's easy to code a different way. If you really want to use synchronized classes, then you should have two of them. The map can be in one synchronized class and the

Re: Same _exact_ code in C and D give different results — why?

On Monday, 4 June 2012 at 16:37:45 UTC, Kagamin wrote: On Monday, 4 June 2012 at 13:58:22 UTC, Mehrdad wrote: (@Andrej Mitrovic, mainly) So I was using your library :) and this happened: http://stackoverflow.com/questions/10878586 Any ideas? You need to specify subsystem 4.0 or something li

Re: Same _exact_ code in C and D give different results — why?

On Monday, 4 June 2012 at 16:20:00 UTC, Andrej Mitrovic wrote: On 6/4/12, Mehrdad wrote: (@Andrej Mitrovic, mainly) So I was using your library :) and this happened: http://stackoverflow.com/questions/10878586 Any ideas? I'm not sure where it went wrong for you. I've made a test folder i

Re: Same _exact_ code in C and D give different results — why?

On Monday, 4 June 2012 at 17:52:10 UTC, Mehrdad wrote: On Monday, 4 June 2012 at 16:37:45 UTC, Kagamin wrote: On Monday, 4 June 2012 at 13:58:22 UTC, Mehrdad wrote: (@Andrej Mitrovic, mainly) So I was using your library :) and this happened: http://stackoverflow.com/questions/10878586 Any id

Re: Same _exact_ code in C and D give different results — why?

04.06.2012 17:58, Mehrdad написал: (@Andrej Mitrovic, mainly) So I was using your library :) and this happened: http://stackoverflow.com/questions/10878586 Any ideas? Answer posted to stackoverflow. -- Денис В. Шеломовский Denis V. Shelomovskij

Re: Same _exact_ code in C and D give different results — why?

On Monday, 4 June 2012 at 17:52:10 UTC, Mehrdad wrote: On Monday, 4 June 2012 at 16:37:45 UTC, Kagamin wrote: On Monday, 4 June 2012 at 13:58:22 UTC, Mehrdad wrote: (@Andrej Mitrovic, mainly) So I was using your library :) and this happened: http://stackoverflow.com/questions/10878586 Any id

Re: Same _exact_ code in C and D give different results — why?

04.06.2012 21:57, John Chapman написал: On Monday, 4 June 2012 at 17:52:10 UTC, Mehrdad wrote: On Monday, 4 June 2012 at 16:37:45 UTC, Kagamin wrote: On Monday, 4 June 2012 at 13:58:22 UTC, Mehrdad wrote: (@Andrej Mitrovic, mainly) So I was using your library :) and this happened: http://sta

Re: More synchronized ideas

On Mon, 04 Jun 2012 07:17:45 -0400, Michel Fortin wrote: After trying to make sense of the thread "synchronized (this[.classinfo]) in druntime and phobos", I had to write my opinion on all this somewhere that wouldn't be instantly lost in a bazilion of posts. It turned out into something

Increment / Decrement Operator Behavior

The increment and decrement operators are highly dependent on operator precedence and associativity. If the actions are performed in a different order than the developer presumed, it could cause unexpected behavior. I had a simple idea to change the behavior of this operator. It works for the

Re: Making generalized Trie type in D

On Monday, 4 June 2012 at 15:35:31 UTC, Dmitry Olshansky wrote: On 04.06.2012 18:19, Andrei Alexandrescu wrote: On 6/4/12 4:46 AM, Dmitry Olshansky wrote: Cross-posting from my GSOC list as I think we had a lack of D rox posts lately :) [snip] I think it would be great if you converted this

Re: AST Macros?

On 2012-06-04 10:03, Don Clugston wrote: AST macros were discussed informally on the day after the conference, and it quickly became clear that the proposed ones were nowhere near powerful enough. Since that time nobody has come up with another proposal, as far as I know. I think others have s

Re: Making generalized Trie type in D

On Monday, 4 June 2012 at 12:15:33 UTC, Denis Shelomovskij wrote: 04.06.2012 13:46, Dmitry Olshansky написал: enum keywords = [ "abstract", "alias", "align", //... all of them, except @ ones "__traits" ]; A nitpick: constant arra

Re: Increment / Decrement Operator Behavior

On Mon, 04 Jun 2012 20:36:14 +0200, Xinok wrote: The increment and decrement operators are highly dependent on operator precedence and associativity. If the actions are performed in a different order than the developer presumed, it could cause unexpected behavior. I had a simple idea to

Re: GitHub for Windows

On Sat, 02 Jun 2012 16:30:07 -0400, Nick Sabalausky wrote: Ouch. I haven't had virus problems on my XP system (knock on wood...), but my sister's had a lot of virus trouble on her Win7 machine (and guess who had to fix the fucking thing every time...) Of course, my dad had a lot of virus

Re: Making generalized Trie type in D

On 04.06.2012 22:42, Roman D. Boiko wrote: On Monday, 4 June 2012 at 15:35:31 UTC, Dmitry Olshansky wrote: On 04.06.2012 18:19, Andrei Alexandrescu wrote: On 6/4/12 4:46 AM, Dmitry Olshansky wrote: Cross-posting from my GSOC list as I think we had a lack of D rox posts lately :) [snip] I thi

Re: runtime hook for Crash on Error

On Mon, 04 Jun 2012 06:20:56 -0400, Don Clugston wrote: 1. There exist cases where you cannot know why the assert failed. 2. Therefore you never know why an assert failed. 3. Therefore it is not safe to unwind the stack from a nothrow function. Spot the fallacies. The fallacy in moving from 2

Re: Same _exact_ code in C and D give different results — why?

On Monday, 4 June 2012 at 18:06:56 UTC, Denis Shelomovskij wrote: How can we all answer the same question in the same time without synchronization? Looks like it's a magical time... Or everyone could be replying at the exact same time (the time typing the reply doesn't count towards the time)

Re: Increment / Decrement Operator Behavior

If you find yourself using postfix increment/decrement operators in the same function call in multiple arguments, slap yourself firmly in the face and refactor that code.

Re: opCaret to complement opDollar when specifying slices

On Sat, 02 Jun 2012 07:49:16 -0400, Dario Schiavon wrote: Hi, I just read some old threads about opDollar and the wish to have it work for non zero-based arrays, arrays with gaps, associative arrays with non-numerical indices, and so on. It was suggested to define opDollar as the end o

Re: Increment / Decrement Operator Behavior

On Mon, 04 Jun 2012 20:57:11 +0200, simendsjo wrote: On Mon, 04 Jun 2012 20:36:14 +0200, Xinok wrote: The increment and decrement operators are highly dependent on operator precedence and associativity. If the actions are performed in a different order than the developer presumed, it coul

Re: Making generalized Trie type in D

On Monday, 4 June 2012 at 19:18:32 UTC, Dmitry Olshansky wrote: On 04.06.2012 22:42, Roman D. Boiko wrote: ... it is possible to create persistent (immutable) tries with efficient (log N) inserting / deleting (this scenario is very important for my DCT project). Immutable hash tables would req

Re: opCaret to complement opDollar when specifying slices

On Monday, 4 June 2012 at 19:55:49 UTC, Steven Schveighoffer wrote: On Sat, 02 Jun 2012 07:49:16 -0400, Dario Schiavon wrote: Hi, I just read some old threads about opDollar and the wish to have it work for non zero-based arrays, arrays with gaps, associative arrays with non-numerical indi

Re: opCaret to complement opDollar when specifying slices

On Mon, 04 Jun 2012 16:13:49 -0400, Mehrdad wrote: On Monday, 4 June 2012 at 19:55:49 UTC, Steven Schveighoffer wrote: On Sat, 02 Jun 2012 07:49:16 -0400, Dario Schiavon wrote: Hi, I just read some old threads about opDollar and the wish to have it work for non zero-based arrays, array

Re: opCaret to complement opDollar when specifying slices

On Monday, 4 June 2012 at 20:26:52 UTC, Steven Schveighoffer wrote: On Mon, 04 Jun 2012 16:13:49 -0400, Mehrdad Can you use "null"? Hm... now that null has its own type, I likely could. I suppose that would map properly to 0. -Steve But if the key is non-nullable this might be confusing, or

Re: Making generalized Trie type in D

[snip] Aye, the good thing about them - the amount of data affected by any change is localized to one "page". So you just copy it over and remap indices/pointers. Actually, Microsoft went this way (immutable hash tables) in their Roslyn preview implementation. However, I still believe that tries

Re: Increment / Decrement Operator Behavior

On Monday, 4 June 2012 at 20:08:57 UTC, simendsjo wrote: Oh, and what should writeln(i++, ++i, ++i, i++) do? It is messy whatever the logic implementation. For prefix operators, it would be logical to perform the action before the statement, such as the code would be rewritten as: ++i ++i w

Re: Increment / Decrement Operator Behavior

Bernard Helyer: If you find yourself using postfix increment/decrement operators in the same function call in multiple arguments, slap yourself firmly in the face and refactor that code. I think this is not acceptable, you can't rely on that, future D programers will not slap themselves and

Re: opCaret to complement opDollar when specifying slices

On Mon, 04 Jun 2012 16:32:55 -0400, Roman D. Boiko wrote: On Monday, 4 June 2012 at 20:26:52 UTC, Steven Schveighoffer wrote: On Mon, 04 Jun 2012 16:13:49 -0400, Mehrdad Can you use "null"? Hm... now that null has its own type, I likely could. I suppose that would map properly to 0. -Stev

Re: Making generalized Trie type in D

On Monday, 4 June 2012 at 20:40:03 UTC, Dmitry Olshansky wrote: [snip] Sorry my Trie implementation focused on "constructe once - read everywhere" case. My cases will likely have quite low amortized number of reads per insert / delete. How do you handle situations when not existent, etc., is

Re: Making generalized Trie type in D

On Monday, 4 June 2012 at 21:07:02 UTC, Roman D. Boiko wrote: For example, one by one would allow ignoring key encoding (and thus using multiple encodings simultaneously just as easily as single). It's just as easy with the whole thing. Treat it as bytes ;) Except when equivalent keys in diff

Re: Increment / Decrement Operator Behavior

On Monday, 4 June 2012 at 20:44:42 UTC, bearophile wrote: Bernard Helyer: If you find yourself using postfix increment/decrement operators in the same function call in multiple arguments, slap yourself firmly in the face and refactor that code. I think this is not acceptable, you can't rely

Re: opCaret to complement opDollar when specifying slices

On Saturday, 2 June 2012 at 11:49:17 UTC, Dario Schiavon wrote: Hi, I just read some old threads about opDollar and the wish to have it work for non zero-based arrays, arrays with gaps, associative arrays with non-numerical indices, and so on. It was suggested to define opDollar as the end of

Re: Making generalized Trie type in D

On 05.06.2012 1:16, Roman D. Boiko wrote: On Monday, 4 June 2012 at 21:07:02 UTC, Roman D. Boiko wrote: For example, one by one would allow ignoring key encoding (and thus using multiple encodings simultaneously just as easily as single). It's just as easy with the whole thing. Treat it as byt

Re: Making generalized Trie type in D

On Monday, 4 June 2012 at 21:39:50 UTC, Dmitry Olshansky wrote: And before you run away with that horrible idea of ever decoding UTF in lexer... Just don't do that. Trust me, it's not as small a price as it seems at first. At least keep it only at prototype stage as it simplifies things. I didn

Re: Making generalized Trie type in D

On Monday, 4 June 2012 at 21:39:50 UTC, Dmitry Olshansky wrote: On 05.06.2012 1:16, Roman D. Boiko wrote: I believe that once encoidng is established your compiler tool should use the best code for that encoding. And that means templates, tailored per encoding in my book. If anything I plan to

Re: Making generalized Trie type in D

On 05.06.2012 1:56, Roman D. Boiko wrote: On Monday, 4 June 2012 at 21:39:50 UTC, Dmitry Olshansky wrote: On 05.06.2012 1:16, Roman D. Boiko wrote: I believe that once encoidng is established your compiler tool should use the best code for that encoding. And that means templates, tailored per en

Re: Making generalized Trie type in D

On 05.06.2012 2:06, Dmitry Olshansky wrote: On 05.06.2012 1:56, Roman D. Boiko wrote: On Monday, 4 June 2012 at 21:39:50 UTC, Dmitry Olshansky wrote: On 05.06.2012 1:16, Roman D. Boiko wrote: I believe that once encoidng is established your compiler tool should use the best code for that encodi

Re: Making generalized Trie type in D

On Monday, 4 June 2012 at 22:06:49 UTC, Dmitry Olshansky wrote: On 05.06.2012 1:56, Roman D. Boiko wrote: Will it be difficult to adapt your API for immutable tries? E.g., it is not possible to implement immutable sequence (linked list) as a range, Linked list? I'm horrified. Though I'd need

Re: More synchronized ideas

On 2012-06-04 18:22:22 +, "Steven Schveighoffer" said: On Mon, 04 Jun 2012 07:17:45 -0400, Michel Fortin wrote: After trying to make sense of the thread "synchronized (this[.classinfo]) in druntime and phobos", I had to write my opinion on all this somewhere that wouldn't be instan

Re: Making generalized Trie type in D

On Monday, 4 June 2012 at 22:21:42 UTC, Dmitry Olshansky wrote: And you can fake immutability, buy always picking up an unused slot btw. No need to go beyond logical immutability. That's applicable in some cases, not in general. But I agree that often it is possible to optimize if use cases are

Re: Increment / Decrement Operator Behavior

On Monday, June 04, 2012 23:22:26 Bernard Helyer wrote: > On Monday, 4 June 2012 at 20:44:42 UTC, bearophile wrote: > > Bernard Helyer: > >> If you find yourself using postfix increment/decrement > >> operators in the same function call in multiple arguments, > >> slap yourself firmly in the face a

Re: Increment / Decrement Operator Behavior

Jonathan M Davis: If they don't bother to learn, then they're going to get bitten, and that's life. A modern language must try to avoid common programmer mistakes, where possible (like in this case). As for treating pre or post-increment operators specially in some manner, that doesn't ma

Re: Increment / Decrement Operator Behavior

On Monday, 4 June 2012 at 20:44:42 UTC, bearophile wrote: 1) Make post/pre increments return void. This avoid those troubles. I think Go language has chosen this. This is my preferred solution. I wonder in that case, is it even worth including in the language? For me anyways, the whole point of

Add compile time mutable variable type

I need a type can be change on compile time, it can be immutable or mutable at run time. For example : --- abstract class Template_parameter_Base{ TypeInto ti; string file ; size_t line l;

Re: Add compile time mutable variable type

On Tuesday, 5 June 2012 at 01:01:07 UTC, Chang Long wrote: I need a type can be change on compile time, it can be immutable or mutable at run time. For example : --- abstract class Template_parameter_Base{ Typ

Re: Increment / Decrement Operator Behavior

On Jun 4, 2012 8:43 PM, "Xinok" wrote: > > I wonder in that case, is it even worth including in the language? For me anyways, the whole point of these operators is to use them in expressions. Otherwise, why not simply write (i+=1)? For pointers they are useful because they go up in units not byte

Re: Add compile time mutable variable type

On Tuesday, 5 June 2012 at 01:01:07 UTC, Chang Long wrote: I need a type can be change on compile time, it can be immutable or mutable at run time. For example : --- abstract class Template_parameter_Base{ Typ

Re: More synchronized ideas

On Monday, 4 June 2012 at 17:40:38 UTC, Michel Fortin wrote: On 2012-06-04 13:15:57 +, "Jason House" said: If you really want to use synchronized classes, then you should have two of them. Valid comment. I thought about creating yet another example illustrating that, but I gave up when

Re: More synchronized ideas

On 2012-06-05 01:58:04 +, "Jason House" said: I was thinking something more like this: shared class Dictionary { private SynchronizedCounters counters; private SynchronizedStringMap translations(counters); void addWord(string word, string foreignWord) shared { // synchron

Re: Making generalized Trie type in D

On 05.06.2012 2:28, Roman D. Boiko wrote: On Monday, 4 June 2012 at 22:21:42 UTC, Dmitry Olshansky wrote: And you can fake immutability, buy always picking up an unused slot btw. No need to go beyond logical immutability. That's applicable in some cases, not in general. But I agree that often i

Re: More synchronized ideas

On Monday, 4 June 2012 at 11:17:45 UTC, Michel Fortin wrote: After trying to make sense of the thread "synchronized (this[.classinfo]) in druntime and phobos", I had to write my opinion on all this somewhere that wouldn't be instantly lost in a bazilion of posts. It turned out into something qu

Re: Making generalized Trie type in D

On Tuesday, 5 June 2012 at 04:42:07 UTC, Dmitry Olshansky wrote: On 05.06.2012 2:28, Roman D. Boiko wrote: My example concern was about fundamental problem of range APIs for immutable data structures, which is not possible to emulate: popFront is mutating by design. Keep in mind Ranges are t

Re: Making generalized Trie type in D

On Monday, 4 June 2012 at 22:22:34 UTC, Roman D. Boiko wrote: On Monday, 4 June 2012 at 22:06:49 UTC, Dmitry Olshansky wrote: On 05.06.2012 1:56, Roman D. Boiko wrote: so range API doesn't fit that (but could with a tweak - returning tail instead of mutating in popFront). If trie API will have

Re: Making generalized Trie type in D

On Tuesday, 5 June 2012 at 05:28:48 UTC, Roman D. Boiko wrote: ... without deep analysis I can't come up with a good API / design for that (without overcomplicating it). Probably keeping mutable and immutable APIs separate is the best choice. Will return to this problem once I get a bit of free

Re: Add compile time mutable variable type

On 06/04/2012 06:22 PM, Chang Long wrote: > The previous two example is not correct, please see this one: Your post sounds interesting but there are lots of errors: > size_t line l; <-- ERROR > void this(string name) { <-- ERROR etc. Can you actually compile that code? It would be better if

Re: More synchronized ideas

On Tuesday, 5 June 2012 at 05:14:36 UTC, Nathan M. Swan wrote: On Monday, 4 June 2012 at 11:17:45 UTC, Michel Fortin wrote: After trying to make sense of the thread "synchronized (this[.classinfo]) in druntime and phobos", I had to write my opinion on all this somewhere that wouldn't be instant

Re: Add compile time mutable variable type

On Tuesday, 5 June 2012 at 05:39:34 UTC, Ali Çehreli wrote: On 06/04/2012 06:22 PM, Chang Long wrote: > The previous two example is not correct, please see this one: Your post sounds interesting but there are lots of errors: > size_t line l; <-- ERROR > void this(string name) { <-- ERROR et

Re: runtime hook for Crash on Error

On 04/06/12 21:29, Steven Schveighoffer wrote: On Mon, 04 Jun 2012 06:20:56 -0400, Don Clugston wrote: 1. There exist cases where you cannot know why the assert failed. 2. Therefore you never know why an assert failed. 3. Therefore it is not safe to unwind the stack from a nothrow function. S