Example of Rust code

Philippe Sigaud philippe.sigaud at gmail.com
Sat Aug 11 05:41:34 PDT 2012


On Sat, Aug 11, 2012 at 2:19 AM, David Piepgrass <qwertie256 at 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.


More information about the Digitalmars-d mailing list