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

"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 ;)

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

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

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.

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

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;
}

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

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.