Re: How initialize a static rectangular array (2-d matrix)
Jarrett Billingsley Wrote: > Bahahaha, oh comma exps. Their usage will need to be quite regulated in D (using them for smarter purposes is a cute idea, but it may impair C compatibility). Bye, bearophile
Re: How initialize a static rectangular array (2-d matrix)
On Thu, Oct 8, 2009 at 10:05 PM, Christopher Wright wrote: > Justin Johansson wrote: >> >> Jarrett Billingsley Wrote: >> >>> On Thu, Oct 8, 2009 at 8:10 PM, Justin Johansson wrote: I almost have to apologize for this question but .. How does one initialize a static rectangular array (2-d matrix) in D1? None of the following or other variations that I've tried compile with DMD 1.0. int[2, 3] matrix = [ 1, 2, 3, 4, 5, 6 ]; >>> >>> ..that's not how you declare a rectangular array type. It's int[3][2]. >>> >>> int[3][2] matrix = [[1, 2, 3], [4, 5, 6]]; >> >> Thanks Jarrett. >> >> Am I having a blonde day? >> >> int[2,3] m = [ 1, 2, 3 ]; writefln( "m=%s, .sizeof=%d", m, m.sizeof); >> >> Compiles and prints: >> >> m=[1,2,3], .sizeof=12 >> >> So what does that declaration, int[2,3], mean? >> >> Think this is what threw me initially. >> >> Thanks, Justin > > 2,3 is a comma expression. Evaluate everything, and return the rightmost > value. > Bahahaha, oh comma exps.
Re: How initialize a static rectangular array (2-d matrix)
Justin Johansson wrote: > Jarrett Billingsley Wrote: > >> On Thu, Oct 8, 2009 at 8:10 PM, Justin Johansson wrote: > > Thanks Jarrett. > > Am I having a blonde day? > >int[2,3] m = [ 1, 2, 3 ]; >writefln( "m=%s, .sizeof=%d", m, m.sizeof); > > Compiles and prints: > > m=[1,2,3], .sizeof=12 > > So what does that declaration, int[2,3], mean? > > Think this is what threw me initially. > > Thanks, Justin > It probably means DMD isn't doing enough validation checking. Comma expression, hence typeof(m) is int[3], m.sizeof is 3 * int.sizeof
Re: How initialize a static rectangular array (2-d matrix)
Justin Johansson wrote: Jarrett Billingsley Wrote: On Thu, Oct 8, 2009 at 8:10 PM, Justin Johansson wrote: I almost have to apologize for this question but .. How does one initialize a static rectangular array (2-d matrix) in D1? None of the following or other variations that I've tried compile with DMD 1.0. int[2, 3] matrix = [ 1, 2, 3, 4, 5, 6 ]; ..that's not how you declare a rectangular array type. It's int[3][2]. int[3][2] matrix = [[1, 2, 3], [4, 5, 6]]; Thanks Jarrett. Am I having a blonde day? int[2,3] m = [ 1, 2, 3 ]; writefln( "m=%s, .sizeof=%d", m, m.sizeof); Compiles and prints: m=[1,2,3], .sizeof=12 So what does that declaration, int[2,3], mean? Think this is what threw me initially. Thanks, Justin 2,3 is a comma expression. Evaluate everything, and return the rightmost value.
Re: How initialize a static rectangular array (2-d matrix)
Jarrett Billingsley Wrote: > On Thu, Oct 8, 2009 at 8:10 PM, Justin Johansson wrote: > > I almost have to apologize for this question but .. > > > > How does one initialize a static rectangular array (2-d matrix) in D1? > > > > None of the following or other variations that I've tried compile with DMD > > 1.0. > > > > int[2, 3] matrix = [ 1, 2, 3, 4, 5, 6 ]; > > ..that's not how you declare a rectangular array type. It's int[3][2]. > > int[3][2] matrix = [[1, 2, 3], [4, 5, 6]]; Thanks Jarrett. Am I having a blonde day? int[2,3] m = [ 1, 2, 3 ]; writefln( "m=%s, .sizeof=%d", m, m.sizeof); Compiles and prints: m=[1,2,3], .sizeof=12 So what does that declaration, int[2,3], mean? Think this is what threw me initially. Thanks, Justin
Re: How initialize a static rectangular array (2-d matrix)
Jarrett Billingsley Wrote: > On Thu, Oct 8, 2009 at 8:10 PM, Justin Johansson wrote: > > I almost have to apologize for this question but .. > > > > How does one initialize a static rectangular array (2-d matrix) in D1? > > > > None of the following or other variations that I've tried compile with DMD > > 1.0. > > > > int[2, 3] matrix = [ 1, 2, 3, 4, 5, 6 ]; > > ..that's not how you declare a rectangular array type. It's int[3][2]. > > int[3][2] matrix = [[1, 2, 3], [4, 5, 6]]; Of course. Blonde moment. Worked 18 hrs yesterday & not enough sleep. :-(
Re: How initialize a static rectangular array (2-d matrix)
On Thu, Oct 8, 2009 at 8:10 PM, Justin Johansson wrote: > I almost have to apologize for this question but .. > > How does one initialize a static rectangular array (2-d matrix) in D1? > > None of the following or other variations that I've tried compile with DMD > 1.0. > > int[2, 3] matrix = [ 1, 2, 3, 4, 5, 6 ]; ..that's not how you declare a rectangular array type. It's int[3][2]. int[3][2] matrix = [[1, 2, 3], [4, 5, 6]];
How initialize a static rectangular array (2-d matrix)
I almost have to apologize for this question but .. How does one initialize a static rectangular array (2-d matrix) in D1? None of the following or other variations that I've tried compile with DMD 1.0. int[2, 3] matrix = [ 1, 2, 3, 4, 5, 6 ]; int[2, 3] matrix = [[ 1, 2, 3 ], [ 4, 5, 6 ]]; Thanks for all help.
Re: Getting constructor's metadata
Max Samukha wrote: Is it possible to get types or aliases of all constructors of a class in D2? No. __traits has some random functionality in this regard. It has a command getVirtualFunctions which only returns virtual overloads. By "virtual", we mean "appears in vtbl". So any non-private, non-static overload will show up. Constructors do not appear in any object vtbl. It would be kind of odd if they did. There's a patch to add getOverloads to __traits. It would do what you want. But I doubt it works on DMD >2.020.
Re: How about macro == symbol for mixin statement? [was Re: Member functions C to D]
Bill Baxter wrote: It seems macros are implemented as compiler extensions. You compile your macros into DLLs first, that then get loaded into the compiler as plugins. On the plus side, doing things that way you really do have access to any API you need at compile-time, using the same syntax as run-time. All of .NET can be used at compile-time in your macros. No more "can't CTFE that" gotchas. But it does raise security concerns. I wonder if they have some way to prevent macros from running malicious code. I guess you better run your web-based compiler service in a tightly partitioned VM. C# has security levels. If you run the Nemerle compiler in low trust mode, fewer bad things can happen. Overall it seems pretty nifty to me, really. Giving macros access to an actual compiler API seems less hackish than throwing in a smattering of diverse functionality under the heading of __traits. And less prone to gotchas than trying to create a separate compile-time D interpreter that runs inside the D compiler. What do you see as the down sides? Just that some rogue macro might mess up the AST? It makes macros highly compiler-specific, or requires the compiler's AST to be part of the language. Nemerle took the nuclear option, and its macros are all-powerful. That's a reasonable way of doing things. I'd be happy with a more restricted system that's easier to standardize, especially if it got rid of all the hacky string manipulation in current D metaprogramming. (Seriously, even __traits returns string arrays for a lot of stuff. It's ridiculous.)
Re: Changing the preferred imagebase (dmd)?
Found it out in the meantime :) dmd test.d -L/BASE:8388608
Re: How about macro == symbol for mixin statement? [was Re: Member functions C to D]
Jarrett Billingsley wrote: On Thu, Oct 8, 2009 at 11:25 AM, Don wrote: Jarrett Billingsley wrote: On Thu, Oct 8, 2009 at 4:00 AM, Don wrote: So it looks to me like the mechanics of it are basically identical. Just Nemerle's syntax is nicer. Only with trivial examples. With more complicated examples they look less identical. I'm basing my views on pages like this: http://nemerle.org/Macros_-_extended_course._Part_2 Unless I'm totally misunderstanding this, it looks to me as though Nemerle macros are implemented as compiler plugins. All the advanced facilities are obtained by exposing the compiler's API! Well they're not.. "plugins" per se as much as "compiled modules." Okay yes that's basically a plugin :P But it's not that different from D, where you use compile-time executed functions to do the same sorts of things. It's just that you precompile those functions instead of having the compiler "compile" them on every compilation. No. CTFE is simply taking constant-folding to its logical conclusion. All the Nemerle *implementation* is doing differently here is having you precompile the functions that are to be executed at compile-time. That's it. The resultant semantics are utterly the same. You are running code at compile-time, it doesn't matter if that code is running on the hardware or in a VM in the compiler. But really, I don't see how this is significantly different from hooking into the D compiler's internals with __traits, .stringof, .mangleof and the like. So it uses an object-oriented API to access those things instead of ad-hoc hacks. And? The thing I think is elegant about D's approach, ugly as the syntax currently is, is the complete separation of the lex - parse - semantic - codegen phases. And I think CTFE is fantastic (and I plan to fix it so it works properly). Think about how easy it is to explain. And Nemerle's macros are *hard* to explain? They're a function that executes at compile time. Oh, wait! That's exactly the same as CTFE. I don't know how you can trash Nemerle's approach while leaving D's unmentioned. What do you mean, 'unmentioned'? Hey, you started this by trashing D's approach! I'm not talking about me. I'm talking about you. I don't know how you can trash a language with macros that were designed *from the bottom up* to be used as such and which are treated as first-class citizens, while not admitting the hilariously ad-hoc nature of a language where macros fall out as a consequence of a number of other, ill-defined poorly-implemented unorthogonal features. Sigh, I'm done. I agree with Jarrett here. And also seeing how some things are implemented in D using CTFE and .stringof and it's parsing is very complex to understand. I mean, I read the code and it's very hard for me to understand what's going on. Specially because it's mostly all of the time parsing strings and extracting information which I don't know in what format it comes in the first place, it's just guess and work around it.
Re: How about macro == symbol for mixin statement? [was Re: Member functions C to D]
On Thu, Oct 8, 2009 at 11:25 AM, Don wrote: > Jarrett Billingsley wrote: >> >> On Thu, Oct 8, 2009 at 4:00 AM, Don wrote: >> So it looks to me like the mechanics of it are basically identical. Just Nemerle's syntax is nicer. >>> >>> Only with trivial examples. With more complicated examples they look less >>> identical. I'm basing my views on pages like this: >>> >>> http://nemerle.org/Macros_-_extended_course._Part_2 >>> >>> Unless I'm totally misunderstanding this, it looks to me as though >>> Nemerle >>> macros are implemented as compiler plugins. >>> All the advanced facilities are obtained by exposing the compiler's API! >> >> Well they're not.. "plugins" per se as much as "compiled modules." >> Okay yes that's basically a plugin :P But it's not that different from >> D, where you use compile-time executed functions to do the same sorts >> of things. It's just that you precompile those functions instead of >> having the compiler "compile" them on every compilation. > > No. CTFE is simply taking constant-folding to its logical conclusion. All the Nemerle *implementation* is doing differently here is having you precompile the functions that are to be executed at compile-time. That's it. The resultant semantics are utterly the same. You are running code at compile-time, it doesn't matter if that code is running on the hardware or in a VM in the compiler. >> But really, I don't see how this is significantly different from >> hooking into the D compiler's internals with __traits, .stringof, >> .mangleof and the like. So it uses an object-oriented API to access >> those things instead of ad-hoc hacks. And? > > The thing I think is elegant about D's approach, ugly as the syntax > currently is, is the complete separation of the lex - parse - semantic - > codegen phases. And I think CTFE is fantastic (and I plan to fix it so it > works properly). Think about how easy it is to explain. And Nemerle's macros are *hard* to explain? They're a function that executes at compile time. Oh, wait! That's exactly the same as CTFE. >> I don't know how you can trash Nemerle's approach while leaving D's >> unmentioned. > > What do you mean, 'unmentioned'? Hey, you started this by trashing D's > approach! I'm not talking about me. I'm talking about you. I don't know how you can trash a language with macros that were designed *from the bottom up* to be used as such and which are treated as first-class citizens, while not admitting the hilariously ad-hoc nature of a language where macros fall out as a consequence of a number of other, ill-defined poorly-implemented unorthogonal features. Sigh, I'm done.
Re: How about macro == symbol for mixin statement? [was Re: Member functions C to D]
Jarrett Billingsley wrote: On Thu, Oct 8, 2009 at 4:00 AM, Don wrote: So it looks to me like the mechanics of it are basically identical. Just Nemerle's syntax is nicer. Only with trivial examples. With more complicated examples they look less identical. I'm basing my views on pages like this: http://nemerle.org/Macros_-_extended_course._Part_2 Unless I'm totally misunderstanding this, it looks to me as though Nemerle macros are implemented as compiler plugins. All the advanced facilities are obtained by exposing the compiler's API! Well they're not.. "plugins" per se as much as "compiled modules." Okay yes that's basically a plugin :P But it's not that different from D, where you use compile-time executed functions to do the same sorts of things. It's just that you precompile those functions instead of having the compiler "compile" them on every compilation. No. CTFE is simply taking constant-folding to its logical conclusion. But really, I don't see how this is significantly different from hooking into the D compiler's internals with __traits, .stringof, .mangleof and the like. So it uses an object-oriented API to access those things instead of ad-hoc hacks. And? The thing I think is elegant about D's approach, ugly as the syntax currently is, is the complete separation of the lex - parse - semantic - codegen phases. And I think CTFE is fantastic (and I plan to fix it so it works properly). Think about how easy it is to explain. I'm not a fan of is(typeof()) .stringof and __traits in their current form. They are hackish indeed, and weren't originally intended for macro development. (Actually .stringof isn't hackish, just buggy and unspecified). BUT they demonstrate the benefit of the seperate compilation phases. The fundamentals are strong. > I don't know how you can trash Nemerle's approach while leaving D's unmentioned. What do you mean, 'unmentioned'? Hey, you started this by trashing D's approach!
Re: How about macro == symbol for mixin statement? [was Re: Member functions C to D]
On Thu, Oct 8, 2009 at 4:00 AM, Don wrote: >> So it looks to me like the mechanics of it are basically identical. >> Just Nemerle's syntax is nicer. > > Only with trivial examples. With more complicated examples they look less > identical. I'm basing my views on pages like this: > > http://nemerle.org/Macros_-_extended_course._Part_2 > > Unless I'm totally misunderstanding this, it looks to me as though Nemerle > macros are implemented as compiler plugins. > All the advanced facilities are obtained by exposing the compiler's API! Well they're not.. "plugins" per se as much as "compiled modules." Okay yes that's basically a plugin :P But it's not that different from D, where you use compile-time executed functions to do the same sorts of things. It's just that you precompile those functions instead of having the compiler "compile" them on every compilation. But really, I don't see how this is significantly different from hooking into the D compiler's internals with __traits, .stringof, .mangleof and the like. So it uses an object-oriented API to access those things instead of ad-hoc hacks. And? I don't know how you can trash Nemerle's approach while leaving D's unmentioned.
Re: How about macro == symbol for mixin statement? [was Re: Member functions C to D]
On Thu, Oct 8, 2009 at 1:06 AM, Don wrote: > Jarrett Billingsley wrote: >> >> On Wed, Oct 7, 2009 at 11:21 AM, Don wrote: >>> >>> Steven Schveighoffer wrote: On Wed, 07 Oct 2009 09:17:59 -0400, Jarrett Billingsley wrote: > It's also insanely kludgy and ugly. Bleh. >>> >>> Ugly, yes. Kludgy, I don't think so. It's only a syntax issue. The basic >>> concept of passing meta-code to the compiler in the form of raw text is >>> simple: >>> >>> mixin() if you want to insert something into the parse step. >>> is(typeof()) if you want to catch it again after the syntax pass. >>> stringof if you want to catch it again after the semantic pass. >>> >>> And that's all. The syntax is ugly, but the semantics are beautifully >>> elegant. >> >> It'd be nice if they actually worked. is(typeof()) fails for *any* >> error, and it eats those errors too, so if your code fails to compile >> for some reason other than the one you're testing for, welp, good luck >> figuring that out. And don't even get me started on .stringof. >> >> Also, see my post on the "get template and its instantiation >> parameters" thread for my detailed opinion on them. >> >>> By contrast, something like Nemerle macros are a kludge. The idea of >>> providing a 'hook' into the compiler is a horrible hack. It exposes all >>> kinds of compiler internals. Yes, it has nicer syntax. >> >> I.. don't even know how to begin to respond to that. > > Have you read the Nemerle extended macro tutorial? The compiler's internal > structures are completely exposed. That's a hack. It seems macros are implemented as compiler extensions. You compile your macros into DLLs first, that then get loaded into the compiler as plugins. On the plus side, doing things that way you really do have access to any API you need at compile-time, using the same syntax as run-time. All of .NET can be used at compile-time in your macros. No more "can't CTFE that" gotchas. But it does raise security concerns. I wonder if they have some way to prevent macros from running malicious code. I guess you better run your web-based compiler service in a tightly partitioned VM. Overall it seems pretty nifty to me, really. Giving macros access to an actual compiler API seems less hackish than throwing in a smattering of diverse functionality under the heading of __traits. And less prone to gotchas than trying to create a separate compile-time D interpreter that runs inside the D compiler. What do you see as the down sides? Just that some rogue macro might mess up the AST? --bb
Getting constructor's metadata
Is it possible to get types or aliases of all constructors of a class in D2?
Re: How about macro == symbol for mixin statement? [was Re: Member functions C to D]
Jarrett Billingsley wrote: On Wed, Oct 7, 2009 at 11:21 AM, Don wrote: Steven Schveighoffer wrote: On Wed, 07 Oct 2009 09:17:59 -0400, Jarrett Billingsley wrote: It's also insanely kludgy and ugly. Bleh. Ugly, yes. Kludgy, I don't think so. It's only a syntax issue. The basic concept of passing meta-code to the compiler in the form of raw text is simple: mixin() if you want to insert something into the parse step. is(typeof()) if you want to catch it again after the syntax pass. stringof if you want to catch it again after the semantic pass. And that's all. The syntax is ugly, but the semantics are beautifully elegant. It'd be nice if they actually worked. is(typeof()) fails for *any* error, and it eats those errors too, so if your code fails to compile for some reason other than the one you're testing for, welp, good luck figuring that out. And don't even get me started on .stringof. Also, see my post on the "get template and its instantiation parameters" thread for my detailed opinion on them. By contrast, something like Nemerle macros are a kludge. The idea of providing a 'hook' into the compiler is a horrible hack. It exposes all kinds of compiler internals. Yes, it has nicer syntax. I.. don't even know how to begin to respond to that. Have you read the Nemerle extended macro tutorial? The compiler's internal structures are completely exposed. That's a hack.
Re: How about macro == symbol for mixin statement? [was Re: Member functions C to D]
Bill Baxter wrote:
On Wed, Oct 7, 2009 at 11:21 AM, Don wrote:
By contrast, something like Nemerle macros are a kludge. The idea of
providing a 'hook' into the compiler is a horrible hack. It exposes all
kinds of compiler internals. Yes, it has nicer syntax.
Are you talking specifically about the ability to define new syntax?
Because it looks to me that one can use nemerle macros just fine
without defining new syntax.
I'm getting that from here: http://nemerle.org/Macros_tutorial
Here's just a simple macro that adds no new syntax from that page:
macro m () {
Nemerle.IO.printf ("compile-time\n");
<[ Nemerle.IO.printf ("run-time\n") ]>;
}
module M {
public Main () : void {
m ();
}
}
That seems significantly more elegant to me than
string m() {
pragma(msg, "compile-time");
return q{writefln("run-time");}
}
void main() {
mixin(m());
}
So it looks to me like the mechanics of it are basically identical.
Just Nemerle's syntax is nicer.
Only with trivial examples. With more complicated examples they look
less identical. I'm basing my views on pages like this:
http://nemerle.org/Macros_-_extended_course._Part_2
Unless I'm totally misunderstanding this, it looks to me as though
Nemerle macros are implemented as compiler plugins.
All the advanced facilities are obtained by exposing the compiler's API!
I pesonally think that is an utterly revolting thing to add to a language.
Compare with macros in Lisp and Forth.
If you want to condem Nemerle's ability to define new syntax, I think
that should be taken up as a separate matter.
I do think it's a profoundly bad idea in a C-like language, but it's not
what I'm referring to here.
