Oberon space
General Category => Общий раздел => Тема начата: Geniepro от Апрель 05, 2011, 06:21:53 am
-
Баловство с препроцессором -- немного оффтопик на Оберон-форуме, но позволяет продемонстрировать, как за счёт простейших сишных макросов можно не только симитировать цикл Дейкстры (http://oberon.talk4fun.net/index.php?topic=39.msg1149#msg1149), но и повысить надёжность софта за счёт автоматизации построения некоторых специализированных структур управления.
Вот, предположим, нужно, что бы в некоей процедуры куски кода выполнялись поочерёдно при каждом вызове этой процедуры, причём эти куски кода нежелательно выделять в отдельные процедуры, поскольку сами по себе они большого смысла не имеют.
В сях это можно изобразить примерно так:
void test(void)
{
static int step = 0;
switch (step++)
{
case 0:
printf("step 0\\n");
break;
case 1:
printf("step 1\\n");
break;
case 2:
printf("step 2\\n");
break;
case 3:
printf("step 3\\n");
default:
step = 0;
break;
}
}
void main(void)
{
int i;
for (i = 0; i < 10; i++)
{
test();
}
}
step 0
step 1
step 2
step 3
step 0
step 1
step 2
step 3
step 0
step 1
Проблема: нужно вручную помечать номер каждого шага в "case x:" (а их может быть немало, легко обсчитаться).
Решение проблемы: сделать макросы, иммтирующие новую языковую конструкцию, которые возьмут на себя эту рутину.
valeksey предложил такой вариант (http://paste.org.ru/?w012wp):
#define FIRST(code) { int flag = 0; static int i = 0; if (i==0) { { code }; flag = 1; }
#define NEXT(code) if (!flag && i == __LINE__) { { code }; flag = 1; } else if (flag == 1) { i = __LINE__; flag=2;}
#define LAST(code) if (!flag && i == __LINE__) { { code }; i = 0; } else if (flag == 1) { i = __LINE__; } }
void test(void)
{
FIRST
(
printf("step 0\\n");
)
NEXT
(
printf("step 1\\n");
)
NEXT
(
printf("step 2\\n");
)
LAST
(
printf("step 3\\n");
)
}
Это решение меня смутило количеством if-ов и не вполне очевидной логикой работы, поэтому я сделал такой вариант:
#define FIRST(var) { static int STEPPER_##var##step = 0; switch (STEPPER_##var##step) { case 0:
#define NEXT(var) STEPPER_##var##step = __LINE__; break; case __LINE__:
#define END(var) default: STEPPER_##var##step = 0; break; } }
void test(void)
{
FIRST(some_id)
printf("step 0\\n");
NEXT(some_id)
printf("step 1\\n");
NEXT(some_id)
printf("step 2\\n");
NEXT(some_id)
printf("step 3\\n");
END(some_id)
}
Мне кажется, что тут логика выполнения более понятно, более нагляден поток выполнения в раскрытых макросах.
Ну и такой варант может быть вложенным, так как эта конструкция параметризуется неким идентификатором...
-
Кроме того твой вариант работает быстрее.
Но есть нюанс. У тебя в твоих блоках кода не получится объявлять перменные, а это иногда нужно. Для того, чтобы их объявить, придется писать как-то так:
void test(void)
{
FIRST(some_id)
{
int j = 0;
printf("step 0 %d\\n", j);
}
NEXT(some_id)
{
printf("step 1\\n");
}
NEXT(some_id)
{
printf("step 2\\n");
}
NEXT(some_id)
{
printf("step 3\\n");
}
END(some_id)
}
Ну и return из середины блока тут точно также как и у меня приводит к тому, что в следующий раз будет исполняться тот же самый блок, а не следующий.
Ну а параметризацию макросов я же предлагал. Только я посчитал что матрёшка тут не нужна, а в случае чего сделать вариант с параметризацией будет тривиально.
-
Но есть нюанс. У тебя в твоих блоках кода не получится объявлять перменные, а это иногда нужно. Для того, чтобы их объявить, придется писать как-то так:
FIRST(some_id)
{
int j = 0;
printf("step 0 %d\\n", j);
}
Да, я в результате тоже пришёл к этим фигурным скобкам. Ну, они тут более ожидаемы, чем круглые.
А, да, я так и задеплоил эти макросы в свой уютненький продакшн -- пусть следующие поколения прогеров, что меня заменят, подивятся... :о)
Ну и return из середины блока тут точно также как и у меня приводит к тому, что в следующий раз будет исполняться тот же самый блок, а не следующий.
Эти макросы и специально сделал, что бы избавиться от кучи ретурнов в первоначальном коде, наиндокоденном сотрудником. Рефакторинг пришлось делать, млин... :о)
Если нужно досрочно выйти из блока -- будет if-then-else вместо этого goto замаскированного под return...
-
Да, я в результате тоже пришёл к этим фигурным скобкам. Ну, они тут более ожидаемы, чем круглые.
А, да, я так и задеплоил эти макросы в свой уютненький продакшн -- пусть следующие поколения прогеров, что меня заменят, подивятся... :о)
...
Если нужно досрочно выйти из блока -- будет if-then-else вместо этого goto замаскированного под return...
Дык я к тому, что следующие поколения удивятся когда им нужно будет поправить что-то в этом коде и они, по привычке, где-нибудь воткнут что-то вроде:
if (!cond) return; // предусловие типа такое
И внезапно у них там это дело может зациклиться.
Собственно правило такое -- любая абстракция должна быть документирована, и чем выше и сложнее абстракция, тем подробней должна быть документирована.
-
Вот, предположим, нужно, что бы в некоей процедуры куски кода выполнялись поочерёдно при каждом вызове этой процедуры, причём эти куски кода нежелательно выделять в отдельные процедуры, поскольку сами по себе они большого смысла не имеют.
Предлагаю всем участникам соревнований, написать, как нужно сделать это по-хорошему.
Без всяких костылей, так сказать, Идеальный Конечный Результат. На идеальном языке, никаких ограничений для полета фантазии.
У меня есть вариант, выложу его чуть позже.
-
Вот, предположим, нужно, что бы в некоей процедуры куски кода выполнялись поочерёдно при каждом вызове этой процедуры, причём эти куски кода нежелательно выделять в отдельные процедуры, поскольку сами по себе они большого смысла не имеют.
Предлагаю всем участникам соревнований, написать, как нужно сделать это по-хорошему.
Вот мой вариант на КП:
MODULE TempTest3;
IMPORT Log := StdLog;
VAR s: INTEGER;
PROCEDURE Test*;
BEGIN
CASE s OF
| 0: Log.String("Test 0");
| 1: Log.String("Test 1");
| 2: Log.String("Test 2");
| 3: Log.String("Test 3");
END;
INC(s);
IF s > 3 THEN s := 0 END;
Log.Ln;
END Test;
BEGIN s := 0;
END TempTest3.
А в чём прикол-то? Тривиальная задачка. :)
-
Вот мой вариант на КП:
MODULE TempTest3;
IMPORT Log := StdLog;
VAR s: INTEGER;
PROCEDURE Test*;
BEGIN
CASE s OF
| 0: Log.String("Test 0");
| 1: Log.String("Test 1");
| 2: Log.String("Test 2");
| 3: Log.String("Test 3");
END;
INC(s);
IF s > 3 THEN s := 0 END;
Log.Ln;
END Test;
BEGIN s := 0;
END TempTest3.
А в чём прикол-то? Тривиальная задачка. :)
Во-первых в этом решении кто угодно (в этом модуле) может как угодно менять переменную s. При этом чисто из объявлений не следует какое значение s как эта процедура будет интерпретировать. То есть вызыв процедуры в текущем решении будет иметь семантику undefined behaviour.
Во-вторых там присутствуют магические константы. И эти магические константы придется ручками пересчитывать и переписывать при добавлении новых блоков кода. Ну и вообще совершенно бесполезная нумерация блоков кода, с точки зрения семантики программы.
Решение не безопасно.
-
Во-первых в этом решении кто угодно (в этом модуле) может как угодно менять переменную s. При этом чисто из объявлений не следует какое значение s как эта процедура будет интерпретировать. То есть вызыв процедуры в текущем решении будет иметь семантику undefined behaviour.
Во-вторых там присутствуют магические константы. И эти магические константы придется ручками пересчитывать и переписывать при добавлении новых блоков кода. Ну и вообще совершенно бесполезная нумерация блоков кода, с точки зрения семантики программы.
Решение не безопасно.
Даже не интересно отвечать. ;D
Тот, кто "как угодно может менять переменную s", тот точно так же может как угодно менять процедуру Test. Замечу, что переменная s не экспортируется.
Процедуры "живут" в модулях, а не сами по себе. Единицей компиляции является модуль, а не процедура. Единицей загрузки/выгрузки является модуль, а не процедура.
Глобальная переменная s имеет вполне определённый смысл: она показывает какой из блоков будет выполнен при следующем вызове процедуры Test.
"Магические константы" локализованы в процедуре Test. В случае добавления новых блоков, понадобится только расширение диапазона переменной s, а не "переписывание".
Может ты и не заметил, но секция ELSE у оператора CASE отсутствует. Значит, если программист где-то в этом модуле присвоит переменной s недопустимое значение, то ошибка обнаружится при первых N тестовых вызовах процедуры Test.
-
На хаскелле реализация этой конструкции выглядит крайне ужасно, пришлось счётчик шагов протаскивать, но вроде работает:
module Main where
import Control.Monad
import Data.IORef
execute_stepper :: [IO ()] -> IORef Int -> IO ()
execute_stepper actions stepper_var = do
let max_step = length actions
step <- readIORef stepper_var
if step < max_step
then do
actions !! step
stepper_var `modifyIORef` (\\x -> if x == max_step - 1 then 0 else x + 1)
else do
head actions
stepper_var `writeIORef` 1
test :: IORef Int -> IO ()
test = execute_stepper
[ do putStrLn "step 0"
, do putStrLn "step 1"
, do putStrLn "step 2"
, do putStrLn "step 3"
]
main = do
stepper_var <- newIORef 0
forM_ [1..10] $ \\i -> do
test stepper_var
output:
step 0
step 1
step 2
step 3
step 0
step 1
step 2
step 3
step 0
step 1
-
А в чём прикол-то? Тривиальная задачка. :)
Решённая Вами задачка и впрямь тривиальна, вот только это не та задачка, что обсуждается в данной теме.
Речь об автоматизации рутины с целью повышения надёжности программы, а Вы предлагаете делать всё вручную...
-
Вот, предположим, нужно, что бы в некоей процедуры куски кода выполнялись поочерёдно при каждом вызове этой процедуры, причём эти куски кода нежелательно выделять в отдельные процедуры, поскольку сами по себе они большого смысла не имеют.
Предлагаю всем участникам соревнований, написать, как нужно сделать это по-хорошему.
Без всяких костылей, так сказать, Идеальный Конечный Результат. На идеальном языке, никаких ограничений для полета фантазии.
Вы упростили формулировку задачи, сведя её к тривиальной... :о(
-
Пока низачот всем...
-
Пока низачот всем...
Ну нинаю, нинаю...
Мне зачет дважды, стопудово! :о))
-
Речь об автоматизации рутины с целью повышения надёжности программы, а Вы предлагаете делать всё вручную...
Автоматизация не всегда ведёт к повышению надёжности. Всё зависит от того, какой ценой даётся эта автоматизация. В конкретном данном примере автоматизация не нужна, IMHO.
-
В конкретном данном примере автоматизация не нужна, IMHO.
Почему?
-
В конкретном данном примере автоматизация не нужна, IMHO.
Почему?
Потому что то, автоматизированное решение получается сложнее ручного, а усложнение обычно не ведёт к повышению надёжности.
Но давайте дождёмся решения Петра Алмазова. Может быть оно повлияет на мою точку зрения.
-
Позволю себе выдвинуть такой тезис:
Тривиальные задачки не подлежат автоматизации.
Хотя, Geniepro возможно намеренно привёл такой простой пример только для демонстрации метода, так сказать. А в жизни предполагается использовать этот метод в более сложных случаях.
-
Позволю себе выдвинуть такой тезис:
Тривиальные задачки не подлежат автоматизации.
Тривиальные ЯП не позволяют автоматизировать тривиальные задачки :) Вон, освобождение ресурса - тоже тривиальная задача. А на обероне - не автоматизируется...
P.S. Еще один тезис: ошибка ручного кодирования тривиальных задач может приводить к нетривиальным багам :)
-
Вот, предположим, нужно, что бы в некоей процедуры куски кода выполнялись поочерёдно при каждом вызове этой процедуры, причём эти куски кода нежелательно выделять в отдельные процедуры, поскольку сами по себе они большого смысла не имеют.
Если речь идет о "кусках кода", то я однозначно начну с функциональных переменных... Применительно к данной задаче: список функторов и итератор.
-
Хотя, Geniepro возможно намеренно привёл такой простой пример только для демонстрации метода, так сказать. А в жизни предполагается использовать этот метод в более сложных случаях.
Естественно, я не стал приводить несколько страниц никому неинтересного тут кода, а выделил саму суть, что бы не отвлекала от идеи.
-
Если речь идет о "кусках кода", то я однозначно начну с функциональных переменных... Применительно к данной задаче: список функторов и итератор.
Тогда возникнет неудобство -- надо будет протаскивать некий контекст, который обрабатывается в этой функции...
-
Вот, предположим, нужно, что бы в некоей процедуры куски кода выполнялись поочерёдно при каждом вызове этой процедуры, причём эти куски кода нежелательно выделять в отдельные процедуры, поскольку сами по себе они большого смысла не имеют.
Если речь идет о "кусках кода", то я однозначно начну с функциональных переменных... Применительно к данной задаче: список функторов и итератор.
Если задачу решать в общем виде, то тут мы имеем банальный Конечный Автомат. И эта задача отлично на Сях решается (даже без плюсов), читабельно и не хуже чем на всяких там ФП и без таких сложных макросов. Но есть нюанс: в этом общем случае нам нужно знать имена состояний и событий (ибо они разные и нам нужно знать ху из ху) и они там будут. Но для данной задачи это избытычно, поэтому это решение (через полновесный КА) будет слишком громоздко.
Собственно говоря, вначале и Geniepro и я пытались решать задачу в рамках именно FSM. Уже потом лишние сущности были вначале отрезаны бритвой Оккама, а затем расстреляны из автомата Калашникова.
Вообще, эта задача решалась бы проще и правильней, если бы в сях были вложенные функции (в gcc есть такой расширизм, кстати).
-
Если речь идет о "кусках кода", то я однозначно начну с функциональных переменных... Применительно к данной задаче: список функторов и итератор.
Тогда возникнет неудобство -- надо будет протаскивать некий контекст, который обрабатывается в этой функции...
Ну это чисто синтаксическое неудобство. Оберонщикам, например, не привыкать ;) Зато все явно, тупо и тривиально:
struct context;
typedef void (*F)(context*);
F steps[] = {&step1, &step2, &step3};
int current_step = 0;
Не путать с приведенным обероновским примером - там тоже тривиально, но вручную :)
-
Вообще, эта задача решалась бы проще и правильней, если бы в сях были вложенные функции (в gcc есть такой расширизм, кстати).
Толку от вложенных функций не сильно много, если они не умеют "захватывать" котнекст. Не зря Вирту они не нравятся... ;)
-
Вообще, эта задача решалась бы проще и правильней, если бы в сях были вложенные функции (в gcc есть такой расширизм, кстати).
Толку от вложенных функций не сильно много, если они не умеют "захватывать" котнекст. Не зря Вирту они не нравятся... ;)
В данном случае они смогут захватить контекста достаточно для выполнения задачи.
-
Толку от вложенных функций не сильно много, если они не умеют "захватывать" котнекст. Не зря Вирту они не нравятся... ;)
В данном случае они смогут захватить контекста достаточно для выполнения задачи.
Угу. Шаг в сторону - и все падает :) Нафиг-нафиг... Хватит уже "недорешений". Или полноценные замыкания или не надо притворяться, что они есть и плодить потенциальные грабли.
-
Толку от вложенных функций не сильно много, если они не умеют "захватывать" котнекст. Не зря Вирту они не нравятся... ;)
В данном случае они смогут захватить контекста достаточно для выполнения задачи.
Угу. Шаг в сторону - и все падает :) Нафиг-нафиг... Хватит уже "недорешений". Или полноценные замыкания или не надо притворяться, что они есть и плодить потенциальные грабли.
Не понял. Нафига в данной задаче полноценные замыкания? И зачем тут тягать какой-то контекст?
-
Не понял. Нафига в данной задаче полноценные замыкания? И зачем тут тягать какой-то контекст?
В какой задаче? Напечатать printf'ом номер шага? :) Если там все-таки что-то более интересное подразумевается, то контекст вылезет. А оттуда и до замыканий совсем немного...
-
Не понял. Нафига в данной задаче полноценные замыкания? И зачем тут тягать какой-то контекст?
В какой задаче? Напечатать printf'ом номер шага? :) Если там все-таки что-то более интересное подразумевается, то контекст вылезет. А оттуда и до замыканий совсем немного...
Контекст у них у всех общий. Если совсем-совсем про данную уже реальную задачу Geniepro говорить, то этот контекст передается в виде неявного указателя this.
Указатели на эти блоки кода (вложенные процедуры) никуда из этой самой процедуры уезжать (в данной задаче) не должны ни при каких обстоятельствах.
В общем, не надо из этой задачи сферконя вытачивать :-)
-
... а Вы предлагаете делать всё вручную...
Возвращаясь к своему варанту решения хочу заметить, что про него правильнее будет сказать "явное", а не "ручное".
Во-первых, манипуляции внутри процедуры, приводящие к смене куска кода при следующем вызове, прописаны явно (без шаманства). Замечу также, что блоку, в котором содержится вызов процедуры Test, нет нужды вникать в эту "кухню".
Во-вторых, вариант исполнения процедуры при следущем вызове прописан явно, при помощи глобальной переменной s. Это придаёт определённую гибкость данному решению. Появляется возможность перед вызовом процедуры явно указать какой должен быть вариант её исполнения, возможно изменив при этом предопределённый порядок. Да, я помню - такого требования в исходной задаче не было, но в жизни требования часто меняются. Гибкую программу гораздо легче адаптировать к изменившимся требованиям, а автоматизация обычно ведёт к снижению гибкости.
-
Возвращаясь к своему варанту решения хочу заметить, что про него правильнее будет сказать "явное", а не "ручное".
Конкретно ручное там:
- последовательная нумерация (без контроля пропусков)
- проверка на последнее значение (ручное) и сброс на начальное (ручное)
Все это "ручное", потому что никак не контролируется компилятором и, в лучшем случае, будет поймано в рантайме на каком-то шаге. А задачка-то - простейшая...
Во-вторых, вариант исполнения процедуры при следущем вызове прописан явно, при помощи глобальной переменной s. Это придаёт определённую гибкость данному решению.
Это придает столько же гибкости сколько и проблем. Кто-то будет не в курсе, что вы где-то особенным образом шаманите с этой s и будет получать "неожиданные" результаты.
Гибкую программу гораздо легче адаптировать к изменившимся требованиям, а автоматизация обычно ведёт к снижению гибкости.
Понятно, что нужен баланс. Исходя из более конкретной задачи. Если решать эту задачу на самом общем (библиотечном) уровне, то я бы однозначно избавился от глобальной (или static) переменной в пользу аргумента, имеющего смысл "текущее состояние".
-
Вообще говоря, что мой, что Geniepro вариант элементарно (буквально в несколько символов) преобразуется к варианту параметризуемому любой переменной. У Geniepro нужно несколько символов удалить, у меня несколько вставить :-)
-
Конкретно ручное там:
- последовательная нумерация (без контроля пропусков)
Было бы странным городить здесь какую-либо нумерацию, отличную от нумерации, основанной на множестве натуральных чисел. Или Вы предлагаете для этой цели ввести какие-либо идентификаторы? Так это легко можно сделать в секции CONST модуля, если понадобится.
- проверка на последнее значение (ручное) и сброс на начальное (ручное)
Ваше (или чьё-либо ещё) автоматизированное решение никак не избежит такой проверки, просто Вы не будете это видеть в своём автоматизированном коде.
Кто-то будет не в курсе, что вы где-то особенным образом шаманите с этой s и будет получать "неожиданные" результаты.
Документирование модуля никто не отменял. Уж, хотя бы на уровне комментариев. На всякий случай напомню: комментарии должны дополнять исходный текст, а не дублировать его.
... я бы однозначно избавился от глобальной (или static) переменной в пользу аргумента, имеющего смысл "текущее состояние".
А я бы решительно запретил это делать. :)
Надо сказать, что использование глобальных переменных в среде крутых программистов считается чуть-ли не позорным занятием. В моём же понимании настоящий программист всегда знает где лучше использовать локальную переменную, а где глобальную.
Кроме того, если ограничить свой выбор каким-либо Оберон-языком, то для решения поставленной тривиальной задачи невозможно избавиться от глобальной переменной. Дело в том, что в этих языках процедура не в состоянии хранить какой-либо контекст после своего завершения: её кадр будет снят со стека вместе со всеми локальными переменными. После неё может остаться только РЕЗУЛЬТАТ её работы. И этот результат она может сохранить для объемлющих блоков только в глобальных по отношению к ней переменных. Всё это называется блочной структурой. Описанные свойства я расцениваю как положительные. Если какой-либо язык нарушает эти принципы, то мне такой язык даром не нужен.
-
Конкретно ручное там:
- последовательная нумерация (без контроля пропусков)
Было бы странным городить здесь какую-либо нумерацию, отличную от нумерации, основанной на множестве натуральных чисел.
А я и не предлагаю. Я говорю, что ее никто не контролирует. Значит возможен человеческий фактор, которому пофиг на ваше "множество натуральных чисел" :)
Или Вы предлагаете для этой цели ввести какие-либо идентификаторы? Так это легко можно сделать в секции CONST модуля, если понадобится.
Нет. Я предлагал список + итератор. В этом случае "сломать" нумерацию, проверку на конец и сброс - невозможно. Написать изначально неправильно (и тут же увидеть, что не работает) - да, можно. Но не потом, когда все работает и надо, например, добавить еще одно состояние. Решение с макросами (при том, что он мне не нравится) тоже свободно от ваших "ручных" недостатков.
- проверка на последнее значение (ручное) и сброс на начальное (ручное)
Ваше (или чьё-либо ещё) автоматизированное решение никак не избежит такой проверки, просто Вы не будете это видеть в своём автоматизированном коде.
Еще раз: эту проверку (автоматизированную) невозможно сломать, если она изначально правильно написана. Ваша "ручная" проверка - может быть сломано каждый раз, когда добавляется/удаляется состояние.
Кто-то будет не в курсе, что вы где-то особенным образом шаманите с этой s и будет получать "неожиданные" результаты.
Документирование модуля никто не отменял. Уж, хотя бы на уровне комментариев. На всякий случай напомню: комментарии должны дополнять исходный текст, а не дублировать его.
На всякий случай напомню: документирование - последняя и самая неэффективная мера по поддержанию кода в рабочем состоянии. После компилятора и тестов.
... я бы однозначно избавился от глобальной (или static) переменной в пользу аргумента, имеющего смысл "текущее состояние".
А я бы решительно запретил это делать. :)
В таком случае вы просто не сможете использовать более одного "автомата". Очень странное ограничение для общего решения.
Надо сказать, что использование глобальных переменных в среде крутых программистов считается чуть-ли не позорным занятием.
Да. И этому есть вполне разумные объяснения. Которые, правда, не всегда доходят, пока не прочувствуешь сам :)
В моём же понимании настоящий программист всегда знает где лучше использовать локальную переменную, а где глобальную.
Конечно. Я же оговорился - все сильно зависит от конкретных обстоятельств.
Кроме того, если ограничить свой выбор каким-либо Оберон-языком, то для решения поставленной тривиальной задачи невозможно избавиться от глобальной переменной.
Вы вообще читаете то, что я пишу? :) Передавайте в качестве аргумента - и все будет возможно :)
Дело в том, что в этих языках процедура не в состоянии хранить какой-либо контекст после своего завершения: её кадр будет снят со стека вместе со всеми локальными переменными. После неё может остаться только РЕЗУЛЬТАТ её работы. И этот результат она может сохранить для объемлющих блоков только в глобальных по отношению к ней переменных. Всё это называется блочной структурой. Описанные свойства я расцениваю как положительные. Если какой-либо язык нарушает эти принципы, то мне такой язык даром не нужен.
Гхм. Если все эти глубокие размышления про блочную структуру всего лишь наезд на сишные static-переменные уровня функций - то мимо :) Они ничем не отличаются от обероновских глобальных переменных, только область видимости у них ограничена функцией. Что, безусловно, однозначный плюс. Особенно, когда вы хотите быть уверенным, что никто не начнет шаманить с "s" за пределами функции ;)
-
Вы вообще читаете то, что я пишу? :) Передавайте в качестве аргумента - и все будет возможно :)
Код в студию, пожалуйста.
-
Это оно?:
struct context;
typedef void (*F)(context*);
F steps[] = {&step1, &step2, &step3};
int current_step = 0;
-
Вы вообще читаете то, что я пишу? :) Передавайте в качестве аргумента - и все будет возможно :)
Код в студию, пожалуйста.
библиотечный хедер:
struct stepper_t
{
virtual ~stepper_t() = 0;
virtual void next() = 0;
};
typedef std::vector< boost::function<void> > steps_t; // список функций
std::auto_ptr<stepper_t> make_stepper(const steps_t&); // инициализировать автомат списком функций
имплементация:
struct impl : stepper_t
{
stepper_t(const steps_t &steps) : steps(steps), current(steps.begin()) {assert(this->current != steps.end();}
virtual void next()
{
(*this->current)();
++this->current;
if (this->current == this->steps.end())
this->current = this->steps.begin();
}
steps_t steps;
steps_t::iterator current;
};
std::auto_ptr<stepper_t> make_stepper(const steps_t& steps)
{
return std::auto_ptr<stepper_t>(new impl(steps));
}
Использование:
void step1(){printf("step1");}
void step2(){printf("step2");}
...
steps_t steps;
steps.push_back(&step1);
steps.push_back(&step2);
...
std::auto_ptr<stepper_t> test1 = make_stepper(steps); // первый автомат
std::auto_ptr<stepper_t> test2 = make_stepper(steps); // второй автомат
test1->next();
test2->next();
test1->next();
test2->next();
И никаких глобальных переменных :)
-
И никаких глобальных переменных :)
В данном случае "аргумент" (состояние) про который я говорил - инкапсулирован в самом автомате. Никто не мешает таскать его явно именно именно как аргумент, но это неудобно и будет источником граблей...
-
А в C++ 2011 это все можно сделать будет уже без уродливых push_back'ов. сразу в фигурных скобках перечислить шаги.
Но есть нюанс: изначально Geniepro принципиально ради этого не хотел плодить функции, и тем более, методы (этот самый голимый степпер, то есть функция с пачкой кусков кода, которые надо исполнять последовательно при вызовах, на самом деле не свободная функция, а, не побоюсь этого слова, член. соответственно разбивая на мелкие функции её либо придется плодить мелкие членики (что не кошерно, ибо будет засран хедер фигней всякой), либо делать их обычными функциями, но тогда они не смогут достучаться до протектедов да приватов, то есть их надо будет сделать френдами, что опять таки засрет хедер фигней всякой). А вот если бы были вложенные функции в сях, тут все стало бы сразу гладно и шелковисто.
-
Да, это я клоню к тому, что в инструментальном наборе программиста должен быть струмент, позволяющий манипулировать AST (модифицировать, создавать его отдельные куски), чтобы вот такие вот мелкие задачки на местах можно было решать максимально безопасно. (это требуется относительно редко, но иногда этого очень нехватает).
-
А в C++ 2011 это все можно сделать будет уже без уродливых push_back'ов. сразу в фигурных скобках перечислить шаги.
Да, невозможность нормально инитить вектор всегда напрягала. В бусте даже велосипед для этого есть.
Но есть нюанс: изначально Geniepro принципиально ради этого не хотел плодить функции, и тем более, методы
Это все понятно... Просто мой вариант - наиболее общий, плюс демонстрация жизни без глобальных переменных :) А в каком-то конкретном случае вполне можно написать и switch по static-переменной...
-
Наиболее общее решение тут это какой-нибудь boost::fsm :-)
-
Почему-то никто не вспомнил ключевое слово сопрограмма. Вот как оно должно выглядеть в идеале
step1
resume;
step2
resume;
step3
resume;
step4
Когда-то давно мне пришлось писать BIOS, в котором была процедура вывода символа. И требовалось обрабатывать Esc-последовательности. Типа этого, но не так много, http://www.felixl.com/Uknc_RAM_description_app
Писать конечный автомат для решения такой задачи – скучнейшее занятие, а на то, что получится в результате кодирования лучше не смотреть.
Задача была решена с помощью сопрограмм. Если перевести ассемблер в псевдокод, то получится что-то типа этого (приведены две последовательности):
(http://s15.radikal.ru/i189/1104/fe/135154638ee1.png)
Пояснение: Esc Y <строка><столбец> - позиционирование курсора.
<строка> и <столбец> - ASCII-символы с кодами строка+32 и столбец+32. Если в какой-либо позиции координаты выходят за допустимые пределы, то позиционирование по данному параметру не производится.
Обратите внимание, что resume идет из недр вложенных скобочных конструкций, поэтому структура программы полностью соответствует структуре данных.
Затраты на реализацию сопрограмм такие: вход в процедуру: одна дополнительная команда (jmp saveAddr), тело процедуры resume: две команды (pop saveAdr; ret). Реально там было еще несколько команд для сохранения/восстановления регистров, но это не связано с сопрограммами.
Сейчас, конечно из за многозадачности, многопоточности, распространения и обработки исключений все не так просто. Ну так я не зря говорил об идеальности.
-
Код в студию, пожалуйста.
...
И никаких глобальных переменных :)
Да. Вместо одной глобальной переменной у Вас теперь не менее глобальная структура и целая горсть новых идентификаторов: stepper_t, next, steps_t, make_stepper, ... (насколько мне удалось разобраться в чужеродном для меня языке :))
Цена за такую автоматизацию получается слишком высока.
Это конечно не означает, что Ваше решение не имеет право на жизнь, но я бы в своём коде так делать не стал.
-
Да. Вместо одной глобальной переменной у Вас теперь не менее глобальная структура
Не следует путать объявление переменной с объявлением типа. Последствия в плане глобальности совершенно разные.
-
Код в студию, пожалуйста.
...
И никаких глобальных переменных :)
Да. Вместо одной глобальной переменной у Вас теперь не менее глобальная структура и целая горсть новых идентификаторов: stepper_t, next, steps_t, make_stepper, ... (насколько мне удалось разобраться в чужеродном для меня языке :))
Не, вы не правы. Нет там никакой глобальной структуры, всего лишь объявление интерфейса, не более глобального чем любой экспортируемый тип в обероне. И сущностей там не больше чем в вашем решении. У вас функция и глобальная переменная (состояние). У меня функция создания состояния (не глобального) и функция, которая работает с этим состоянием. Можно было без лишних идентификаторов и структур, но менее наглядно:
хедер:
boost::function<void> make_stepper(std::vector< boost::function<void> > const&);
// возвращает функцию, которая на каждом вызове вызывает очередную функцию из списка переданных функций
использование:
boost::function<void> test1 = make_stepper(...);
boost::function<void> test2 = make_stepper(...);
test1(); // step1
test2(); // step1
test1(); // step2
test2(); // step2
-
Почему-то никто не вспомнил ключевое слово сопрограмма
Да, есть такие штуки. Я их не щупал, а всегда хотел увидеть простой пример. Спасибо :) Чем то похоже на "генератор". Есть принципиальная разница?
-
Чем то похоже на "генератор".
Поясните, о чем речь. Я не врубаюсь.
-
Чем то похоже на "генератор".
Поясните, о чем речь. Я не врубаюсь.
def gen():
yield 1
yield 2
yield 3
print list(gen())
Напечатает: [1, 2, 3]
Отличие в том, что генератор принимает аргумент один раз. Затем можно "лениво" итерироваться по результатам.
-
Применительно к данной задачке - вот питоновский код с генератором:
import sys
def stepper(functions):
i = 0
while True:
functions[i]()
yield
i = i + 1
if i == len(functions):
i = 0
s = stepper([lambda: sys.stdout.write("test1"), lambda: sys.stdout.write("test2")])
s.next()
s.next()
s.next()
И по-прежнему без глобальных переменных ;)
-
Да, похоже, я пробовал yield в C#, но он там может использоваться только в итераторах. А то было бы самое оно.
-
Да, похоже, я пробовал yield в C#, но он там может использоваться только в итераторах. А то было бы самое оно.
Кстати, почему поклонники Дейкстры никак не прореагировали на такой конструкт?
while True:
yield
Это не break и не goto, но должно же вызвать какую-нибудь реакцию? :)
-
Когда я писал в примере
пока истина цикл
...
resume;
...
у меня было желание написать в комментарии: "цикл бесконечный".
Но потом подумал, что читатели могут расценить такой комментарий как совсем уже для тупых, и не стал писать.
А какой реакции вы ждете?
-
Судя по всему, сопрограммы являются формой записи конечного автомата. Конечный автомат избыточен для данной задачи.
-
у меня было желание написать в комментарии: "цикл бесконечный".
Но потом подумал, что читатели могут расценить такой комментарий как совсем уже для тупых, и не стал писать.
А какой реакции вы ждете?
Ну на самом деле цикл не вечный. В том смысле, что не зацикливает программу. При том, что программа вполне себе классическая/однопоточная. Т.е. имеет место некий "разрыв" в потоке от "блока" к "блоку", от "входа" к "выходу". Поэтому и хотелось услышать комментарии от ценителей "истинного" (догматического) структурного программирования. Сам я отношусь к такой конструкции не более чем как к абстракции, которая в определенных ситуациях хорошо описывает происходящее в программе. Моим "истинным" принципам эта абстракция не противоречит.
-
Кстати, почему поклонники Дейкстры никак не прореагировали на такой конструкт?
У меня есть реализация сопрограмм для КП/ББ, библиотечная. Хороший весчь.
-
Кстати, почему поклонники Дейкстры никак не прореагировали на такой конструкт?
У меня есть реализация сопрограмм для КП/ББ, библиотечная. Хороший весчь.
Можно взглянуть?
-
setjump/longjump?
-
Кстати, почему поклонники Дейкстры никак не прореагировали на такой конструкт?
У меня есть реализация сопрограмм для КП/ББ, библиотечная. Хороший весчь.
И это все? :) Ну и ладно...
-
setjump/longjump?
Не совсем. Это, наверное, не совсем сопрограммы, а скорее фиберы.
В код отдельной такой сопрограммы вставляем вызов спец. процедуры Pass, диспетчер возобновляет очередную сопрограмму, пока и она не вызовет Pass. И т.п. Кооперативная многозадачность.
Реализация - на общем стеке, главном стеке программы. Кадры засыпающей сопрограммы снимаются со стека и запоминаются, на стек помещаются кадры получающей управление сопрограммы.
Никакой поддержки ОС не требуется, легковесный библиотечный параллелизм, поскольку стек один, можно иметь очень много параллельных задач.
-
Прошу прощения, это действительно немножечко другое, нежели сопрограммы, хотя реализация схожа, можно переделать.
По вопросу сопрограмм и оптимизации компилятором концевых вызовов (как варианте реализации) я писал на ОберонКоре, ветка с анализом проблемы GOTO. Позже дам ссылку, когда у местного провайдера кончатся проблемы.
-
Никакой поддержки ОС не требуется, легковесный библиотечный параллелизм, поскольку стек один, можно иметь очень много параллельных задач.
Кстати, в моём биосном примере стек тоже один.
-
На выходных мы с сыном решили переписать пример Vlad'а на КП/Блэкбокс, в учебно-тренировочных целях, так сказать. К тому же, сын выступил в качестве консультанта по языку С++, поскольку сам я с этим языком не дружу. :)
Полной аналогии с исходным примером конечно нет, но такой цели и не ставилось. Комментировать особо не буду, и так всё видно.
-
Обещал ссылку в тему сопрограмм.
Вот такая веточка у нас есть:
http://forum.oberoncore.ru/viewtopic.php?f=86&t=3237
И в ней я высказывал свои мысли про концевой вызов процедур:
http://forum.oberoncore.ru/viewtopic.php?p=59493#p59493
-
Мысли это хорошо, а реализацию то покажешь? :-)
-
Полной аналогии с исходным примером конечно нет, но такой цели и не ставилось. Комментировать особо не буду, и так всё видно.
Да, он достаточно аналогичен. Без глобальных переменных :)
-
Мысли это хорошо, а реализацию то покажешь? :-)
Про концевой вызов - нету реализации; т.к. я не занимаюсь пока что вещами, требующими модификации компилятора.
А про лёгкий параллелизм - не покажу :), а вот если кому реально надо, для реальной задачи, готов в личке рассказать и показать (если человек объяснит, опять же, зачем надо).
А для праздного любопытства я не стану выделять эту реализацию из общего каркаса, время публикации которого ещё не пришло.
-
Тогда к чему было это упоминать? Ладно, Реализацию не можешь показать, тогда покажи хотя бы пример использования например применительно к обсуждаемой задаче. Тут ни выделять из каркаса ничего не надо, ни публиковать. Просто пример использования. Код.
-
IMPORT Tasks;
PROCEDURE Task (IN par: ANYREC);
BEGIN
WITH par: ... DO
...step1...;
Tasks.Pass;
...step2...;
Tasks.Pass;
...step3...
END
END Task;
PROCEDURE X;
VAR par: ...;
BEGIN
par.. := ...
Tasks.Begin(Task, par)
END X;
-
Да, он достаточно аналогичен. Без глобальных переменных :)
Должен сказать, что цели "избавиться от глобальных переменных" нами не ставилось. Ваш подход к решению привёл к тому, что глобальные переменные исчезли как бы нечаянно. :)
Хочу отметить, что не смотря на то что КП несравненно меньше и проще языка С++, он тем не менее оказался достаточно выразительным и пригодным для такого применения.
Из недостатков (или особенностей, которые вызвали неудобство) могу отметить следующие:
- Отсутствие полноценных конструкторов заставляет эмулировать их при помощи довольно корявого вызова обычного метода сразу после NEW.
- Отсутствие шаблонов классов вызвает затруднение при описании вектора, который может состоять из однотипных элементов абсолютно любого типа (в примере описан вектор, который может состоять только из процедур).
Про достоинства сильно "трещать" не буду, ибо пользы от этого мало. :D
-
Да, он достаточно аналогичен. Без глобальных переменных :)
Должен сказать, что цели "избавиться от глобальных переменных" нами не ставилось.
Просто глобальные переменные - это лакмусовая бумажка :) Показывающая будущие проблемы в сопровождении. Поэтому я привык их избегать любой ценой.
Хочу отметить, что не смотря на то что КП несравненно меньше и проще языка С++, он тем не менее оказался достаточно выразительным и пригодным для такого применения.
Выразительностью я бы не стал особо восхищаться... А то, что КП пригоден - никто не сомневался.
Из недостатков или особенностей, которые вызвали неудобство) могу отметить следующие:
- Отсутствие полноценных конструкторов заставляет эмулировать их при помощи довольно корявого вызова обычного метода сразу после NEW.
Оно не просто коряво. Оно концептуально неверно и ведет к граблям. Используйте фабрики.
- Отсутствие шаблонов классов вызвает затруднение при описании вектора, который может состоять из однотипных элементов абсолютно любого типа (в примере описан вектор, который может состоять только из процедур).
Да, подобные велосипеды не добавляют выразительности ;) И заставляют идти по пути глобальных переменных :)
-
Оно не просто коряво. Оно концептуально неверно и ведет к граблям. Используйте фабрики.
Да фабрики хороши - одна проблема - не гарантируют создания экземпляра ИСКЛЮЧИТЕЛЬНО по ЗАДАННЫМ правилам или я ошибаюсь?.
-
Всё-таки нужно различать прикладной код и библиотечный.
Если я пишу какую-либо прикладную программу, в которой нужно однократно решить изначальную задачку (см. самое первое сообщение Geniepro в теме), то лучшим решением будет то, которое я предложил в начале.
Если данная задачка встречается довольно часто, то нужно библиотечное решение, и тогда лучшим решением будет то, которое предложил Vlad.
Решение, основанное на использовании макросов, мне откровенно не нравится (концептуально, а не по исполнению!). Что-то типа библиотеки для ленивых. Но говорю это с большой долей субъективизма.
-
Оно не просто коряво. Оно концептуально неверно и ведет к граблям. Используйте фабрики.
Да фабрики хороши - одна проблема - не гарантируют создания экземпляра ИСКЛЮЧИТЕЛЬНО по ЗАДАННЫМ правилам или я ошибаюсь?.
Почему же? Они именно для этого и есть, то есть для создания объектов по жестким заданным правилам.
-
Решение, основанное на использовании макросов, мне откровенно не нравится (концептуально, а не по исполнению!). Что-то типа библиотеки для ленивых. Но говорю это с большой долей субъективизма.
Не нравится сама идея создания и использования eDSL, или же реализация её посредством макросов?
-
Оно не просто коряво. Оно концептуально неверно и ведет к граблям. Используйте фабрики.
Да фабрики хороши - одна проблема - не гарантируют создания экземпляра ИСКЛЮЧИТЕЛЬНО по ЗАДАННЫМ правилам или я ошибаюсь?.
Почему же? Они именно для этого и есть, то есть для создания объектов по жестким заданным правилам.
Как ? я говорю про обеспечение непротиворечивого СОЗДАНИЯ экземпляра (переменной) составного типа - такой фокус могут обеспечить только конструкторы (а фабричные функции вы можете использовать для этой цели ,а можете и не использовать).Т.е ничто вам не помешает инициализировать переменную так , как это сделал Игорь (имея при этом в загашнике прекрасную фабричную функцию).
-
Не нравится сама идея создания и использования eDSL, или же реализация её посредством макросов?
Не нравится реализация eDSL посредством макросов.
Отношение к самой идеи eDSL у меня пока не однозначно.
-
Как ? я говорю про обеспечение непротиворечивого СОЗДАНИЯ экземпляра (переменной) составного типа - такой фокус могут обеспечить только конструкторы (а фабричные функции вы можете использовать для этой цели ,а можете и не использовать).Т.е ничто вам не помешает инициализировать переменную так , как это сделал Игорь (имея при этом в загашнике прекрасную фабричную функцию).
Непротиворечивость можно обеспечить известным архитектурным приёмом:
наружу выставляется абстрактный тип, тип наследник - скрыт, фабрика типа возвращает
экземпляр наследника под видом абстрактного.
-
Как ? я говорю про обеспечение непротиворечивого СОЗДАНИЯ экземпляра (переменной) составного типа - такой фокус могут обеспечить только конструкторы (а фабричные функции вы можете использовать для этой цели ,а можете и не использовать).Т.е ничто вам не помешает инициализировать переменную так , как это сделал Игорь (имея при этом в загашнике прекрасную фабричную функцию).
Непротиворечивость можно обеспечить известным архитектурным приёмом:
наружу выставляется абстрактный тип, тип наследник - скрыт, фабрика типа возвращает
экземпляр наследника под видом абстрактного.
Плодить иерархию по пустякам... и потом, если нет в ЯП такого понятия как ADT (как ,например, в стандартном обероне)?
-
По пустякам и конструкторов не надо.
-
По пустякам и конструкторов не надо.
Вы это к тому, что Оберон - язычек на пустячек? ;)
-
Непротиворечивость можно обеспечить известным архитектурным приёмом:
наружу выставляется абстрактный тип, тип наследник - скрыт, фабрика типа возвращает
экземпляр наследника под видом абстрактного.
2igor: Именно это я и имел ввиду применительно к оберонам.
-
По пустякам и конструкторов не надо.
Вы это к тому, что Оберон - язычек на пустячек? ;)
В качестве шутки сойдёт, но из контекста разговора понятно, что нет.
-
По пустякам и конструкторов не надо.
Вы это к тому, что Оберон - язычек на пустячек? ;)
В качестве шутки сойдёт, но из контекста разговора понятно, что нет.
Точно. Интересно, что эта тема (о необходимости в ЯП конструкций аналогичных конструкторам) поднималась несколько раз у коровцев (как оберонофилами так и оберонофобами).. в качестве аргументации в основном были "жизненные" примеры.. Понятно что на каждый такой пример находился контрпример (или , на худой конец, "нафиг энто нужно"). Я считаю - что даже в простом СОВРЕМЕННОМ ЯВУ такая вещь (назовем ее инициализатором) - крайне полезна ибо позволяет описывать моделируемую систему точно и надежно (это является для меня ДОСТАТОЧНЫМ основанием).
-
Я считаю - что даже в простом СОВРЕМЕННОМ ЯВУ такая вещь (назовем ее инициализатором) - крайне полезна ибо позволяет описывать моделируемую систему точно и надежно (это является для меня ДОСТАТОЧНЫМ основанием).
Необходимость в конструкторах (или инициализаторах) я для себя обосновываю несколько иначе.
Основную цель конструкторов я вижу в том, чтобы перевести только что созданный объект (до первого использования) во внутренне непротиворечивое состояние. Дело в том, что конструктор - это особый метод, который вызывается тогда, когда объекта ещё как бы нет (в том смысле, что этот объект ещё не доступен для использования). К тому же этот метод вызывается автоматически, так что у программиста нет возможности "забыть" его вызвать.
Всё это звучит несколько академически, но я действительно так думаю. :)
-
Я считаю - что даже в простом СОВРЕМЕННОМ ЯВУ такая вещь (назовем ее инициализатором) - крайне полезна ибо позволяет описывать моделируемую систему точно и надежно (это является для меня ДОСТАТОЧНЫМ основанием).
Необходимость в конструкторах (или инициализаторах) я для себя обосновываю несколько иначе.
Основную цель конструкторов я вижу в том, чтобы перевести только что созданный объект (до первого использования) во внутренне непротиворечивое состояние. Дело в том, что конструктор - это особый метод, который вызывается тогда, когда объекта ещё как бы нет (в том смысле, что этот объект ещё не доступен для использования). К тому же этот метод вызывается автоматически, так что у программиста нет возможности "забыть" его вызвать.
Всё это звучит несколько академически, но я действительно так думаю. :)
Поздравляю, время внести коррективы в свою точку зрения :). Описанная вами проблема лечится просто - при создании переменной в нее заносится некоторое значение из области определения (например, численные типы инициализируются нулем, указатели -NIL) . Я говорю , про то, что необходимость в конструкторах имеет другую природу (и вообще говоря вывести ее логически из постулатов информатики невозможно- можно только ввести их в ЯП аксиоматически...а введение новых сущностей нужно жестко обосновывать, иначе винегрет)
-
Я считаю - что даже в простом СОВРЕМЕННОМ ЯВУ такая вещь (назовем ее инициализатором) - крайне полезна ибо позволяет описывать моделируемую систему точно и надежно (это является для меня ДОСТАТОЧНЫМ основанием).
Необходимость в конструкторах (или инициализаторах) я для себя обосновываю несколько иначе.
Основную цель конструкторов я вижу в том, чтобы перевести только что созданный объект (до первого использования) во внутренне непротиворечивое состояние. Дело в том, что конструктор - это особый метод, который вызывается тогда, когда объекта ещё как бы нет (в том смысле, что этот объект ещё не доступен для использования). К тому же этот метод вызывается автоматически, так что у программиста нет возможности "забыть" его вызвать. Кстати , не так давно вы пытались сделать что-то подобное по отношению к вычислениям с плавающей точкой...
Всё это звучит несколько академически, но я действительно так думаю. :)
Поздравляю, время внести коррективы в свою точку зрения :). Описанная вами проблема лечится просто - при создании переменной в нее заносится некоторое значение из области определения (например, численные типы инициализируются нулем, указатели -NIL) . Я говорю , про то, что необходимость в конструкторах имеет другую природу (и вообще говоря вывести ее логически из постулатов информатики невозможно- можно только ввести их в ЯП аксиоматически...а введение новых сущностей нужно жестко обосновывать, иначе винегрет)
-
Описанная вами проблема лечится просто - при создании переменной в нее заносится некоторое значение из области определения (например, численные типы инициализируются нулем, указатели -NIL) .
В том то и дело, что с точки зрения автора объекта нулевые значения могут быть некорректными. Например, в объекте Window поле width означает ширину окна, а по замыслу автора ширина любого окна (любого экземпляра объекта Window) ни при каких обстоятельствах не должна быть меньше 50 пикселей. Как гарантировать этот инвариант при создании объекта? При помощи конструктора (!), чтобы даже нечаянно не получилось создать объект, у которого будет width < 50.
-
Плодить иерархию по пустякам...
В КП есть LIMITED RECORD, как раз для такой цели (чтобы в обход фабрики нельзя было создать).
Используется редко (но метко), потому что базовый абстрактный тип имеет смысл вводить в большинстве случаев. И уж в случае прикладного моделирования точно (чтобы потом свободно играть с разными вариантами реализации какого-нибудь понятия).
Относиться к желательности введения ABSTRACT-типа можно так же, как к обязанности объявлять секцию interface в Object Pascal, дефинишн в Модуле или Аде, или хидер в Сях. Объём работы не увеличивается, т.к. как раз дефинишн Оберон генерирует автоматом, только звёздочки успевай ставить... Это как раз и к вопросу о том, почему в Оберонах теряет актуальность явное объявление спецификаций. Основные спецификации фиксируются в объявлениях ABSTRACT-типов.
-
В КП есть LIMITED RECORD, как раз для такой цели (чтобы в обход фабрики нельзя было создать).
Но это только для переменных в куче. Не интересно.
Относиться к желательности введения ABSTRACT-типа можно так же, как к обязанности объявлять секцию interface в Object Pascal, дефинишн в Модуле или Аде, или хидер в Сях.
В сях хидер не обязателен абсолютно.
Объём работы не увеличивается, т.к. как раз дефинишн Оберон генерирует автоматом, только звёздочки успевай ставить... Это как раз и к вопросу о том, почему в Оберонах теряет актуальность явное объявление спецификаций. Основные спецификации фиксируются в объявлениях ABSTRACT-типов.
Где в Обероне ABSTRACT-типы? Их там как раз вроде бы нет.
Алсо беспорядочно раскиданые звездочки по тексту очень нелегко вылавливать. Я это дело прочувствовал когда на этих выходных писал на Oberon-7 :-)
-
Алсо беспорядочно раскиданые звездочки по тексту очень нелегко вылавливать. Я это дело прочувствовал когда на этих выходных писал на Oberon-7 :-)
Так вы дойдете до необходимости подсветки, однако - нехорошо товарищч... ;)
-
В том то и дело, что с точки зрения автора объекта нулевые значения могут быть некорректными. Например, в объекте Window поле width означает ширину окна, а по замыслу автора ширина любого окна (любого экземпляра объекта Window) ни при каких обстоятельствах не должна быть меньше 50 пикселей. Как гарантировать этот инвариант при создании объекта? При помощи конструктора (!), чтобы даже нечаянно не получилось создать объект, у которого будет width < 50.
Я вам ПРО ЭТО И ГОВОРЮ (что САМО ЗНАЧЕНИЕ ПЕРЕМЕННОЙ - ОПРЕДЕЛЯЕТСЯ ВНЕШНИМИ ПО ОТНОШЕНИЮ к ЯП ФАКТОРАМИ -ЗАДАЧЕЙ (если вам так легче это осознать)) - с точки зрения обеспечения непротиворечивости внутренней логики программы - ДОСТАТОЧНО сделать то что я сказал.
-
Плодить иерархию по пустякам...
В КП есть LIMITED RECORD, как раз для такой цели (чтобы в обход фабрики нельзя было создать).
Используется редко (но метко), потому что базовый абстрактный тип имеет смысл вводить в большинстве случаев. И уж в случае прикладного моделирования точно (чтобы потом свободно играть с разными вариантами реализации какого-нибудь понятия).
Относиться к желательности введения ABSTRACT-типа можно так же, как к обязанности объявлять секцию interface в Object Pascal, дефинишн в Модуле или Аде, или хидер в Сях. Объём работы не увеличивается, т.к. как раз дефинишн Оберон генерирует автоматом, только звёздочки успевай ставить... Это как раз и к вопросу о том, почему в Оберонах теряет актуальность явное объявление спецификаций. Основные спецификации фиксируются в объявлениях ABSTRACT-типов.
И это Вы называете простым ЯП и проталкиваете его для начинающих ? - мля... да и только.
-
Алсо беспорядочно раскиданые звездочки по тексту очень нелегко вылавливать. Я это дело прочувствовал когда на этих выходных писал на Oberon-7 :-)
Так вы дойдете до необходимости подсветки, однако - нехорошо товарищч... ;)
Скорее перепишу все что есть с нуля самостоятельно так, чтобы экспортируемые сущности были сгруппированы отдельно. Благо исходников на Обероне-7 кот наплакал, можно вообще все переписать безболезненно совершенно :-)
-
Алсо беспорядочно раскиданые звездочки по тексту очень нелегко вылавливать. Я это дело прочувствовал когда на этих выходных писал на Oberon-7 :-)
Так вы дойдете до необходимости подсветки, однако - нехорошо товарищч... ;)
Скорее перепишу все что есть с нуля самостоятельно так, чтобы экспортируемые сущности были сгруппированы отдельно. Благо исходников на Обероне-7 кот наплакал, можно вообще все переписать безболезненно совершенно :-)
Вы это - злобный эгоист- индивидуалист ? как не стыдно :D
-
И это Вы называете простым ЯП и проталкиваете его для начинающих ? - мля... да и только.
А Вы считаете что ООП имеет отношение к начинающим? (утрирую)
К начинающим имеет отношение использование объектов, это проходит на ура.
Как вводить понятия ООП - вопрос вообще открытый. У меня есть хорошая безболезненная последовательность, поддержанная примерами, но только в этом году она сложилась. Дело начинается с объявления типов, расширяющих некоторые стандартные (сначала расширение Services.Action, для создания асинхронных действий; потом расширение Views.View), такие типы вообще не экспортируются. Потом в какой-то момент, имея уже графический объект (игра "Сапёр"), отделяем от вьюшки модель - и вот тут-то впервые создаём свой тип. И ABSTRACT появляется тоже естественно (тем более, что до этого мы занимались тем, что такие ABSTRACT-ы расширяли-реализовывали). Проблем не замечено.
Касательно простоты: простота - это чистота от мусора, но не от существенных вещей, простота не должна быть профанирующей. ООП так ООП, всё нормальное ООП строится на гомогенных иерархиях (с базовыми абстрактными типами и скрытыми реализациями). Надо приучать, аккуратно, на постепенных примерах, а не изолировать "в песочнице".
ООП ещё требует осмысления и доочищения, это понятно, но на данном уровне сбалансированнее, чем в КП, пока не видать.
-
Вопли про подсветку непонятны. В Блэкбоксе экспортированные элементы выделяются жирностью, естественно. В чём проблема.
Проблема как раз у Веселовского на плоском тексте.
-
САМО ЗНАЧЕНИЕ ПЕРЕМЕННОЙ - ОПРЕДЕЛЯЕТСЯ ВНЕШНИМИ ПО ОТНОШЕНИЮ к ЯП ФАКТОРАМИ -ЗАДАЧЕЙ (если вам так легче это осознать)
Я не могу осознать другое, зачем Вы тогда предлагали инициализировать поля нулевыми значениями? Вы считаете что такое решение заранее подойдёт для всех задач? :D
-
САМО ЗНАЧЕНИЕ ПЕРЕМЕННОЙ - ОПРЕДЕЛЯЕТСЯ ВНЕШНИМИ ПО ОТНОШЕНИЮ к ЯП ФАКТОРАМИ -ЗАДАЧЕЙ (если вам так легче это осознать)
Я не могу осознать другое, зачем Вы тогда предлагали инициализировать поля нулевыми значениями? Вы считаете что такое решение заранее подойдёт для всех задач? :D
1. ЗАТЕМ, что ЭТО ЛЕЧИТ ПРОБЛЕМУ УКАЗАННУЮ В ВАШЕМ СООБЩЕНИИ (ОБЕСПЕЧИВАЕТ НЕПРОТИВОРИЧИВОСТЬ)... 2. Затем, что для большинства задач начального уровня (ИМХО) - это разумный ( и естесственный с точки зрения человеческой психики) выбор 3. затем что это безопасно для исполнителя и оружающей среды- разве этого мало?
-
Вопли про подсветку непонятны. В Блэкбоксе экспортированные элементы выделяются жирностью, естественно. В чём проблема.
Проблема как раз у Веселовского на плоском тексте.
А они там выделяются автоматически? Опять таки, речь шла про Оберон(1,2) таки, а не про КП и тем более не про его конкретную реализацию-ББ.
А подсветка тут не поможет. И выделение жирным поможет не очень. Мне не хочется по всей реализации бегать чтобы увидеть полторы экспортируемые сущности.
PS. Инструментальные среды я в данный момент не критикую. Я критикую подход который начался в Обероне и укоренился в яве и шарпе — не писать отдельно спецификацию на компонент. Спецификация должна писаться ручками, потому что она первична, а вот реализация может частично по ней генерироваться :-)
-
Если экспортируется только ABSTRACT-тип, то там всё сверху модуля.
В среде нажать Ctrl-D, чтобы увидеть спецификацию, не проблема. (А не раз говорилось, что Обероны без среды теряют очень многое).
По поводу первичности спецификации - я с Вами соглашусь, рассуждая эдак "вообще". Но в конкретно своей практике, по причине того же переноса акцента на ABTSRACT-типы и т.п., я имею подтверждение того, что спецификации на модули не востребованы. Они востребованы, безусловно, когда могло быть несколько реализаций одного модуля. Сейчас (в компонентном ООП) так не делается.
-
Если экспортируется только ABSTRACT-тип, то там всё сверху модуля.
В среде нажать Ctrl-D, чтобы увидеть спецификацию, не проблема. (А не раз говорилось, что Обероны без среды теряют очень многое).
Кстати, Оберон не один такой, java/c# тоже очень многое теряют без среды. Становятся почти что неюзабельными (особенно java). Haskell, кстати, без repl'а его тоже становится не слишком удобным (потому как не запустить в произвольный момент времени выводилку типов).
Среда по большей части не важна таким языкам как: С, C++, Ada, ObjC, Modula, D.
-
И это Вы называете простым ЯП и проталкиваете его для начинающих ? - мля... да и только.
А Вы считаете что ООП имеет отношение к начинающим? (утрирую)
К начинающим имеет отношение использование объектов, это проходит на ура.
Как вводить понятия ООП - вопрос вообще открытый. У меня есть хорошая безболезненная последовательность, поддержанная примерами, но только в этом году она сложилась. Дело начинается с объявления типов, расширяющих некоторые стандартные (сначала расширение Services.Action, для создания асинхронных действий; потом расширение Views.View), такие типы вообще не экспортируются. Потом в какой-то момент, имея уже графический объект (игра "Сапёр"), отделяем от вьюшки модель - и вот тут-то впервые создаём свой тип. И ABSTRACT появляется тоже естественно (тем более, что до этого мы занимались тем, что такие ABSTRACT-ы расширяли-реализовывали). Проблем не замечено.
Касательно простоты: простота - это чистота от мусора, но не от существенных вещей, простота не должна быть профанирующей. ООП так ООП, всё нормальное ООП строится на гомогенных иерархиях (с базовыми абстрактными типами и скрытыми реализациями). Надо приучать, аккуратно, на постепенных примерах, а не изолировать "в песочнице".
ООП ещё требует осмысления и доочищения, это понятно, но на данном уровне сбалансированнее, чем в КП, пока не видать.
Какая вьюшка или фигнюшка - я говорю про простые задачи - понятные школьникам напр. есть точка (на плоскости) из 1 координатной четверти, есть точка из 3 -найти рассояние между ними... самый надежный способ определить два типа и функцию возвращающую расстояние.- здесь нет никакого полиморфизма или наследования... работаем только с переменными пользовательских типов. И уж коль скоро мы говорим о них (пременных пользовательских типов ) - почему бы не сделать их полноценными (коль скоро постулируем СТРОГУЮ ТИПИЗАЦИЮ). Да и еще я говорил про простой СОВРЕМЕННЫЙ ЯВУ..все -таки кое какой багаж за последние 40 лет накоплен...
-
....
Среда по большей части не важна таким языкам как: С, C++, Ada, ObjC, Modula, D.
Вы это про что (почему для Модулы это не важно а для Оберона важно)? про наличие заголовочных файлов ? так в случая Оберонов они без проблем генерируются при компиляции (если компилятор нормальный - напр. XDS) - не фиг писать ручками то что можно сделать автоматически (впрочем можно и ручками -если есть желание) другое дело что проблему навигации
по коду это не решает (но то же самое можно сказать и про любой ЯП из вашего списка).
-
Скорее перепишу все что есть с нуля самостоятельно так, чтобы экспортируемые сущности были сгруппированы отдельно. Благо исходников на Обероне-7 кот наплакал, можно вообще все переписать безболезненно совершенно :-)
Просто добавьте DEF-файлы, и в зависимости от задач и предпочтений решайте - генерируются они автоматически из модулей или наоборот - из них автоматически генерируются болванки модулей. Так что то, как сделано в Обероне - хорошо, надо только увидеть это.
-
Скорее перепишу все что есть с нуля самостоятельно так, чтобы экспортируемые сущности были сгруппированы отдельно. Благо исходников на Обероне-7 кот наплакал, можно вообще все переписать безболезненно совершенно :-)
Просто добавьте DEF-файлы, и в зависимости от задач и предпочтений решайте - генерируются они автоматически из модулей или наоборот - из них автоматически генерируются болванки модулей. Так что то, как сделано в Обероне - хорошо, надо только увидеть это.
Так в Обероне же нет DEF-файлов :-) Их синтаксис не определен.
-
Просто добавьте DEF-файлы, и в зависимости от задач и предпочтений решайте - генерируются они автоматически из модулей или наоборот - из них автоматически генерируются болванки модулей. Так что то, как сделано в Обероне - хорошо, надо только увидеть это.
Не понял -как можно сделать болванку из дефа (в XDS) автоматом?
-
Так в Обероне же нет DEF-файлов :-) Их синтаксис не определен.
Если нужно просто ориентироваться в импортированных сущностях, то это и не важно. Если же нужно использовать как полноценные сущности, то конечно - доопределить. А в самом описании Оберона этого может и не быть, как и описания поведения при выходе за границы массива, стандартной библиотеки и т.д. Это может содержаться в более объемлющем стандарте.
Не понял -как можно сделать болванку из дефа (в XDS) автоматом?
Скорее всего никак, я всего лишь, ссылаясь на потенциальное желание Алексея всё переписать, предлагал возможный путь.
-
Да там переписывать то… Три или четыре файла :-)
-
Какая вьюшка или фигнюшка - я говорю про простые задачи - понятные школьникам напр. есть точка (на плоскости) из 1 координатной четверти, есть точка из 3 -найти рассояние между ними... самый надежный способ определить два типа и функцию возвращающую расстояние.- здесь нет никакого полиморфизма или наследования... работаем только с переменными пользовательских типов. И уж коль скоро мы говорим о них (пременных пользовательских типов ) - почему бы не сделать их полноценными (коль скоро постулируем СТРОГУЮ ТИПИЗАЦИЮ). Да и еще я говорил про простой СОВРЕМЕННЫЙ ЯВУ..все -таки кое какой багаж за последние 40 лет накоплен...
Понятно. Хороший пример.
И чего Вам не хватает в просто RECORD-е для него? Тут действительно нет никакого ООП.
Процедуры, RECORD-ы.
Можно придумывать всякую лабуду, чтобы "оно себя вело надёжнее и как встроенное". Но будет ли это проще?
Я, например, не стал бы считать простой какую-то внешне простую "вкусность", про которую я не могу на пальцах и с парой рисунков на доске объяснить, как она работает (во что отображается в памяти, в какие действия машины и т.п.). Простое - это прозрачное в поведении.
С одной стороны, идея независимости абстракций от реализации - правильная идея. Но на самом деле эта независимость должна быть "как-бы-независимостью". Т.е. абстракции надо придумывать так, чтобы определены они были без связи с реализацией; но вот хорошее объяснение и изучение всегда должно показывать, а как это внутри устроено. Нельзя использовать то, об устройстве чего нет представления (во что и как это ниже отображается, примерно).
-
Понятно. Хороший пример.
И чего Вам не хватает в просто RECORD-е для него? Тут действительно нет никакого ООП.
Процедуры, RECORD-ы.
Можно придумывать всякую лабуду, чтобы "оно себя вело надёжнее и как встроенное". Но будет ли это проще?
Я, например, не стал бы считать простой какую-то внешне простую "вкусность", про которую я не могу на пальцах и с парой рисунков на доске объяснить, как она работает (во что отображается в памяти, в какие действия машины и т.п.). Простое - это прозрачное в поведении.
С одной стороны, идея независимости абстракций от реализации - правильная идея. Но на самом деле эта независимость должна быть "как-бы-независимостью". Т.е. абстракции надо придумывать так, чтобы определены они были без связи с реализацией; но вот хорошее объяснение и изучение всегда должно показывать, а как это внутри устроено. Нельзя использовать то, об устройстве чего нет представления (во что и как это ниже отображается, примерно).
1. Механизма который обеспечивал бы непротиворечивое создание экземпляра переменной ПОЛЬЗОВАТЕЛЬСКОГО типа.
2. Зачастую абстракции не надо придумывать - есть куча теорий, методов - нужно просто взять их отобразить их на ЯП максимально корректно и простым образом (но даже если и приходится это делать - то аттрибуты и свойства таких абстракций диктуются практической задачей).
3. МОЖНО И НУЖНО (блондинка не знает как устроен ПОРШ (как и я), но из этого не следует что она не МОЖЕТ кататься на нем (а вот я - нет ;) ), а НУЖНОСТЬ следует , хотя бы из того, что мы ДОЛЖНЫ обучать школьников и студентов (программированию ) в текущих условиях (при чем не обязательно программистов по профилю)... :D
-
Но будет ли это проще?
Я, например, не стал бы считать простой какую-то внешне простую "вкусность", про которую я не могу на пальцах и с парой рисунков на доске объяснить, как она работает (во что отображается в памяти, в какие действия машины и т.п.). Простое - это прозрачное в поведении.
Тут речь идет даже скорее не о простоте, а о полезности - а полезность у инициализатора такая же как и у конструктора... более полезно (с моей точки зрения) наличие механизма обеспечивающего непротиворечивое состояние переменной в течении всего срока ее жизни.
-
Вы считаете что такое решение заранее подойдёт для всех задач? :D
... для большинства задач начального уровня (ИМХО) - это разумный ( и естесственный с точки зрения человеческой психики) выбор
С Вами всё ясно. :)
-
Просто добавьте DEF-файлы, и в зависимости от задач и предпочтений решайте - генерируются они автоматически из модулей или наоборот - из них автоматически генерируются болванки модулей.
Кстати, интересная мысль. :)
Допустим, в команде разработчиков роли могут быть распределены так, что один разрабатывает интерфейсы модулей (архитектор), а другие строчат эти модули (программисты). Тогда сначала архитектор пишет DEF-ки, а затем программисты автоматически генерируют по DEF-кам болванки модулей и начинают работать. По окончании работы по готовым модулям автоматически генерируются DEF-ки. И не дай Бог, если новые DEF-ки не соответсвуют старым! :)
-
Вы считаете что такое решение заранее подойдёт для всех задач? :D
... для большинства задач начального уровня (ИМХО) - это разумный ( и естесственный с точки зрения человеческой психики) выбор
С Вами всё ясно. :)
Так за взаимопонимание ;)
-
Не понял -как можно сделать болванку из дефа (в XDS) автоматом?
DEFINITION заменить на MODULE и вперёд! :) Остальные мелкие огрехи - не беда, всё-равно болванку править. На крайняк можно утилитку написать, которая будет править заголовок и выносить методы из описания записей-классов-объектов.
-
Не понял -как можно сделать болванку из дефа (в XDS) автоматом?
DEFINITION заменить на MODULE и вперёд! :) Остальные мелкие огрехи - не беда, всё-равно болванку править. На крайняк можно утилитку написать, которая будет править заголовок и выносить методы из описания записей-классов-объектов.
Тогда нафига делать деф ;D
-
Тогда нафига делать деф ;D
Так тому кто разрабатывает только интерфейс модуля удобнее нотация DEF. И опять же проверка готового модуля будет в первую очередь производится на предмет соответствия изначально разработанному интерфейсу.
-
Тогда нафига делать деф ;D
Так тому кто разрабатывает только интерфейс модуля удобнее нотация DEF. И опять же проверка готового модуля будет в первую очередь производится на предмет соответствия изначально разработанному интерфейсу.
Я к тому что от дефа (в случае оберонов) компилируемая пустышка будет отличаться всего лишь наличием BEGIN END; после каждого определения функции (вследствии того, что стиль оберонцев - большая куча узкоспециализированных маленьких модулей)
-
Я к тому что от дефа (в случае оберонов) компилируемая пустышка будет отличаться всего лишь наличием BEGIN END;
Ещё (2) все заголовки методов будут внесены в описания соответствующих типов; и (3) будут исключены все приватные объявления.
-
Я к тому что от дефа (в случае оберонов) компилируемая пустышка будет отличаться всего лишь наличием BEGIN END;
Ещё (2) все заголовки методов будут внесены в описания соответствующих типов; и (3) будут исключены все приватные объявления.
да в теории это так - но опять повторю - стиль оберона- один класс-один модуль ...
-
да в теории это так - но опять повторю - стиль оберона- один класс-один модуль ...
Ну, вообще говоря, это не так. Точнее, не обязательно так. Удобно бывает в модуле объявить ворох тесносвязанных сущностей-рекордов, которые гарантированно должны знать друг о друге, реализовать функции их совместной обработки и заэкспортировать все это, возможно без доступа к конкретным полям этих рекордов.
-
да в теории это так - но опять повторю - стиль оберона- один класс-один модуль ...
Ну, вообще говоря, это не так. Точнее, не обязательно так. Удобно бывает в модуле объявить ворох тесносвязанных сущностей-рекордов, которые гарантированно должны знать друг о друге, реализовать функции их совместной обработки и заэкспортировать все это, возможно без доступа к конкретным полям этих рекордов.
А я и не говорю про абсолют - речь идет о том что (ИМХО) язык подталкивает к такому стилю (косвенно это подтверждают исходники ББ+уверения некоторых коровцев о их эталонности (с точки зрения проектирования) ;) ).
-
речь идет о том что (ИМХО) язык подталкивает к такому стилю
Как он может подталкивать к этому? В 16 страницах вроде ни слова нет про принципы проектирования модулей и систем из них...
-
речь идет о том что (ИМХО) язык подталкивает к такому стилю
Как он может подталкивать к этому? В 16 страницах вроде ни слова нет про принципы проектирования модулей и систем из них...
Ну начнем, с того , что в системе расчитанной на компонентную разработку просто неприлично иметь излишне большие динамически подгружаемые модули. далее -инкапсуляция и ООП на уровне модуля, простая линейная структура его (без дефов задолбаешься елозить по нему), отсутствие перегрузки функций... хватит ?
-
В общем, резюмируя, язык вынуждает проектировать культурно, т.е. следовать принципу "Разделяй и управляй".
-
Ну начнем, с того , что в системе расчитанной на компонентную разработку просто неприлично иметь излишне большие динамически подгружаемые модули. далее -инкапсуляция и ООП на уровне модуля, простая линейная структура его (без дефов задолбаешься елозить по нему), отсутствие перегрузки функций... хватит ?
То есть речь не о языке, а о некоторых его реализациях.
Другие реализации к этому совершенно не подталкивают.
ЗЫ. Даже в ETH Oberon был компонент под названием Oberon Companion, в котором были перегруженные процедуры (операции), так что "отсутствие перегрузки функций" лучше вычеркнуть из этого списка...
-
В общем, резюмируя, язык вынуждает проектировать культурно, т.е. следовать принципу "Разделяй и управляй".
Спорное утверждение, как, впрочем, и многие другие восхваления оберонов...
-
В общем, резюмируя, язык вынуждает проектировать культурно, т.е. следовать принципу "Разделяй и управляй".
Спорное утверждение, как, впрочем, и многие другие восхваления оберонов...
Вообще говоря да (перспектива менеджмента кучи мелких модулей раздражает, по крайней мере, в текущей реализации ББ), но для образовательных целей такой стиль самое то ...
в отличие от Хацкельного.
-
В общем, резюмируя, язык вынуждает проектировать культурно, т.е. следовать принципу "Разделяй и управляй".
Спорное утверждение, как, впрочем, и многие другие восхваления оберонов...
Вообще говоря да (перспектива менеджмента кучи мелких модулей раздражает, по крайней мере, в текущей реализации ББ), но для образовательных целей такой стиль самое то ...
в отличие от Хацкельного.
А какой стиль у хацкеля? :-)
-
Вообще говоря да (перспектива менеджмента кучи мелких модулей раздражает, по крайней мере, в текущей реализации ББ), но для образовательных целей такой стиль самое то ...
в отличие от Хацкельного.
Зато этот мелкий модуль один раз реализован - и эксплуатируется, без изменений. Возникли вариации - делается другой, новый. Исходный код "твёрдый", "отлитый".
-
В общем, резюмируя, язык вынуждает проектировать культурно, т.е. следовать принципу "Разделяй и управляй".
Спорное утверждение, как, впрочем, и многие другие восхваления оберонов...
Вообще говоря да (перспектива менеджмента кучи мелких модулей раздражает, по крайней мере, в текущей реализации ББ), но для образовательных целей такой стиль самое то ...
в отличие от Хацкельного.
А какой стиль у хацкеля? :-)
Гнусные программки на 500 строк с низходящим проектированием и оголтелым использованием рекурсий... ;)
-
А какой стиль у хацкеля? :-)
Гнусные программки на 500 строк с низходящим проектированием и оголтелым использованием рекурсий... ;)
Это что угодно, но не Haskell-way. Возможно, на Рефале так и пишут.
Вот последняя утилитка на Хаскелле, которую я сделал для анализа логов расхода траффика одной моей программы: ни одной рекурсии. Куча map'ов, по одному filter, groupBy, fold, lines/unlines. Рекурсии почему-то не понадобились...
Опять оберонщеги лгут, ну что за жисть?..
-
А какой стиль у хацкеля? :-)
Гнусные программки на 500 строк с низходящим проектированием и оголтелым использованием рекурсий... ;)
Это что угодно, но не Haskell-way. Возможно, на Рефале так и пишут.
Вот последняя утилитка на Хаскелле, которую я сделал для анализа логов расхода траффика одной моей программы: ни одной рекурсии. Куча map'ов, по одному filter, groupBy, fold, lines/unlines. Рекурсии почему-то не понадобились...
Опять оберонщеги лгут, ну что за жисть?..
:D :D :D Вы не тру хаскиллер - в Вас поселилась "гниль" императивщины ( с вражинами поведешься - от них и наберешься). ;D ;D ;D ;D
-
А какой стиль у хацкеля? :-)
Гнусные программки на 500 строк с низходящим проектированием и оголтелым использованием рекурсий... ;)
Это что угодно, но не Haskell-way. Возможно, на Рефале так и пишут.
Вот последняя утилитка на Хаскелле, которую я сделал для анализа логов расхода траффика одной моей программы: ни одной рекурсии. Куча map'ов, по одному filter, groupBy, fold, lines/unlines. Рекурсии почему-то не понадобились...
Опять оберонщеги лгут, ну что за жисть?..
:D :D :D Вы не тру хаскиллер - в Вас поселилась "гниль" императивщины ( с вражинами поведешься - от них и наберешься). ;D ;D ;D ;D
Какая императивнщина, о чём это Вы? о_О
Перечисленные мною функции ни разу не императивны -- чистейшей воды ФП...
-
А какой стиль у хацкеля? :-)
Гнусные программки на 500 строк с низходящим проектированием и оголтелым использованием рекурсий... ;)
Это что угодно, но не Haskell-way. Возможно, на Рефале так и пишут.
Вот последняя утилитка на Хаскелле, которую я сделал для анализа логов расхода траффика одной моей программы: ни одной рекурсии. Куча map'ов, по одному filter, groupBy, fold, lines/unlines. Рекурсии почему-то не понадобились...
Опять оберонщеги лгут, ну что за жисть?..
:D :D :D Вы не тру хаскиллер - в Вас поселилась "гниль" императивщины ( с вражинами поведешься - от них и наберешься). ;D ;D ;D ;D
Какая императивнщина, о чём это Вы? о_О
Перечисленные мною функции ни разу не императивны -- чистейшей воды ФП...
Признаю ошибку- вы функциональщик по духу (они очень специфическое (функциональное) восприятие юмора -заключающееся (как правило) в его отсутствии (восприятия)). :)
Но ответ прост -в ФЯП вы либо ограничиваетесь минимумом (достаточно сложных) понятий (но активно юзаете рекурсию -путь ранних ФЯП), либо плодите сущности (часть из который перечисленна вами выше) и юзаете их - путь Хаскеля. (и то и другое для обучения масс (ИМХО) программированию на начальном этапе (вспомните с чего началось веселье ;) ) слабо применимо в текущей реальности)
-
Признаю ошибку- вы функциональщик по духу (они очень специфическое (функциональное) восприятие юмора -заключающееся (как правило) в его отсутствии (восприятия)). :)
Ну это явная клевета.
Но ответ прост -в ФЯП вы либо ограничиваетесь минимумом (достаточно сложных) понятий (но активно юзаете рекурсию -путь ранних ФЯП), либо плодите сущности (часть из который перечисленна вами выше) и юзаете их - путь Хаскеля. (и то и другое для обучения масс (ИМХО) программированию на начальном этапе (вспомните с чего началось веселье ;) ) слабо применимо в текущей реальности)
Почему это вдруг? Массы вполне легко всё это осваивают -- и рекурсию, и ФВП.
Или Вы имеете в виду массы, мозги которых испорченны императивщиной, бейсиком 60-х годов?
-
Ну это явная клевета.
Ну да ... ;) оно и видно. :D :D
Почему это вдруг? Массы вполне легко всё это осваивают -- и рекурсию, и ФВП.
Или Вы имеете в виду массы, мозги которых испорченны императивщиной, бейсиком 60-х годов?
Если бы ... я имею ввиду массы которые народились и обучались после развала совка. :(