[std.database] at compile time

[Ary Manzana]

On 10/16/11 4:56 AM, foobar wrote:
> Don Wrote:
>
>> On 16.10.2011 04:16, Ary Manzana wrote:
>>> On 10/15/11 5:00 PM, Marco Leise wrote:
>>>> Am 15.10.2011, 18:24 Uhr, schrieb Ary Manzana<ary at esperanto.org.ar>:
>>>>
>>>>> On 10/14/11 5:16 PM, Graham Fawcett wrote:
>>>>>> On Fri, 14 Oct 2011 21:10:29 +0200, Jacob Carlborg wrote:
>>>>>>
>>>>>>> On 2011-10-14 15:26, Andrei Alexandrescu wrote:
>>>>>>>> On 10/14/11 6:08 AM, Jacob Carlborg wrote:
>>>>>>>>> On 2011-10-14 12:19, foobar wrote:
>>>>>>>>>> Has anyone looked at Nemerle's design for this? They have an SQL
>>>>>>>>>> macro which allows to write SQL such as:
>>>>>>>>>>
>>>>>>>>>> var employName = "FooBar"
>>>>>>>>>> SQL (DBconn, "select * from employees where name = $employName");
>>>>>>>>>>
>>>>>>>>>> what that supposed to do is bind the variable(s) and it also
>>>>>>>>>> validates the sql query with the database. This is all done at
>>>>>>>>>> compile-time.
>>>>>>>>>>
>>>>>>>>>> My understanding is that D's compile-time features are powerful
>>>>>>>>>> enough to implement this.
>>>>>>>>>
>>>>>>>>> You cannot connect to a database in D at compile time. You could
>>>>>>>>> some
>>>>>>>>> form of validation and escape the query without connecting to the
>>>>>>>>> database.
>>>>>>>>
>>>>>>>> A little SQL interpreter can be written that figures out e.g. the
>>>>>>>> names
>>>>>>>> of the columns involved.
>>>>>>>>
>>>>>>>> Andrei
>>>>>>>
>>>>>>> But you still won't be able to verify the columns to the actual
>>>>>>> database
>>>>>>> scheme?
>>>>>>
>>>>>> One approach would be to write a separate tool that connects to the
>>>>>> database and writes out a representation of the schema to a source
>>>>>> file. At compile time, the representation is statically imported, and
>>>>>> used to verify the data model.
>>>>>>
>>>>>> If we had preprocessor support, the tool could be run as such,
>>>>>> checking the model just before passing the source to the compiler.
>>>>>
>>>>> Yeah, but you need a separate tool.
>>>>>
>>>>> In Nemerle it seems you can do everything just in Nemerle...
>>>>>
>>>>> It would be awesome if CTFE would be implemented by JITting functions,
>>>>> not by reinventing the wheel and implementing a handcrafted
>>>>> interpreter...
>>>>
>>>> I wonder if that would work well with cross-compiling. If you blindly
>>>> JIT functions, they may end up using structs of the wrong size, or
>>>> integers with different endianness. Compile for 64-bit on a 32-bit
>>>> machine. What size is size_t during CTFE?
>>>
>>> I don't understand this quite well. I want JITted functions to just
>>> generate code that ultimately will be compiled. It's like what CTFE is
>>> doing now, except that instead of doing it by interpreting every bit and
>>> spec of the language you would compile the function, run it to generate
>>> code, and then compile the code for the target machine.
>> [snip]
>>> Maybe I'm not taking something into account... what is it?
>>
>> You're assuming that the compiler can run the code it's generating. This
>> isn't true in general. Suppose you're on x86, compiling for ARM. You
>> can't run the ARM code from the compiler.
>>
>
> This is quite possible in Nemerle's model of compilation.
> This is the same concept as XLST - a macro is a high level transform from D code to D code.
>
> 1. compile the macro ahead of time into a loadable compiler module/plugin.
>      the plugin is compiled for the HOST machine (x86) either by a separate compiler
>      or by a cross-compiler that can also compile to its HOST target.
> 2. cross-compiler loads the plugin and uses it during compilation of your code to the TARGET machine (arm).
>      E.g. the SQL plugin will connect to db and verify your query against the db schema and will *generate* D code
>      to query the db.
>      the generated D code is compiled to the TARGET machine.
>
>
> The JIT to .net is merely an implementation detail for Nemerle which makes it much easier to implement.
> I don't see how Endianess or word size affects this model in any way.

Exactly!! :-)