Re: GCs in the news
On Sunday, 20 July 2014 at 12:07:47 UTC, Kagamin wrote: On Sunday, 20 July 2014 at 11:44:56 UTC, Mike wrote: Being able to specify an alternate memory manager at compile-time, link-time and/or runtime would be most advantageous, and probably put an end to the GC-phobia. AFAIK, GC is not directly referenced in druntime, so you already should be able to link with different GC implementation. If you provide all symbols requested by the code, the linker won't link default GC module. Yes, I believe you are correct. I also believe there is even a GCStub in the runtime that uses malloc without free. What's missing is API documentation and examples that makes such features accessible. Also missing, are language/runtime hooks that could allow users to try alternative memory management schemes such as ARC and find what works best for them through experimentation. In short, IMO, D should not embrace one type of automatic memory management, they should make it extensible. In time two ore three high quality memory managers will prevail. Mike
Re: Software Assurance Reference Dataset
Walter Bright: I doubt they'll want to use an @tailrec attribute. In Scala there is "@tailrec": http://www.scala-lang.org/api/current/scala/annotation/tailrec.html In both F# and OcaML there is the "rec" keyword: http://msdn.microsoft.com/en-us/library/dd233232.aspx http://caml.inria.fr/pub/docs/manual-ocaml-400/manual003.html#toc4 In Clojure there is "recur" (that is not an annotation): http://clojure.org/special_forms?responseToken=08ea4841337f67bb8f07663aa70b03aca#recur I think functional programmers are willing to use @tailrec attribute if it's well designed and it does what's written on its tin. What about the @continuation (http://en.wikipedia.org/wiki/Continuation-passing_style )? I doubt they'll want to use that attribute, either. I don't know. It's more general than the @tailrec, but probably many C and C++ and Java programmers don't even know what it is. But it allows a programming style that in some case is interesting (far cleaner than computed gotos). In any case, D supports more styles of programming than any other language I can think of. I doubt adding even more will be that helpful. I think a basic form of pattern matching implemented with the switch construct is a good idea for D. Bye, bearophile
Re: GCs in the news
On Sunday, 20 July 2014 at 11:44:56 UTC, Mike wrote: Being able to specify an alternate memory manager at compile-time, link-time and/or runtime would be most advantageous, and probably put an end to the GC-phobia. AFAIK, GC is not directly referenced in druntime, so you already should be able to link with different GC implementation. If you provide all symbols requested by the code, the linker won't link default GC module.
Re: function default arguments depending on other arguments
Tove:
IIRC:
Walter's stance was that he needs compelling examples, which
proves the utility of this new feature.
Recently I have had a desire for that feature, to write a
function like this:
int[][] generateTable(in uint nx, in uint ny=nx) {...}
If you give just one argument to this function, it generates a
square table, otherwise it uses both the given sizes.
Bye,
bearophile
Re: GCs in the news
On Sunday, 20 July 2014 at 08:41:16 UTC, Iain Buclaw via Digitalmars-d wrote: On 17 Jul 2014 13:40, "w0rp via Digitalmars-d" The key to making D's GC acceptable lies in two factors I believe. 1. Improve the implementation enough so that you will only be impacted by GC in extermely low memory or real time environments. 2. Defer allocation more and more by using ranges and algorithms more, and trust that compiler optimisations will make these fast. How about 1. Make it easier to select which GC you want to use at runtime init. 2. Write an alternate GC aimed at different application uses (ie: real-time) Yes, Please! Being able to specify an alternate memory manager at compile-time, link-time and/or runtime would be most advantageous, and probably put an end to the GC-phobia. DIP46 [1] also proposes and interesting alternative to the GC by creating regions at runtime. And given the passion surrounding the GC in this community, if runtime hooks and/or a suitable API for custom memory managers were created and documented, it would invite participation and an informal, highly competitive contest for the best GC would likely ensue. Mike [1] http://wiki.dlang.org/DIP46
Re: Integer overflow and underflow semantics?
"Marc Schütz" wrote:
> On Saturday, 19 July 2014 at 19:49:24 UTC, Ola Fosheim Grøstad wrote:
>> On Saturday, 19 July 2014 at 08:34:39 UTC, Kagamin wrote:
>>> Can't it simply generate code as is? Seems wasteful to spend >> compilation
>>> time on this.
>>
>> Not if you want fast code, consider a template with:
>>
>> if (a.length+M < b.length+N) {}
>>
>> then you alias b = a in the template instantiation:
>>
>> if(a.length+M < a.length+N){}
>>
>> you want this reduced to:
>>
>> if (M> }
>>
>> which can be resolved at compile time.
>
> Yes, but that is the optimizer's job. The front-end doesn't need to spend
> time on it, if the back-end then anyway does the same optimization again.
I don't think anyone has said that the frontend does that.
But the language semantics forbid such optimizations if overflow is defined
as wrapping.
If the optimizer respects that is a different chapter, as the experiment
with GDC shows.
Tobi
Re: Software Assurance Reference Dataset
20-Jul-2014 10:45, Walter Bright пишет: On 7/19/2014 11:06 PM, bearophile wrote: A @tailrec annotation seems good, and will improve the functional usages of D. It should stop compilation with a error if the function doesn't call itself or if the compiler is not able to remove the recursive call. This means it has to be fully enforced. If you want to guarantee replacement of a recursive call with a loop, just write a loop. Functional programming is full of simple recursion and it would be nice not to stack overflow in debug builds. Another use case is so-called threaded code interpreter, that can be done with either computed gotos (and bunch of labels) or forced tail calls (and bunch of functions). In both cases computed jump or tail call is indirect. -- Dmitry Olshansky
Re: Naming of new lazy versions of existing Phobos functions
On Saturday, 19 July 2014 at 00:05:55 UTC, Brad Anderson wrote: To summarize what I think are the best ideas so far: std.string -- EagerLazy - capitalize capitalized center centered detabdetabbed entabentabbed format formatted leftJustify leftJustified munchmunched outdent outdented removechars charsRemoved rightJustify rightJustified splitLines (none, uses splitter) squeeze squeezed stripstripped stripLeftleftStripped stripRight rightStripped succ successor toLower lowercased toStringznullTerminated toUpper uppercased translatetranslated wrap wrapped std.path EagerLazy - absolutePath absolutePathOf * buildNormalizedPath asNormalizedPath * buildPathasPath * defaultExtension withDefaultExtension * dirName dirNameOf * driveNamedriveNameOf * expandTilde tildeExpanded relativePath relativePathOf * setExtension withExtension stripDrive driveStripped stripExtension extensionStripped * - not terribly happy with these but I'd say it's the best of what's been proposed Generally it seems like past tense works when the function has a verb, "with" prefix when there is no verb but you are modifying something about the input, and "Of" suffix when you are pulling something out. Also, the verb should come last because it has a better ring to it. Do we really want to be naming functions which aren't properties with adjectives instead of verbs? That seems very wrong to me. I'd much rather see stuff like setExt or setExtLazy than withExtension or extensionSet. Function names are supposed to be verbs unless they're emulating variables. They _do_ something, even if it's lazy. - Jonathan M Davis
GC on Unreal Engine
Since this theme keeps being discussed. Here is some info how Unreal Engine makes use of GC in C++. https://wiki.unrealengine.com/Garbage_Collection_Overview -- Paulo
Re: Copying parameter lists verbatim
On Saturday, 19 July 2014 at 17:40:01 UTC, Andrei Alexandrescu wrote: On 7/19/14, 9:36 AM, Jakob Ovrum wrote: On Saturday, 19 July 2014 at 06:13:10 UTC, Manu via Digitalmars-d wrote: Anyway, does anybody know a nice tidy way to do it? Unfortunately the only way to create perfect forwarding functions completely generically is still using an ugly string mixin that generates the forwarding function. A subset of forwarding functions can be created using templates and auto-ref, but of course a function template has many disadvantages to a concrete function (virtual functions being a good example). How can this be encapsulated as a library artifact? -- Andrei Since the key parts of the forwarding function - the parameter list and attribute list - are part of the signature, the entire function declaration has to be mixed in. That means the function body has to be provided as a string argument. This tends to cause some seriously unreadable code. It may be a lost cause but I'm hoping we can amend the language to avoid that.
Re: Integer overflow and underflow semantics?
On Saturday, 19 July 2014 at 19:49:24 UTC, Ola Fosheim Grøstad
wrote:
On Saturday, 19 July 2014 at 08:34:39 UTC, Kagamin wrote:
Can't it simply generate code as is? Seems wasteful to spend
compilation time on this.
Not if you want fast code, consider a template with:
if (a.length+M < b.length+N) {}
then you alias b = a in the template instantiation:
if(a.length+M < a.length+N){}
you want this reduced to:
if (M
Yes, but that is the optimizer's job. The front-end doesn't need
to spend time on it, if the back-end then anyway does the same
optimization again.
Re: function default arguments depending on other arguments
On Friday, 18 July 2014 at 17:40:23 UTC, Timon Gehr wrote:
On 07/18/2014 12:00 AM, Trass3r wrote:
void foo(int a, int b = a)
{
}
is illegal in C++ because order of evaluation is undefined.
But since D defines the order to be left to right couldn't it
also allow
this?
It could, and I think it is an unnecessary limitation that it
currently does not. (This can also be useful if that parameter
is the hidden 'this' reference.)
This request keeps popping up, I've seen it at least 3 times
before and there's even an enhancement request for it:
https://issues.dlang.org/show_bug.cgi?id=8075
IIRC:
Walter's stance was that he needs compelling examples, which
proves the utility of this new feature.
[Dangerously OT] Re: D logo copyright
On 19/07/2014 8:43 PM, "Ola Fosheim Grøstad" " wrote: Not sure why you want a citation. Fair use differs from country to country. Mona Lisa is in the public domain, but photos of it that has been "enhanced" are not. Many novels and poems are in the public domain, but a book that contains a collection of novels is not, i.e. the selection of novels or poems constitutes a work protected by copyright. I perhaps wasn't specific enough about what you had written that was contrary to what I had read, specifically it was this... > The copyright will be held by BOTH the original author and the author > of the derivative work Fair use, public domain and collective works legislation have nothing to do with the case in hand. I have found no cases where a derived work has copyright shared with the owner of the original. In the UK, US and France at least the protection follows the guidance of the Berne Convention whereby the derived work is the parts added to the original and its copyright belongs entirely to the deriving artist. By virtue of the fact that permission for the derivative to be made was granted by the original artist, the derived work can freely incorporate original but there is no sharing of copyright. The caveat to this is that the additions of the derived work have to be substantial and copyrightable on their own. Many open licenses give permission to make derivatives with restrictions which may require attribution, transitive licensing or non-commercial use, but those are the terms of the license and are separate from the protection of copyright law. As has been mentioned, the Berne convention is the minimum requirement of the signed up nations and it is entirely possible that some countries offer greater protection than others. I have not been able to discover if Germany is one of those countries or not. As interesting as I found this investigation, it has turned out to be a dead end anyway. Almost entirely because of the definition of what a counts as a derivative work. A...
Re: GCs in the news
On 17 Jul 2014 13:40, "w0rp via Digitalmars-d" wrote: > > The key to making D's GC acceptable lies in two factors I believe. > > 1. Improve the implementation enough so that you will only be impacted by GC in extermely low memory or real time environments. > 2. Defer allocation more and more by using ranges and algorithms more, and trust that compiler optimisations will make these fast. > How about 1. Make it easier to select which GC you want to use at runtime init. 2. Write an alternate GC aimed at different application uses (ie: real-time) We already have (at least) three GC implementations for D. Regards Iain
Re: Why are the nogc crowed labeled as alarmists?!?!
On Thursday, 17 July 2014 at 18:57:51 UTC, Andrei Alexandrescu wrote: To paraphrase a common phrase used among Facebook engineers: "Nothing in D is someone else's problem." That would make a good motto. - Jonathan M Davis
Re: GCs in the news
On Saturday, 19 July 2014 at 21:12:44 UTC, Walter Bright wrote: 3. slices become mostly unworkable, and slices are a fantastic way to speed up a program They are even more fantastic for speeding up programming. I think that programmer time isn't included often enough in discussions. I have a program which I used D to quickly prototype and form my baseline implementation. After getting a semi-refined implementation I converted the performance critical part to C++. The D code that survived the rewrite uses slices + ranges, and it's not worth converting that to C++ code (it would be less elegant and isn't worth the time.) The bottom line is that without D's slices, I might not have bothered bringing that small project to the level of completion it has today.
Re: Software Assurance Reference Dataset
On 7/19/2014 11:55 PM, bearophile wrote: Walter Bright: If you want to guarantee replacement of a recursive call with a loop, just write a loop. There are cases where a recursive algorithm is nicer. And people that want to use D functionally, may also be used to writing code recursively. I doubt they'll want to use an @tailrec attribute. What about the @continuation (http://en.wikipedia.org/wiki/Continuation-passing_style )? I doubt they'll want to use that attribute, either. In any case, D supports more styles of programming than any other language I can think of. I doubt adding even more will be that helpful.
Re: Software Assurance Reference Dataset
Walter Bright: If you want to guarantee replacement of a recursive call with a loop, just write a loop. There are cases where a recursive algorithm is nicer. And people that want to use D functionally, may also be used to writing code recursively. What about the @continuation (http://en.wikipedia.org/wiki/Continuation-passing_style )? Bye, bearophile
