Re: Функционал и интерфейс
Alexey Pechnikov -> debian-russian@lists.debian.org @ Thu, 19 Mar 2009 11:19:57 +0300:
>> AP> Alexander Danilov недавно высказывал желание сделать аналог SQLite на
>> одном из AP> функциональных языков. Имхо не лучшая идея с точки зрения
>> эффективности, AP> предпочитаю на С низкоуровневые вещи делать (ну может
>> еще и ностальгия у меня AP> по С, не буду отрицать). Ну если напишет -
>> посмотрим :-)
>>
>> Эээ... А где ты в задаче написания _аналога_ SQLite обнаружил низкий
>> уровень?
AP> SQLite использует встроенную виртуальную машину:
AP> Each instruction in the virtual machine consists of an opcode and up to five
AP> operands named P1, P2 P3, P4, and P5. P1, P2, and P3 are 32-bit signed
AP> integers. These operands often refer to registers. P2 is always the jump
AP> destination in any operation that might cause a jump. P4 may be a 32-bit
AP> signed integer, a 64-bit signed integer, a 64-bit floating point value, a
AP> string literal, a Blob literal, a pointer to a collating sequence comparison
AP> function, or a pointer to the implemantation of an application-defined SQL
AP> function, or various other things. P5 is an unsigned character normally used
AP> as a flag. Some operators use all five operands. Some use one or two. Some
AP> operators use none of the operand
AP> Или для вас работа с регистрами процессора это задача для скриптового языка?
1. "often refer to registers" не означает, что они там работают с
регистрами процессора. Это и не для C, прямо скажем, задача. Это
только на ассемблере.
2. Соответственно, если делать такую же машину на нормальном
функциональном языке, оно тоже будет "often refer to registers". Но ...
3. И наконец, зачем при создании _аналога SQLite_ на функциональном
языке реализовать эту самую виртуальную машину? Это когда его пишут на
C, эту машину надо делать. А в функциональном, скорее всего, нужные
возможности предоставлены языком.
Разумеется, эмуляция ассемблерного кода на хаскеле будет работать
медленнее оригинала. Возможно - намного медленнее. А вот реализация
той же функциональности...
--
Artem Chuprina
RFC2822: <ran{}ran.pp.ru> Jabber: ran@jabber.ran.pp.ru
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
-- Phil Greenspun
"Including Common Lisp."
-- Robert Morris
Reply to: