digitalmars.D - Meta / CTFE library
- Matthias Walter (8/8) Jun 23 2008 Hello,
- Jarrett Billingsley (14/20) Jun 23 2008 I think it's a great idea. I don't know how many times I've done some
- Robert Fraser (7/12) Jun 23 2008 I'd love to see a compile-time language parser infrastructure. There's
- Matthias Walter (2/13) Jun 23 2008 This sounds crank - although interesting, but I guess, this won't be my ...
- Robert Fraser (7/22) Jun 23 2008 Proving D is better at making domain-specific meta-languages than LISP?
- BCS (21/53) Jun 23 2008 dparse (my template lib to, at compile time, generated a runtime parser)...
- BCS (4/29) Jun 23 2008 And I thought *I* was nuts (OTOH I've considered that myself :)
Hello, as I'm doing much stuff with CTFE / Template Metaprogramming, I thought about collecting important stuff in a library. I already found the following interesting: 1. parsing routines for compile-time; although every standard lib has their parsing routines, but sometimes they don't work at compile time (e.g. using some libc-stuff), or at least are not optimized for this use. This includes parsing / printing numbers as well, because at least for dumping some numbers, while debugging a CT-program, one needs these quiet often. Everyone, who read Dons BLADE library, will know his enquote() function. This one is very important if you like to do some recursive mixin programming, like he did there. 2. finding out attributes of types and identifiers (the latter means variables, functions, delegates, etc.). There are some attributes, which at least in D1, are nearly unaccessable. For example, one cannot tell (via a template / function), whether a function (given as a template alias) is static or not. I've coded a demangler, that can be used to extract all information, which is in the mangle. (as opposed to Walters and Dons demanglers which only print the names) 3. here comes the point of my post: I'd like to know your whishes, what should be in there, too! Has anyone found some special functions quiet useful for his own CT-projects, or desired some functionality, he could not implement? Have you further suggestions about such a library, either in design or content? best regards Matthias Walter
Jun 23 2008
"Jarrett Billingsley" <kb3ctd2 yahoo.com> "Matthias Walter" <Matthias.Walter st.ovgu.de> wrote in message news:g3nnn9$2pvf$1 digitalmars.com...3. here comes the point of my post: I'd like to know your whishes, what should be in there, too! Has anyone found some special functions quiet useful for his own CT-projects, or desired some functionality, he could not implement?I think it's a great idea. I don't know how many times I've done some compile-time stuff and thought "someone's probably already solved this." And then I go digging in DDL.meta or PyD and usually find it ;)Have you further suggestions about such a library, either in design or content?You might already have this stuff, but I've got some compile-time stuff for things like getting a tuple of all the names of the fields of a struct/class/union (in D1; it's a horrid hack), finding the minimum number of arguments that a function can be called with, and converting between various Unicode encodings at runtime. I've also got some scarier stuff -- compile-time tuple qsort with custom predicates and template map, reduce, and range. Having some kind of standard string <-> number conversion functions would probably save me ten minutes and 50 lines on everything I work on ;)
Jun 23 2008
Matthias Walter wrote:Hello, as I'm doing much stuff with CTFE / Template Metaprogramming, I thought about collecting important stuff in a library. I already found the following interesting: 1. parsing routines for compile-time; although every standard lib has their parsing routines, but sometimes they don't work at compile time (e.g. using some libc-stuff), or at least are not optimized for this use. This includes parsing / printing numbers as well, because at least for dumping some numbers, while debugging a CT-program, one needs these quiet often. Everyone, who read Dons BLADE library, will know his enquote() function. This one is very important if you like to do some recursive mixin programming, like he did there.I'd love to see a compile-time language parser infrastructure. There's already code (BCS's) that takes an EBNF grammar and generates a runtime code parser, but what about something that can create a (semi) efficient compile-time parser (that is, given an EBNF grammar and a code string, create some compile-time structs of the syntax of the code string, which can then be used to generate other compile-time code).
Jun 23 2008
Robert Fraser Wrote:Matthias Walter wrote:This sounds crank - although interesting, but I guess, this won't be my main target for the library, cuz I didn't want to code a meta-meta-lib :) But it is possible: One could write templates / ctfe functions which generate the code for the compile-time parser and you must mix it in then... Why does one need a compile-time-parser, if I'm allowed to ask?!as I'm doing much stuff with CTFE / Template Metaprogramming, I thought about collecting important stuff in a library. I already found the following interesting: 1. parsing routines for compile-time; although every standard lib has their parsing routines, but sometimes they don't work at compile time (e.g. using some libc-stuff), or at least are not optimized for this use. This includes parsing / printing numbers as well, because at least for dumping some numbers, while debugging a CT-program, one needs these quiet often. Everyone, who read Dons BLADE library, will know his enquote() function. This one is very important if you like to do some recursive mixin programming, like he did there.I'd love to see a compile-time language parser infrastructure. There's already code (BCS's) that takes an EBNF grammar and generates a runtime code parser, but what about something that can create a (semi) efficient compile-time parser (that is, given an EBNF grammar and a code string, create some compile-time structs of the syntax of the code string, which can then be used to generate other compile-time code).
Jun 23 2008
Matthias Walter Wrote:Robert Fraser Wrote:Proving D is better at making domain-specific meta-languages than LISP? Also, I was considering making a "LINQ" clone in D1. This is basically the first step. I agree, though, it's a kind of tall task, I'm not even sure if it's possible to make it both general and efficient enough so that compiles don't take 20 minutes apiece. Having a compiler that correctly does CTFE would be a first step here.Matthias Walter wrote:This sounds crank - although interesting, but I guess, this won't be my main target for the library, cuz I didn't want to code a meta-meta-lib :) But it is possible: One could write templates / ctfe functions which generate the code for the compile-time parser and you must mix it in then... Why does one need a compile-time-parser, if I'm allowed to ask?!as I'm doing much stuff with CTFE / Template Metaprogramming, I thought about collecting important stuff in a library. I already found the following interesting: 1. parsing routines for compile-time; although every standard lib has their parsing routines, but sometimes they don't work at compile time (e.g. using some libc-stuff), or at least are not optimized for this use. This includes parsing / printing numbers as well, because at least for dumping some numbers, while debugging a CT-program, one needs these quiet often. Everyone, who read Dons BLADE library, will know his enquote() function. This one is very important if you like to do some recursive mixin programming, like he did there.I'd love to see a compile-time language parser infrastructure. There's already code (BCS's) that takes an EBNF grammar and generates a runtime code parser, but what about something that can create a (semi) efficient compile-time parser (that is, given an EBNF grammar and a code string, create some compile-time structs of the syntax of the code string, which can then be used to generate other compile-time code).
Jun 23 2008
Reply to Matthias,Robert Fraser Wrote:dparse (my template lib to, at compile time, generated a runtime parser) has in it a compile time parser. Being able to defined that from BNF rather than hand codeing it would be handy. Linq like things also would be neet struct Man { char[] name; int age Job job; } class Job { char[] name; float pay; } Man[] men; // You'll want a parser here ---v foreach(guy; Query!("SELECT name,job.name WHERE job.pay < age").From(men)) { writef("%s, %s\n", guy.name, guy.job.name; }Matthias Walter wrote:This sounds crank - although interesting, but I guess, this won't be my main target for the library, cuz I didn't want to code a meta-meta-lib :) But it is possible: One could write templates / ctfe functions which generate the code for the compile-time parser and you must mix it in then... Why does one need a compile-time-parser, if I'm allowed to ask?!as I'm doing much stuff with CTFE / Template Metaprogramming, I thought about collecting important stuff in a library. I already found the following interesting: 1. parsing routines for compile-time; although every standard lib has their parsing routines, but sometimes they don't work at compile time (e.g. using some libc-stuff), or at least are not optimized for this use. This includes parsing / printing numbers as well, because at least for dumping some numbers, while debugging a CT-program, one needs these quiet often. Everyone, who read Dons BLADE library, will know his enquote() function. This one is very important if you like to do some recursive mixin programming, like he did there.I'd love to see a compile-time language parser infrastructure. There's already code (BCS's) that takes an EBNF grammar and generates a runtime code parser, but what about something that can create a (semi) efficient compile-time parser (that is, given an EBNF grammar and a code string, create some compile-time structs of the syntax of the code string, which can then be used to generate other compile-time code).
Jun 23 2008
Reply to Robert,Matthias Walter wrote:And I thought *I* was nuts (OTOH I've considered that myself :) Feel free to steal stuff from dparse (It'll be getting a few more things as soon as my current reworking is done.Hello, as I'm doing much stuff with CTFE / Template Metaprogramming, I thought about collecting important stuff in a library. I already found the following interesting: 1. parsing routines for compile-time; although every standard lib has their parsing routines, but sometimes they don't work at compile time (e.g. using some libc-stuff), or at least are not optimized for this use. This includes parsing / printing numbers as well, because at least for dumping some numbers, while debugging a CT-program, one needs these quiet often. Everyone, who read Dons BLADE library, will know his enquote() function. This one is very important if you like to do some recursive mixin programming, like he did there.I'd love to see a compile-time language parser infrastructure. There's already code (BCS's) that takes an EBNF grammar and generates a runtime code parser, but what about something that can create a (semi) efficient compile-time parser (that is, given an EBNF grammar and a code string, create some compile-time structs of the syntax of the code string, which can then be used to generate other compile-time code).
Jun 23 2008