On 02/10/17 21:35, Adriano dos Santos Fernandes wrote: > On 10/02/2017 14:20, Dimitry Sibiryakov wrote: >> 10.02.2017 16:32, Adriano dos Santos Fernandes wrote: >>> Firebird BLR must be improved to be easier to read (the code), to be >>> easier to generate and parse and to be extensible. >> Why to improve something that must die?.. >> >> > I don't see C++, Java, Intel, etc switching from binary code to source code. > > Why would Firebird will do it to be slower?
Not sure that comaprison with c++ is correct here. Compiler stores it's otuput as ready for use by CPU bytes, interpreter has a kind of Binary Language Representation. In our case we anyway transform it to the tree of executable nodes (which are anyway interpreted). I.e. our BLR can not be comapred even with Java bytecode which is typically (correct me if I'm wromg) processed by JITC. Our BLR is intermediate form used to create interpretable form of SQL. May be better store something directly convertable to execuatble tree? > Having the source stored and using it when needed is a thing. Recompile > text sources for nothing is another thing. > > > Adriano > > BTW: "this is going to die" for almost 10 years, and the BLR mess is > there, limited use of context is there, etc. > Yes - instead of enhancing BLR it's high time to spent that efforts for avoiding it... ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
