Здравствуйте, VladD2, Вы писали:

AVK>>Тут я немножко наврал. Кое какие ограничения на типы в result expression имеются и описаны в п. 9.3 стандарта SQL'92.

VD>У тебя он явно под рукой. Приведи, плиз, цитату.

Там много.

AVK>>Параметры запроса. Типы их нигде в самом запросе не декларируются (за исключением хранимок).

VD>А ничего, что, скажем в C# в вызовах методов (и в LINQ-запросах) тоже не описываются типы параметров (да и возвращаемого значения тоже, начиная с 3.0)?

Типы параметров, в отличие от, вывести невозможно. Поэтому в рантайме их приходится задавать отдельно.

Здравствуйте, AndrewVK, Вы писали:

VD>>Дык макросам фиолетово скомпилированы ли типы которые эти макросы анализируют или просто находятся в виде исходников. Для них это прозрачно.

AVK>Зачем мне для анализа скомпилированных типов макросы? И где эти макросы надо применять, если на момент деплоймента никаких исходников нет вобще?

Кроме анализа еще есть стадия генерации кода. Вот она радикально упростится. Кроме того руки будут развязаны и можно будет пользоваться не только скомпилированными сборками в качестве входных данных, но и обычным кодом. А это уже может предоставить новые, более тонкие пути решения проблем. Становится не нужным ХМЛ и трах с ХСЛТ, так как нужную информацию можно описать в терминах основного языка. В общем, более гибкий подход. Лучший контроль (да, просто его наличие на ранних стадиях). Отсуствие необходимости делать мешанину из языков.

VD>>Понимаю. Видимо примитивные системы очень тяжелы в разработке, раз вы их так долго пишите...

AVK>А кто тебе сказал, что у нас проблемы с проксями? Их код черт знает сколько времени не трогался вобще.

Да, я ничего и не говорю. Просто все просто, а конца и края не видно.

Здравствуйте, EvilChild, Вы писали:

VD>>Вообще-то это была ирония, если кто не заметил...
EC>Ты в таких сложных местах комментарии (смайлы) добавляй,
EC>потому как людям не использующим макросы такой юмор ещё не понятен

А людям не кажется странным, что термин "очевидно" употреблен к двум страницам кода?

Здравствуйте, AndrewVK, Вы писали:

AVK>>>Тут я немножко наврал. Кое какие ограничения на типы в result expression имеются и описаны в п. 9.3 стандарта SQL'92.

VD>>У тебя он явно под рукой. Приведи, плиз, цитату.

AVK>Там много.

А ты процитируй, то о чем ведешь речь.

AVK>Типы параметров, в отличие от, вывести невозможно. Поэтому в рантайме их приходится задавать отдельно.

1. Возможно.
2. Если в рантайме их задают, значит они есть.

Здравствуйте, VladD2, Вы писали:

VD>Кроме анализа еще есть стадия генерации кода. Вот она радикально упростится.

За счет чего?

VD> Кроме того руки будут развязаны и можно будет пользоваться не только скомпилированными сборками в качестве входных данных

Это просто не нужно.

AVK>>А кто тебе сказал, что у нас проблемы с проксями? Их код черт знает сколько времени не трогался вобще.

VD>Да, я ничего и не говорю. Просто все просто, а конца и края не видно.

Это демагогия.

Здравствуйте, VladD2, Вы писали:

VD>А ты процитируй, то о чем ведешь речь.

9.3 Set operation result data types

Function

Specify the Syntax Rules and result data types for <case expres-
sion>s and <query expression>s having set operators.

Syntax Rules

1) Let DTS be a set of data types specified in an application of
this Subclause.

2) All of the data types in DTS shall be comparable.

3) Case:

a) If any of the data types in DTS is character string, then
all data types in DTS shall be character string, and all of
them shall have the same character repertoire. That charac-
ter repertoire is the character repertoire of the result. The
character set of the result is the character set of one of
the data types in DTS. The specific character set chosen is
implementation-dependent. The collating sequence and the co-
ercibility attribute are determined as specified in Table 2,
"Collating coercibility rules for dyadic operators".

Case:

i) If any of the data types in DTS is variable-length char-
acter string, then the result data type is variable-length
character string with maximum length in characters equal
to the maximum of the lengths in characters and maximum
lengths in characters of the data types in DTS.

ii) Otherwise, the result data type is fixed-length character
string with length in characters equal to the maximum of
the lengths in characters of the data types in DTS.

b) If any of the data types in DTS is bit string, then all data
types in DTS shall be bit string.

Case:

i) If any of the data types in DTS is variable-length bit
string, then the result data type is variable-length bit
string with maximum length in bits equal to the maximum of
the lengths in bits and maximum lengths in bits of the data
types in DTS.

ii) Otherwise, the result data type is fixed-length bit string
with length in bits equal to the maximum of the lengths in
bits of the data types in DTS.

c) If all of the data types in DTS are exact numeric, then the
result data type is exact numeric with implementation-defined
precision and with scale equal to the maximum of the scales
of the data types in DTS.

d) If any data type in DTS is approximate numeric, then each
data type in DTS shall be numeric and the result data type is
approximate numeric with implementation-defined precision.

e) If any data type in DTS is a datetime data type, then each
data type in DTS shall be the same datetime data type. The
result data type is the same datetime data type.

f) If any data type in DTS is interval, then each data type
in DTS shall be interval. If the precision of any data type
in DTS specifies YEAR or MONTH, then the precision of each
data type shall specify only YEAR or MONTH. If the preci-
sion of any data type in DTS specifies DAY, HOUR, MINUTE, or
SECOND(N), then the precision of no data type of DTS shall
specify the <datetime field>s YEAR and MONTH. The result
data type is interval with precision "S TO E", where S and E
are the most significant of the <start field>s and the least
significant of the <end field>s of the data types in DTS,
respectively.

General Rules

None.

AVK>>Типы параметров, в отличие от, вывести невозможно. Поэтому в рантайме их приходится задавать отдельно.

VD>1. Возможно.

SELECT @param

Выводи.

VD>2. Если в рантайме их задают, значит они есть.

Выяснение типов в рантайме как раз и есть динамическая типизиция.

Здравствуйте, VladD2, Вы писали:

VD>Да, я ничего и не говорю. Просто все просто, а конца и края не видно.

Не надо спорить с АВК на его территории Он принял архитектурное решение, при котором макросы не могут проявить себя никак. Пытаться что-то доказать в такой ситуации что-либо совершенно бесполезное занятие. Здесь вопрос нужно ставить совершенно по-другому. Можно ли найти решение при для той задачи, которую решает АВК, при котором макросы проявят себя в полную силу.

Здравствуйте, IT, Вы писали:

IT>Он принял архитектурное решение

Решение принял не я. Отсутствие исходников фигурирует в ТЗ.

Здравствуйте, IT, Вы писали:

IT>макросы не могут проявить себя никак

Не "макросы" вообще, а "макросы N", btw

Здравствуйте, AndrewVK, Вы писали:

IT>>Он принял архитектурное решение

AVK>Решение принял не я. Отсутствие исходников фигурирует в ТЗ.

Какая связь между отсутствием исходников и генерацией проксей? Зачем вообще нужно генерировать прокси?

Здравствуйте, IT, Вы писали:

AVK>>Решение принял не я. Отсутствие исходников фигурирует в ТЗ.

IT>Какая связь между отсутствием исходников и генерацией проксей? Зачем вообще нужно генерировать прокси?

Затем, что сервер должен перехватывать обращения к бизнес-классам. Сразу оговорюсь — написание бизнес-кода на Nemerle и наличие рантайма сервера при компиляции неприемлемо все по тому же ТЗ.

Здравствуйте, VladD2, Вы писали:

VD>А людям не кажется странным, что термин "очевидно" употреблен к двум страницам кода?
Может для тебя это и очевидно, мне почём знать?

Здравствуйте, AndrewVK, Вы писали:

AVK>Затем, что сервер должен перехватывать обращения к бизнес-классам. Сразу оговорюсь — написание бизнес-кода на Nemerle и наличие рантайма сервера при компиляции неприемлемо все по тому же ТЗ.

А кто ТЗ составлял?

Здравствуйте, cl-user, Вы писали:

CU>Здравствуйте, FR, Вы писали:

FR>>У форта для близких к железу решений есть два железных преимущества, легкость портирования (аппаратно зависимые части ядра всего килобайты) и компактность получаемого кода (обгоняет многие ассемблеры). Поэтому для встраиваемых устройств очень хороший выбор. Кроме того по параметру размер реализации / высокоуровневость кода, форт рекордсмен до сих пор.

CU>Так я и не спорил с применением во всяких контроллерах и прочей "ембедщине". Но тут его вроде как GPL предлагали?..

А ты почитай внимательно, что и как предлагали. Меньше флейма будет. Речь идет исключительно об встраиваемой разработке. Я знаю, что Локотков занимается embedded разработкой — по-моему либо он либо я об этом явно сказали, и хорошо представляю, какой именно совет ему даю.

Здравствуйте, cl-user, Вы писали:

G>> Форт (есть такой жутко гибкий макроязык для встраиваемых систем — по гибкости не уступает LISP, по близости к железу — ассемблеру и С).

CU>"Твои слова да богу в уши"

Спасибо, не надо. Ты бы читал внимательнее посты, спорил бы меньше.

CU>Есть реализация (многоплатформенная и многопроцессорная), оптимально использующая при "шитье" все регистры используемых процессоров и/или умеющая оптимизировать свой "шитый" код?

Многоплатформенную сделать труда не составит, конечно — я тебе могу на чистом С сделать замечательный кроссплатформенный форт. Я это уже делал один раз, кстати. Многопроцессорные реализации ФОРТ-а есть, проблем с этим никаких, но это не вперлость при ембеддед разработке никак, там обыкновенно одно управляющее ядро. Шитый код оптимизировать глупо — надо оптимизировать критичные куски целиком (их немного) переписыванием на С (на asm-е под MIPS особо не наоптимизишь — gcc совершенно ацки компилить умеет, накладывая аппаратное умножение на второе умножение через сдвиги-сложения, используя слот инструкции после джампов, и прочее). Форт-машина должна быть тупой, это ее основное преимущество. Задействовать все регистры при "шитье" тоже, гхм, не нужно, наоборот, надо по возможности задействовать минимум регистров.

Впрочем, голову стека данных я постарался бы хранить в отдельном регистре, как делают практически все аппаратные реализации форта — уж больно сильно это арифметику ускоряет — всего одно чтение памяти на операцию. Обеспечивается это буквально несколькими коротенькими вставками на ассемблере. Использовать два регистра под верхушку стека имеет смысл для суперскалярных процессоров, и навороченных процов, которые могут наложить обращение в память на вычисления. Это видишь ли не случай в embedded-разработке, так что смысла не имеет. Хотя, если говорить о сигнальных процах, типа блэкфина и прочих ацких сигнальниках... Или модных ядрах типа SH... То множно и задуматься.

CU>Гибкость — да, скорость — нет.

На эту тему тебе хорошо ответили ниже по ветке.

Здравствуйте, Gaperton, Вы писали:

G>Шитый код оптимизировать глупо — надо оптимизировать критичные куски целиком (их немного) переписыванием на С (на asm-е под MIPS особо не наоптимизишь — gcc совершенно ацки компилить умеет, накладывая аппаратное умножение на второе умножение через сдвиги-сложения, используя слот инструкции после джампов, и прочее). Форт-машина должна быть тупой, это ее основное преимущество. Задействовать все регистры при "шитье" тоже, гхм, не нужно, наоборот, надо по возможности задействовать минимум регистров.

JFYI, я для Samsung-а переписал main loop явовского интерпретатора (KVM) на ассемблере (MIPS). Ускорение вышло в 2 раза. В основном за счёт правильного джамп-а при диспатчинге опкода (все хэндлеры имели по 16 или 32 комманды, не помню), расположения верхушки стека в регистре и т.п. Потом подрихтовал на ассемблере вызов методов, оптимизировал байткод при загрузке класса, оптимизнул несколько библиотечных методов и синхронизацию — и вышло ещё ускорение в 1.8 раз.

Здравствуйте, mkizub, Вы писали:

M>Здравствуйте, FR, Вы писали:

FR>>По сравнению с той же явой которую суют сейчас в мобилки форт будет очень шустрым, он медленен только относительно достаточно хорошего си компилятора.

M>Не будет. Совать форт, написанный непонятно кем, в свой телефон нормальный человек не будет. Потому как фортовских программ с встроенным вирусом образуется больше, чем сейчас спама образовалось из e-mail-а.

Ограничить доступ к ресурсам телефона для форт-машины — проблем нет никаких. Будет так же безопасно. Правда в форте есть адресная арифметика... Ну и то не беда — надо будет в каждой операции записи "!" маскировать адрес чтоб уписать его в сегмент, и всего делов. Совместимым на уровне байт-кода меж разными телефонами такой форт сделать тяжело — но можно, надо ввести переносимое промежуточное представление, либо прям в исходниках программу заливать.

Короче, технических проблем нет. Другое дело, что форт все-таки пониже уровнем чем ява и С — это практически ассемблер (ну хорошо — макроассемблер). Писать на нем было бы тяжело. Гражданские языки типа С (которые требуют поддерки стек фреймов) в него компилятся тоже непросто — с проблемами. В общем, явский байт-код далеко не самый плохой вариант — к чему-то подобному и пришлось бы прийти в любом случае.

M>Явовский код — это такой же стек, как и фортовский, плюс проверки на нулевой указатель, выход за границы массивов, проверки типов и прочее. Явовскому интерпретатору просто не от чего быть медленее, кроме проверок — а без них левый код на мобилку не загрузишь.

Есть от чего. Там в байткоде на один уровень косвенности больше, байткод это не просто адреса, и если не применяется JIT, (а он не применяется в JVM которые реализуют CLDC, например, в KVM — том самом, который в мобильных телефонах), то явский байткод будет медленнее.

M>Больше того, нынешние мобилки прекрасно позволяют компилировать яву в нэйтивный код, памяти у них хватает. И для распространённых на мобилках CPU эти компиляторы написаны и работают. Интепретатор форта не сдюжит против компилятора в нэйтивный код никаким местом.

Мобилы реализуют CLDC и применяют в массе своей KVM в котором JIT не предусмотрен, поэтому ява для них ацки тормозит. Кроме случая, если в них как в смартфонах применяется ARM c Jazelle, тогда там ява должна быть быстра.

Здравствуйте, Gaperton, Вы писали:

M>>Явовский код — это такой же стек, как и фортовский, плюс проверки на нулевой указатель, выход за границы массивов, проверки типов и прочее. Явовскому интерпретатору просто не от чего быть медленее, кроме проверок — а без них левый код на мобилку не загрузишь.

G>Есть от чего. Там в байткоде на один уровень косвенности больше, байткод это не просто адреса, и если не применяется JIT, (а он не применяется в JVM которые реализуют CLDC, например, в KVM — том самом, который в мобильных телефонах), то явский байткод будет медленнее.

О каком дополнительном уровне косвенности ты говоришь?

M>>Больше того, нынешние мобилки прекрасно позволяют компилировать яву в нэйтивный код, памяти у них хватает. И для распространённых на мобилках CPU эти компиляторы написаны и работают. Интепретатор форта не сдюжит против компилятора в нэйтивный код никаким местом.

G>Мобилы реализуют CLDC и применяют в массе своей KVM в котором JIT не предусмотрен, поэтому ява для них ацки тормозит. Кроме случая, если в них как в смартфонах применяется ARM c Jazelle, тогда там ява должна быть быстра.

Ща. Я больше трёх лет работал в Esmertec. Их продукт (Jbed) — это AOP компилятор явы. А библиотечные функции компилятся в нэйтивный код на хосте, и раборают (сюрприз!) быстрее С-шных (за счёт интеграции с GC и избегания алиасинга, в C надо лепить volatile указателям, а в явовском коде не надо, плюс unsafe хаки в компиляторе для библиотечного кода). Jazelle — мёртворождённая технология. В ней переключение между режимом java и arm/thumb слишком медленное. Следующая версия ARM-а уже будет иметь инструкции для аппаратной проверки нулевых указателей, границ массива и ещё нескольких шибко удобных вещей — код (нэйтивный) в который компилятется ява имеет размер меньше байткода, а скорость работы сам понимаешь — полная. Тут Jazelle вообще пипец настанет.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, BulatZiganshin, Вы писали:

BZ>>так вот, описание констант или темплейтов в C++ тоже можно считать средставми макроподстановки и генерации кода. тем не менее это средства, которые сингтегрированы в сам язык, и никто их не отделяет от "обычной" порграммы.

VD>Шаблоны С++ не позволяют программировать генерацию. Они просто позволяют подставить праметры. Разумется, что это справедливо, если мы не ведем речь о метапрограммировании на шаблонах в стиле Александреску (с испоьзованием побочных эффектов при частичной специализации и рекурсивных шаблонах).

она программируется, но на другом языке. понимаешь, метаязык — это тоже язык, хотя он выглядит по-другому и даже может быть не Тьюринг-полным и вообще его предназначение — не вычисления, как у базового языка, а генерация кода. вот макроязыки типа немерле, TH или препроцессора pl/1 — они обычные императвиные языки, по идеологии похожие на какой-нибудь С

язык же темпоейтов C++ насколько я в курсе — фнкциоанльый и при этом Тьюринг полный. язык typeclasses хаскеля — логический и тоже Тьюринг-полный. на них обоих иожно реализовать, к примеру, обычную арифметику, используя так называемые Peano numbers — числа, представленные типами:

data Zero 
data Succ a
-- тип Succ Zero представляет 1, Succ(Succ Zero) - 2 и т.д.

class Add a b c | a,b->c  -- класс описывает соотноешние между трёмя типами a,b,c такими что a+b=c
instance Add Zero Zero Zero
instance Add a b c => Add (Succ a) b (Succ c)  
instance Add a b c => Add a (Succ b) (Succ c)  
-- согласно этим правилам вывода этому классу например принадлежит 
-- Add (Succ(Succ Zero)) (Succ Zero) (Succ (Succ(Succ Zero)))

так вот, в то время как макросы обеспечивают доступ к AST генерируемого кода плюс обычные средства ЯП для манипуляции с ним — templates/generics предоставляют свой собственный набор операций, нацеленный именно на generic программирование, и в этой области они позволяют достигать того же эффекта затратой куда меньших усилий. сишные темплейты вероятно не позволяют реализовать то, что тебе нужно, но в хаскеле это одна из поппулярных областей исследований и среди хаскеловских систем generic программирования есть достаточно мощные

в частности, syb подход (у которого есть динамическая и compile-time реализации) позволяет строить достаточно мощные функции, производящие обход структуры данных и различные манипуляции над ней — map, fold, zip и т.д. в статическом подходе с помощью type classes генерится код, специфичный для данного конретного типа. т.е. запись типа такой:

data T = A Int T | B Int String | C String | D [T]
f = gmap (+1)

генерится такой:

f (A n t) = A (n+1) (f t)
f (B n s) = B (n+1) s
f (C s)   = C s
f (D ts)  = D (map f ts)

можешь нарисовать определения type classes/templates для операции "делать +1 рекурсивно" и убедиться, что именно такой код сгенерится. хаскел просто предсоатвляет более высокооуровневые средства, позволяя определить универсальную порцедуру gmap, через которую можно выражать любые рекурсивные обходы данных, в то втремя как в C++ каждый такой gmap(+1) придётся писать индивидуально

подытоживая — речь идёт о том, что задачи generic программирования, которые в C* языках имеют решение только черехз макросы, здесь могут быть рещшены другими средствами, непосредственно отражающими специфику области. вот и всё. макросы, как всегда — универсальный инструмент для реализации всего того, чего ещё нет в языке

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, BulatZiganshin, Вы писали:

BZ>>далее, ты упираешь на эффективность генерации кода во время компиляции.
BZ>> рднако опттимизировать скорость кода следует только в том случае, когда...

VD>Это все лирика. Для решения конкретных задач она непригодна. Я не из тех кто будет заниматься глупыми предварительными оптимизациями. Поверь, задача того трбовала.

BZ>> это критично для проекта в целом, в большинстве же случаев следует оптимизировать время ращработчика. и двухуровневая система язык+макросы усложняет его жизнь

VD>Это прописные истины. Я с ними не спорю. Вот только они не отменяют того факта, что на Хаскеле получаетя другое решение. С другими характеристиками и с другими последствиями.

а причём тут ваша частная задача? про неё ты можешь говорить что угодно — это твоё право. в целом же generic программирование, как и программирование вообще, требует оптимизации не более чем в 20% случаев