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

[kris]

Andrei Alexandrescu (See Website For Email) wrote:
> kris wrote:
> 
>> Robby wrote:
>>
>>>
>>>>>
>>>>> Walter gave another good case study: Ruby on Rails. The success of 
>>>>> Ruby on Rails has a lot to do with its ability to express 
>>>>> abstractions that were a complete mess to deal with in concreteland.
>>>>>
>>>>
>>>> Let look at that case study, then. The /real/ power in RoR comes 
>>>> from being able to dynamically bind via rich reflection. What we're 
>>>> talking about here does not add full reflection to D. Neither does 
>>>> it assist in getting D modules dynamically loaded at runtime.
>>>>
>>>> As it turns out, some of us are actively looking /specifically/ at 
>>>> the killer RoR for D; far beyond what RoR does. Oddly enough, our 
>>>> working name for it is - DeRailed -
>>>>
>>>> We have solid notions of what's needed; and several of us have build 
>>>> related platforms in the past. But this topic, at face value, 
>>>> doesn't appear to help us in any notable fashion. Perhaps you can 
>>>> expain this further?
>>>>
>>>> - Kris
>>>
>>>
>>>
>>> I'm having a hard time putting together the association with RoR, 
>>> DSL's and the regex feature together. Perhaps they're completely 
>>> separate.
>>
>>
>> Me too. I failed to see any connection that would measurably assist 
>> DeRailed. And the question above was sadly left unaddressed.
> 
> 
> It's very simple. A scheme based on compile-time in(tro)spection has 
> superior and automatic means to detect, say, mismatches between an 
> expected database schema and the runtime reality.

Let's step back for a moment, please?

In a practical sense, the user/developer cares mostly about the extent 
and capability of the development facilities exposed. Yes? That includes 
the whole edit, compile, debug, edit cycle along with the quality of the 
tools and environment presented.

Whether the scheme you mention is implemented at compile-time or at 
runtime has little bearing in the overall practical picture; e.g. as 
long as the cycle is short, intuitive and effective, either approach 
works. At that point, it's all about practical tradeoffs instead of 
theoretical one-upmanship?

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

One might argue that such a DSL design is incorrect? OK; then what about 
the security aspects? Your example is talking about a DSL that can be 
verified at compile-time; against a database scheme. Yes? How could that 
possibly be /permitted/ to run at compile time? It's a /gaping/ security 
issue. With sandboxing, any compiler 'extension' would likely have to 
eschew OS handles, which means no DB access, no network access, no file 
access, and no registry access. How does your example operate under such 
conditions? I fail to see that there's any practical thought behind the 
example given, and sincerely hope you can correct that?

Lastly: the example you give fails to meet the criteria of "measurably 
assist DeRailed". Even if it /were/ feasible from a security and 
compile-cycle efficiency standpoint, it still would have little bearing 
on the overall productivity of a user/developer (using DeRailed). In 
other words, there's a whole lot of pain for very little gain. What 
there is of value quickly vanishes against the far greater concerns over 
full-on reflection and dynamic linking.

- Kris