DConf 2014 Day 1 Talk 4: Inside the Regular Expressions in D by Dmitry Olshansky

[Dicebot via Digitalmars-d-announce]

On Saturday, 14 June 2014 at 16:34:35 UTC, Dmitry Olshansky wrote:
>> Consider something like REST API generator I have described 
>> during
>> DConf. There is different code generated in different contexts 
>> from same
>> declarative description - both for server and client. Right 
>> now simple
>> fact that you import very same module from both gives solid 
>> 100%
>> guarantee that API usage between those two programs stays in 
>> sync.
>
> But let's face it - it's a one-time job to get it right in your 
> favorite build tool. Then you have fast and cached (re)build. 
> Comparatively costs of CTFE generation are paid in full during 
> _each_ build.

There is no such thing as one-time job in programming unless you 
work alone and abandon any long-term maintenance. As time goes 
any mistake that can possibly happen will inevitably happen.

>> In your proposed scenario there will be two different 
>> generated files
>> imported by server and client respectively. Tiny typo in 
>> writing your
>> build script will result in hard to detect run-time bug while 
>> code
>> itself still happily compiles.
>
> Or a link error if we go a hybrid path where the imported 
> module is emitting declarations/hooks via CTFE to be linked to 
> by the proper generated code. This is something I'm thinking 
> that could be a practical solution.
>
> <snip>

What is the benefit of this approach over simply keeping all 
ctRegex bodies in separate package, compiling it as a static 
library and referring from actual app by own unique symbol? This 
is something that can does not need any changes in compiler or 
Phobos, just matter of project layout.

It does not work for more complicated cases were you actually 
need access to generated sources (generate templates for example).

>> You may keep convenience but losing guarantees hurts a lot. To 
>> be able
>> to verify static correctness of your program / group of 
>> programs type
>> system needs to be aware how generated code relates to 
>> original source.
>
> Build system does it. We have this problem with all of external 
> deps anyway (i.e. who verifies the right version of libXYZ is 
> linked not some other?)

It is somewhat worse because you don't routinely change external 
libraries, as opposed to local sources.

>> Huge mess to maintain. According to my experience
>> all builds systems are incredibly fragile beasts, trusting them
>> something that impacts program correctness and won't be 
>> detected at
>> compile time is just too dangerous.
>
> Could be, but we have dub which should be simple and nice.
> I had very positive experience with scons and half-generated 
> sources.

dub is terrible at defining any complicated build models. Pretty 
much anything that is not single step compile-them-all approach 
can only be done via calling external shell script. If using 
external generators is necessary I will take make over anything 
else :)

> <snip>

tl; dr: I believe that we should improve compiler technology to 
achieve same results instead of promoting temporary hacks as the 
true way to do things. Relying on build system is likely to be 
most practical solution today but it is not solution I am 
satisfied with and hardly one I can accept as accomplished target.

Imaginary compiler that continuously runs as daemon/service, is 
capable of JIT-ing and provides basic dependency tracking as part 
of compilation step should behave as good as any external 
solution with much better correctness guarantees and overall user 
experience out of the box.