www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Meta / CTFE library

reply Matthias Walter <Matthias.Walter st.ovgu.de> writes:
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
next sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"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
prev sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
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
next sibling parent reply Matthias Walter <Matthias.Walter st.ovgu.de> writes:
Robert Fraser Wrote:

 Matthias Walter wrote:
 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).

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?!
Jun 23 2008
next sibling parent Robert Fraser <fraserofthenight gmail.com> writes:
Matthias Walter Wrote:

 Robert Fraser Wrote:
 
 Matthias Walter wrote:
 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).

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?!

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.
Jun 23 2008
prev sibling parent BCS <ao pathlink.com> writes:
Reply to Matthias,

 Robert Fraser Wrote:
 
 Matthias Walter wrote:
 
 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.
 

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).

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?!

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; }
Jun 23 2008
prev sibling parent BCS <ao pathlink.com> writes:
Reply to Robert,

 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.
 

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).

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.
Jun 23 2008