История изменений

Последний коммит в 2013. Как язык его уже никто не развивает и развивать не будет. Там, где оно еще применяется, в 95% случаев плюют на декларативность и тупо засовывают в grammar C++ код.

Всегда ли есть способ обойтись одной лишь декларативностью? Рассмотрим например очередной прототип примитивной файловой системы, где для простоты не будет никакой фрагментации, и файлы целиком будут идти сплошным куском, длина имени файла ограничена в 4 байта и структуры, описыващие файлы, отсортированы по именам файлов:

used bytes | text description          | d
-----------+---------------------------+---------------
0..3       | ASCII header "MyFS"       |\ struct header
4..7       | uint32_t numoffiles = 3   |/
8..11      | ASCII file_1 name "aaaa"  |\
12..15     | uint32_t file_1_start = 0 | > struct file 
16..19     | uint32_t file_1_len   = 10|/
20..23     | ASCII file_2 name "bbbb"  |\
24..27     | uint32_t file_2_start = 11| > struct file
28..31     | uint32_t file_2_len   = 7 |/
32..35     | ASCII file_3 name "сссc"  |\
36..39     | uint32_t file_3_start = 18| > struct file
40..43     | uint32_t file_3_len   = 3 |/
// конец описания = 44
44..53     | file_1_data {binary blob} | 10 byte blob
54..60     | file_2_data {binary blob} | 7  byte blob
61..63     | file_3_data {binary blob} | 3  byte blob

Есть структура header в которой записано два поля: сам заголовок и numoffiles из которого известно количество файлов в этой ФС. Далее идет структуры file (в количестве, равном количеству файлов в ФС) в которых записан адрес с которого файл начинается (этот адрес относительно конца этих структур file). При этом есть один важный момент : файлы упорядочены по возрастанию. Если у нас будет 10000 файлов в этой ФС, то чтобы по имени достать оттуда один конкретный файл (т.е. узнать адрес начала и размер в байтах) можно применить двоичный поиск, найдя это в худшем случае за O(log n) от количества файлов. Если же просто перебирать последовательно все структуры, получим в результате O(n) что довольно плохо, если файлов много. Так вот, как вы предлагаете декларативно описать то, что тут вот файлы по имени отсортированы, и чтобы по этому декларативному описанию был сгенерирован код, который бы применял двоичный поиск для вытаскивания файла из ФС?

А если применяется что-то более сложное, например хеш-таблицы? Тут уж без встраивания некоего языка программирования не обойтись, и при этом это язык надо еще уметь эффективно транслировать во все целевые языки... Довольно сложная задача, как по мне.

Можно ли конкретно очертить круг задач, которые должны быть решаемыми через KS, и которые уже выходят за рамки?

Последний коммит в 2013. Как язык его уже никто не развивает и развивать не будет. Там, где оно еще применяется, в 95% случаев плюют на декларативность и тупо засовывают в grammar C++ код.

Всегда ли есть способ обойтись одной лишь декларативностью? Рассмотрим например очередной прототип примитивной файловой системы, где для простоты не будет никакой фрагментации, и файлы целиком будут идти сплошным куском, длина имени файла ограничена в 4 байта и структуры, описыващие файлы, отсортированы по именам файлов:

used bytes | text description          | d
-----------+---------------------------+---------------
0..4       | ASCII header "MyFS"       |\ struct header
5..8       | uint32_t numoffiles = 3   |/
9..12      | ASCII file_1 name "aaaa"  |\
13..16     | uint32_t file_1_start = 0 | > struct file 
17..20     | uint32_t file_1_len   = 10|/
21..24     | ASCII file_2 name "bbbb"  |\
25..28     | uint32_t file_2_start = 11| > struct file
29..32     | uint32_t file_2_len   = 7 |/
33..36     | ASCII file_3 name "сссc"  |\
37..40     | uint32_t file_3_start = 18| > struct file
41..44     | uint32_t file_3_len   = 3 |/
// конец описания = 45
45..54     | file_1_data {binary blob} | 10 byte blob
55..61     | file_2_data {binary blob} | 7  byte blob
62..64     | file_3_data {binary blob} | 3  byte blob

Есть структура header в которой записано два поля: сам заголовок и numoffiles из которого известно количество файлов в этой ФС. Далее идет структуры file (в количестве, равном количеству файлов в ФС) в которых записан адрес с которого файл начинается (этот адрес относительно конца этих структур file). При этом есть один важный момент : файлы упорядочены по возрастанию. Если у нас будет 10000 файлов в этой ФС, то чтобы по имени достать оттуда один конкретный файл (т.е. узнать адрес начала и размер в байтах) можно применить двоичный поиск, найдя это в худшем случае за O(log n) от количества файлов. Если же просто перебирать последовательно все структуры, получим в результате O(n) что довольно плохо, если файлов много. Так вот, как вы предлагаете декларативно описать то, что тут вот файлы по имени отсортированы, и чтобы по этому декларативному описанию был сгенерирован код, который бы применял двоичный поиск для вытаскивания файла из ФС?

А если применяется что-то более сложное, например хеш-таблицы? Тут уж без встраивания некоего языка программирования не обойтись, и при этом это язык надо еще уметь эффективно транслировать во все целевые языки... Довольно сложная задача, как по мне.

Можно ли конкретно очертить круг задач, которые должны быть решаемыми через KS, и которые уже выходят за рамки?

Последний коммит в 2013. Как язык его уже никто не развивает и развивать не будет. Там, где оно еще применяется, в 95% случаев плюют на декларативность и тупо засовывают в grammar C++ код.

Всегда ли есть способ обойтись одной лишь декларативностью? Рассмотрим например очередной прототип примитивной файловой системы, где для простоты не будет никакой фрагментации, и файлы целиком будут идти сплошным куском, длина имени файла ограничена в 4 байта и структуры, описыващие файлы, отсортированы по именам файлов:

used bytes | text description          | d
-----------+---------------------------+---------------
0..4       | ASCII header "MyFS"       |\ struct header
5..8       | uint32_t numoffiles = 3   |/
9..12      | ASCII file_1 name "aaaa"  |\
13..16     | uint32_t file_1_start = 0 | > struct file 
17..20     | uint32_t file_1_len   = 10|/
21..24     | ASCII file_2 name "bbbb"  |\
25..28     | uint32_t file_2_start = 11| > struct file
29..32     | uint32_t file_2_len   = 7 |/
33..36     | ASCII file_3 name "сссc"  |\
37..40     | uint32_t file_3_start = 18| > struct file
41..44     | uint32_t file_3_len   = 3 |/
// конец описания = 45
45..55     | file_1_data {binary blob} | 10 byte blob
56..63     | file_2_data {binary blob} | 7  byte blob
64..66     | file_3_data {binary blob} | 3  byte blob

Есть структура header в которой записано два поля: сам заголовок и numoffiles из которого известно количество файлов в этой ФС. Далее идет структуры file (в количестве, равном количеству файлов в ФС) в которых записан адрес с которого файл начинается (этот адрес относительно конца этих структур file). При этом есть один важный момент : файлы упорядочены по возрастанию. Если у нас будет 10000 файлов в этой ФС, то чтобы по имени достать оттуда один конкретный файл (т.е. узнать адрес начала и размер в байтах) можно применить двоичный поиск, найдя это в худшем случае за O(log n) от количества файлов. Если же просто перебирать последовательно все структуры, получим в результате O(n) что довольно плохо, если файлов много. Так вот, как вы предлагаете декларативно описать то, что тут вот файлы по имени отсортированы, и чтобы по этому декларативному описанию был сгенерирован код, который бы применял двоичный поиск для вытаскивания файла из ФС?

А если применяется что-то более сложное, например хеш-таблицы? Тут уж без встраивания некоего языка программирования не обойтись, и при этом это язык надо еще уметь эффективно транслировать во все целевые языки... Довольно сложная задача, как по мне.

Можно ли конкретно очертить круг задач, которые должны быть решаемыми через KS, и которые уже выходят за рамки?

Последний коммит в 2013. Как язык его уже никто не развивает и развивать не будет. Там, где оно еще применяется, в 95% случаев плюют на декларативность и тупо засовывают в grammar C++ код.

Всегда ли есть способ обойтись одной лишь декларативностью? Рассмотрим например очередной прототип примитивной файловой системы, где для простоты не будет никакой фрагментации, и файлы целиком будут идти друг за другом в алфавитном порядке, длина имени файла ограничена в 4 байта:

used bytes | text description          | d
-----------+---------------------------+---------------
0..4       | ASCII header "MyFS"       |\ struct header
5..8       | uint32_t numoffiles = 3   |/
9..12      | ASCII file_1 name "aaaa"  |\
13..16     | uint32_t file_1_start = 0 | > struct file 
17..20     | uint32_t file_1_len   = 10|/
21..24     | ASCII file_2 name "bbbb"  |\
25..28     | uint32_t file_2_start = 11| > struct file
29..32     | uint32_t file_2_len   = 7 |/
33..36     | ASCII file_3 name "сссc"  |\
37..40     | uint32_t file_3_start = 18| > struct file
41..44     | uint32_t file_3_len   = 3 |/
// конец описания = 45
45..55     | file_1_data {binary blob} | 10 byte blob
56..63     | file_2_data {binary blob} | 7  byte blob
64..66     | file_3_data {binary blob} | 3  byte blob

Есть структура header в которой записано два поля: сам заголовок и numoffiles из которого известно количество файлов в этой ФС. Далее идет структуры file (в количестве, равном количеству файлов в ФС) в которых записан адрес с которого файл начинается (этот адрес относительно конца этих структур file). При этом есть один важный момент : файлы упорядочены по возрастанию. Если у нас будет 10000 файлов в этой ФС, то чтобы по имени достать оттуда один конкретный файл (т.е. узнать адрес начала и размер в байтах) можно применить двоичный поиск, найдя это в худшем случае за O(log n) от количества файлов. Если же просто перебирать последовательно все структуры, получим в результате O(n) что довольно плохо, если файлов много. Так вот, как вы предлагаете декларативно описать то, что тут вот файлы по имени отсортированы, и чтобы по этому декларативному описанию был сгенерирован код, который бы применял двоичный поиск для вытаскивания файла из ФС?

А если применяется что-то более сложное, например хеш-таблицы? Тут уж без встраивания некоего языка программирования не обойтись, и при этом это язык надо еще уметь эффективно транслировать во все целевые языки... Довольно сложная задача, как по мне.

Можно ли конкретно очертить круг задач, которые должны быть решаемыми через KS, и которые уже выходят за рамки?