DeRailed DSL (was Re: compile-time regex redux)

[Sean Kelly]

Andrei Alexandrescu (See Website For Email) wrote:
> kris wrote:
>> For example, having a DSL go and hit a database at /compile time/ 
>> sounds like an appalling reduction in /perceived/ compiler efficiency. 
>> If I have to hit the DB for every single compilation of each module 
>> with such a DSL embedded, I will simply discard the toolset. That 
>> approach would be borderline insanity :p
> 
> Probably we haven't worked in the same environments. In the large 
> database systems I worked with (Chase Manhattan)

Funny.  I worked in that building (Chase Manhattan Plaza 1) up through 
the end of 2000.  Was for a different firm though.

 > the schema and the
> basic views change very rarely, and whenever that happens, the stored 
> procedures are spilled automatically in text files that can be read by 
> the build process. It was entirely reasonable to recompile the system 
> whenever that happened, and it was highly desirable to fix mismatches 
> before the system runs.

What I've done in the past is manage the entire schema, stored 
procedures and all, in a modeling system like ErWin.  From there I'll 
dump the lot to a series of scripts which are then applied to the DB. 
In this case, the DSL would be the intermediate query files, though 
parsing the complete SQL query syntax (since the files include 
transactions, etc), sounds sub-optimal.  I suppose a peripheral data 
format would perhaps be more appropriate for generating code based on 
the static representation of a DB schema.  UML perhaps?

My only concern here is that the process seems confusing and unwieldy: 
manage the schema in one tool, dump the data description in a 
meta-language to a file, and then have template code in the application 
parse that file during compilation to generate code.  Each of these 
translation points creates a potential for failure, and the process and 
code risks being incomprehensible and unmanageable for new employees.

Since you've established that the schema for large systems changes only 
rarely and that the changes are a careful and deliberate process, is it 
truly the best approach to attempt to automate code changes in this way? 
  I would think that a well-designed application or interface library 
could be modified manually in concert with the schema changes to produce 
the same result, and with a verifiable audit trail to boot.

Alternately, if the process were truly to be automated, it seems 
preferable to generate D code directly from the schema management 
application or via a standalone tool operating on the intermediate data 
rather than in preprocessor code during compilation.  This approach 
would give much more informative error messages, and the process could 
be easily tracked and debugged.

Please note that I'm not criticizing in-language DSL parsing as a 
general idea so much as questioning whether this is truly the best 
example for the usefulness of such a feature.

> In other cases, a dynamic approach does better. Dynamic has always been 
> more flexible, no doubt about that. The point is that each approach has 
> its advantages and disadvantages.

I would think it is perhaps worth comparing the two here since they can 
both be used for the same thing (ie. customizing an application for a 
database), and prior discussion had already mentioned RoR as a 
motivating factor for these features?  Or perhaps I misunderstood.

I'll grant that the comparison isn't entirely fair because Ruby is a 
dynamic language while D is a static language, but since the tasks the 
new import/mixin intend to solve are essentially a compile-time 
equivalent of what is done in Ruby at run-time (as I understand it 
anyway--I don't have much Ruby experience), then the utility of each 
approach can perhaps be weighed against the other in an attempt to 
understand the situations where the D approach may or may not be 
appropriate?

> I can also do without the belligerent tone. Not knowing or not 
> understanding does not automatically lend insanity on the interlocutor.

No offense, but this statement is a bit patronizing.  I think Kris was 
merely attempting to explain his position?


Sean