+11
materials I've seen. They really need the feature to make the new
lambdas
work.
Cheers,
Pillsy
ems like this would primarily benefit picking
better optimization strategies at *runtime*, which strikes me as a
fairly esoteric use case.
Cheers,
Pillsy
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
> On 9/22/11 10:42 AM, pillsy wrote:
> > == Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
[...]
> >> Already does. We're looking for a briefer syntax.
> >
it make sense to have a template library along the lines of
boost::proto/boost::lambda to allow even
shorter, expression-based lambdas like
_1 + _2
I'm not exactly a D template metaprogramming pro, but I think this would work
for a lot of common cases.
Cheers, Pillsy
guate, the function can
always be declared void, or an explicit
return statement can still be used. The less ceremony necessary to define a
function, the better, IMO.
Cheers, Pillsy
adding a third, dummy, reference-type parameter that takes a suitable
default value allow you to hack
around this?
Cheers,
Pillsy
n identifier; this could provide additional safety when
metaprogramming with mixin templates and string mixins. Right now
you have to do hacky and not-terribly-robust things to synthesize
unique IDs out of __FILE__ and __LINE__.
Cheers,
Pillsy
l/DIPs/DIP9
> I've made suggested changes, please review again.
I like this design. Thanks for proposing it.
Cheers,
Pillsy
bearophile wrote:
> Pillsy:
[...]
> > It has one other advantage, in that you can use the `scope`
> > keyword for things other than varargs, like closures.
> That scope syntax is already supported for closures, and it's partially
> implemented (or fully implemented,
ther advantage, in that you can use the `scope` keyword for things other
than varargs, like closures.
Cheers,
Pillsy
uriel_follower wrote:
> Pillsy Wrote:
[...]
> > At this point I'm mystified as to why language designers just keep
> > on making this same mistake by leaving support for generic
> > programming out of their statically typed languages. Java and C#
> > had to gra
stified as to why language designers just keep on making
this same mistake by leaving support for generic programming out of their
statically typed languages. Java and C# had to graft generics onto their
languages after the fact; why ignore that?
Cheers,
Pillsy
macros, but D doesn't have preprocessor macros, so the main reason for having
it isn't there.
Either way, it's not exactly a make or break feature.
Cheers,
Pillsy
Steven Schveighoffer Wrote:
> On Tue, 09 Nov 2010 08:14:40 -0500, Pillsy wrote:
[...]
> > Ah! This is a lot of what was confusing me about arrays; I still thought
> > they had this behavior. The fact that they don't makes me a good deal
> > more comfortable with
ays; I still thought they
had this behavior. The fact that they don't makes me a good deal more
comfortable with them, though I still don't like the non-deterministic way that
they may copy their elements or they may share structure after you append stuff
to them.
Cheers,
Pillsy
Pillsy Wrote:
[...]
> So, wait, if I have a program like this:
> void appendSailor (string s) {
>s ~= "Sailor";
> }
> void main () {
>auto s = "Hello World!";
>
>appendSailor(s[0 .. 6]);
>
>writefln(s);
> }
> I shou
Steven Schveighoffer Wrote:
> On Mon, 08 Nov 2010 13:46:52 -0500, Pillsy
> wrote:
> > Besides, isn't catenating or appending in place impossible with D's
> > (immutable) strings anyway?
> This is a misconception, a string is not immutable, the data it poin
Jonathan M Davis wrote:
> On Monday, November 08, 2010 08:43:20 Pillsy wrote:
> > The length property of an array shouldn't be directly mutable,
> > and you shouldn't be able to append onto the end of a dynamic
> > array, because it can cause some surprising behavi
lot to learn anyway, given how
much lower level and more static D is as a language.
[1] From a "marketing" perspective, they're also great way to show off how
using a GCed language can actually improve performance and memory use.
Cheers,
Pillsy
terface, adding garbage collection, making strings
immutable...?
D is as much Java++ as it is C+=2.
Cheers,
Pillsy
't make this(this) perform
expensive operations." :)
The important thing to my thinking is that `this(this)` gives programmers what
they need to do reference counting themselves when they need it to get their
value types right.
Cheers,
Pillsy
who want to take the risk of shooting themslves in the foot
shoot themselves in the foot by having this(this) open an HTTP collection to
Alpha Centauri if that's what they really want.
Cheers,
Pillsy
t GC QoI issues strikes me as a bad plan.
Cheers,
Pillsy
e context
of D---like multimethods---would be a huge addition.
Cheers,
Pillsy
[1] The "open multimethods" described in
http://www2.research.att.com/~bs/multimethods.pdf
are very similar to Dylan's "generic functions". They don't have a lot to do
with "generics" or "generic programming".
osity involved.
T abs(T num) (-1 * num).qualof {
return (num < 0) ? -1 * num : num;
}
is even shorter, and would have the possibility of also handling concerns of
constness and sharedness and the like properly.
Cheers,
Pillsy
copying, because it allows you to treat an immutable
reference type exactly like a value type.
Cheers,
Pillsy
be feasible, and that's actually a lot, much as 90%
> sounds like a big number).
This is definitely agree with. Making something that legitimately
does everything anyone could ever want is how you end up with
nightmares like Scheme's call-with-current-continuation, but letting
1 use case in 10 drop on the floor makes the cost/benefit ratio of
learning your library or language really dubious.
[...]
Cheers,
Pillsy
Steven Schveighoffer Wrote:
> On Thu, 26 Aug 2010 11:17:32 -0400, Pillsy
> wrote:
[...]
> > If you don't mind me asking, what made you give up on it?
> A cursor that refers to one element is much more efficient to pass
> around/copy.
Ah, yes. If you just need th
Steven Schveighoffer Wrote:
> On Thu, 26 Aug 2010 10:18:51 -0400, Pillsy
> wrote:
[...]
> > The key idea is that these cursors aren't a primitive part of a
> > range; instead, they take a range and add a position *inside*
> > the range. They're a perfe
cific indexed
elemnt for RandomAccess ranges).
The key idea is that these cursors aren't a primitive part of a range; instead,
they take a range and add a position *inside* the range. They're a perfect fit
for all those "three-legged" operations out there because they actually have
three legs.
Cheers,
Pillsy
o makes for a fine replacement for the comma operator, because you can
use it anywhere you can use an expression.
I'd love a bit of syntactic sugar for the idiom, that would do the same thing
the Lisp LET does, transforming
let (x = a, y = b) { foo(x); bar(y); return quux(x, y); }
into
(x, y){ foo(x); bar(y); return quux(x, y); }(a, b)
automatically.
Cheers,
Pillsy
(){ return "compile-time-string" ~ type.stringof; });
one time in a hundred, is it really that bad?
Cheers,
Pillsy
d free should be free. I'd like almost any
other conceivable pair of
names better, like make/unmake, create/destroy, build/smash, whatever.
Cheers,
Pillsy
ul in all
sorts of ways. RIght now D is only
a couple steps away from where it would need to be in order to allow people to
build a really useful macro
system in libraries.
Cheers,
Pillsy
[...]
r nicer if
you could use some sort of __traits form to get a unique name (and
then that could be wrapped in a string-mixin macro)!
> Also, to me, it's trivial to understand string manipulation
> where the end result is the language I already know, vs.
> having to learn how the compiler represents syntax.
String manipulation scales very poorly, it's error prone, and it's
tedious.
Cheers,
Pillsy
more palatable to some?
> There's little doubt that it's the part of the language which needs the
> most attention in the long term. But the way forward is not at all
> obvious. So it's been deferred.
I'm not clear on how one is supposed to go about making the equivalent of
hygienic macros using just
string mixins and CTFE.
Cheers,
Pillsy
iler is up to
supporting them, which would make both the containers and
the "smart pointers" a good deal more useful.
Cheers,
Pillsy
[1] I asked some questions about the feasibility of this in d.learn.
is allocated as a single block and
(presumably) GC'd as a single block. If I copy a 1000 element list
and then remove 999 elements from the front using removeFront(),
won't I end up leaking memory for the first 999 nodes?
Cheers,
Pillsy
38 matches
Mail list logo
