On Sat, Aug 11, 2012 at 2:19 AM, David Piepgrass <qwertie...@gmail.com> wrote:
> I must say though, that while ADTs are useful for simple ASTs, I am not > convinced that they scale to big and complex ASTs, let alone extensible > ASTs, which I care about more. You mean AST for D code? > Nevertheless ADTs are at least useful for > rapid prototyping, and pattern matching is really nice too. I'm sure > somebody could at least write a D mixin for ADTs, if not pattern matching.) I did it, maybe 2 years ago. I worked for recursive ADT too (lists, trees) and automatically generated small matchers, and maybe specific map/reduce. That would be easier today, with this CTFE++ we now have. IIRC, it generated an abstract class with internal subtypes and a tag to distinguish the state. I guess I could have used a union for the fields, like Timon did further upthread. Hmm, does a union allow for recursive fields? I never tried to do generic pattern matchers, that would work also on any struct and class, by using .tupleof. I daydreamed about it a few times, tough, but never found a palatable syntax. Maybe with the new () => syntax, that'd be better. > I hope someday to have a programming system whose features are not limited > to whatever features the language designers saw fit to include -- a language > where the users can add their own features, all the while maintaining > "native efficiency" like D. That language would potentially allow Rust-like > code, D-like code, Ruby-like code and even ugly C-like code. > > I guess you don't want to be the one to kickstart that PL. I've been > planning to do it myself, but so far the task seems just too big for one > person. Well, we are not far from having an official D lexer. Then, an official D parser. >From this, adding user-defined extensions is not *that* complicated (not simple, mind you, but doable). * define lowerings (aka, translations from your extended syntax to D syntax), maybe by snatching the unused macro keyword * code a small wrapper around dmd, rdmd-like: given a file, it extracts the macros, parses the extended code, transforms the extensions, does that as many times as necessary, if some macros call other macros. * Discard the macros and then pass the transformed file to dmd. It looks like C macros and preprocessor-based programming, but since it knows the D grammar, it's nearer Lisp macros, I think.