CTFE where can it go?

Over the past five months I've been working quite a lot on Compile Time Function Execution (CTFE) and what I keep seeing is at the current point in time, a lot of crazy stuff can be done. But netherless very very neat.

However there is many limitations at the current point in time. For example:

• A lot of D's standard library is not capable of running at CTFE.
  While this is a little exaggeration its still annoying. I do have to have my own version of some functions like split. While I can understand it not working at CTFE for possible performance reasons or what not. However it does mean at some point I'll either be fixing this myself or creating a CTFE capable library.
• Not being able to get all modules/classes. This is an inherent limitation of D's compilation model.
  In that the final modules and classes can only be known at link time. Kinda a big problem when I want access to it at CTFE. This has lead me to believe that it will be required to extend this so that if its a link operation the compiler will be able to make access this information. However I do believe this won't be easy to make happen.
• Unable to export text at CTFE like its possible to do with string imports.
• Lastly string imports. Can't do subdirectories access. Really really not good.
  At worse what needs to go on here is to say no ".." in the file names. Then its just a simple check to see if its a string import directory (-J compiler flag).
  From memory this is only an issue on Windows not Linux.

Now on to some crazy stuff that can be done. After all what else are you here for?

ASN.1

Abstract Syntax Notation is a format which describes messages independent of the language. Its also heavily geared towards low level efficient transmission. Its used in the telecommunications industry heavily as well as with LDAP/ActiveDirectory.

Now how could this miraculous thing be used with CTFE? How about converting a notation format directly into a D data structure. That could be utilised for an ORM or direct transmission via e.g. node communication.

I'm personally a huge fan of ASN.1 in terms of describing data structures for messages. However it is showing its age. After all it originated in 1984! If you want to check out its spec link.

Part of the notation syntax is the ability to control size of a type for e.g. integers. As well as valid values.

This is quite a clever thing. However implementing it is a little bit harder. Yet with D we have contract based programming in the format of in/body/out and invariants on types.

Now the in/body/out blocks won't be all that useful however the invariants will be. There is one other feature that isn't so common and that is alias this statements. What they do is allow you to merge another type into your own type e.g. struct/class. Which is a very nice thing. So everything that int can do, guess what your struct can do too!

But that really isn't the clever part of this. By using a struct to represent a type that the ASN.1 notation file has specified to having a range you can specify that it must validate. If it doesn't hello exception!

For my implementation link whose implementation wasn't complete but netherless utilises a struct per protocol. And within that struct more structs and classes are defined per message. Some types like a direct integer or string can be done via an alias. However if they have ranges/validation must be a struct wrapper as described above.

All in all its a very clever thing to be able to do. Now if only writing a BER encoder was just as easy...

Than I would have a working LDAP client library.

Macro preprocessor

For those that have lived in the c/c++ worlds and possibly even assembly you'll know just how powerful and irritating the macro preprocessor can be. And of course that it runs as a separate program before the compiler can do anything.

Now imagine in the D world where we have no 'easy' way to create interfaces to c/c++ libraries. Other than doing it manually. Imagine if you could just say hey go grab these header files and create a set of extern functions for it. With help of outputting c++ code to link the c++ library to D fully.

Without modifying the compiler itself this would require a CTFE'able frontend to c/c++ and a macro preprocessor but not just that but also the ability to say heres a directory you can go import anything you want from it and its subdirectories.

The same can go for objective-c too.

The ramifications of doing this would be huge. However the cost to implement the front ends and parsers.. well its quite high. Since this is a completely revolutionary concept.

UML and input or is it an output?

So for those who do a lot of enterprise level work will know, UML or Unified Modeling Language is used to model data and modeling interactions within a system. Now what would you do if you wanted to get out from a system a UML diagram of what it is composed of?

It would be possible with D's documentation mechanism to output a website that has the necessary information about each class/function but it can also be done at CTFE. This does have the unfortunate requirement that outputting to file system of the end result happens at CTFE not at runtime. But its not crazy to expect it as a module constructor when in debug.

This is entirely theoretical but it should be doable.

Ajax wait you write that?

So by this heading you probably can guess what this is about. Specifically as a web developer why do you have to write the Javascript code to actually perform a request to a known server route with the specific parameters. This is a menial task that is completely redundant.

A compiler like D's has the information required to generate that Javascript code and then make available as a static file.

As an example of this, here is a little demonstration:

Now the end javascript hasn't been tested at this point. But hey, the information is there in the right places, so it would be a simple task of fixing it.

You will have noticed that there is a bunch of restful related functions that was generated. They are normal with that restful mixin. You wouldn't normally use this so it should probably be ignored by the generator.
The reason is that there is generation of data models in a class format. The query capabilities as of this writing hasn't been implemented. However it should be a menial task to do so.
There is limitations in the format of not allowing a find all operation in javascript code. But you really really wouldn't want that. Especially for a 100+ records. If you must do evil stuff like this you must manually expose this via your own route and the ORM.

But this proves one thing. These two approaches of generating the javascript data models that yes can be limited for view/create/modify/delete via the restful service is very powerful and could mean the end of writing the ajax calls yourself. Which is a huge benefit to businesses in terms of development time.


Perhaps this would have interested somebody to explore these capabilities of D. Or even seeing this as being a potential new advance in programming.
Because I'm sure am a huge believer that CTFE will mean great things. Sure it means things become a little harder to understand, after all adds another period of time execution can occur!
Note however that CTFE alone hasn't contributed to this. Other features of D including meta programming and traits have. Which are just as important.