Re: reddit.com: first Chapter of TDPL available for free
MIURA Masahiro wrote: Andrei Alexandrescu wrote: http://www.reddit.com/r/programming/comments/975ng/diving_into_the_d_programming_language_tdpl/ Thanks for sharing it! Typos: in section 1.1, there are inchPerFoot's and inchperfoot's. Noted, thanks. Andrei
Re: reddit.com: first Chapter of TDPL available for free
Pablo Ripolles wrote: MIURA Masahiro Wrote: Andrei Alexandrescu wrote: http://www.reddit.com/r/programming/comments/975ng/diving_into_the_d_programming_language_tdpl/ Thanks for sharing it! Typos: in section 1.1, there are inchPerFoot's and inchperfoot's. And, of course, the same goes for cmperinch's. Some other observations are the following: In section 1.2 you refer to prior if statements introduced in above samples, what samples? is there maybe a 0 chapte?r In section 1.4, subsection Building a Vocabulary it's not very clear what stdio.byLine is... I mean, it says nothing about how to feed the text to the program. Also in subsection Counting Frequencies. Lambda Functions there appears a call to splitter function, isn't it named split instead? Besides the hamlet.txt URL doesn't work already, maybe a bit of indirection here would also be appreciated... In section 1.5, maybe I miss the reason of importing std.range. In section 1.6, stats is a variable and stats.d is the name of the file/module, shouldn't stats.d be renamed to stat.d so that stat.Max makes sense and so the name of the program becomes stat and it's invoked that way in the command line? Or maybe rename stat.Max to stats.Max? Besides, aren't you talking firstly about Min? Why not to illustrate the thing with stat.Min instead of stat.Max? In the references to different other chapters the word sometimes appears capitalized and sometimes doesn't. Cheers! Thanks, Pablo. Andrei
Re: reddit.com: first Chapter of TDPL available for free
Andrei Alexandrescu wrote:
http://www.reddit.com/r/programming/comments/975ng/diving_into_the_d_programming_language_tdpl/
(Don't tell anyone, but I plan to rewrite it.)
Andrei
Dump of thoughts as I read it:
-- Personally, I've replaced Hello, World! in my own code with Don't
Worry, Be Happy!. Making the program whistle through the PC speaker
optional.
(Actually, I made that last bit up, but now I have an overwhelming urge
to work out how to do it...)
-- What's with all the quote marks in the heights example? I... OOOH...
feet and inches. Out of interest, is it correct to replace '' with
\? Also, maybe put cm on the end of the line.
-- Why immutable and not enum? They're not only unlikely to change,
they don't need to be stored in the program.
-- Re: writefln example. I thought integers were %d, not %i.
-- Assigning to arr.length reallocates the array. Shouldn't that be
something along the lines of Assigning to arr.length reallocates the
array if you try to make it larger.?
-- by setting to write a binarySearch -- by setting doesn't really
parse.
-- in D, the semantics of a module-level symbol never depends on its
relative ordering with others. HAHAHAHAHAHAHA! Oh, that's a good one.
Glad to see you have a sense of humour. :D
-- What is freqs.keys if not an array? (You call array on it, indication
that it puts it in array format, but don't explain what would happen
if you don't do that.)
-- startsWith and tolower have inconsistent capitalisation. Just
sayin', is all. :)
-- Following the style guide, shouldn't postprocess be postProcess.
Everyone's free to use whatever style they like, but since this is the
official book, I just wonder if it should follow the guide.
-- I realise it's a simple example, but wouldn't double.inf or, better
yet, double.nan, be a more appropriate initialiser? double.inf is the
absolute largest value you could possibly get (imagine the input
contains an exceedingly large value that overflows to inf; the output is
no longer accurate.)
double.nan is even better because unless the input is malformed, you
can't get it. Of course, then you need to be a little trickier in how
you write your test; if (!(x = min)) { min = x; } should do it. Then
again, this requires you to explain wtf is going on... :P
-- You don't indicate what enforce does.
Closing thoughts:
I like it. It's easy to read and well-written.
Re: Contextualizing keywords
Michael Mittner wrote:
Ary Borenszweig wrote:
Yes. Maybe every keyword could be just keyword(...). For example:
keyword(static), keyword(final), etc. For example this code now:
pure SomeType foo() {
}
would be, with this change:
keyword(pure) SomeType foo() {
}
Hmm...
Or maybe:
@pure void foo() {
}
:-)
For future extensibility it should be
keyword type=pure SomeType foo() { /* ... */ }
;)
function-declaration
puretrue/pure
returnTypeSomeType/returnType
namefoo/name
parameters/
body
comment ... /comment
/body
/function-declaration
smilie:)/smilie
Using elements instead of attributes allows you to put arbitrary
subexpressions as the value. :D
Re: My body is ugly [Re: Contextualizing keywords]
Michel Fortin wrote:
Also, I wonder why we need braces everywhere in contracts. I'd like it
if I could write:
int test(int i)
in
assert(i 1);
out (z)
assert(z 0);
do
return -i + 1;
Just bikeshedding a bit around... why not make it even simpler, and just
leave away the body/do completely? That would finally be a syntax I'd be
happy with. It wouldn't destroy the normal code layout too, because
in/out contracts are fully additional syntax.
int test(int i)
in assert(i 1);
out(z) assert(z 0);
{ return -i + 1; }
Re: Iterators Must Go video online
grauzone wrote: torhu wrote: On 03.08.2009 19:47, Andrei Alexandrescu wrote: A while ago I mentioned the video of my BoostCon keynote Iterators Must Go will be soon available online. Here it is: http://boostcon.blip.tv/ Andrei Cool. I'm having some trouble skipping to the parts I'm interested in, can anyone point me to a downloadable video? This works for me: wget 'http://blip.tv/file/get/Boostcon-BoostCon2009Keynote487.flv?referrer=boostcon.blip.tvamp;ext=.flv' I didn't find a download link, but had to go through the sourcecode and had to deal with their JavaScript/AJAX/XML crap. Why? Because you don't have the LiveHTTPHeaders extension for Firefox installed so you can sniff the URLs as it grabs stuff. Bwahahaha. (Actually, I usually just use an extension that lets me search the cache.)
Re: DIP6: Attributes
Steven Schveighoffer wrote:
On Mon, 03 Aug 2009 11:42:33 -0400, Ary Borenszweig
a...@esperanto.org.ar wrote:
Don wrote:
Ary Borenszweig wrote:
Don escribió:
grauzone wrote:
Don wrote:
Ary Borenszweig wrote:
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6
This looks like a solution in search of a problem. What's the
problem being solved?
Attaching additional data to types, that can't be specified
otherwhere. This should help with metaprogramming-like stuff.
For example serialization. How do you specify that a field
shouldn't be part of the serialized data? Java has an extra
keyword attribute like
transient (comes from before attributes were introduced). C#
uses what we call annotation in this thread. How would you do this
in D?
I agree that there doesn't seem to be a nice way at present. One
possibility would be to establish a naming convention for transient
fields -- a Ruby-style solution, I guess.
But are annotations actually an ideal solution for this problem?
Presumably, you'll have to specify that somewhere else anyway. I
mean, during reading it will need to either be initialized
separately after serialisation (like opPostBlit, perhaps?), or else
remain uninitialized. Serialisation seems to be _extremely_ similar
to construction. I'm not sure that annotations capture that.
D has much more powerful metaprogramming than C# or Java, so my
intuition and hope is that we shouldn't need to adopt hacks from
those weaker languages. The annotation syntax in C# and Java looks
like an ugly hack to me. Purely a subjective opinion, of course,
but it seems really out of place in a C-family language.
Attributes has many, many other uses. Appart from serialization, you
could specify how a field is stored in a database. How a method maps
to an http request (post, get, which parameters to bind to the
request, etc.). Whether a method should do security checks before
executing. Whether a method should be run as a test, and what's the
expected exception to be thrown. [insert your usage here]
Great, you've answered my question. That should be in the DIP,
instead of the vague stuff that's in there now -- the existing DIP is
about replacing keywords, which is very unconvincing. (It doesn't
work, actually -- the name mangling is important for most of the
keywords mentioned).
But the DIP I wrote isn't about general-purpose annotations. It's just
the first step. Are pure and nothrow part of the mangling? Or
which are? I thought not. Can you overload a pure and a not-pure
function with the same parameter count and types?
Yes, they have to be. There are reasons besides overloading for
including other attributes in the naming.
For example, if a function is pure, then becomes unpure, you don't
existing code that is expecting a pure function to link against it.
In other words, the linker is dumb. It only knows how to match symbols,
so you have to embed into the symbols the important pieces of the
interface that you want the linker to consider important.
A question: in C#/Java, can you have annotations on function pointer and
delegate declarations?
void foo( int delegate(int) pure dg) {
...
}
What would this look like with annotations?
(The underlying question is, how do annotations interact with the type
system?)
To answer Don's point, there is nothing saying that the compiler can't
read attributes and change its behavior. Of course, those would have to
be builtin attributes.
Yes, but then they're just keywords, with an @ in front. You'd just be
kidding yourself if you think you've reduced the keyword count.
My opinion on removing existing keywords is -- don't. There's little to
no gain. Let that ship sail, and concentrate on future keyword proposals.
-Steve
Re: DIP6: Attributes
Don wrote:
...
A question: in C#/Java, can you have annotations on function pointer and
delegate declarations?
void foo( int delegate(int) pure dg) {
...
}
What would this look like with annotations?
Well, Java doesn't HAVE delegates and C# doesn't (AFAIK) allow you to
define them inline; they have a special declaration syntax that can't be
used in an expression.
C# would probably look something like:
namespace Blech
{
[Pure]
public delegate int Moo(int);
public class Urk
{
public static void foo(Moo dg) {
...
}
}
}
(The underlying question is, how do annotations interact with the type
system?)
I don't think they form part of the type; they're just sort of attached
to that particular declaration.
To answer Don's point, there is nothing saying that the compiler can't
read attributes and change its behavior. Of course, those would have
to be builtin attributes.
Yes, but then they're just keywords, with an @ in front. You'd just be
kidding yourself if you think you've reduced the keyword count.
I suspect the reasoning goes like this:
* I want attributes. Walter doesn't see the use.
* Walter complains about adding keywords.
* I can make keywords look like attributes, and then I get attributes!
:P
My opinion on removing existing keywords is -- don't. There's little
to no gain. Let that ship sail, and concentrate on future keyword
proposals.
-Steve
Re: DIP6: Attributes
Daniel Keep wrote: Yes, but then they're just keywords, with an @ in front. You'd just be kidding yourself if you think you've reduced the keyword count. I suspect the reasoning goes like this: * I want attributes. Walter doesn't see the use. * Walter complains about adding keywords. * I can make keywords look like attributes, and then I get attributes! :P The idea is just stolen from C#/Java. I guess the idea is that 1. keywords/annotations are in a different namespace and 2. even compile time keyword annotations can be handled as normal identifiers. The second point means introducing a new keyword is like declaring a new identifier in object.d. But it would also allow users shadowing annotation keywords by defining their own annotations, which might be a problem or not.
Re: Iterators Must Go video online
Daniel Keep wrote: grauzone wrote: torhu wrote: On 03.08.2009 19:47, Andrei Alexandrescu wrote: A while ago I mentioned the video of my BoostCon keynote Iterators Must Go will be soon available online. Here it is: http://boostcon.blip.tv/ Andrei Cool. I'm having some trouble skipping to the parts I'm interested in, can anyone point me to a downloadable video? This works for me: wget 'http://blip.tv/file/get/Boostcon-BoostCon2009Keynote487.flv?referrer=boostcon.blip.tvamp;ext=.flv' I didn't find a download link, but had to go through the sourcecode and had to deal with their JavaScript/AJAX/XML crap. Why? Because you don't have the LiveHTTPHeaders extension for Firefox installed so you can sniff the URLs as it grabs stuff. Bwahahaha. (Actually, I usually just use an extension that lets me search the cache.) And if I don't use Firefox? Anyway, the intention of blip.tv seems to be not to allow users downloading content, at least in no obvious way. They're probably just too lazy to implement more strict DRM. Same with Youtube.
Re: DIP6: Attributes
grauzone Wrote: Daniel Keep wrote: Yes, but then they're just keywords, with an @ in front. You'd just be kidding yourself if you think you've reduced the keyword count. I suspect the reasoning goes like this: * I want attributes. Walter doesn't see the use. * Walter complains about adding keywords. * I can make keywords look like attributes, and then I get attributes! :P The idea is just stolen from C#/Java. I guess the idea is that 1. keywords/annotations are in a different namespace and 2. even compile time keyword annotations can be handled as normal identifiers. The second point means introducing a new keyword is like declaring a new identifier in object.d. But it would also allow users shadowing annotation keywords by defining their own annotations, which might be a problem or not. IIRC, in C# you can use keywords as identifiers. int @if = 3; // this is a variable called if the @ in C# is a way to tell the parser - don't treat this as a keyword.
Re: My body is ugly [Re: Contextualizing keywords]
On 2009-08-04 02:50:23 -0400, grauzone n...@example.net said:
Michel Fortin wrote:
Also, I wonder why we need braces everywhere in contracts. I'd like it
if I could write:
int test(int i)
in
assert(i 1);
out (z)
assert(z 0);
do
return -i + 1;
Just bikeshedding a bit around... why not make it even simpler, and
just leave away the body/do completely? That would finally be a syntax
I'd be happy with. It wouldn't destroy the normal code layout too,
because in/out contracts are fully additional syntax.
int test(int i)
in assert(i 1);
out(z) assert(z 0);
{ return -i + 1; }
That could work if the in and out blocks were alwasy one-statement
long. That's hardly the case, and so you'd have two blocks following
each other which I find a little strange:
int test(int i)
in {
assert(i 1);
}
out (z) {
assert(z 0);
}
{
return -i + 1;
}
Nothing catastrophic, but in my opinion it reads better with a keyword
in front of the last opening brace.
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
Re: DIP6: Attributes
Steven Schveighoffer Wrote: Yes, they have to be. There are reasons besides overloading for including other attributes in the naming. For example, if a function is pure, then becomes unpure, you don't existing code that is expecting a pure function to link against it. In other words, the linker is dumb. It only knows how to match symbols, so you have to embed into the symbols the important pieces of the interface that you want the linker to consider important. To answer Don's point, there is nothing saying that the compiler can't read attributes and change its behavior. Of course, those would have to be builtin attributes. My opinion on removing existing keywords is -- don't. There's little to no gain. Let that ship sail, and concentrate on future keyword proposals. -Steve If we are willing to have our own specialized linker format than the compiler can output data structures that contain a symbol with an assosiated map of attributes (meta-data). This will remove the need to have mangled symbols. For example, the compiler can provide to the linker the dependency graph as attributes.
Re: DIP6: Attributes
grauzone Wrote: inheritance? You want to inherit annotations? What for? Backward compatibility: obtain annotation cast it, work with it, then later change its type. Annotations will be used by reflection, so classinfo will be useful.
Re: DIP6: Attributes
Don Wrote: Annotations are useful in many ways, but without full reflection capabilities, they are restricted to things that can read them via source code, and so they are no better than comments. This is a very, very important observation, and I think it belongs in the DIP. It means that it probably doesn't make much sense to implement annotations without also having an intention to implement full-blown reflection. The DIP is about the first step: to allow syntax.
Re: DIP6: Attributes
Don Wrote: To answer Don's point, there is nothing saying that the compiler can't read attributes and change its behavior. Of course, those would have to be builtin attributes. Yes, but then they're just keywords, with an @ in front. You'd just be kidding yourself if you think you've reduced the keyword count. The problem with keywords is they're global. Why do you think there is module std.string, but there isn't core.stdc.wchar? It's because string is not a keyword, while wchar is. And annotations are also identifiers (though predefined, like Object) rather than keywords.
Re: DIP6: Attributes
Daniel Keep Wrote: Which one works right now and doesn't require you first spend at least a year convincing Walter that it's useful, then convincing him it's necessary As far as I see, necessity is not questioned. It may be only of low priority or something like that.
Re: DIP6: Attributes
Kagamin wrote: Don Wrote: To answer Don's point, there is nothing saying that the compiler can't read attributes and change its behavior. Of course, those would have to be builtin attributes. Yes, but then they're just keywords, with an @ in front. You'd just be kidding yourself if you think you've reduced the keyword count. The problem with keywords is they're global. Why do you think there is module std.string, but there isn't core.stdc.wchar? It's because string is not a keyword, while wchar is. And annotations are also identifiers (though predefined, like Object) rather than keywords. No, that's only one of the problems with keywords. Prefixing all new keywords with __ solves the same problem, and it's no more ugly than prefixing with @. But it doesn't solve the other keyword problems.
Re: DIP6: Attributes
Don escribió:
Steven Schveighoffer wrote:
On Mon, 03 Aug 2009 11:42:33 -0400, Ary Borenszweig
a...@esperanto.org.ar wrote:
Don wrote:
Ary Borenszweig wrote:
Don escribió:
grauzone wrote:
Don wrote:
Ary Borenszweig wrote:
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP6
This looks like a solution in search of a problem. What's the
problem being solved?
Attaching additional data to types, that can't be specified
otherwhere. This should help with metaprogramming-like stuff.
For example serialization. How do you specify that a field
shouldn't be part of the serialized data? Java has an extra
keyword attribute like
transient (comes from before attributes were introduced). C#
uses what we call annotation in this thread. How would you do
this in D?
I agree that there doesn't seem to be a nice way at present. One
possibility would be to establish a naming convention for
transient fields -- a Ruby-style solution, I guess.
But are annotations actually an ideal solution for this problem?
Presumably, you'll have to specify that somewhere else anyway. I
mean, during reading it will need to either be initialized
separately after serialisation (like opPostBlit, perhaps?), or
else remain uninitialized. Serialisation seems to be _extremely_
similar to construction. I'm not sure that annotations capture that.
D has much more powerful metaprogramming than C# or Java, so my
intuition and hope is that we shouldn't need to adopt hacks from
those weaker languages. The annotation syntax in C# and Java looks
like an ugly hack to me. Purely a subjective opinion, of course,
but it seems really out of place in a C-family language.
Attributes has many, many other uses. Appart from serialization,
you could specify how a field is stored in a database. How a method
maps to an http request (post, get, which parameters to bind to the
request, etc.). Whether a method should do security checks before
executing. Whether a method should be run as a test, and what's the
expected exception to be thrown. [insert your usage here]
Great, you've answered my question. That should be in the DIP,
instead of the vague stuff that's in there now -- the existing DIP
is about replacing keywords, which is very unconvincing. (It doesn't
work, actually -- the name mangling is important for most of the
keywords mentioned).
But the DIP I wrote isn't about general-purpose annotations. It's
just the first step. Are pure and nothrow part of the mangling?
Or which are? I thought not. Can you overload a pure and a not-pure
function with the same parameter count and types?
Yes, they have to be. There are reasons besides overloading for
including other attributes in the naming.
For example, if a function is pure, then becomes unpure, you don't
existing code that is expecting a pure function to link against it.
In other words, the linker is dumb. It only knows how to match
symbols, so you have to embed into the symbols the important pieces of
the interface that you want the linker to consider important.
A question: in C#/Java, can you have annotations on function pointer and
delegate declarations?
void foo( int delegate(int) pure dg) {
...
}
What would this look like with annotations?
(The underlying question is, how do annotations interact with the type
system?)
In C# (and they were going to add it to Java) you can annotate a lof of
things: declarations, statements, function arguments. I don't know if
expressions.
So you could do:
void foo(@pure int delegate(int) dg) {
}
but that'll mark as pure the argument dg, not the type of dg. That
doesn't mean there shouldn't be a way to annotate types.
Re: reddit.com: first Chapter of TDPL available for free
Sorry for my stepping in,but as a beginner in D ,I think maybe you( all of you
experts) have interest to hear what he think after he read the book:This is
really really great!Thank you so much for your great job!
Here a couple of questions regarding first chapter:
1.foreach (line; stdin.byLine) {
Did not mention how to read data from file *hamlet.txt* to the analyse.If I
want to run the test case,I don't know how.
2. foreach (word; splitter(strip(line))) {
2.1 what's the purpose of splitter(strip(line)) ,I can guess a bit but not
sure;
2.2 In the first place you used split,after that you use splitter;
3.string[] words = array(freqs.keys);
what's array? I can not find it from phobos,was I missing something?If
yes,please forgive me.
4.sort!((a, b) { return freqs[a] freqs[b]; })(words);
cann't get compiled under dmd 2.031.
5.abstract class IncrementalStat : Stat {...}
Why need this extra abstract class which derived from interface Stat?For
class Max,Min and AVG,does't it work fine just implementing the Stat?For a
beginner,it confused me a lot.I think it would be much better to explain more
here.
At the very begining,I am typing while reading to test all the impressive
examples,but very quicky I found I am lost starting at the point of my
qestion#1-4.So finally I gave up to test the example,just read.This is my
experience.
Thank you again and best regards,
Sam
Re: Just a thought: read-only fields
Mon, 3 Aug 2009 22:04:51 -0400, Nick Sabalausky wrote: It's been established in the recent epic-discussions on properties that one of the biggest uses for properties is to implement publically read-only (but privately-writable) fields. That got me thinking, why not actually have real publically read-only fields instead of merely emulating them with properties? They are, after all, a fairly common idiom. // *Not* an actual syntax proposal, but just to get the idea across: private @publicread int foo; // The class sees it as int, but everything else sees it as const(int) // ...or something like that... Um... @publiconst? XD or private int foo; public alias const foo foo; or even private public(const) int foo; Weird... OTOH this should be trivial from the implementation POV. On the even other hand this only worth considering if actual properties are dropped because properties are more generic and you *can* implement a read-only field with them. Maybe some syntactic sugar is in order if it really is such a common thing.
Re: Iterators Must Go video online
Mon, 03 Aug 2009 12:47:40 -0500, Andrei Alexandrescu wrote: A while ago I mentioned the video of my BoostCon keynote Iterators Must Go will be soon available online. Here it is: http://boostcon.blip.tv/ Andrei Nice talk! The Try THAT with iterators, @($#* ! part was especially entertaining. XD What I didn't get was why range.front is so much superior to *i. At the end of the day they're both just functions returning whatever they please.
Re: Just a thought: read-only fields
Sergey Gromov Wrote: Mon, 3 Aug 2009 22:04:51 -0400, Nick Sabalausky wrote: It's been established in the recent epic-discussions on properties that one of the biggest uses for properties is to implement publically read-only (but privately-writable) fields. That got me thinking, why not actually have real publically read-only fields instead of merely emulating them with properties? They are, after all, a fairly common idiom. // *Not* an actual syntax proposal, but just to get the idea across: private @publicread int foo; // The class sees it as int, but everything else sees it as const(int) // ...or something like that... Um... @publiconst? XD or private int foo; public alias const foo foo; or even private public(const) int foo; Weird... OTOH this should be trivial from the implementation POV. On the even other hand this only worth considering if actual properties are dropped because properties are more generic and you *can* implement a read-only field with them. Maybe some syntactic sugar is in order if it really is such a common thing. I like the idea. Writing a property requires more code, which is not essential. I think there can be many constructs. I don't know if private public(const) is easily parsed by the compiler though. perhaps this construct is: pragma(read: const) private int foo; otherwise a new keyword is necessary I think. access(public, private) int foo; Where the first parameter is the read situation, and the second parameter is the write situation. Or perhaps more verbose: access(read: public, write: private) int foo; Or maybe even better: access(immutable: public, const: protected, mutable: private) int foo; Meaning: everyone is able to read foo, subclasses can write to internal structures, but not change the object and only the object itself has full write access. Just my 2 ct
Re: property syntax strawman
Tue, 4 Aug 2009 01:15:45 +0400, Sergey Gromov wrote:
Mon, 03 Aug 2009 11:06:53 -0400, Steven Schveighoffer wrote:
I just thought of another issue with property definitions. How do you
declare a property of an array? Today it's:
char[] chomped(char[] input);
Note that any getter property contains an argument which is the object
you're calling the property on (normally implied because the definition is
inside an aggregate definition). But with arrays it's explicit.
So how does this fit in Walter's proposed syntax?
char[] chomped {...}
Where does the input go?
I proposed a keyword, 'inject', a year ago. Or it could be an
annotation. I suppose such a keyword might significantly simplify
implmentation of external functions and properties:
@inject @property char[] chomped(char[] arr) {...}
@inject void sort!(alias pred, T)(T[] arr) {...}
Though prepending 'this' to the first parameter may also work, C# style.
Or, this can work with Walter's syntax:
@extension!char[] char[] chomped {...}
Re: DIP6: Attributes
Tue, 04 Aug 2009 17:22:50 +1000, Daniel Keep wrote:
Don wrote:
...
A question: in C#/Java, can you have annotations on function pointer and
delegate declarations?
void foo( int delegate(int) pure dg) {
...
}
What would this look like with annotations?
Well, Java doesn't HAVE delegates and C# doesn't (AFAIK) allow you to
define them inline; they have a special declaration syntax that can't be
used in an expression.
C#:
Listint ls;
ls.Sort((x, y) = y - x);
or
ls.Sort((x, y) = { int a; a = y; a -= x; return a; });
Re: DIP6: Attributes
Sergey Gromov wrote:
Tue, 04 Aug 2009 17:22:50 +1000, Daniel Keep wrote:
Don wrote:
...
A question: in C#/Java, can you have annotations on function pointer and
delegate declarations?
void foo( int delegate(int) pure dg) {
...
}
What would this look like with annotations?
Well, Java doesn't HAVE delegates and C# doesn't (AFAIK) allow you to
define them inline; they have a special declaration syntax that can't be
used in an expression.
C#:
Listint ls;
ls.Sort((x, y) = y - x);
or
ls.Sort((x, y) = { int a; a = y; a -= x; return a; });
That's not a delegate type, that's a delegate literal.
Re: Iterators Must Go video online
grauzone wrote: Daniel Keep wrote: grauzone wrote: torhu wrote: On 03.08.2009 19:47, Andrei Alexandrescu wrote: A while ago I mentioned the video of my BoostCon keynote Iterators Must Go will be soon available online. Here it is: http://boostcon.blip.tv/ Andrei Cool. I'm having some trouble skipping to the parts I'm interested in, can anyone point me to a downloadable video? This works for me: wget 'http://blip.tv/file/get/Boostcon-BoostCon2009Keynote487.flv?referrer=boostcon.blip.tvamp;ext=.flv' I didn't find a download link, but had to go through the sourcecode and had to deal with their JavaScript/AJAX/XML crap. Why? Because you don't have the LiveHTTPHeaders extension for Firefox installed so you can sniff the URLs as it grabs stuff. Bwahahaha. (Actually, I usually just use an extension that lets me search the cache.) And if I don't use Firefox? kdesu wireshark! Works for me.
Re: property syntax strawman
Andrei Alexandrescu Wrote:
Nick Sabalausky wrote:
Walter Bright newshou...@digitalmars.com wrote in message
news:h53g3i$el...@digitalmars.com...
bool empty { ... }
void empty=(bool b) { ... }
What do you think?
I think that if D starts to make a habit of aping the ugly C++ approach to
adding new features (as this does), then we may as well just use C++.
Let's not forget that C++ got very conservative about adding keywords
after a keyword spree (class that is essentially same as struct,
namespace, xyz_cast, oh yes typename, and, or, not plus other useful
names that I probably forgot). We don't want to get there.
Andrei
I understand your point of view, but I am afraid that using an awkward syntax
makes things difficult to understand. However, I could certainly live with the
current proposal. But this has to do that I'm not afraid of symbolic ways to
achieve something. Others might find it more difficult.
I think that a setter and a getter are two different things, but I would avoid
to have an inconsistent property, such as setting an int and getting a bool, or
something similar. Perhaps a compiler check could intercept?
But I think I can do it with the keywords that we already have in our
possession:
bool in empty
{
}
bool out empty
{
}
Although perhaps this could be argued against, as in and out are used for
contract programming. But this clearly is a different use.
Re: Omissible Parentheses...
Benji Smith wrote:
Denis Koroskin wrote:
Stdout(Hello, World!).newline.newline.newline;
Ugh. This is one of the few things about Tango that really drives me
nuts. I hate all the usage of the opCall overload and non-parenthetized
function calls.
At first glance, that code doesn't make any sense to me. My brain just
doesn't grok what's going on. It takes me a split second to mentally
parse it.
Another thing about omissable parenthesis and function calls. When you
define an opCall, to use it you must write (). That implies that to
call a function you must write (). So not writing () should imply a
function call!
--
import std.stdio;
struct Bar {
Foo foo;
}
struct Foo {
int opCall() {
return 1;
}
}
void main() {
Bar bar;
writefln(%s, bar.foo); // prints Foo
writefln(%s, bar.foo()); // prints 1
}
--
Isn't that an inconsistency?
Re: Omissible Parentheses...
Ary Borenszweig wrote: Benji Smith wrote: Denis Koroskin wrote: Stdout(Hello, World!).newline.newline.newline; Ugh. This is one of the few things about Tango that really drives me nuts. I hate all the usage of the opCall overload and non-parenthetized function calls. At first glance, that code doesn't make any sense to me. My brain just doesn't grok what's going on. It takes me a split second to mentally parse it. Another thing about omissable parenthesis and function calls. When you define an opCall, to use it you must write (). That implies that to call a function you must write (). So not writing () should imply a function call! Oops, typo: should *not* imply a function call.
Re: property syntax strawman
Sjoerd van Leent wrote:
Andrei Alexandrescu Wrote:
Nick Sabalausky wrote:
Walter Bright newshou...@digitalmars.com wrote in message
news:h53g3i$el...@digitalmars.com...
bool empty { ... }
void empty=(bool b) { ... }
What do you think?
I think that if D starts to make a habit of aping the ugly C++ approach to
adding new features (as this does), then we may as well just use C++.
Let's not forget that C++ got very conservative about adding keywords
after a keyword spree (class that is essentially same as struct,
namespace, xyz_cast, oh yes typename, and, or, not plus other useful
names that I probably forgot). We don't want to get there.
Andrei
I understand your point of view, but I am afraid that using an awkward syntax
makes things difficult to understand. However, I could certainly live with the
current proposal. But this has to do that I'm not afraid of symbolic ways to
achieve something. Others might find it more difficult.
I think that a setter and a getter are two different things, but I would avoid
to have an inconsistent property, such as setting an int and getting a bool, or
something similar. Perhaps a compiler check could intercept?
But I think I can do it with the keywords that we already have in our
possession:
bool in empty
{
}
bool out empty
{
}
Although perhaps this could be argued against, as in and out are used for
contract programming. But this clearly is a different use.
in and out are also used for function parameters, remember.
Re: DIP6: Attributes
On Tue, 04 Aug 2009 03:03:12 -0400, Don nos...@nospam.com wrote:
A question: in C#/Java, can you have annotations on function pointer and
delegate declarations?
void foo( int delegate(int) pure dg) {
...
}
What would this look like with annotations?
(The underlying question is, how do annotations interact with the type
system?)
I'm not familiar with Java annotations, it's been a while since I used
Java.
In C#, you would not use an attribute as a type modifier, the attributes
are attached to a declaration (e.g. a class, member, function parameter).
So basically, an attribute can modify how the compiler treats something,
but it doesn't allow you to define new types with it. I suppose you could
use it that way, but I think it would be better to just use it as hints
and information, not an integral part of the type system.
When you have runtime reflection, you can query for attributes on almost
anything, but they are usually descriptors, and don't affect type
matching. The only places I've used it are as hints to other things
reading my compiled objects. For example, SerializableAttribute is used
by serializers to know what to serialize and what not to serialize.
If pure weren't part of the function signature, but simply a way to
compile a function, then it would be fine as an annotation.
A good usage for annotation, for example, would be scope, since it simply
indicates where the compiler should put things, and doesn't affect types
or signatures.
To answer Don's point, there is nothing saying that the compiler can't
read attributes and change its behavior. Of course, those would have
to be builtin attributes.
Yes, but then they're just keywords, with an @ in front. You'd just be
kidding yourself if you think you've reduced the keyword count.
keywords are global, that was one of Walter's main points against adding a
keyword for properties. Since annotations necessarily have a different
syntax than normal symbols, you don't have to worry about avoiding those
words. Others have also said that adding a builtin annotation would be
easier because it doesn't affect the parser.
For the record, I'm not really keen on using annotations for *everything*
as some people have suggested. They have good uses, but I don't think
it's worth adding them until we can have full reflection capabilities so
we can get at elements of code and therefore get the annotations
associated with it. I see much more usefulness for annotations as
reflection hints than as a replacement for keywords.
-Steve
Re: property syntax strawman
On Sun, 02 Aug 2009 03:43:43 -0400, Walter Bright
newshou...@digitalmars.com wrote:
Having optional parentheses does lead to unresolvable ambiguities. How
much of a problem that really is is debatable, but let's assume it
should be resolved. To resolve it, a property must be distinguishable
from a regular function.
One way is to simply add a property attribute keyword:
property bool empty() { ... }
property void empty(bool b) { ... }
The problem is that:
1. there are a lot of keywords already
2. keywords are global things
The alternative is to have a unique syntax for properties. Ideally, the
syntax should be intuitive and mimic its use. After much fiddling, and
based on n.g. suggestions, Andrei and I penciled in:
bool empty { ... }
void empty=(bool b) { ... }
The only problem is when a declaration but not definition is desired:
bool empty;
but oops! That defines a field. So we came up with essentially a hack:
bool empty{}
i.e. the {} means the getter is declared, but defined elsewhere.
What do you think?
I stated it elsewhere, but I'll bring it up to the front.
I don't think the getter syntax is viable without parentheses, since that
precludes array properties, e.g.:
string asUpper(string s);
usage:
string s = abcde.asUpper;
It wouldn't be possible to define this as a property using your syntax,
unless you want to introduce a syntax for extending types...
-Steve
Re: DIP6: Attributes
Steven Schveighoffer wrote: For the record, I'm not really keen on using annotations for *everything* as some people have suggested. They have good uses, but I Me neither, but I think they'd be a worthy feature. Of course, there are far more pressing issues, but if Walter has time to introduce const/immutable/pure, then why not annotations? don't think it's worth adding them until we can have full reflection capabilities so we can get at elements of code and therefore get the annotations associated with it. I see much more usefulness for annotations as reflection hints than as a replacement for keywords. But we already have full reflection. It's called __traits. You can build a serialization library or proper (user friendly?) reflection on top of it.
Re: DIP6: Attributes
Kagamin wrote: grauzone Wrote: inheritance? You want to inherit annotations? What for? Backward compatibility: obtain annotation cast it, work with it, then later change its type. Annotations will be used by reflection, so classinfo will be useful. Code can do that at compiletime. No need for casting, because the tuple returned by __traits will use the correct types directly. For runtime, I have no idea. The D crowd seems to prefer compile time. We got __traits instead of more detailed TypeInfo/ClassInfo. If you want to do runtime stuff, you'll have to generate your own RTTI using compile time code.
Re: Contextualizing keywords
Jarrett Billingsley wrote: You referring to that blogger who said he was ready for languages with keywords enclosed in XML tags after seeing a D presentation? ;) No, I didn't see that one.
Re: Just a thought: read-only fields
Sergey Gromov schrieb:
Mon, 3 Aug 2009 22:04:51 -0400, Nick Sabalausky wrote:
It's been established in the recent epic-discussions on properties that one
of the biggest uses for properties is to implement publically read-only (but
privately-writable) fields. That got me thinking, why not actually have real
publically read-only fields instead of merely emulating them with
properties? They are, after all, a fairly common idiom.
// *Not* an actual syntax proposal, but just to get the idea across:
private @publicread int foo;
// The class sees it as int, but everything else sees it as const(int)
// ...or something like that...
Um... @publiconst? XD
or
private int foo;
public alias const foo foo;
or even
private public(const) int foo;
Weird... OTOH this should be trivial from the implementation POV. On
the even other hand this only worth considering if actual properties are
dropped because properties are more generic and you *can* implement a
read-only field with them. Maybe some syntactic sugar is in order if it
really is such a common thing.
Sounds good. Although I would like to keep the possibility that
functions can be used as properties because there are cases when it's
desirable. E.g:
---
class Clock {
private int sec_;
void sec(int s) {sec_ = s;}
int sec() {return sec_;}
void min(int m) {sec_ = m * 60;}
int min() {return sec_ / 60;}
}
---
Here, only the sec property has a variable but min can be called the
same way. Suppose you want to store the time in minutes later. When you
are allowed to have wrapper properties like this it's easier to change
because it looks the same from the outside. And it's more consistent, so
coders don't have to think about what property was a function and what
was a variable.
Often though, they are just trivial functions like sec here. For that
case, it is reasonable to have a shorter form.
Re: DIP6: Attributes
Tue, 04 Aug 2009 22:46:22 +1000, Daniel Keep wrote:
Sergey Gromov wrote:
Tue, 04 Aug 2009 17:22:50 +1000, Daniel Keep wrote:
Don wrote:
...
A question: in C#/Java, can you have annotations on function pointer and
delegate declarations?
void foo( int delegate(int) pure dg) {
...
}
What would this look like with annotations?
Well, Java doesn't HAVE delegates and C# doesn't (AFAIK) allow you to
define them inline; they have a special declaration syntax that can't be
used in an expression.
C#:
Listint ls;
ls.Sort((x, y) = y - x);
or
ls.Sort((x, y) = { int a; a = y; a -= x; return a; });
That's not a delegate type, that's a delegate literal.
Sorry, you said: C# doesn't ... allow you to define them (delegates)
inline. Delegate literal *is* an inline definition of a delegate.
What you say now is that C# doesn't allow to define a delegate type
inside a function which is definitely true and is very annoying.
Re: DIP6: Attributes
Sergey Gromov wrote:
Tue, 04 Aug 2009 22:46:22 +1000, Daniel Keep wrote:
Sergey Gromov wrote:
Tue, 04 Aug 2009 17:22:50 +1000, Daniel Keep wrote:
Don wrote:
...
A question: in C#/Java, can you have annotations on function pointer and
delegate declarations?
void foo( int delegate(int) pure dg) {
...
}
What would this look like with annotations?
Well, Java doesn't HAVE delegates and C# doesn't (AFAIK) allow you to
define them inline; they have a special declaration syntax that can't be
used in an expression.
C#:
Listint ls;
ls.Sort((x, y) = y - x);
or
ls.Sort((x, y) = { int a; a = y; a -= x; return a; });
That's not a delegate type, that's a delegate literal.
Sorry, you said: C# doesn't ... allow you to define them (delegates)
inline. Delegate literal *is* an inline definition of a delegate.
What you say now is that C# doesn't allow to define a delegate type
inside a function which is definitely true and is very annoying.
Have you seen the Func delegates? They are exactly for that.
The above example would be:
void foo(Funcint, int dg) { ... }
Re: DIP6: Attributes
Tue, 04 Aug 2009 11:58:27 -0300, Ary Borenszweig wrote:
Sergey Gromov wrote:
Tue, 04 Aug 2009 22:46:22 +1000, Daniel Keep wrote:
Sergey Gromov wrote:
Tue, 04 Aug 2009 17:22:50 +1000, Daniel Keep wrote:
Don wrote:
...
A question: in C#/Java, can you have annotations on function pointer and
delegate declarations?
void foo( int delegate(int) pure dg) {
...
}
What would this look like with annotations?
Well, Java doesn't HAVE delegates and C# doesn't (AFAIK) allow you to
define them inline; they have a special declaration syntax that can't be
used in an expression.
C#:
Listint ls;
ls.Sort((x, y) = y - x);
or
ls.Sort((x, y) = { int a; a = y; a -= x; return a; });
That's not a delegate type, that's a delegate literal.
Sorry, you said: C# doesn't ... allow you to define them (delegates)
inline. Delegate literal *is* an inline definition of a delegate.
What you say now is that C# doesn't allow to define a delegate type
inside a function which is definitely true and is very annoying.
Have you seen the Func delegates? They are exactly for that.
The above example would be:
void foo(Funcint, int dg) { ... }
Func defines a delegate with one argument and a non-void return. There
are lots of others like Action, Predicate, Comparator etc. which you
must either remember or look up every time you need a specific delegate
signature.
Re: DIP6: Attributes
Sergey Gromov wrote:
Tue, 04 Aug 2009 11:58:27 -0300, Ary Borenszweig wrote:
Sergey Gromov wrote:
Tue, 04 Aug 2009 22:46:22 +1000, Daniel Keep wrote:
Sergey Gromov wrote:
Tue, 04 Aug 2009 17:22:50 +1000, Daniel Keep wrote:
Don wrote:
...
A question: in C#/Java, can you have annotations on function pointer and
delegate declarations?
void foo( int delegate(int) pure dg) {
...
}
What would this look like with annotations?
Well, Java doesn't HAVE delegates and C# doesn't (AFAIK) allow you to
define them inline; they have a special declaration syntax that can't be
used in an expression.
C#:
Listint ls;
ls.Sort((x, y) = y - x);
or
ls.Sort((x, y) = { int a; a = y; a -= x; return a; });
That's not a delegate type, that's a delegate literal.
Sorry, you said: C# doesn't ... allow you to define them (delegates)
inline. Delegate literal *is* an inline definition of a delegate.
What you say now is that C# doesn't allow to define a delegate type
inside a function which is definitely true and is very annoying.
Have you seen the Func delegates? They are exactly for that.
The above example would be:
void foo(Funcint, int dg) { ... }
Func defines a delegate with one argument and a non-void return. There
are lots of others like Action, Predicate, Comparator etc. which you
must either remember or look up every time you need a specific delegate
signature.
Ah, I didn't know you can't do something like Funcvoid, int. So there
could just be two things to remember: Func and Action.
Also you have FuncT1, T2, TResult, FuncT1, T2, T3, TResult, so it's
not just one argument.
I just tried casting one delegate type to another one with the same
signature and it doesn't work. So you are right, you need to remember
Predicate, Comparator, etc. :-(
Re: reddit.com: first Chapter of TDPL available for free
The compiler allows omitting type declarations only when types can be unambiguously inferred from context. That's not exactly true, is it? A small non-negative integer literal could be an integer of any width or signedness. Yet 'int' is arbitrarily chosen for some reason. There are also multiple floating point types. My points: * The line I quoted is incorrect. Int/float literals are not unambiguous. * D literals can have a suffix specifying the exact type. Perhaps that's worth mentioning. I find your style of writing a bit too informal, though easy to read. -- Michiel Helvensteijn
Re: new DIP5: Properties 2
Kagamin wrote: Andrei Alexandrescu Wrote: I've seen a vote in which more than 50 voted. Still doesn't say anything statistically significant, but it's more than a handful. The polls miss those gave up on D. And those who will come :o). Andrei
Re: My body is ugly [Re: Contextualizing keywords]
Oliver Hoog wrote: Michiel Helvensteijn schrieb: Denis Koroskin wrote: Because a function precondition indicates the set of admissible states before execution of a function. Emphasis on *before* and *function*. Allowing them anywhere inside a function body will only improve the feature. BTW, it is already allowed, just use 'debug' instead of 'in': Or just use an assertion without an enclosing scope? The difference between a precondition (in) and an arbitrary assertion inside the function body is that the precondition is part of the public interface, whereas the function implementation is not. TBH, I'd just drop the whole DBC feature from a language, it creates more problems than solves. I, on the other hand, believe it's the future of program verification. I also find them very useful with inherited functions. That they can be inherited wouldn't be intuitive (and not as easily possible) with an 'in' block nested into the function block. And that's not even an option for interfaces that have in blocks, something not implemented. By and large, my opinion is that either we implement DbC correctly (with contract inheritance) or we drop it from the language. As of now it's completely redundant. Andrei
Re: Iterators Must Go video online
Sergey Gromov wrote: Mon, 03 Aug 2009 12:47:40 -0500, Andrei Alexandrescu wrote: A while ago I mentioned the video of my BoostCon keynote Iterators Must Go will be soon available online. Here it is: http://boostcon.blip.tv/ Andrei Nice talk! The Try THAT with iterators, @($#* ! part was especially entertaining. XD What I didn't get was why range.front is so much superior to *i. At the end of the day they're both just functions returning whatever they please. range.front could insert a cheap check for validity, i.e. assert(!empty). *i has no chance; it puts the burden of precondition on its user. Andrei
Re: DIP6: Attributes
Steven Schveighoffer wrote:
On Tue, 04 Aug 2009 09:45:51 -0400, grauzone n...@example.net wrote:
Steven Schveighoffer wrote:
don't think it's worth adding them until we can have full reflection
capabilities so we can get at elements of code and therefore get the
annotations associated with it. I see much more usefulness for
annotations as reflection hints than as a replacement for keywords.
But we already have full reflection. It's called __traits. You can
build a serialization library or proper (user friendly?) reflection
on top of it.
I think you are the 1 millionth person to say it, and yet we still do
not have a user friendly reflection system. Why is that? You'd think
that if it could be done, somebody would have done it by now.
The reality is there's quite few of us. D is not in the stage where if
something could be done, somebody somewhere has done it or is working on it.
For example, I myself didn't know about __traits(allMembers) until it
was mentioned in this group. That's why I'd defined defineEnum, which
now is a relic replaced by the appropriate mechanism, contributed to by
Shin Fujishiro.
I know exactly how to go about a reflection system, but I simply haven't
gotten around to it. Here's an initial shot: starting with std.variant,
implement a function call:
class A { int foo() { return 42; } }
...
auto v = Variant(new A);
writeln(*v.call(foo).peek!int());
That should print 42. This is eminently doable with what we have now,
and could then be extended to multiple arguments etc. with the
appropriate amount of sweat.
The way to implement this would be to use __traits(allMembers) in the
templated constructor to store a hash that maps strings to delegates.
The delegates take no argument and return Variant. During construction
you can figure which members can be invoked with no arguments by using
e.g. is(typeof(...)) and initialize the hash appropriately. In the
call() function, you look up the string and fire the delegate.
Andrei
Re: reddit.com: first Chapter of TDPL available for free
Sam Hu wrote:
Sorry for my stepping in,but as a beginner in D ,I think maybe you( all of you
experts) have interest to hear what he think after he read the book:This is
really really great!Thank you so much for your great job!
Thanks, Sam. I saved your comments and will modify the book accordingly.
To get you going:
Here a couple of questions regarding first chapter:
1.foreach (line; stdin.byLine) {
Did not mention how to read data from file *hamlet.txt* to the analyse.If I
want to run the test case,I don't know how.
You'd need to input it in the command line with , e.g. progname
hamlet.txt.
2. foreach (word; splitter(strip(line))) {
2.1 what's the purpose of splitter(strip(line)) ,I can guess a bit but not
sure;
2.2 In the first place you used split,after that you use splitter;
split() splits a string by whitespace in one operation. splitter() does
the same, but lazily - one at a time, as you go through the foreach
loop. The advantage of the latter is that it does not require temporary
storage.
3.string[] words = array(freqs.keys);
what's array? I can not find it from phobos,was I missing something?If
yes,please forgive me.
It's in std.array (added fairly recently).
4.sort!((a, b) { return freqs[a] freqs[b]; })(words);
cann't get compiled under dmd 2.031.
Walter!!!
This has worked on and off like forever. One day I'll break into
Walter's house and etch that code onto his LCD monitor.
5.abstract class IncrementalStat : Stat {...}
Why need this extra abstract class which derived from interface Stat?For class Max,Min and AVG,does't it work fine just implementing the Stat?For a beginner,it confused me a lot.I think it would be much better to explain more here.
Will do.
At the very begining,I am typing while reading to test all the impressive
examples,but very quicky I found I am lost starting at the point of my
qestion#1-4.So finally I gave up to test the example,just read.This is my
experience.
Thank you again and best regards,
Sam
Thanks, Sam.
Andrei
Re: reddit.com: first Chapter of TDPL available for free
Michiel Helvensteijn wrote: The compiler allows omitting type declarations only when types can be unambiguously inferred from context. That's not exactly true, is it? A small non-negative integer literal could be an integer of any width or signedness. Yet 'int' is arbitrarily chosen for some reason. There are also multiple floating point types. My points: * The line I quoted is incorrect. Int/float literals are not unambiguous. * D literals can have a suffix specifying the exact type. Perhaps that's worth mentioning. Thanks for your comments, I added them to my todo list. I find your style of writing a bit too informal, though easy to read. I swear I was trying to keep wit down. (I mean if I'm left to my own devices... The Case for D.) One very real problem I'm now experiencing is that I need to literally write a doctoral thesis at day and a book at night. It's often difficult to handle the swing between the required styles. On the upside, heck, I think the dissertation will turn out to be one of the more readable ones :o). Andrei
Re: DIP6: Attributes
On Tue, 04 Aug 2009 12:23:41 -0400, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: Steven Schveighoffer wrote: On Tue, 04 Aug 2009 09:45:51 -0400, grauzone n...@example.net wrote: Steven Schveighoffer wrote: don't think it's worth adding them until we can have full reflection capabilities so we can get at elements of code and therefore get the annotations associated with it. I see much more usefulness for annotations as reflection hints than as a replacement for keywords. But we already have full reflection. It's called __traits. You can build a serialization library or proper (user friendly?) reflection on top of it. I think you are the 1 millionth person to say it, and yet we still do not have a user friendly reflection system. Why is that? You'd think that if it could be done, somebody would have done it by now. The reality is there's quite few of us. D is not in the stage where if something could be done, somebody somewhere has done it or is working on it. That's understandable, nobody can expect a language as young as D to have everything. But in reality, I think the *theory* that everything is there to build a reflection system is only proven when it actually happens. I'm sure when the enterprising person or persons go to develop it, they will find pieces missing from the static reflection system. So my point is that adding annotations before reflection works and is implemented makes little sense to me, because the usage of them will be crippled by the fact that reflection isn't complete. What I'd like to see is something like this possible: void foo (int timeout, string bar, float f = 4.0); void foo(int timeout); call!(foo)(timeout=5,bar=\hello\); Taking into account the default value of f, what the parameters are named, and which overload to call. I could certainly do it with C#. -Steve
Re: reddit.com: first Chapter of TDPL available for free
Andrei Alexandrescu Wrote: KennyTM~ wrote: Andrei Alexandrescu wrote: http://www.reddit.com/r/programming/comments/975ng/diving_into_the_d_programming_language_tdpl/ (Don't tell anyone, but I plan to rewrite it.) Andrei What's a so-called IEEE 754 double-extended 79-bit format? :p Heck, I didn't know until I googled for it! BTW folks, please please vote the reddit link up. It's a simple and effective way to increase exposure to D and grow the community. http://www.reddit.com/r/programming/comments/975ng/diving_into_the_d_programming_language_tdpl/ Andrei And I always thought it was double-extended 80-bit. The IEEE standard actually specifies = 79 bits and Intel implements it as 80bits. Well you learn something new everyday!
Re: DIP6: Attributes
Steven Schveighoffer wrote: On Tue, 04 Aug 2009 12:23:41 -0400, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: Steven Schveighoffer wrote: On Tue, 04 Aug 2009 09:45:51 -0400, grauzone n...@example.net wrote: Steven Schveighoffer wrote: don't think it's worth adding them until we can have full reflection capabilities so we can get at elements of code and therefore get the annotations associated with it. I see much more usefulness for annotations as reflection hints than as a replacement for keywords. But we already have full reflection. It's called __traits. You can build a serialization library or proper (user friendly?) reflection on top of it. I think you are the 1 millionth person to say it, and yet we still do not have a user friendly reflection system. Why is that? You'd think that if it could be done, somebody would have done it by now. The reality is there's quite few of us. D is not in the stage where if something could be done, somebody somewhere has done it or is working on it. That's understandable, nobody can expect a language as young as D to have everything. But in reality, I think the *theory* that everything is there to build a reflection system is only proven when it actually happens. I'm sure when the enterprising person or persons go to develop it, they will find pieces missing from the static reflection system. Exactly. I'm absolutely sure there are quite a few things needed here and there. I can assure you I'll push hard for those. So my point is that adding annotations before reflection works and is implemented makes little sense to me, because the usage of them will be crippled by the fact that reflection isn't complete. What I'd like to see is something like this possible: void foo (int timeout, string bar, float f = 4.0); void foo(int timeout); call!(foo)(timeout=5,bar=\hello\); Taking into account the default value of f, what the parameters are named, and which overload to call. I could certainly do it with C#. This is interesting. It means we'd need reflection for parameter names, which currently does not exist. Andrei
Re: reddit.com: first Chapter of TDPL available for free
Jeremie Pelletier: And I always thought it was double-extended 80-bit. The IEEE standard actually specifies = 79 bits and Intel implements it as 80bits. But it seems there are weird differences across operating systems regarding how much memory is allocated to represent such numbers, like 10, 12, 16 bytes on Windows, Linux, Mac (this comes from something Walter said when he has adapted DMD to the other OSs). Do you know why they have chosen different solutions regarding something so basic? (I don't even want to talk about the stupid endianess of CPUs). Bye, bearophile
Re: DIP6: Attributes
Andrei Alexandrescu wrote: Steven Schveighoffer wrote: On Tue, 04 Aug 2009 12:23:41 -0400, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: Steven Schveighoffer wrote: On Tue, 04 Aug 2009 09:45:51 -0400, grauzone n...@example.net wrote: Steven Schveighoffer wrote: don't think it's worth adding them until we can have full reflection capabilities so we can get at elements of code and therefore get the annotations associated with it. I see much more usefulness for annotations as reflection hints than as a replacement for keywords. But we already have full reflection. It's called __traits. You can build a serialization library or proper (user friendly?) reflection on top of it. I think you are the 1 millionth person to say it, and yet we still do not have a user friendly reflection system. Why is that? You'd think that if it could be done, somebody would have done it by now. The reality is there's quite few of us. D is not in the stage where if something could be done, somebody somewhere has done it or is working on it. That's understandable, nobody can expect a language as young as D to have everything. But in reality, I think the *theory* that everything is there to build a reflection system is only proven when it actually happens. I'm sure when the enterprising person or persons go to develop it, they will find pieces missing from the static reflection system. Exactly. I'm absolutely sure there are quite a few things needed here and there. I can assure you I'll push hard for those. So my point is that adding annotations before reflection works and is implemented makes little sense to me, because the usage of them will be crippled by the fact that reflection isn't complete. What I'd like to see is something like this possible: void foo (int timeout, string bar, float f = 4.0); void foo(int timeout); call!(foo)(timeout=5,bar=\hello\); Taking into account the default value of f, what the parameters are named, and which overload to call. I could certainly do it with C#. This is interesting. It means we'd need reflection for parameter names, which currently does not exist. Why do it with strings? Why not call!(foo)(5, hello) with varaidic args?
Re: DIP6: Attributes
On Tue, 04 Aug 2009 13:44:46 -0400, Ary Borenszweig a...@esperanto.org.ar wrote: Andrei Alexandrescu wrote: Steven Schveighoffer wrote: What I'd like to see is something like this possible: void foo (int timeout, string bar, float f = 4.0); void foo(int timeout); call!(foo)(timeout=5,bar=\hello\); Taking into account the default value of f, what the parameters are named, and which overload to call. I could certainly do it with C#. This is interesting. It means we'd need reflection for parameter names, which currently does not exist. Why do it with strings? Why not call!(foo)(5, hello) with varaidic args? Ok, say foo is: void foo(string bar, int timeout) -Steve
Re: Just a thought: read-only fields
Reply to Nick, It's been established in the recent epic-discussions on properties that one of the biggest uses for properties is to implement publically read-only (but privately-writable) fields. That got me thinking, why not actually have real publically read-only fields instead of merely emulating them with properties? They are, after all, a fairly common idiom. // *Not* an actual syntax proposal, but just to get the idea across: private @publicread int foo; // The class sees it as int, but everything else sees it as const(int) // ...or something like that... how about this for a syntax: private int i; alias public const i;
Re: DIP6: Attributes
Steven Schveighoffer wrote: On Tue, 04 Aug 2009 13:44:46 -0400, Ary Borenszweig a...@esperanto.org.ar wrote: Andrei Alexandrescu wrote: Steven Schveighoffer wrote: What I'd like to see is something like this possible: void foo (int timeout, string bar, float f = 4.0); void foo(int timeout); call!(foo)(timeout=5,bar=\hello\); Taking into account the default value of f, what the parameters are named, and which overload to call. I could certainly do it with C#. This is interesting. It means we'd need reflection for parameter names, which currently does not exist. Why do it with strings? Why not call!(foo)(5, hello) with varaidic args? Ok, say foo is: void foo(string bar, int timeout) What's the difference?
Re: DIP6: Attributes
On Tue, 04 Aug 2009 14:46:34 -0400, Ary Borenszweig a...@esperanto.org.ar wrote: Steven Schveighoffer wrote: On Tue, 04 Aug 2009 13:44:46 -0400, Ary Borenszweig a...@esperanto.org.ar wrote: Andrei Alexandrescu wrote: Steven Schveighoffer wrote: What I'd like to see is something like this possible: void foo (int timeout, string bar, float f = 4.0); void foo(int timeout); call!(foo)(timeout=5,bar=\hello\); Taking into account the default value of f, what the parameters are named, and which overload to call. I could certainly do it with C#. This is interesting. It means we'd need reflection for parameter names, which currently does not exist. Why do it with strings? Why not call!(foo)(5, hello) with varaidic args? Ok, say foo is: void foo(string bar, int timeout) What's the difference? The difference is, I'm saying I want to call foo with parameters identified by parameter name, not parameter order. -Steve
Re: DIP6: Attributes
Andrei Alexandrescu schrieb: Ary Borenszweig wrote: call!(foo)(5, hello) with varaidic args? Well some don't like to need to remember the order of arguments. Andrei Assigning the argument by name instead of order has two other benefits, i can think of... 1. on the call side, it is documented for what the given values are used. 2. it may be possible to let all parameters have default values and for example just give a value for the last parameter. This is not possible with just the parameter order.
Re: DIP6: Attributes
Andrei Alexandrescu wrote:
Ary Borenszweig wrote:
Andrei Alexandrescu wrote:
Steven Schveighoffer wrote:
On Tue, 04 Aug 2009 12:23:41 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Steven Schveighoffer wrote:
On Tue, 04 Aug 2009 09:45:51 -0400, grauzone n...@example.net
wrote:
Steven Schveighoffer wrote:
don't think it's worth adding them until we can have full
reflection capabilities so we can get at elements of code and
therefore get the annotations associated with it. I see much
more usefulness for annotations as reflection hints than as a
replacement for keywords.
But we already have full reflection. It's called __traits. You
can build a serialization library or proper (user friendly?)
reflection on top of it.
I think you are the 1 millionth person to say it, and yet we
still do not have a user friendly reflection system. Why is
that? You'd think that if it could be done, somebody would have
done it by now.
The reality is there's quite few of us. D is not in the stage where
if something could be done, somebody somewhere has done it or is
working on it.
That's understandable, nobody can expect a language as young as D to
have everything.
But in reality, I think the *theory* that everything is there to
build a reflection system is only proven when it actually happens.
I'm sure when the enterprising person or persons go to develop it,
they will find pieces missing from the static reflection system.
Exactly. I'm absolutely sure there are quite a few things needed here
and there. I can assure you I'll push hard for those.
So my point is that adding annotations before reflection works and
is implemented makes little sense to me, because the usage of them
will be crippled by the fact that reflection isn't complete.
What I'd like to see is something like this possible:
void foo (int timeout, string bar, float f = 4.0);
void foo(int timeout);
call!(foo)(timeout=5,bar=\hello\);
Taking into account the default value of f, what the parameters are
named, and which overload to call. I could certainly do it with C#.
This is interesting. It means we'd need reflection for parameter
names, which currently does not exist.
Why do it with strings? Why not
call!(foo)(5, hello)
with varaidic args?
Well some don't like to need to remember the order of arguments.
But that's a way totally different thing discussed here.
First you need to introduce argument names when invoking a function.
void foo(int timeout, string bar) {
..
}
Can be used as:
foo(timeout=5, bar=100)
(with some other syntax, of course)
Once you have that, you could do:
call!(foo)(timeout=5, bar=100)
Voilà!
Re: DIP6: Attributes
Ary Borenszweig wrote: Andrei Alexandrescu wrote: Ary Borenszweig wrote: Andrei Alexandrescu wrote: Steven Schveighoffer wrote: On Tue, 04 Aug 2009 12:23:41 -0400, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: Steven Schveighoffer wrote: On Tue, 04 Aug 2009 09:45:51 -0400, grauzone n...@example.net wrote: Steven Schveighoffer wrote: don't think it's worth adding them until we can have full reflection capabilities so we can get at elements of code and therefore get the annotations associated with it. I see much more usefulness for annotations as reflection hints than as a replacement for keywords. But we already have full reflection. It's called __traits. You can build a serialization library or proper (user friendly?) reflection on top of it. I think you are the 1 millionth person to say it, and yet we still do not have a user friendly reflection system. Why is that? You'd think that if it could be done, somebody would have done it by now. The reality is there's quite few of us. D is not in the stage where if something could be done, somebody somewhere has done it or is working on it. That's understandable, nobody can expect a language as young as D to have everything. But in reality, I think the *theory* that everything is there to build a reflection system is only proven when it actually happens. I'm sure when the enterprising person or persons go to develop it, they will find pieces missing from the static reflection system. Exactly. I'm absolutely sure there are quite a few things needed here and there. I can assure you I'll push hard for those. So my point is that adding annotations before reflection works and is implemented makes little sense to me, because the usage of them will be crippled by the fact that reflection isn't complete. What I'd like to see is something like this possible: void foo (int timeout, string bar, float f = 4.0); void foo(int timeout); call!(foo)(timeout=5,bar=\hello\); Taking into account the default value of f, what the parameters are named, and which overload to call. I could certainly do it with C#. This is interesting. It means we'd need reflection for parameter names, which currently does not exist. Why do it with strings? Why not call!(foo)(5, hello) with varaidic args? Well some don't like to need to remember the order of arguments. But that's a way totally different thing discussed here. Sorry, not totally different. What I'm saying is: one thing at a time.
Re: DIP6: Attributes
On Tue, 04 Aug 2009 15:56:16 -0400, Ary Borenszweig a...@esperanto.org.ar
wrote:
Andrei Alexandrescu wrote:
Well some don't like to need to remember the order of arguments.
But that's a way totally different thing discussed here.
First you need to introduce argument names when invoking a function.
void foo(int timeout, string bar) {
..
}
Can be used as:
foo(timeout=5, bar=100)
(with some other syntax, of course)
Once you have that, you could do:
call!(foo)(timeout=5, bar=100)
Voilà!
It could also be accomplished via a fully implemented reflection library,
which is my side topic for this thread branch :P
For instance you could do this exact thing in C#, even though C# doesn't
support named parameters.
-Steve
Re: DIP6: Attributes
Steven Schveighoffer wrote:
On Tue, 04 Aug 2009 15:56:16 -0400, Ary Borenszweig
a...@esperanto.org.ar wrote:
Andrei Alexandrescu wrote:
Well some don't like to need to remember the order of arguments.
But that's a way totally different thing discussed here.
First you need to introduce argument names when invoking a function.
void foo(int timeout, string bar) {
..
}
Can be used as:
foo(timeout=5, bar=100)
(with some other syntax, of course)
Once you have that, you could do:
call!(foo)(timeout=5, bar=100)
Voilà!
It could also be accomplished via a fully implemented reflection
library, which is my side topic for this thread branch :P
For instance you could do this exact thing in C#, even though C# doesn't
support named parameters.
Aaah... I see now. :)
Re: DIP6: Attributes
Steven Schveighoffer wrote: On Tue, 04 Aug 2009 15:56:16 -0400, Ary Borenszweig a...@esperanto.org.ar wrote: foo(timeout=5, bar=100) It could also be accomplished via a fully implemented reflection library, which is my side topic for this thread branch :P No. The names of positional arguments are an implementation detail, and should not be exposed via reflection. Named arguments are different from positional arguments and require separate language support. Consider the ambiguity caused by function overloading: void f(int x, string y); void f(string y, int x); f(x = 1, y = ); Consider the implications of function pointers: void f(int x, int y); void g(int y, int x); (cond ? f : g)(x = 1, y = 2); -- Rainer Deyke - rain...@eldwood.com
Re: DIP6: Attributes
Steven Schveighoffer wrote: For instance you could do this exact thing in C#, even though C# doesn't support named parameters. But they're coming: http://msdn.microsoft.com/en-us/library/dd264739(VS.100).aspx
Re: DIP6: Attributes
On 8/4/09 18:55, Steven Schveighoffer wrote: On Tue, 04 Aug 2009 12:23:41 -0400, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: Steven Schveighoffer wrote: On Tue, 04 Aug 2009 09:45:51 -0400, grauzone n...@example.net wrote: Steven Schveighoffer wrote: don't think it's worth adding them until we can have full reflection capabilities so we can get at elements of code and therefore get the annotations associated with it. I see much more usefulness for annotations as reflection hints than as a replacement for keywords. But we already have full reflection. It's called __traits. You can build a serialization library or proper (user friendly?) reflection on top of it. I think you are the 1 millionth person to say it, and yet we still do not have a user friendly reflection system. Why is that? You'd think that if it could be done, somebody would have done it by now. The reality is there's quite few of us. D is not in the stage where if something could be done, somebody somewhere has done it or is working on it. That's understandable, nobody can expect a language as young as D to have everything. But in reality, I think the *theory* that everything is there to build a reflection system is only proven when it actually happens. I'm sure when the enterprising person or persons go to develop it, they will find pieces missing from the static reflection system. So my point is that adding annotations before reflection works and is implemented makes little sense to me, because the usage of them will be crippled by the fact that reflection isn't complete. What I'd like to see is something like this possible: void foo (int timeout, string bar, float f = 4.0); void foo(int timeout); call!(foo)(timeout=5,bar=\hello\); Taking into account the default value of f, what the parameters are named, and which overload to call. I could certainly do it with C#. -Steve You mean like this: http://tango.pastebin.com/m129241b0 ? /Jacob Carlborg
Re: DIP6: Attributes
On 8/5/09 00:22, Jacob Carlborg wrote: On 8/4/09 18:55, Steven Schveighoffer wrote: On Tue, 04 Aug 2009 12:23:41 -0400, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: Steven Schveighoffer wrote: On Tue, 04 Aug 2009 09:45:51 -0400, grauzone n...@example.net wrote: Steven Schveighoffer wrote: don't think it's worth adding them until we can have full reflection capabilities so we can get at elements of code and therefore get the annotations associated with it. I see much more usefulness for annotations as reflection hints than as a replacement for keywords. But we already have full reflection. It's called __traits. You can build a serialization library or proper (user friendly?) reflection on top of it. I think you are the 1 millionth person to say it, and yet we still do not have a user friendly reflection system. Why is that? You'd think that if it could be done, somebody would have done it by now. The reality is there's quite few of us. D is not in the stage where if something could be done, somebody somewhere has done it or is working on it. That's understandable, nobody can expect a language as young as D to have everything. But in reality, I think the *theory* that everything is there to build a reflection system is only proven when it actually happens. I'm sure when the enterprising person or persons go to develop it, they will find pieces missing from the static reflection system. So my point is that adding annotations before reflection works and is implemented makes little sense to me, because the usage of them will be crippled by the fact that reflection isn't complete. What I'd like to see is something like this possible: void foo (int timeout, string bar, float f = 4.0); void foo(int timeout); call!(foo)(timeout=5,bar=\hello\); Taking into account the default value of f, what the parameters are named, and which overload to call. I could certainly do it with C#. -Steve You mean like this: http://tango.pastebin.com/m129241b0 ? /Jacob Carlborg Forgot to say: this works in D1 with dmd, gdc and ldc. /Jacob Carlborg
Re: The XML module in Phobos
On 2009-08-04 10:01:51 -0400, Michael Rynn michaelr...@optushome.com.au said: It would be nice to have well defined interfaces for DOM, SAX and PULL parsers which share some of the base parsing code. The DOM can be partial, as node sets returned from XPath query. Nice how the phobos parser can make a full DOM or just the bits required. Exactly what I've been working on: Tokenizer part: http://michelf.com/docs/d/mfr/xmltok.html DOM part: http://michelf.com/docs/d/mfr/xml.html Note that it's still a work in progress. Here are some things I'd like to do: tokenizer: add specialized exception classes to better report various problems, add better checks for valid characters (should be optional), better support for ranges (currently only string because I rely on a.before(b) to avoid dynamic allocation), also add support for the internal subset in the doctype (but that's low priority). Writer: replace by a simple template function and a toString function defined for each token type? or a writeTo function (to avoid creating a intermediary string)? XMLForwardRange: allow a template parameter specifying the token types you want to see, skipping all others. This could be done by passing a custom Algebraic type instead of the provided one what can contain all tokens. DOM classes: it's mostly experimental for now. There's no SAX yet, although it should be trivial to add over the existing callback tokenizer. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: DIP6: Attributes
On Tue, 04 Aug 2009 17:20:53 -0400, Rainer Deyke rain...@eldwood.com wrote: Steven Schveighoffer wrote: On Tue, 04 Aug 2009 15:56:16 -0400, Ary Borenszweig a...@esperanto.org.ar wrote: foo(timeout=5, bar=100) It could also be accomplished via a fully implemented reflection library, which is my side topic for this thread branch :P No. The names of positional arguments are an implementation detail, and should not be exposed via reflection. Named arguments are different from positional arguments and require separate language support. It works. See http://msdn.microsoft.com/en-us/library/system.reflection.parameterinfo.name.aspx Consider the ambiguity caused by function overloading: void f(int x, string y); void f(string y, int x); f(x = 1, y = ); That is a case where the proposed function would throw an exception. Consider the implications of function pointers: void f(int x, int y); void g(int y, int x); (cond ? f : g)(x = 1, y = 2); I don't see what this has to do with reflection... -Steve
Naming things in Phobos - std.algorithm and writefln
In std.algorithm, wouldn't it be clearer if splitter was called splitLazily or splitLazy? splitter is a noun, but as a function shouldn't it be a verb. makeSplitter or toSplitter perhaps? And what about the array function? Wouldn't it be clearer if it was toArray so we know we're preforming a convertion? As you know, I tried to write some guidelines[1] for naming things in D. Those guidelines looks well at first glance, but then you look at Phobos and you see that half of it use some arbitrary naming rules. Take writefln for instance: following my guidelines (as they are currently written) it should be renamed to something like writeFormattedLine. [1]: http://prowiki.org/wiki4d/wiki.cgi?DProgrammingGuidelines I don't necessarily want to change every function name, but if we want this document to make sense and Phobos to have some uniformity, both should be harmonized. Phobos should give the example and follow the guidelines and the guidelines should match Phobos, otherwise the guidelines have no weight for developers of other libraries and Phobos will make life harder to those who want to follow them. For names we don't want to follow the guidelines, there should be some documentation explaining what rule they disobey and why. I could take a look at std.algorithm and other modules in Phobos to list inconsistencies with the guidelines. From this we could make improvements both to the guideline document and the API. But before going too deep I think we should start with a few examples, such as those above, and see what to do with them. What does everyone thinks about all this? -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: DIP6: Attributes
Frank Benoit wrote: Andrei Alexandrescu schrieb: Ary Borenszweig wrote: call!(foo)(5, hello) with varaidic args? Well some don't like to need to remember the order of arguments. Andrei Assigning the argument by name instead of order has two other benefits, i can think of... 1. on the call side, it is documented for what the given values are used. 2. it may be possible to let all parameters have default values and for example just give a value for the last parameter. This is not possible with just the parameter order. But these aren't issues with reflection. These are just the same function calling rules applied elsewhere in the language: 1) If you want to call a function: you must know its name. 2) If you want to pass parameters: you must know the correct order. I can't imagine a circumstance where someone uses reflection to call a function and knows how to create the correct set of arguments, but doesn't know what order to put them in. --benji
Re: Shared Object with DMD v2.031
Sun, 2 Aug 2009 11:18:24 + (UTC), teo wrote: On Sun, 02 Aug 2009 02:18:28 +0400, Sergey Gromov wrote: My guess is that test.di is exactly the same as test.d because all the functions are small. Therefore compiling 'dmd prog.d test.di' resolves all symbols statically and the .so is simply not linked. Does your 'prog' have any unresolved symbols in its symbol table? It looks like this is the case. I found following in the symbols: 0804b8cc T _D4test6testMeFZi 0804b8d8 T _D4test9testClassFiZC4test4Test The whole nm output is too long, but if you want I can send it to you. When I use the *--undefined-only* option I get: $ nm -u prog [snip] All unresolved symbols seem to be in glibc. I've filed a bug: http://d.puremagic.com/issues/show_bug.cgi?id=3226
At compile time
D2 is now able to execute math functions (sin, cos, sqrt, etc) at compile time.
This little C++ program compiles correctly with G++:
// C++ code
#include math.h
#include stdio.h
struct V3 {
double x, y, z;
V3(const double a, const double b, const double c) : x(a), y(b), z(c) {}
V3 operator*(const double d) const { return V3(x * d, y * d, z * d); }
V3 norm() const { return *this * (1.0 / sqrt(magsqr())); }
double dot(const V3 v) const { return x * v.x+y * v.y + z * v.z; }
double magsqr() const { return dot(*this); }
};
const V3 v(V3(-0.5, -0.65, 0.9).norm());
int main() {
printf(%f %f %f\n, v.x, v.y, v.z);
return 0;
}
But similar D2 program produces, with DMD v.2.031:
test.d(12): Error: non-constant expression (V3(1,2,3)).norm()
// D2 code
import std.math, std.c.stdio;
struct V3 {
double x, y, z;
V3 opMul(double d) { return V3(x * d, y * d, z * d); }
V3 norm() { return this * (1.0 / sqrt(this.magsqr())); }
double dot(ref V3 v) { return x * v.x+y * v.y + z * v.z; }
double magsqr() { return dot(this); }
}
const V3 v = V3(1.0, 2.0, 3.0).norm();
int main() {
printf(%f %f %f\n, v.x, v.y, v.z);
return 0;
}
Do you know why?
Can the D2 compiler modified/improved to allow this?
Bye and thank you,
bearophile
Re: At compile time
On Tue, Aug 4, 2009 at 7:57 PM, bearophilebearophileh...@lycos.com wrote:
D2 is now able to execute math functions (sin, cos, sqrt, etc) at compile
time.
This little C++ program compiles correctly with G++:
// C++ code
#include math.h
#include stdio.h
struct V3 {
double x, y, z;
V3(const double a, const double b, const double c) : x(a), y(b), z(c) {}
V3 operator*(const double d) const { return V3(x * d, y * d, z * d); }
V3 norm() const { return *this * (1.0 / sqrt(magsqr())); }
double dot(const V3 v) const { return x * v.x+y * v.y + z * v.z; }
double magsqr() const { return dot(*this); }
};
const V3 v(V3(-0.5, -0.65, 0.9).norm());
int main() {
printf(%f %f %f\n, v.x, v.y, v.z);
return 0;
}
But similar D2 program produces, with DMD v.2.031:
test.d(12): Error: non-constant expression (V3(1,2,3)).norm()
// D2 code
import std.math, std.c.stdio;
struct V3 {
double x, y, z;
V3 opMul(double d) { return V3(x * d, y * d, z * d); }
V3 norm() { return this * (1.0 / sqrt(this.magsqr())); }
double dot(ref V3 v) { return x * v.x+y * v.y + z * v.z; }
double magsqr() { return dot(this); }
}
const V3 v = V3(1.0, 2.0, 3.0).norm();
int main() {
printf(%f %f %f\n, v.x, v.y, v.z);
return 0;
}
Do you know why?
I don't think you can call struct methods at compile-time. Kind of
lame, I know. Try making norm a free function.
Can the D2 compiler modified/improved to allow this?
It sure would be nice.
Re: At compile time
Jarrett Billingsley: I don't think you can call struct methods at compile-time. Kind of lame, I know. Try making norm a free function. I see. It's a significant limitation, that curiously G++ doesn't share. I have tried to follow your suggestion, but so far with not too much luck, even essentially pulling out all methods of that struct :-) Thank you, bye, bearophile
Re: At compile time
On Tue, Aug 4, 2009 at 10:13 PM, bearophilebearophileh...@lycos.com wrote:
Jarrett Billingsley:
I don't think you can call struct methods at compile-time. Kind of
lame, I know. Try making norm a free function.
I see. It's a significant limitation, that curiously G++ doesn't share.
I don't think your C++ code is doing what you think it's doing. I'm
pretty sure the C++ code:
const V3 v(V3(-0.5, -0.65, 0.9).norm());
is equivalent to the following D code:
const V3 v;
static this() { v = V3(-0.5, -0.65, 0.9).norm(); }
C++ has static initialization that occurs before main() too. It's
just.. hidden.
[Issue 3224] New: std.random documentation bugs
http://d.puremagic.com/issues/show_bug.cgi?id=3224 Summary: std.random documentation bugs Product: D Version: future Platform: All OS/Version: All Status: NEW Keywords: spec Severity: normal Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: k...@kmonos.net struct LinearCongruentialEngine(UIntType,UIntType a,UIntType c,UIntType m); bool empty; Always true (random generators are infinite ranges). should be Always false alias MinstdRand0; alias MinstdRand; Example: // seed with a constant auto rnd0 = MinstdRand0(1); auto n = rnd0.popFront; // same for each run // Seed with an unpredictable value rnd0.seed(unpredictableSeed); n = rnd0.popFront; // different across runs should call .front, instead of .popFront (twice). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3224] std.random documentation bugs
http://d.puremagic.com/issues/show_bug.cgi?id=3224 Andrei Alexandrescu and...@metalanguage.com changed: What|Removed |Added Status|NEW |ASSIGNED CC||and...@metalanguage.com AssignedTo|nob...@puremagic.com|and...@metalanguage.com -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2697] [DMC too] Cast of float function return to ulong or uint gives bogus value
http://d.puremagic.com/issues/show_bug.cgi?id=2697 --- Comment #4 from Don clugd...@yahoo.com.au 2009-08-04 00:27:08 PDT --- The evil is done in cdcnvt() in cod4.c, just after this bit... case OPf_d: case OPd_f: /* if won't do us much good to transfer back and*/ /* forth between 8088 registers and 8087 registers*/ So it elides the conversion. This comment, and the transformation it performs, is false in the case where the OPf_d is followed a conversion from double to uint or ulong (OPd_u32 or OPd_u64). This is because the C functions which perform the conversion expect the double to be in EDX:EAX: ie, it genuinely needs to be converted to double. Conversions from float to uint work on Linux because a different function is called, which expects the double to be passed in ST0. They work on DMC Windows because the conversion gets inlined. Before presenting a patch, I'd like to make sure that there aren't any other failing cases. Could someone please check whether conversions from float to ulong work on Linux? (I'm surprised by the comment that it works on Linux, I would expect it to fail). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2697] [DMC too] Cast of float function return to ulong or uint gives bogus value
http://d.puremagic.com/issues/show_bug.cgi?id=2697 Lars T. Kyllingstad bugzi...@kyllingen.net changed: What|Removed |Added CC||bugzi...@kyllingen.net --- Comment #5 from Lars T. Kyllingstad bugzi...@kyllingen.net 2009-08-04 01:14:48 PDT --- This is the output I get from running Stewart's program with DMD 2.031 on Linux (64-bit, although since DMD is 32-bit it probably doesn't matter): float: 5.00 ulong: 9223372036854775808 long: 5 uint: 5 int:5 ushort: 5 short: 5 ubyte: 5 byte: 5 float: 5.00 ulong: 5 long: 5 uint: 5 int:5 ushort: 5 short: 5 ubyte: 5 byte: 5 As you suspected, float-uint works, while float-ulong fails. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2697] [DMC too] Cast of float function return to ulong or uint gives bogus value
http://d.puremagic.com/issues/show_bug.cgi?id=2697 --- Comment #6 from Don clugd...@yahoo.com.au 2009-08-04 01:48:40 PDT --- (In reply to comment #5) This is the output I get from running Stewart's program with DMD 2.031 on Linux As you suspected, float-uint works, while float-ulong fails. Awesome! There's several ways to fix this, I'm not sure which is the best. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2702] Declaring struct, assigning rvalue via opAssign in same statement fails silently
http://d.puremagic.com/issues/show_bug.cgi?id=2702 Don clugd...@yahoo.com.au changed: What|Removed |Added CC||clugd...@yahoo.com.au --- Comment #1 from Don clugd...@yahoo.com.au 2009-08-04 02:22:05 PDT --- I think this is invalid. Bar bar=1; is a construction, not an assignment. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2152] Parentheses usage inconsistency.
http://d.puremagic.com/issues/show_bug.cgi?id=2152
Rob Jacques sandf...@jhu.edu changed:
What|Removed |Added
CC||sandf...@jhu.edu
--- Comment #2 from Rob Jacques sandf...@jhu.edu 2009-08-04 05:48:49 PDT ---
This seems releated to Issue 2409. Also another use case:
void delegate(int) func();
void main() {
func(1);
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 2409] property is not called
http://d.puremagic.com/issues/show_bug.cgi?id=2409
Rob Jacques sandf...@jhu.edu changed:
What|Removed |Added
CC||sandf...@jhu.edu
--- Comment #1 from Rob Jacques sandf...@jhu.edu 2009-08-04 05:47:08 PDT ---
Another similar use case:
void delegate(int) func();
void main() {
func(1);
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 2282] Struct copy-constructor should call opAssign
http://d.puremagic.com/issues/show_bug.cgi?id=2282 Don clugd...@yahoo.com.au changed: What|Removed |Added Keywords|wrong-code | CC||clugd...@yahoo.com.au Severity|normal |enhancement --- Comment #1 from Don clugd...@yahoo.com.au 2009-08-04 06:44:30 PDT --- This behaviour is by design. I'm marking it as an enhancement, but it should probably be closed as invalid. It's definitely not a wrong-code bug. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1084] lazy variadic parameters break in strange way
http://d.puremagic.com/issues/show_bug.cgi?id=1084 Don clugd...@yahoo.com.au changed: What|Removed |Added Keywords|wrong-code |accepts-invalid CC||clugd...@yahoo.com.au --- Comment #3 from Don clugd...@yahoo.com.au 2009-08-04 07:31:14 PDT --- This isn't wrong-code, the bug is in the user's code. Changing to accepts-invalid. (Perhaps lazy []... should be illegal?) On DMD2, it displays: bug(12): Error: escaping reference to local __arrayArg502 So it's a D1-only issue. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3225] std.string function name casing
http://d.puremagic.com/issues/show_bug.cgi?id=3225 Andrei Alexandrescu and...@metalanguage.com changed: What|Removed |Added Status|NEW |ASSIGNED CC||and...@metalanguage.com AssignedTo|nob...@puremagic.com|and...@metalanguage.com --- Comment #1 from Andrei Alexandrescu and...@metalanguage.com 2009-08-04 09:33:38 PDT --- thanks -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
