Re: On garbage collection
deadalnix wrote: http://www.infoq.com/presentations/Understanding-Java-Garbage-Collection This is java focussed, but I think this is still very interesting for D people. So I'm sharing it here. The first half wasn't even java focussed at all :-) Great intro to most of the definitions and GC algorithms in use today.
Re: Haxe (From: Java > Scala -> new thread: GUI for D)
Nick Sabalausky wrote: So anyway, with my own Haxe implementation, I can just add an optional "-sane" switch to enable either a runtime or compile-time check...And nobody can stop me!! Mwuuahahahaha!! AH HA HA HA!!! BWAH HA HA HA!@!!! HAHhahahaAHHAAHA - As a long time haXe user I appreciate this! :D But, have you looked at the new haXe macro output feature?: http://haxe.org/api/haxe/macro/jsgenapi You could write a D generator macro which acts as a JS target. Probably alot less work too. I find it unfortunate D -> haXe is so complex, as I'd much rather write my code in D. If only D was as multiplatform as haXe... :-(
Re: [contest] Is a Cow an animal ++
Op Wed, 29 Sep 2010 15:33:29 +0200 schreef retard : Wed, 29 Sep 2010 09:21:11 +0200, Norbert Nemec wrote: I experimented with this (a colleague of mine already solved all 11 cases at compile time with Scala) Would your colleague share the Scala solution? :-)
Re: DMD source overview?
Op Tue, 14 Sep 2010 21:33:37 +0200 schreef Nick Sabalausky : But you do raise a good point. What's the current state of ddmd's front-end? What I have in mind is to just rip out dmd's current backend stuff entirely, maybe even including the toObjFile and toIR methods, or at least big chunks of them, and replace it all with a PHP-generator. (Yea...I'm fairly determined to be able to do as much of my web dev as possible in D.) What?! No haxe output? I would love D -> Haxe...
Re: enforce()?
Op Mon, 28 Jun 2010 10:33:24 +0200 schreef Norbert Nemec : Conceptually, the ultimate solution would certainly be to place code for input contract checking in the *calling* code. After all, this checking code serves to debug the calling code, so it should be left to the caller to decide whether checking is necessary. I like this idea. This approach would also allow the compiler to optimize out some checks when their correctness can be tested at compile time. Output contract checks, on the other hand should be compiled inside the returning routine. After all, it is all a matter of trust. A language designer should trust the language user to know what he is doing. A library designer should trust the library user to act responsibly. After all - if the application breaks it is the application designer who has to answer for it. Alot. :-)
Re: This just in: authorless TDPL becomes collector's edition
I got two collectors editions. I'll sell one for 1000$ :-D On Tue, 22 Jun 2010 13:10:00 +0200, Tyro[a.c.edwards] wrote: good for you, sucks for me though, I didn't get a collector's edition and I ordered my copy back in over six months ago.
Re: D Language 2.0
On Wed, 20 Jan 2010 14:18:52 +0100, Leandro Lucarella wrote: Again? RC is *not* -nogc, is -anothergc. And reference counting won't do the trick unless you add a backing GC to free cycles. What I mean about -nogc is *no* GC, is "please, mr compiler, give me an error when a GC facility is used". I guess a custom object.d which static asserts as soon as a GC facility is used would do that trick?
Re: @disable
On Fri, 15 Jan 2010 07:54:56 +0100, Andrei Alexandrescu wrote: At least we copy with attribution :o). Andrei @lol And yes, it was out loud. :D
Re: Should pure nothrow ---> @pure @nothrow ?
Op Fri, 27 Nov 2009 11:58:59 +0100 schreef Don :
void foo()
@naked body
{
LOL! Spam filters would love that!!
I can already imagine the jokes spreading over the internets:
@safe public double penetration(of a) @naked body { ... }
Re: The Thermopylae excerpt of TDPL available online
Op Fri, 30 Oct 2009 11:44:08 +0100 schreef bearophile
:
Simpler alternative, the dot isn't necessary:
traits_compiles(XXX)
traits_typeid(TTT)
traits_stringof(T)
traits_allmembers(T)
traits_error("message");
Not nice. Bad.
Re: Semicolons: mostly unnecessary?
Op Thu, 22 Oct 2009 07:44:44 +0200 schreef AJ : Also, referring to your second struct example above, D never has semicolons directly after a closing curly-brace. Isn't that ironic! Kinda far fetched to call that ironic. The struct decleration was already ended by '}'. I don't end my sentences with ;. either.
Re: Type unions in D
Op Thu, 17 Sep 2009 16:56:41 +0200 schreef Andrei Alexandrescu
:
I have big plans with Variant - I want to make it (or a related type)
the variable type common in dynamic languages, with flexibility, dynamic
invocation using common syntax, the works. So if you write a short
script and want dynamic typing, you should be able to use Variant
throughout.
Including some sort of object literal syntax?
You know, like javascript
var obj = {i_am:"Dynamic", ...};
Re: [OT] Haxe "if" context-sensitive? (Q for Grammar Experts)
Nick are you on freenode.org #haxe ? :-)
Re: Nullable or Optional? Or something else?
Op Wed, 02 Sep 2009 22:55:53 +0200 schreef Andrei Alexandrescu : So if pointers wouldn't be considered evil, Maybe!T* would suffice? Can someone point me out what the big difference is between ref and simply disallowing pointer arithmitic? Is it marketing? Ref means lvalue of type T. Pointer is a type distinct from T. So although NullableRef!T is substitutable for an lvalue of type T, Nullable!(T*) is not. Andrei Thanks. I googled first but couldn't find some explicit documentation about 'ref' just it being mentioned here and there :-) Are there any problems with something like: Nullable!(ref T) ?
Re: Nullable or Optional? Or something else?
Op Wed, 02 Sep 2009 22:20:04 +0200 schreef Andrei Alexandrescu : Jarrett Billingsley wrote: On Wed, Sep 2, 2009 at 4:13 PM, Simen Kjaeraas wrote: Danny Wilson wrote: Op Wed, 02 Sep 2009 21:39:28 +0200 schreef Andrei Alexandrescu : I plan to add a Nullable struct to Phobos (akin to C#'s Nullable, Boost's Optional). Apparently a good design is to define Optional!T with a minimum of member functions (ideally none) and have it use the "alias this" feature to masquerade as a T. That way Optional!T looks and feels much like a T, except that it supports a function bool isNull(T)(Optional!T value); Am I on the right track? If so, what is the name you'd prefer for this artifact? Andrei How about: Maybe!T Got that from Haskell :-) I also feel the bikeshed should be colored 'Maybe'. Thirded! Great. Now, before we get all jolly about Maybe, let me point out that we also need the "ref" corresponding type. And OptionalRef and NullableRef may sound better to some than MaybeRef. Andrei So if pointers wouldn't be considered evil, Maybe!T* would suffice? Can someone point me out what the big difference is between ref and simply disallowing pointer arithmitic? Is it marketing?
Re: Nullable or Optional? Or something else?
Op Wed, 02 Sep 2009 21:39:28 +0200 schreef Andrei Alexandrescu : I plan to add a Nullable struct to Phobos (akin to C#'s Nullable, Boost's Optional). Apparently a good design is to define Optional!T with a minimum of member functions (ideally none) and have it use the "alias this" feature to masquerade as a T. That way Optional!T looks and feels much like a T, except that it supports a function bool isNull(T)(Optional!T value); Am I on the right track? If so, what is the name you'd prefer for this artifact? Andrei How about: Maybe!T Got that from Haskell :-)
Re: Scala future, Sing#
Op Wed, 26 Aug 2009 02:04:18 +0200 schreef bearophile : Note: LTO isn't done automatically yet by LDC, so to do it you have to input 3 different commands. Ask (to me, for example) if you want to know them. Well I do :-)
Re: The proper case for D.
Op Fri, 19 Jun 2009 22:53:54 +0200 schreef Sean Kelly : Uppercase. Thats awesome, made me chuckle. :-) Calling it 'd' lacks a certain punch.
Re: D Wiki
Op Tue, 09 Jun 2009 18:38:36 +0200 schreef grauzone : BCS wrote: Hello grauzone, I'd even prefer a flash widget that would provide proper UI Oh god... oh god no... I'm going to have nightmares again... yah, ditto, OTOH that was in a tone of "if all else fails" OK. But you know... someone might actually go and do it. No! Oh noes! The horrors of beautiful text! http://labs.adobe.com/technologies/textlayout/ *ducks for cover*
Re: If T[new] is the container for T[], then what is the container for T[U]?
Op Sat, 25 Apr 2009 15:07:52 +0200 schreef Andrei Alexandrescu : It looks we can't make it with only T[]. We need a genuine container type, and T[new] was suggested. It would probably have value semantics. T[U] seems to have the same problem. If T[U] is the range, then how do you call the container? T[new U] ? T[new(U)] ? T[U new] ? you knew...? still, reusing new like that looks pretty akward to me.
Re: Fully dynamic d by opDotExp overloading
Op Sat, 18 Apr 2009 12:25:55 +0200 schreef Danny Wilson : Op Fri, 17 Apr 2009 22:31:04 +0200 schreef Nick Sabalausky : so far, opDotExp's benefits are trivial at best. I don't want to have to keep track of "ok, is this class using opDotExp or not, because if it is, then I need to be more careful", just for the sake of a feature that provides such a tiny and questionable benefit. So what exactly are you afraid of?! What I was really trying to say is: sure you have to keep track of which class uses opDotExp but you won't be thinking about it. You'll be thinking "How do I access this json 'object'?" and then remember you can just access it. With quoted identifiers you'll think exactly the same: "How do i access?" use: ["object"]. In both cases you'll get a runtime exception of some sort and have to take a look at the code if you made typos. HaXe (and Actionscript a little) are great examples of statically-dynamically-typed languages :-) I use static typing pretty much all the time. Just in a few cases I use Dynamic (or this opDotExp like thing) and then I'll know where to look for simple errors like typos. Null pointers are a far more common bug for me but that's beside the point.
Re: Fully dynamic d by opDotExp overloading
Op Fri, 17 Apr 2009 22:31:04 +0200 schreef Nick Sabalausky :
But with opDotExp, its mere *existence* undermines my ability to be sure
that non-quoted identifiers are ok as long as they've compiled. That
type of
tradeoff is obviously fine when the potential benefits are significant
enough (operator overloading, for instance). But from everything I've
seen
so far, opDotExp's benefits are trivial at best. I don't want to have to
keep track of "ok, is this class using opDotExp or not, because if it is,
then I need to be more careful", just for the sake of a feature that
provides such a tiny and questionable benefit.
class AbstractConceptInvoker
{
public void activate(){}
}
auto a = new AbstractConceptInvoker();
a.activate();
What does my code do? Who knows? It could connect to a DB and delete all
tables. It could be an O(infinity) operation...
You have no idea until you either read (correct) documentation about it,
or look at the code.
Now let's go from that obvious observation to opDotExp()
You know the class uses opDotExp() because it said so in the docs.
Examples that could really benifit from this are:
- XMLRPC and other kinds of remoting
- Quick access to: XML / JSON / Yaml / Config files / DB access
- Calling DLLs without bindings
- Lots more
All these would mention it in their docs, guaranteed. Because they use
opDotExp it's implicitly mentioned. I don't think anyone would tell a
documentation generator to list all public methods except opDotExp .. that
would be just braindead. And you could generate the docs yourself if you
have to code..
So what exactly are you afraid of?!
Re: Fully dynamic d by opDotExp overloading
Op Sat, 18 Apr 2009 00:22:25 +0200 schreef Christopher Wright
:
Let's say you integrate D with a scripting language where you can add
methods to an object at arbitrary times. Instead of writing:
scriptObj.invokeMethod("methodname", arguments);
I thought that would be the obvious application, and decided to mention
the haXe instead :-)
Guess it's only obvious for someone used to dynamic languages...
Re: Fully dynamic d by opDotExp overloading
Op Sat, 18 Apr 2009 09:24:39 +0200 schreef Andrei Alexandrescu
:
now you have an easy way to know if a type is dynamic without changing
the method invocation syntax. A proper IDE can easily mark those Types
as different, for example, using a different color.
The dynamic behavior is indicated by the use of opDotExp. The redundancy
of the two notations doesn't quite sit well.
Andrei
Not necessarily.
dynamic class A {
void opDotExp... // compiles
}
class A {
void opDotExp... // error
}
class A {
void nothrow opDotExp... // compiles
}
But yea its still redundant ofcourse. The 'proper' IDE could color classes
which have an opDotExp (thats allowed to throw) differently just aswell.
Re: Fully dynamic d by opDotExp overloading
Op Fri, 17 Apr 2009 08:31:02 +0200 schreef davidl : it generates the output: god it works dynamicmethod god it works qq 5 Any comments? Do you like this feature? Awesome, this is exactly what I thought was the point of 'opDot' when i first skimmed over it in the docs. This is great for lots of purposes. A small nice example is: http://haxe.org/doc/advanced/xml_fast
Re: My body is ugly (was Re: Contract programming syntax)
2 x Fifthed + 1 = Eleventhed! Op Wed, 08 Apr 2009 20:51:17 +0200 schreef Alexander Pánek : Fifthed. How about using bigfloat for that?
Re: OPTLINK needs to die.
Op Tue, 17 Feb 2009 11:06:43 +0100 schreef Walter Bright : It does not crash when I try it. Are you sure you're not running a multicore computer? It's pretty hard to _NOT_ get a multicore computer these days. Please kill OPTLINK.
Re: Pluggable type sytems
Op Mon, 09 Feb 2009 02:25:55 +0100 schreef Denis Koroskin <2kor...@gmail.com>: On Mon, 09 Feb 2009 04:09:26 +0300, Bartosz Milewski wrote: ... My impression is that theoreticians and very advanced programmers love elaborate type systems. Nine-to-five programmers, which are in the majority, prefer simplicity even if the cost is reliability. Just look at the comments to my blog post. I know we have to do something about null references in D, but I'm still on the fence about how we should accomplish that. So, let's ask the community: Would you like to see nullable types in D? http://www.micropoll.com/akira/mpview/539369-138652 (please, don't abuse by voting multiple time) Explain your reasoning in newsgroups. Thank you. I voted yes. There have been far too many NullPointerExceptions in various languages, for the 9-5 programmer to understand in 15 minutes what non-nullable types are :-)
Re: People speaketh
Op Thu, 29 Jan 2009 22:42:49 +0100 schreef Derek Parnell : Curious that first/last didn't get a mention in your poll? Woops, sorry about that. Added it below the others, otherwise it messed up the voting count :-S
Re: People speaketh
We are programmers, and voting by counting messages manually?? Come on! :-) Btw, I like head/last because it _isn't_ symmetrical and both 4 characters long. I'm the kind of programmer that lines up all my variable declerations, etc. Porbably because I do some design work now and then as well :-) Anyway, I set this up in a minute (not that I knew the site, it's just the first google hit): http://www.micropoll.com/akira/mpview/534034-136045 I can add more choises if needed, or Andrei could create his own poll or whatever.
Re: foreach ... else statement
foreach(languageStatement; AllProgrammingLanguages)
Stdout.format(
"It's possible to create grotesque configurations of '{}' which are "~
"extremely difficult to analyze. But most uses of {} are simple.",
languageStatement
).newline;
