Re: Here's looking at you, kid
On Saturday, 14 November 2015 at 03:40:08 UTC, Walter Bright wrote: The current state can be found here: https://www.youtube.com/watch?v=IkwaV6k6BmM slides: http://www.walterbright.com/cppint.pdf If someone would care to turn that into a pull request for http://dlang.org/cpp_interface.html that would be most appreciated! Walter, why didn't you make an announce thread for this talk? It would have been very popular on reddit as well.
Re: Here's looking at you, kid
On Saturday, 14 November 2015 at 13:46:32 UTC, Russel Winder wrote: On Sat, 2015-11-14 at 10:47 +1000, Manu via Digitalmars-d wrote: […] I'd love to read a revised edition of that page! :) So write it, and do the pull request. It doesn't matter if it is any good or not, what matters is activity. All the waffling and wailing on the mailing list results in f### a##, only constructive activity changes things. Someone putting something forward will generate activity leading to something better. The reason people are posting instead of editing is because nobody friggin knows how the new stuff works except Daniel Murphy. At least that's what I thought until Walter posted the dconf talk which ostensibly explains it; I haven't watched it yet, but if I do and it covers the new stuff, then I will definitely update the specification.
Re: Catching C++ std::exception in D
David Nadlinger writes: > On Friday, 13 November 2015 at 18:40:06 UTC, Iain Buclaw wrote: >> There may be a few other holes between how Fibers and EH interact. >> >> https://github.com/D-Programming-Language/druntime/commit/f6633abb43ea1f2464d3a772b8f8fe78216ffd8e > > The SJLJ stack switching should probably be added to this mechanism. > > — David I did a quick experiment to merge the two approaches and it failed in unittests. I am not sure why yet. They are implemented slightly different in that SjLj context is saved in the Fiber object, whereas _d_eh_swapContext is saving in a Thread.Context object.
Re: Implement the "unum" representation in D ?
On 09/11/15 04:38, Richard Davies wrote: On Friday, 18 September 2015 at 03:19:26 UTC, Nick B wrote: On Thursday, 17 September 2015 at 23:53:30 UTC, Anthony Di Franco wrote: I read the whole book and did not regret it at all, but I was already looking for good interval arithmetic implementations. I found that the techniques are not too different (though improved in important ways) from what is mainstream in verified computing. Hi, I haven't finished the book but have read over half of it and browsed the rest. I wanted to add that an implementation of unums would have advantages beyond verifiable computing. Some examples that spring to mind are: Using low precision (8-bit) unums to determine if an answer exists before using a higher precision representation to do the calculation (example briefly discussed in the book is ray tracing). More generally, unums can self-tune their precision which may be generally useful in getting high precision answers efficiently. It is possible for the programmer to specify the level of accuracy so that unums don't waste time calculating bits that have no meaning. Parallelisation - floating point ops are not associative but unum ops are. Tighter bounds on results than interval arithmetic or significance arithmetic. These are just a few areas where a software implementation could be useful. If you've ever had any issues with floating point, I'd recommend reading the book, not just because of the approach it proposes to solve these but also because it's very clearly written and quite entertaining (given the subject matter). Richard Yeah, I got curious too. I spend some time on it yesterday and had a stab at writing it in D. I was playing with the idea of using native floating point types to store Unums. This would not have the full benefit of the dynamically sized Unums, but would allow for the accuracy benefits. Still need to implement the basic arithmetic (interval) stuff: https://github.com/lionello/unumd L.
Re: Will std.allocator make it easy to bypass the GC?
On Saturday, 14 November 2015 at 14:56:57 UTC, maik klein wrote: http://dlang.org/phobos/std_experimental_allocator.html I am not sure what the plan is but it seems to me that the standard library could make use of the "theAllocator" for allocation and also allow you to swap in different allocators. So could it then be possible to completely bypass the GC once "allocators" are used by the std? I imagine that we could set "theAllocator = Malloc" and every allocation will use malloc? Or maybe some function allocates by default but you know that the allocation is small enough to be allocated on the stack which would allow us to call the function like this "someFunction!(StackAlloactor)(foo);" ? Allocators provide mechanisms for allocating memory but don't do anything for memory management. Unlike the GC which automatically frees memory, you must explicitly free memory in allocators. In fact, some allocators aren't even required to implement free(). Allocators and containers should go a long way in eliminating much use of the GC in the std library. However, some language features still rely on the GC and we'll need alternate mechanisms to deal with those, such as RC or lifetime semantics (a la Rust).
Re: Persistent list
On Saturday, 14 November 2015 at 16:05:10 UTC, Andrei Alexandrescu wrote: Technically, that clearly works. There's a problem with scaling it up: COMPOSITION Disallowing immutable(RC!T) in favor of RC!(immutable T) effectively disables composition of larger immutable objects from smaller ones. Yeah, I totally agree, I by no means think that external reference counting is some kind of silver bullet - as proven time and again, it is rife with issues when applied generally. I just wanted to point out, since a lot of lay people read these threads, that it will continue to be an option. I look forward to see what kind of memory safe reference counting you PL buffs will figure out. One obvious thing to do is with a reference counted object it to make it a field of a larger object. That effectively makes that larger object impossible to be used with immutable, transitively. Random off-topic thought (sorry): maybe the immutable larger object could survive if there was a way to make immutable(RefCounted!T) behave like immutable(Unique!T). It would be uncopyable (non-copyable? Damn you, boost!) but perhaps still usable. I guess it would still need a cast for `free`/`deallocate` in the destructor.
Thought on the 2015H2 Vision Participation Goal
Hi everyone, Just looked at the vision for this half, and I had an idea pop in my head. Before I get to that idea, let me explain what I think might be an issue with it as-is. I've consistently seen D's participation metrics marked by the number of pull requests created and closed, which is great. This gives us input as to how active people are on actually developing the core part of D. Unfortunately it doesn't give us an indication as to what caused this number to increase. Was it new users? Was it people becoming more familiar being more productive? Etc. While I don't doubt participation is correlated to pull request counts, I don't think its a great indicator of new users. Furthermore, I don't know if this can scale. We get small dedicated group capable of taking out 3-5 issues a month each, and where does that leave us? With a lot of issues open probably. How do we fix that? Ask the small dedicated group to take more time out of their, presumably busy, life and fix our problems for us. # So what should we do instead? Why not try and target people who haven't worked on a language previously that are interested in doing so, but don't know where to get started. I definitely fall into this group. I know there's something I could do that would be useful, but I don't know how to find it to get it done. I just wish there was something out there that literally baby stepped me through the entire process. Yeah, I might not be tackling extremely difficult problems right out of the gate, but if there was even 20% of our issues that the only thing holding them up is a lack of someone assigned to them, this could be a huge win for everyone. # What could we do to accomplish this? Here's where I think that reorienting the goal actually makes the goal a lot more manageable. At the cost of efficiency now, what I (and presumably people like me) need are those baby steps. Ideas could include: * A video about setting up their environment from scratch. This is presumably 1 time thing for most users, but honestly one of the easiest ways to get discouraged. If you're on your own for this it instantly feels like you're going to be on your own for all of it. It really shreds any notion of a community working together. Because of the experience this can cause, and the minimal amount of time that's required to do this, it should be a no-brainer. * Flags for issues that are based on expected completion time for someone reasonably competent with D. As a newcomer, I might not know how involved an issue is. E.g. I don't mind spending 1-3 hours this week, but *every* issue looks like it might unravel on me and take a really long time. * Live code reviews where there can be feedback from experts on how to approach things in a D oriented way. The forums work great for getting a quick answer on something, but a lot of times newcomers don't know the correct question to ask. This kind of interaction is also extremely marketable... look at Jonathan Blow with Jai, and he isn't even letting people use it yet. People interested in helping out with this kind of project need to learn somewhere... why not D? TL;DR: Change our participation goal to be more oriented towards force multiplication. I question whether PR activity is a sustainable metric.
Re: Persistent list
On Saturday, 14 November 2015 at 23:20:08 UTC, Andrei Alexandrescu wrote: On 11/14/15 5:49 PM, Timon Gehr wrote: It's supposed to guarantee that the given reference is not used to transitively mutate the object. The casts violate this. I think that semantics needs to change. Specifically, either we add a @mutable attribute (which means const doesn't apply to fields marked as such and immutable objects cannot be created); or we could just decree that if a const object originates in a mutable object, casts should be well-defined. -- Andrei Either way, we'd be throwing away the idea that const is physical const and provides actual guarantees against mutation via const references. We'd essentially be going the route of having C++'s const except that it's transitive, which is a definite loss IMHO, but at the same time, with D's const, you frequently have to give up on using const, because physical const is so restrictive as to be unusable in many cases. I honestly don't know if it's better to just say that you can't use const if you want to do something like reference counting or using an allocator or to gut the guarantees that D's const provides. Ideally, we'd keep the guarantees, but they often seem to end up being completely impractical in practice. And they don't jive at all with the recent push to support RC. That being said, if we are going to make a change like this, I'm not sure if we even _can_ do it. immutable throws a serious wrench in any attempt have something like C++'s const in D. As it stands, the only thing that really ensures that immutable objects aren't mutated is the type system. As I understand it, if an immutable object gets put into ROM (or memory that's being treated as ROM), then mutating it will cause a segfault, but the only case where that might happen right now AFAIK is if the object was created at compile time and stored as part of the program's data. Certainly, any immutable objects created at runtime are only protected from mutation by the type system. So, even if the compiler makes _zero_ assumptions based on const, casting away const and mutating is very dangerous, because you risk mutating an immutable object and violating all of the guarantees associated with that. The only time that casting away const and mutating could work would be in cases where you could somehow guarantee that the object you're mutating is actually a mutable variable underneath the hood. That would be possible in a restricted setting, but in a large program or in a public API, it's a lot less likely that you can guarantee that the object isn't actually immutable. There would have to be some way for the type system to guarantee that the object isn't actually immutable - which either means making it so that the type in question can't be immutable for some reason or having an attribute other than const for non-physical const. Your @mutable suggestion/proposal does step in that direction by basically making it so that a const type which contains a @mutable member isn't really const. It's some other attribute that's not explicitly named (cpp_const, logical_const, @mutable_const, or whatever we'd want to call it). And that seems like it would work to a point. It would even allow for implicit casts instead of explicit ones and make the whole thing far safer in general than simply allowing arbitrary casting would. However, @mutable still isn't an attribute on the type. It's an attribute on a member. So, as soon as you have an opaque pointer or a base class reference, the compiler doesn't know that the object is actually @mutable_const. So, it can't know that it's not legit to have the object be immutable. Now, the compiler would have to know that when the object is created, and presumably an @mutable_const derived class couldn't convert to an immutable base class, so maybe this would actually work, but it seems like we're at serious risk of a loophole if we're not really careful here. It feels like each time work through this I flip-flop as to whether I think that it can work or not. And of course, even if we do make @mutable work, it would basically mean that const doesn't necessarily guarantee much of anything anymore other than preventing accidental mutation, since unless the compiler can guarantee that no @mutable_const is involved, it can't assume much of anything about const (though what it can assume about const is already pretty limited - particularly when pure isn't involved), and programmers can't assume that a const object will really not be mutated by const member functions (though in practice, it's unlikely that anyone is going to slap @mutable on everything). But even then, we'd still be ahead of C++'s const if we have transitivity and disallow casting away const to mutate. I'm torn on the whole thing. On the one hand, I think that D's guarantees with physical const have been great. On the other hand, too much
Re: D parsing
On Sunday, 3 November 2013 at 01:45:23 UTC, Timothee Cour wrote: 1) The main issue I see with pegged is PEG grammars don't support left recursion, so for example will fail on foo[1].bar(2).fun(). Unless there's a plan to accomodate those, I sense a dead end. One can eliminate left recursion but this has issues. 2) There is some material on extending PEG to support those, eg "Left Recursion in Parsing Expression Grammars", or code https://github.com/orlandohill/peg-left-recursion but I don't know how well they work in practice. Left-recursion for Pegged is in the works: https://github.com/PhilippeSigaud/Pegged/pull/164 :-)
critical wrong code
This code fails on 32 bit Linux / FreeBSD.
It is very dangerous bug.
Please pay attention to it!
```
unittest {
double a, b;
a = -5.50533e+307;
b = 4.49423e+307;
writefln("a = %a, b = %a, (a+b)/2.0 = %a", a, b, (a+b)/2.0);
assert((a+b)/2.0 > a);
}
```
issue: https://issues.dlang.org/show_bug.cgi?id=15204
Re: Catching C++ std::exception in D
Sorry for the delay, here's the initial commit for C++ exception catching in Calypso: https://github.com/Syniurge/Calypso/commit/8b55ec1f013c29df86455ab055fbba91a72d92af https://github.com/Syniurge/druntime/commit/d33d8bf32c739bf9a30705dfc764718c817f16b1 The main files of interest are: https://github.com/Syniurge/druntime/blob/release-0.16.1/src/ldc/eh/cpp/gnu.d https://github.com/Syniurge/Calypso/blob/master/gen/cpp/cppeh.cpp And a basic example which segfaults at e.what() because __cxa_begin_catch returns null: https://github.com/Syniurge/Calypso/blob/master/tests/calypso/eh/std_exception.d Resulting IR : https://paste.kde.org/pvi2bokqx catch (C++) were added to be able to catch any type, and that's the only cost for being able to catch any C++ exception and not just std::exception I think, Clang and the libstdc++ makes working with std::type_info very easy. For the time the handler uses unwind-cxx.h copied from GNU's libstdc++ (it's an internal header which doesn't ship with any Ubuntu package). Its license is more permissive than the GPL, but if it isn't compatible it could be replaced by its libc++ equivalent.
Re: Persistent list
On 11/15/2015 12:20 AM, Andrei Alexandrescu wrote: On 11/14/15 5:49 PM, Timon Gehr wrote: It's supposed to guarantee that the given reference is not used to transitively mutate the object. The casts violate this. I think that semantics needs to change. Specifically, either we add a @mutable attribute (which means const doesn't apply to fields marked as such and immutable objects cannot be created); or we could just decree that if a const object originates in a mutable object, casts should be well-defined. -- Andrei There's also this closely related situation: https://issues.dlang.org/show_bug.cgi?id=9149 (I.e. delegates with mutable context pointer can be implicitly converted to delegates with const context pointer, but when type checking the delegate, a mutable context pointer is assumed.)
Re: Persistent list
On 11/14/2015 11:37 PM, Andrei Alexandrescu wrote: On 11/14/2015 05:04 PM, Timon Gehr wrote: We have had the discussion you are asking for before, and you have decided to ignore it, with the justification that this was how you decided and a vague appeal to emotion. I usually don't operate under the assumption that identical experiments lead to different outcomes without a good reason. Yah, of course I remember that discussion. Thing is I remained unconvinced after said discussion. There's no technical argument being made here. It's a judgment call. Clearly allowing List!int with the same codebase as http://dpaste.dzfl.pl/0981640c2835 is possible, and it would allow a number of additional uses at the cost of somewhat murky semantics (that list is not a value and not a reference; defining other containers with similar semantics is tricky). But there's a distinct possibility: List!(immutable int) is indistinguishable from a value type - each value is independent from all others, up to taking address of elements in the list. So what we could do is define List!int to implement value semantics with a completely different implementation - COW. How to implement COW without support for writing? That's a very appealing equation for the user: "List!T is always a value regardless of T." Optimizations apply depending on T, but that's transparent and the user doesn't need to care. A List!T is a value. Boom. Done. ... It is awesome if List!T acts like a value type. More precisely, like a struct. That in particular means its elements should not always need to be transitively immutable. Per what you propose, we'd have "List!T is a Lisp-style list. It has cons cells and atoms, and cons(head, list) creates a new list that shares its tail with list." etc. ... It's not precisely what I want, but it is a way to get close. Ideal semantics would be that List!T is a value type with (by default, unless qualified immutable) mutable slots, much like what you get for structs. Now the problem is just that D does not support expressing this. Allowing mutable reference access is the next most obvious viable thing, but maybe we can find another way to get close to the right semantics. (I guess we might never support mutating method calls on elements in the best fashion possible though.) You seem to assert there's no contest, and anyone choosing (1) over (2) is seriously incompetent. There's no contest because there shouldn't need to be a mandated choice. Categorically choosing (2) over (1) is not the right course of action either. (And (2) is already a suboptimal compromise!) I seem to think there is a real choice there, and I want to keep it open for the time being. Is this reasonable? ... This is reasonable enough. It's not what "I've decided persistent lists with mutable elements just too weird to endorse" communicates though. I think it is clear what can be done next time (on both sides) to avoid an unproductive subthread like this one. Maybe not, but what is? It can't be laying down a well-reasoned argument, because as recent history shows it will just be ignored without a reasonable justification. I guess one other good way to proceed would be to just not have the dialog for now and instead wait until people who are actually trying to use the containers start complaining in blog posts and on reddit. Feel free to voice any better suggestions you may have. One interesting problem Walter and I have as leaders of this community is to attract within the core circle people who are literally better than ourselves. People whom we can trust with using good judgment in complex situation and can lead themselves entire features and parts of the language (such as compiler-supported RC etc). Amaury and you (Timon) may as well be the smartest people hanging out in this forum. You both are also very generous with your time. I can't talk for Walter, but for all I can tell you two are better than I'll ever be at all metrics that matter to language design. The challenge, then, becomes in convincing you to put that good expertise and good will toward something positive; because, to be blunt, a large chunk of your and Amaury's energy is dedicated to picking fights and proving just what chowderheads Walter and I are for not doing as you say. I'm very happy to admit - you're a whole lot better than myself. So let's do something constructive. ... That's flattering, thanks! But it was not my intention to pick a fight. It is just that for my current project, persistent data structures would be a great option to have. However, the data structures would be close to useless to me if they were to mandate transitive immutability, and mirroring them manually is a PITA.
Re: Persistent list
On 11/14/15 5:49 PM, Timon Gehr wrote: It's supposed to guarantee that the given reference is not used to transitively mutate the object. The casts violate this. I think that semantics needs to change. Specifically, either we add a @mutable attribute (which means const doesn't apply to fields marked as such and immutable objects cannot be created); or we could just decree that if a const object originates in a mutable object, casts should be well-defined. -- Andrei
Re: Persistent list
On 11/14/2015 10:59 PM, Andrei Alexandrescu wrote: On 11/14/2015 03:55 PM, Timon Gehr wrote: On 11/14/2015 12:10 AM, Andrei Alexandrescu wrote: ... * Lines 11-12: I came to terms with the notion that some types cannot be made immutable. We've been trying to do reference counting on immutable objects for a long time. It's time to acknowledge that true immutability (which the immutable keyword models) and reference counting don't mix. Const does work (more below). But overall I'm at peace with the notion that if you can't live without immutable, I'll refer you to the garbage collector. ... I.e. you think it is fine that there can be no list of lists. T may be const in List!T, so composing with const should work fine. ... List uses RC internally. I don't think the UB casts will stay for the final version, unless you are willing to completely dilute the meaning of const in ways that Walter has explicitly expressed will not be done in the past. Anyway, the static assert does not actually do what you intend it to do. The odd thing is it does as far as I can tell, but the error message is less than informative. Try it! ... I cannot get the list to compile with 2.069.1 without replacing the calls to emplace, which is odd (as it works on dpaste), but in any case, the static assert is a no-op. typeof(this) is always unqualified at aggregate scope. What is preventing the construction of a non-empty immutable list is that there is no immutable non-default constructor. * Lines 26-29: The allocator is fundamentally a mutable part of the container. This is an insufficiency of our type system - we can't say "this object may be constant, but this reference is to a mutable part of it". We can't explain that necessity out of existence, and List is part of the proof. So we need to make that cast legal. ... Just don't make the method const. (This is not C++.) I want to allow mutable lists and const lists, just not immutable lists. It seems to me const has a value even if it doesn't originate from immutable. ... It's supposed to guarantee that the given reference is not used to transitively mutate the object. The casts violate this.
Re: Persistent list
On 11/14/2015 05:04 PM, Timon Gehr wrote: We have had the discussion you are asking for before, and you have decided to ignore it, with the justification that this was how you decided and a vague appeal to emotion. I usually don't operate under the assumption that identical experiments lead to different outcomes without a good reason. Yah, of course I remember that discussion. Thing is I remained unconvinced after said discussion. There's no technical argument being made here. It's a judgment call. Clearly allowing List!int with the same codebase as http://dpaste.dzfl.pl/0981640c2835 is possible, and it would allow a number of additional uses at the cost of somewhat murky semantics (that list is not a value and not a reference; defining other containers with similar semantics is tricky). But there's a distinct possibility: List!(immutable int) is indistinguishable from a value type - each value is independent from all others, up to taking address of elements in the list. So what we could do is define List!int to implement value semantics with a completely different implementation - COW. That's a very appealing equation for the user: "List!T is always a value regardless of T." Optimizations apply depending on T, but that's transparent and the user doesn't need to care. A List!T is a value. Boom. Done. Per what you propose, we'd have "List!T is a Lisp-style list. It has cons cells and atoms, and cons(head, list) creates a new list that shares its tail with list." etc. You seem to assert there's no contest, and anyone choosing (1) over (2) is seriously incompetent. I seem to think there is a real choice there, and I want to keep it open for the time being. Is this reasonable? Maybe not, but what is? It can't be laying down a well-reasoned argument, because as recent history shows it will just be ignored without a reasonable justification. I guess one other good way to proceed would be to just not have the dialog for now and instead wait until people who are actually trying to use the containers start complaining in blog posts and on reddit. Feel free to voice any better suggestions you may have. One interesting problem Walter and I have as leaders of this community is to attract within the core circle people who are literally better than ourselves. People whom we can trust with using good judgment in complex situation and can lead themselves entire features and parts of the language (such as compiler-supported RC etc). Amaury and you (Timon) may as well be the smartest people hanging out in this forum. You both are also very generous with your time. I can't talk for Walter, but for all I can tell you two are better than I'll ever be at all metrics that matter to language design. The challenge, then, becomes in convincing you to put that good expertise and good will toward something positive; because, to be blunt, a large chunk of your and Amaury's energy is dedicated to picking fights and proving just what chowderheads Walter and I are for not doing as you say. I'm very happy to admit - you're a whole lot better than myself. So let's do something constructive. Andrei
Re: Our template emission strategy is broken
On 11/13/2015 07:51 AM, Stefan wrote: On Thursday, 12 November 2015 at 23:08:57 UTC, Jakob Ovrum wrote: > [...dependency check...] It can be implemented as an external tool with the -deps compiler switch. there is depend [1]. It warns about cycles and unintended dependencies if you specify the target dependencies. It helps us to maintain our commercial code base. src as well as unittest. [1] https://github.com/funkwerk/depend Hi Stefan, it was great to meet in Stuttgart! This is a simple but very useful tool, it ought to be made part of the standard distribution. I just created https://issues.dlang.org/show_bug.cgi?id=15337, in summary: 1. Relicensing the work under Boost 2. Make the tool easier to use, e.g. have it run dmd automatically if needed etc. 3. Integrate the tool within the tools/ repository and make it part of the standard dmd distribution. Good tooling has been a huge asset for Go - we could take a page from their book. Stefan, Dragos - do you guys think you could take this to completion? Thanks, Andrei
Re: Persistent list
On 11/14/2015 09:42 PM, Andrei Alexandrescu wrote: On 11/14/2015 03:36 PM, Timon Gehr wrote: Right, because e.g. whether the elements are reference counted or traced should totally completely change the required container semantics for the problem at hand! This does not make any sense, unless you are saying that nobody should actually use the persistent containers, in which case it seems like a waste of time to concentrate efforts on them. I'm just as weary of persistent containers of mutable elements using GC. It doesn't make a difference. ... There must be a misunderstanding here. Fully mutable vs fully transitive immutable is a false dichotomy. I'm arguing for allowing at least the obviously valid use cases, you are arguing for disallowing at least the obviously wrong use cases. You have not provided a technical argument, so I am going to assume you have an irrational fear of bad PR. Forcing transitive immutable on people who want persistent container semantics is ultimately a very poor choice both from a technical and a PR perspective. The English language has a word I like a lot: "unassuming". I'm not sure about its etymology, but a nice theory is "a person who doesn't assume bad things about others". ... Assuming this was the definition, your well-meaning intention cannot be to say that you assume that I am not entirely unassuming unless you consider it a good thing not to be unassuming. Anyway, I don't consider appeal to the assumed etymology of words to be a sound principle of reasoning. In case that was unclear, I clearly did not mean to _assert_ that you in fact have this fear, as I have no way to know. I was just trying to probe what your reasoning was built on and possibly argue against it. Furthermore, it wouldn't necessarily be a bad thing. I'm glad to hear about various pros and cons regarding these containers. We have had the discussion you are asking for before, and you have decided to ignore it, with the justification that this was how you decided and a vague appeal to emotion. I usually don't operate under the assumption that identical experiments lead to different outcomes without a good reason. Slinging this kind of stuff (I'm not slinging any kind of stuff.) is unlikely to further the dialog. ... Maybe not, but what is? It can't be laying down a well-reasoned argument, because as recent history shows it will just be ignored without a reasonable justification. I guess one other good way to proceed would be to just not have the dialog for now and instead wait until people who are actually trying to use the containers start complaining in blog posts and on reddit. Feel free to voice any better suggestions you may have.
Re: Persistent list
On 11/14/2015 03:55 PM, Timon Gehr wrote: On 11/14/2015 12:10 AM, Andrei Alexandrescu wrote: ... * Lines 11-12: I came to terms with the notion that some types cannot be made immutable. We've been trying to do reference counting on immutable objects for a long time. It's time to acknowledge that true immutability (which the immutable keyword models) and reference counting don't mix. Const does work (more below). But overall I'm at peace with the notion that if you can't live without immutable, I'll refer you to the garbage collector. ... I.e. you think it is fine that there can be no list of lists. T may be const in List!T, so composing with const should work fine. Anyway, the static assert does not actually do what you intend it to do. The odd thing is it does as far as I can tell, but the error message is less than informative. Try it! * Lines 26-29: The allocator is fundamentally a mutable part of the container. This is an insufficiency of our type system - we can't say "this object may be constant, but this reference is to a mutable part of it". We can't explain that necessity out of existence, and List is part of the proof. So we need to make that cast legal. ... Just don't make the method const. (This is not C++.) I want to allow mutable lists and const lists, just not immutable lists. It seems to me const has a value even if it doesn't originate from immutable. Andrei
Re: Persistent list
On 11/14/2015 03:36 PM, Timon Gehr wrote: Right, because e.g. whether the elements are reference counted or traced should totally completely change the required container semantics for the problem at hand! This does not make any sense, unless you are saying that nobody should actually use the persistent containers, in which case it seems like a waste of time to concentrate efforts on them. I'm just as weary of persistent containers of mutable elements using GC. It doesn't make a difference. You have not provided a technical argument, so I am going to assume you have an irrational fear of bad PR. Forcing transitive immutable on people who want persistent container semantics is ultimately a very poor choice both from a technical and a PR perspective. The English language has a word I like a lot: "unassuming". I'm not sure about its etymology, but a nice theory is "a person who doesn't assume bad things about others". I'm glad to hear about various pros and cons regarding these containers. Slinging this kind of stuff is unlikely to further the dialog. Andrei
Re: Persistent list
On Saturday, 14 November 2015 at 16:27:17 UTC, Dicebot wrote: All trouble comes from trying to use physical immutable as logical one while still pretending it gives physical guarantees. Even if existing immutability is not widely applicable, I'd prefer to have narrow applicability over wide false confidence. Right now I know for sure that if I can use immutable data without any thread locking and it is not possible to screw it up. It is rarely important, but when it is, it is priceless. I can't say I'm following this discussion in great detail, but one thing strikes me. "const"-ness and "immutable"-ility are at some abstract level flavors of value stability. And that suggests to me that perhaps we should not be looking so much for backdoors as for new terms, leaving the old terms alone. Perhaps a given old keyword won't work well with RC; so be it. Perhaps a new keyword such as "stable" could be used to describe a storage category where the payload fields are unchanging but any metadata fields are potentially mutable. Then perhaps const could mean physically immutable, while stable means logically immutable. Or something like that.
Re: Persistent list
On 11/14/2015 12:10 AM, Andrei Alexandrescu wrote: ... * Lines 11-12: I came to terms with the notion that some types cannot be made immutable. We've been trying to do reference counting on immutable objects for a long time. It's time to acknowledge that true immutability (which the immutable keyword models) and reference counting don't mix. Const does work (more below). But overall I'm at peace with the notion that if you can't live without immutable, I'll refer you to the garbage collector. ... I.e. you think it is fine that there can be no list of lists. Anyway, the static assert does not actually do what you intend it to do. * Lines 26-29: The allocator is fundamentally a mutable part of the container. This is an insufficiency of our type system - we can't say "this object may be constant, but this reference is to a mutable part of it". We can't explain that necessity out of existence, and List is part of the proof. So we need to make that cast legal. ... Just don't make the method const. (This is not C++.)
Re: Persistent list
On 11/14/2015 05:05 PM, Andrei Alexandrescu wrote: Technically, that clearly works. There's a problem with scaling it up: COMPOSITION ... Composition matters. Disallowing immutable(RC!T) in favor of RC!(immutable T) effectively disables composition of larger immutable objects from smaller ones. One obvious thing to do is with a reference counted object it to make it a field of a larger object. That effectively makes that larger object impossible to be used with immutable, transitively. That's not a bad thing; it's merely a factual acknowledgment that in the D programming language, immutable models (transitively and in a way that makes composition possible) true immutability of bits, which makes sharing possible at no cost. Reference counting is mutating, therefore it does not and cannot work with immutability as defined by D. Obviously. But RC /does/ work with persistent containers! (Unless the author of the container has added a gratuitous compile-time check to make it impossible.)
Re: Persistent list
On 11/14/2015 04:45 PM, Andrei Alexandrescu wrote: On 11/13/2015 06:41 PM, Timon Gehr wrote: On 11/14/2015 12:10 AM, Andrei Alexandrescu wrote: * Lines 6: By construction the list doesn't work with mutable objects. =( I've decided persistent lists with mutable elements just too weird to endorse. Not /enforcing/ _transitive_ immutability is not the same as endorsing arbitrary mutation patterns as reasonable. Lisp allows them but every time it mentions that it very strongly advises against it. ... This is just not true. E.g. lazy thunks are considered fine. Other container semantics are better, I think, for mutable elements. Right, because e.g. whether the elements are reference counted or traced should totally completely change the required container semantics for the problem at hand! This does not make any sense, unless you are saying that nobody should actually use the persistent containers, in which case it seems like a waste of time to concentrate efforts on them. You have not provided a technical argument, so I am going to assume you have an irrational fear of bad PR. Forcing transitive immutable on people who want persistent container semantics is ultimately a very poor choice both from a technical and a PR perspective. Let's leave persistent lists have their nice value semantics. ... It does not make sense to conflate transitive immutability and value semantics, unless one considers it reasonable to make all struct fields transitively tail-immutable.
Re: RFC in Comparison between Rust, D and Go
On Saturday, 14 November 2015 at 16:19:13 UTC, Walter Bright wrote: On 11/14/2015 3:39 AM, Ola Fosheim Grøstad wrote: What I think is that for a language that is aligned with C semantics, you can with reasonable effort generate good quality C99 code. https://www.youtube.com/watch?v=YlVDGmjz7eM :-) https://www.youtube.com/watch?v=CfdFw3hXkf0
Re: Rust's simple download script
On Friday, 13 November 2015 at 21:30:35 UTC, Rory McGuire wrote: On Tue, Nov 10, 2015 at 6:56 PM, Steven Schveighoffer via Digitalmars-d < digitalmars-d@puremagic.com> wrote: To install a new compiler I just download the latest .tar.xz and place in /usr/local/dmd/; and then rename "dmd2" directory to version number. The same here... the most easy way. /P
Re: Here's looking at you, kid
On Saturday, 14 November 2015 at 17:03:21 UTC, Reg wrote: On Saturday, 14 November 2015 at 17:01:53 UTC, Loretta wrote: On Saturday, 14 November 2015 at 13:46:32 UTC, Russel Winder wrote: On Sat, 2015-11-14 at 10:47 +1000, Manu via Digitalmars-d wrote: [...] So write it, and do the pull request. It doesn't matter if it is any good or not, what matters is activity. All the waffling and wailing on the mailing list results in f### a##, only constructive activity changes things. Someone putting something forward will generate activity leading to something better. I agree. It's action that counts, not words, and we need action now. We could sit around here all day talking, passing resolutions, making clever speeches. It's not going to shift one Roman soldier! Sorry - I couldn't resist :-) https://www.youtube.com/watch?v=YawagQ6lLrA
Re: Here's looking at you, kid
On Saturday, 14 November 2015 at 13:46:32 UTC, Russel Winder wrote: On Sat, 2015-11-14 at 10:47 +1000, Manu via Digitalmars-d wrote: […] I'd love to read a revised edition of that page! :) So write it, and do the pull request. It doesn't matter if it is any good or not, what matters is activity. All the waffling and wailing on the mailing list results in f### a##, only constructive activity changes things. Someone putting something forward will generate activity leading to something better. I agree. It's action that counts, not words, and we need action now.
Re: Here's looking at you, kid
On Saturday, 14 November 2015 at 17:01:53 UTC, Loretta wrote: On Saturday, 14 November 2015 at 13:46:32 UTC, Russel Winder wrote: On Sat, 2015-11-14 at 10:47 +1000, Manu via Digitalmars-d wrote: […] I'd love to read a revised edition of that page! :) So write it, and do the pull request. It doesn't matter if it is any good or not, what matters is activity. All the waffling and wailing on the mailing list results in f### a##, only constructive activity changes things. Someone putting something forward will generate activity leading to something better. I agree. It's action that counts, not words, and we need action now. We could sit around here all day talking, passing resolutions, making clever speeches. It's not going to shift one Roman soldier!
Re: Here's looking at you, kid
On 11/14/2015 08:47 AM, Russel Winder via Digitalmars-d wrote: On Fri, 2015-11-13 at 19:40 -0800, Walter Bright via Digitalmars-d wrote: […] that would be most appreciated! Or you could do it based on your material, no? I take it there's a bit of sarcasm there, so probably it's worth trying a longer answer. There's been a recurring matter in our community with delegating work. Some work can be done by several of our talented contributors, whereas some other work can only be tackled by a few core contributors. Naturally, it stands to reason that Walter should be able to delegate non-Walter work and focus on Walter work. Same goes for me - I cannot delegate work such as the Foundation, conference travels, DConf sponsorship/strategy/PR, or writing articles; but I should be able to delegate things such as at least some of the work on reference counting, collections, fixing bugs found in the process, updating dconf.org, etc. We've had moderate success at delegating work but it's been highly unpredictable whether any specific request could go through. This can get quite frustrating; for example, it is well acknowledged by the community that Phobos should not create garbage gratuitously. Seeing that nobody is actually doing it, Walter did a bunch of work on that, but his initiative has not been followed. Recently I also pitched in with "Under 1000 opened bugs for Phobos" and suggested that a simple pass through by us all could thin the list considerably to the much fewer bugs that are truly difficult. The response was non-null (thank you) but much smaller than it could have been. This has been going on for a good while, and again my perception is there has been some progress. But by and large Walter has been hard at work on a mix of only-Walter and non-Walter problems, with the known negative effects on focus and effectiveness. So we agreed that Walter will focus on C++ exceptions and I'll save him of Foundation, refcounting, and DConf work. In light of him being focused on getting C++ exceptions going, I think it's entirely appropriate that he suggests others to write the documentation. Thanks, Andrei
Re: Persistent list
P.S. another problem with `RC!(immutable T)` is that it actually must be `shared(RC!(immutable T)` to be provide @safe API.
Re: Persistent list
I don't think immutable should be something casual and widespread in most designs at all. It is a very restrictive qualifier with an extremely narrow use case, trying to retro-fit it to be easy to use and compose tends to do more harm than actually going with mutable instead. All trouble comes from trying to use physical immutable as logical one while still pretending it gives physical guarantees. Even if existing immutability is not widely applicable, I'd prefer to have narrow applicability over wide false confidence. Right now I know for sure that if I can use immutable data without any thread locking and it is not possible to screw it up. It is rarely important, but when it is, it is priceless.
Re: RFC in Comparison between Rust, D and Go
On 11/14/2015 3:39 AM, Ola Fosheim Grøstad wrote: What I think is that for a language that is aligned with C semantics, you can with reasonable effort generate good quality C99 code. https://www.youtube.com/watch?v=YlVDGmjz7eM :-)
Re: RFC in Comparison between Rust, D and Go
On 11/14/2015 4:35 AM, cym13 wrote: Off-topic, but I'd like to know more about that. Did you by any chance ever wrote a blog post of some sort describing thoses issues? Sorry, it was a couple years ago, I don't recall the specifics.
Re: Persistent list
On 11/13/2015 07:28 PM, Jakob Ovrum wrote: On Friday, 13 November 2015 at 23:10:04 UTC, Andrei Alexandrescu wrote: * Lines 11-12: I came to terms with the notion that some types cannot be made immutable. We've been trying to do reference counting on immutable objects for a long time. It's time to acknowledge that true immutability (which the immutable keyword models) and reference counting don't mix. External reference counting should work fine with immutable, i.e. RefCounted!(immutable T). I've been asking this same question myself, vaguely, many times. Whenever I want to get work done using that mindset, I can't. Then I bring it up to Walter, and he asks again the same. Then I don't know how to explain it. Time to nip it in the bud once and for all. Clarify it forever so no need to bring it up again, ever. The general pattern goes like this: "So okay, understood, immutable doesn't work with reference counting. Then, clearly what we need is an object with an immutable part and a mutable part! Instead of immutable(RC!T), we use RC!(immutable T) throughout. It has a mutable reference count and an immutable Problem solved!" Technically, that clearly works. There's a problem with scaling it up: COMPOSITION Disallowing immutable(RC!T) in favor of RC!(immutable T) effectively disables composition of larger immutable objects from smaller ones. One obvious thing to do is with a reference counted object it to make it a field of a larger object. That effectively makes that larger object impossible to be used with immutable, transitively. That's not a bad thing; it's merely a factual acknowledgment that in the D programming language, immutable models (transitively and in a way that makes composition possible) true immutability of bits, which makes sharing possible at no cost. Reference counting is mutating, therefore it does not and cannot work with immutability as defined by D. So disabling immutable(RC!T) in favor of RC!(immutable T) is a fine way to approach things, but not a solution to the general problem of making general reference counted D objects mutable. That problem does not have a solution. Andrei
Re: Persistent list
On 11/13/2015 06:41 PM, Timon Gehr wrote: On 11/14/2015 12:10 AM, Andrei Alexandrescu wrote: * Lines 6: By construction the list doesn't work with mutable objects. =( I've decided persistent lists with mutable elements just too weird to endorse. Lisp allows them but every time it mentions that it very strongly advises against it. Other container semantics are better, I think, for mutable elements. Let's leave persistent lists have their nice value semantics. Andrei
Re: Persistent list
On 11/13/2015 06:26 PM, Ali Çehreli wrote: On 11/13/2015 03:10 PM, Andrei Alexandrescu wrote: > at http://dpaste.dzfl.pl/0981640c2835 > * Lines 11-12: I came to terms with the notion that some types cannot be > made immutable. Could constructor qualifiers help in such cases? I would like to hear war stories and experiences from others who used that feature before: The spec: http://dlang.org/struct.html#struct-constructor My rewording: http://ddili.org/ders/d.en/special_functions.html#ix_special_functions.constructor%20qualifier DIP53: http://wiki.dlang.org/DIP53 Ali Great writeup. Constructor qualifiers are part of the larger discussion about collections, but in this case it's a deeper matter. The code uses non-atomic ++ and -- for the refcount exactly because an immutable List cannot be constructed, so it's not shared among threads. Andrei
Re: Persistent list
On 11/13/2015 06:36 PM, Steven Schveighoffer wrote:
On 11/13/15 6:10 PM, Andrei Alexandrescu wrote:
I created a simple persistent list with reference counting and custom
allocation at http://dpaste.dzfl.pl/0981640c2835. It's a good
illustration of a number of issues. In particular, each cast must be
properly explained.
Here's my exegesis:
* Lines 141-152: I couldn't make tail() work with inout. Generally I'm
very unhappy about inout. I don't know how to use it. Everything I read
about it is extremely complicated compared to its power. I wish we
removed it from the language and replaced it with an understandable
idiom.
This seems to work for me:
inout(List) tail() inout
{
assert(root);
auto n = root.next;
incRef(n);
return inout(List)(n, allocator);
}
That doesn't work for me with my unittests, I get:
persistent_list.d(154): Error: None of the overloads of '__ctor' are
callable using a inout object, candidates are:
persistent_list.d(93):
persistent_list.List!(immutable(int)).List.this(const(Node*) n,
IAllocator a)
persistent_list.d(264): Error: template instance
persistent_list.List!(immutable(int)) error instantiating
154 is the last line in the function above.
Andrei
Re: Catching C++ std::exception in D
On Friday, 13 November 2015 at 18:40:06 UTC, Iain Buclaw wrote: There may be a few other holes between how Fibers and EH interact. https://github.com/D-Programming-Language/druntime/commit/f6633abb43ea1f2464d3a772b8f8fe78216ffd8e The SJLJ stack switching should probably be added to this mechanism. — David
Re: Reviewing syntax highlight support in cgdb
On Saturday, 14 November 2015 at 11:39:12 UTC, Brian Schott wrote: On Saturday, 14 November 2015 at 10:44:53 UTC, Iain Buclaw wrote: Hi, I'm currently making changes to cgdb, and would like to have someone give a quick view over the lexer rules. https://github.com/cgdb/cgdb/blob/master/lib/tokenizer/dlexer.l Having a skim over myself, I see @nogc needs adding, and probably c_long, cpp_long and other ABI compatibility types that the compiler recognises. Anything else missing? Could be any feature, not just keywords. Iain. I'm guessing the best way to test this would be to check out and build your fork? The downloading the latest release should be enough, you should have it available on whatever flavour of Linux you prefer. Shouldn't need to checkout the fork unless you want to help out with testing or want to build a testsuite for support. I haven't began to make any changes yet. And actually am looking at how much work it would be to switch the backend driver over from the old annotate interface to gdb/mi.
Re: DIP85: Lazy Initialization of const Members
On Saturday, 14 November 2015 at 14:30:33 UTC, Marc Schütz wrote: http://wiki.dlang.org/DIP85 This DIP proposes an officially sanctioned way to initialize const members (or mutable members of const structs) lazily by allowing limited mutation of const objects. Destroy! I'm just right now reading Andrei's post on persistent lists, and I realize it can be even more useful if it supports immutable objects. I made some modifications to allow that.
Will std.allocator make it easy to bypass the GC?
http://dlang.org/phobos/std_experimental_allocator.html I am not sure what the plan is but it seems to me that the standard library could make use of the "theAllocator" for allocation and also allow you to swap in different allocators. So could it then be possible to completely bypass the GC once "allocators" are used by the std? I imagine that we could set "theAllocator = Malloc" and every allocation will use malloc? Or maybe some function allocates by default but you know that the allocation is small enough to be allocated on the stack which would allow us to call the function like this "someFunction!(StackAlloactor)(foo);" ?
Re: Catching C++ std::exception in D
Dan Olson writes: > Johannes Pfau writes: > >> Am Thu, 12 Nov 2015 09:59:14 -0800 >> schrieb Dan Olson : >> >>> Johannes Pfau writes: >>> > To expand on this: I think we'd prefer one __d_personality_v0 which >>> > is implemented in upstream druntime and identical for all >>> > compilers. >>> >>> Speacking of upstream support. GDC support SjLj exceptions. In >>> 2.067, it became obvious that Fiber needed separate SjLj context >>> stacks which are normally thread specific. I have a change in my iOS >>> LDC fork which I suppose could go to upstream thread.d file so GDC >>> can pick it up to. >>> >>> https://github.com/smolt/druntime/commit/5d32e9e68cc6bd8b13cacfdb18a4d91374bf6b3e >>> >>> See, I even included GNU_SjLj_Exceptions :-) >>> >>> Sound like a good idea? It is getting queued up soon as a PR to LDC >>> once we get an iOS version officially in the compiler frontend. >> >> Nice work. We certainly want that in GDC or even better in upstream. >> I guess we don't have a unittest yet which can detect this problem. Is >> it possible to add a unittest for this? > > I had 2.067 unittest failures without this change, I don't recall which. > I know it made me laugh becase exceptions were being thrown from Fiber A > but being caught by Fiber B. I can easily find out what fails by > rerunning without the change. I'll report back later. I removed my SjLj change in core.thread to see what fails. Running 2.067 unittests, std.concurrency fails with a memory access error. Latest core.thread has a unittest for "Test exception chaining when switching contexts in finally blocks" that also fails with a memory access error.
DIP85: Lazy Initialization of const Members
http://wiki.dlang.org/DIP85 This DIP proposes an officially sanctioned way to initialize const members (or mutable members of const structs) lazily by allowing limited mutation of const objects. Destroy!
Re: Here's looking at you, kid
On Fri, 2015-11-13 at 19:40 -0800, Walter Bright via Digitalmars-d wrote: > […] > > that would be most appreciated! Or you could do it based on your material, no? -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Here's looking at you, kid
On Sat, 2015-11-14 at 10:47 +1000, Manu via Digitalmars-d wrote: > […] > I'd love to read a revised edition of that page! :) So write it, and do the pull request. It doesn't matter if it is any good or not, what matters is activity. All the waffling and wailing on the mailing list results in f### a##, only constructive activity changes things. Someone putting something forward will generate activity leading to something better. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Doc page with a list of the DMD compiler limits
This is a classic topic in .learn when someone tries to declare a static array over 10 MB. Are there other limits ? Are they worth a new documentation page ? For example, FPC has http://www.freepascal.org/docs-html/3.0.0/prog/progap3.html
Re: DMD is faster than LDC and GDC
On Saturday, 14 November 2015 at 00:37:51 UTC, Manu wrote: In the meantime, there probably needs to be strong warnings about violating attributes, and if patterns have emerged that rely on violating such attributes, we should publish a recommended alternative. One pattern that comes to mind immediately is lazily initialized members in a const object. Another one that's already officially supported is impure debug statements in pure functions.
Re: RFC in Comparison between Rust, D and Go
On Saturday, 14 November 2015 at 11:30:04 UTC, Walter Bright wrote: Guess what happened when I found out that people were relying on bugs in gcc's preprocessor, not to mention all of its non-standard behavior. Off-topic, but I'd like to know more about that. Did you by any chance ever wrote a blog post of some sort describing thoses issues?
Re: Reviewing syntax highlight support in cgdb
On Saturday, 14 November 2015 at 10:44:53 UTC, Iain Buclaw wrote: Hi, I'm currently making changes to cgdb, and would like to have someone give a quick view over the lexer rules. https://github.com/cgdb/cgdb/blob/master/lib/tokenizer/dlexer.l Having a skim over myself, I see @nogc needs adding, and probably c_long, cpp_long and other ABI compatibility types that the compiler recognises. Anything else missing? Could be any feature, not just keywords. Iain. I'm guessing the best way to test this would be to check out and build your fork?
Re: RFC in Comparison between Rust, D and Go
On 11/11/2015 4:19 AM, Walter Bright wrote: I've looked into generating C code as an output format. I found the problems to be endemic and working around them was harder than just generating native code: 1. You're at the mercy of bugs in the C compiler you cannot fix. 2. C leaves quite a lot as "implementation defined", causing endless compatibility issues with various C compilers. 3. C's integral promotion rules. 4. Generating exception handling code for C is miserable and inefficient. 5. Your compiler is going to be slower than C. 6. You'll suffer from endless bug reports caused by a mismatch between your compiler and the user's C compiler, whatever that might be. 7. You cannot generate symbolic debug info in a format that looks like your language's definitions. 8. C's symbols will differ from your program's symbols, again making use of a debugger about like debugging code with an asm debugger, only much worse. 9. The generated C code will look awful. 10. The order of evaluation of C code expressions is implementation defined. 11. Installation problems, again, because you don't control the user's C compiler. 12. If your language supports a basic type that isn't supported by C, tough noogies (think SIMD types). 13. C has no concept of immutability or purity, so no hope of getting the C optimizer to take advantage of that. ... and on ... I forgot to add: 14. Many C compilers do not emit COMDATs, which cripples flexibility in emitting code. 15. C doesn't give access to special features in the object file, which you may need, such as weak externs, special sections, etc.
Re: RFC in Comparison between Rust, D and Go
On Saturday, 14 November 2015 at 11:30:04 UTC, Walter Bright wrote: Like I said, you think the points I raised are all non-issues. Please don't make assumptions about what I think. What I think is that for a language that is aligned with C semantics, you can with reasonable effort generate good quality C99 code. I just have to laugh. You even admit that Microsoft C doesn't implement C99. That's true. Microsoft has decided that C++ is sufficient. What that means is that you need to target C99 and modern C++. I'm sorry, but Modern C does not provide exact representations for 10 bit bytes unless the underlying hardware supports 10 bit bytes. And the 10 bit byte Modern C compilers do not provide representations for 8 bit bytes. That is true, but that is a very unlikely target today, and neither D or Rust support this configuration AFAIK. Even 24 bit integers are rare, though they exists in some DSP CPUs.
Re: RFC in Comparison between Rust, D and Go
On 11/14/2015 1:58 AM, Ola Fosheim Grøstad wrote: [...] Like I said, you think the points I raised are all non-issues. You'll change your mind once you try to implement one, and then try to support it with a diverse group of customers. > C99 defines [...] I just have to laugh. You even admit that Microsoft C doesn't implement C99. What do you think is going to happen when you file a bug report? Do you really believe that all the other C compilers out there are C99 compliant? Or even C89 compliant? Remember the Warp C preprocessor I wrote a couple years ago? https://github.com/facebookarchive/warp Guess what happened when I found out that people were relying on bugs in gcc's preprocessor, not to mention all of its non-standard behavior. > Modern C has headers with exact bit representations though. I'm sorry, but Modern C does not provide exact representations for 10 bit bytes unless the underlying hardware supports 10 bit bytes. And the 10 bit byte Modern C compilers do not provide representations for 8 bit bytes. -- Your posts on this subject remind me of when I learned how to do data flow analysis from Ullman and Hennessy. The algorithms looked great, and were provably correct. I implemented them. They did not work - because real CPUs and languages did not behave according to Ullman's mathematical models. Getting things to work right required considerably more effort. The Dragon Book was not terribly concerned with the dirty details of how things really work. There's a huge difference between reading an academic paper about something and getting it to work in the field, one you discount completely.
Reviewing syntax highlight support in cgdb
Hi, I'm currently making changes to cgdb, and would like to have someone give a quick view over the lexer rules. https://github.com/cgdb/cgdb/blob/master/lib/tokenizer/dlexer.l Having a skim over myself, I see @nogc needs adding, and probably c_long, cpp_long and other ABI compatibility types that the compiler recognises. Anything else missing? Could be any feature, not just keywords. Iain.
Re: RFC in Comparison between Rust, D and Go
On Saturday, 14 November 2015 at 09:58:19 UTC, Ola Fosheim Grøstad wrote: http://www.mercurylang.org/backends.html Btw, didn't Ali convert his book on D using princeXML? princeXML is written in Mercury: https://en.wikipedia.org/wiki/Prince_(software)
Re: RFC in Comparison between Rust, D and Go
On Saturday, 14 November 2015 at 08:28:08 UTC, Walter Bright wrote: If your new language doesn't have the C preprocessor in it, then you must set it aside. If it does have a C preprocessor in it, then it really isn't a new language at all, it's just a C permutation. But you can do code gen with standard macro invocations present, without the compiler having the actual macro definitions (just a representation of the semantics for the standard headers). That's all very fine until the that C compiler evaluates expressions in a different way than the one you debugged it with, and your language fails on your customer's machine with your customer's C compiler, and fails in weird ways. IIRC C99 defines sequencing points. Granted Microsoft does not support C99, but I'd say C99 is the standard to aim for these days. BTW, although C compilers exist for all kinds of weird machines, the weirder the machine is, the worse (i.e. more limited and buggier) the C compiler is for it (as a general rule). Sure enough, there are weird C compilers for DSP chips that have 32 bit integers with 24 bit ALU operations over it. But changing the backend to emit different C for weird targets is less work than changing a full backend... Good luck porting your language to a C compiler that has 10 bit bytes in it, or one with 32 bit bytes. Yes, those compilers exist. Yes, those are C standard conforming variations. Nope, none of your "portable" C code will work on it. Modern C has headers with exact bit representations though. It always is once your project exceeds trivial size. Remember, my experience is a factor of 4x slower. And you cannot fix it. Is the fastest non-optimizing C compiler is 4x slower than D? Compiling to C is actually a very nice thing to have, it keeps languages alive and limits lockin. Thanks to that we have access to classic languages like Simula or interesting niche languages like Mercury on a wide range of platforms. And you can make it work (with a little effort) even if the compiler is old. http://folk.uio.no/simula67/cim.shtml http://www.mercurylang.org/backends.html I could probably make these languages run as asm.js. Having a C generating backend is an enabler.
Re: Persistent list
On 14-Nov-2015 02:10, Andrei Alexandrescu wrote:
I created a simple persistent list with reference counting and custom
allocation at http://dpaste.dzfl.pl/0981640c2835. It's a good
illustration of a number of issues. In particular, each cast must be
properly explained.
Here's my exegesis:
[snip]
* Lines 11-12: I came to terms with the notion that some types cannot be
made immutable. We've been trying to do reference counting on immutable
objects for a long time. It's time to acknowledge that true immutability
(which the immutable keyword models) and reference counting don't mix.
Const does work (more below). But overall I'm at peace with the notion
that if you can't live without immutable, I'll refer you to the garbage
collector.
* Lines 26-29: The allocator is fundamentally a mutable part of the
container. This is an insufficiency of our type system - we can't say
"this object may be constant, but this reference is to a mutable part of
it". We can't explain that necessity out of existence, and List is part
of the proof. So we need to make that cast legal.
Just don't make it const (see your point at 11-12). I have a feeling
that ref-count and allocator are in the same mold - fields that must mutate.
So I imagine const/immutable for complex types will only work like this:
struct Layout{
immutable Core core; //all constness ends here
// accounting fields
uint refCount;
UAllocator alloc;
// ... any tracing and/or stats fit this definition
}
I totally do not understand the whole knee-jerk reaction of "everything
must be const because it looks good in my code" and bug reports a-la:
const obj = SomeComplexTypeFromStd(); // doesn't compile!
Well some types can't be transitively const (w/o sacrificing
functionality/performance). Low-level immutable is a tool to create
high-level immutable constructs IMHO.
It might make sense to re-purpose final storage class to be write-once
a-la Java, because this is what folks expect when writing
`immutable/const x = ...;` everywhere possible.
* Lines 141-152: I couldn't make tail() work with inout. Generally I'm
very unhappy about inout. I don't know how to use it. Everything I read
about it is extremely complicated compared to its power. I wish we
removed it from the language and replaced it with an understandable idiom.
I can't agree more. Every time dealing with inout when I finally think I
grok how it works the next instant I see that it doesn't do what I expect.
For me inout inevitably stops at the boundary of being unnable to have
List!(inout(T)) and the like.
--
Dmitry Olshansky
Re: RFC in Comparison between Rust, D and Go
On 11/14/2015 12:06 AM, Ola Fosheim Grøstad wrote: I'm not sure if it reasonable to set aside the preprocessor, If your new language doesn't have the C preprocessor in it, then you must set it aside. If it does have a C preprocessor in it, then it really isn't a new language at all, it's just a C permutation. but it depends on what you mean by interop: 1. portability - A language like Nim obviously has a better portability future since that is the one of the primary goal of having portable C source code. That's all very fine until the that C compiler evaluates expressions in a different way than the one you debugged it with, and your language fails on your customer's machine with your customer's C compiler, and fails in weird ways. You can't just dismiss the points I made and say "It's C, so it's portable." It isn't. If you're anxious to learn the hard way, feel free :-) It's one thing to read the C standard and pontificate about it, it's quite another to actually be in the trenches and deal with it. BTW, although C compilers exist for all kinds of weird machines, the weirder the machine is, the worse (i.e. more limited and buggier) the C compiler is for it (as a general rule). Good luck porting your language to a C compiler that has 10 bit bytes in it, or one with 32 bit bytes. Yes, those compilers exist. Yes, those are C standard conforming variations. Nope, none of your "portable" C code will work on it. Compile time does not have to be a big issue, It always is once your project exceeds trivial size. Remember, my experience is a factor of 4x slower. And you cannot fix it.
Re: RFC in Comparison between Rust, D and Go
On Saturday, 14 November 2015 at 06:16:15 UTC, Walter Bright wrote: True, but that doesn't support your assertion that transpiling to C produces better C interop. Setting aside compatibility with the C preprocessor, I've asked for a single instance where a language that transpiles to C has better C interop than D does. I'm not sure if it reasonable to set aside the preprocessor, but it depends on what you mean by interop: 1. portability - A language like Nim obviously has a better portability future since that is the one of the primary goal of having portable C source code. 2. ability to use language X as a C library - Plenty of tools (specialised languages, like generators for parsers etc) do very well in this department, fully supporting ability to inline the code across compilers. - D does ok, for the platforms it integrates with, but you have to generate the header files. 3. ability to use C libraries and engines from language X - D does ok here if the C header files are suitable for translation Compile time does not have to be a big issue, if you have a good build system and changes are kept locally in the generated C files (smart partitioning of the code into C files). Language semantics efficiency is really the primary reason for not targeting C, imho.
