Привет Курилка.
Ну и с чем ты несогласен? Нафига минус поставил?
Если кто-то думает, что автоматизация программирования произойдёт от лингвистических фокусов, тот жестоко ошибается. Поговорите со старшими товарищами, они раскажут вам легенды про компиляторы компиляторов и прочих выкрутасов.
Рекомендую повторять как мантру: автоматизация программирования произойдёт через развитие среды разработки.
Re[14]: Паттерны суть слабости языков программирования
Здравствуйте, AVC, Вы писали:
AVC>Давай разберемся; может, я неправильно понимаю. AVC>Как это "контекст не передается"? AVC>callback — какая-то внешняя процедура, мы передаем туда fn, callback вызывает fn, fn использует значение n из своего контекста (откуда же еще?).
Здравствуйте, AVC, Вы писали:
AVC>Давай разберемся; может, я неправильно понимаю. AVC>Как это "контекст не передается"? AVC>callback — какая-то внешняя процедура, мы передаем туда fn, callback вызывает fn, fn использует значение n из своего контекста (откуда же еще?).
В том и дело, что не процедура
Хотя это лирика...
А смысл в том, что у тебя есть только контекст вызова, а для замыкания нужен ещё конктекст создания замыкания (может есть другие определения, я из головы придумал ) Получается, что в одном месте ты создаёшь замыкание, в котором участвуют переменные, которые определены в данный момент, потом это замыкание передаётся куда-либо (вот это будет проблемой для паскаля/оберона, т.к. локальные переменные уже могут быть не видны в той точке куда мы попадём) и т.к. это функция, то туда передаются ещё параметры для вызова (0 параметров как один из вариантов). Примерно так.
У тебя же внутри происходи вызов и никуда замыкание "уйти" не может...
WR>Привет Курилка. WR>Ну и с чем ты несогласен? Нафига минус поставил?
Не согласен вообще с идеей и где тут счастье я не понимаю. У тебя получается кодогенератор с ридонли генерируемыми файлами. Повышения абстракции тут я мало вижу. Может прикажешь просто смотреть код, который из программы дизассемблером получить можно?
Re[15]: Паттерны суть слабости языков программирования
Здравствуйте, Курилка, Вы писали:
К>А смысл в том, что у тебя есть только контекст вызова, а для замыкания нужен ещё конктекст создания замыкания (может есть другие определения, я из головы придумал )
Да не нужны никакие определения . Разница в том, что в одном случае контекст хранится в стеке, а во втором в куче. Соответственно, время его существования либо совпадает со временем активности определяющей его процедуры, либо определяется сборщиком мусора.
Re[16]: Паттерны суть слабости языков программирования
Здравствуйте, Трурль, Вы писали:
Т>Да не нужны никакие определения . Разница в том, что в одном случае контекст хранится в стеке, а во втором в куче. Соответственно, время его существования либо совпадает со временем активности определяющей его процедуры, либо определяется сборщиком мусора.
То-то я не мог понять, зачем ребята сюда GC "приплели"...
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Хоар
Re[15]: Паттерны суть слабости языков программирования
Здравствуйте, FR, Вы писали:
AVC>>Давай разберемся; может, я неправильно понимаю. AVC>>Как это "контекст не передается"? AVC>>callback — какая-то внешняя процедура, мы передаем туда fn, callback вызывает fn, fn использует значение n из своего контекста (откуда же еще?).
FR>Смотри тут Re[4]: Почему у Nemerle нет будущего
ИМХО, Трурль показал, в чем ошибка в приведенном примере.
Сначала выходишь из процедуры, портишь стек, а затем сетуешь, что "контекст не сохранился".
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, Курилка, Вы писали:
К>Не согласен вообще с идеей и где тут счастье я не понимаю. У тебя получается кодогенератор с ридонли генерируемыми файлами. Повышения абстракции тут я мало вижу. Может прикажешь просто смотреть код, который из программы дизассемблером получить можно?
Извини что недостаточно подробно описал идею.
Если непонятно, то может и ново? Сейчас побегу патент делать.
Короче. Представь себе что это текст который можно править.
А это текст который нельзя править.
Это тоже нельзя ни удалять ни править.
А здесь снова можно править.
Ура!!!
Понятно?
Re[8]: Паттерны суть слабости языков программирования
Здравствуйте, Трурль, Вы писали:
AVC>>>О каких именно современных конструкциях идет речь? K>>Параметрические типы. K>>Функции как fco, ну и, соответственно, полноценные лексические замыкания и лямбды. K>>Алгебраические типы, кортежи, pattern matching. Т>Какие же это это современные конструкции? Наследие 70-х.
Нет! Нееет!!! Только не бросайте меня в терновый куст!
Все дело в том, что разговор начинался так:
Все потенциально возможные конструкции конечно не нужно включать, но и минимализм Вирта когда в язык не включены просто необходимые для современного языка конструкции и возможности тоже плохо.
А продолжался так:
О каких именно современных конструкциях идет речь?
Легко видеть, что на данном этапе конструкции, необходимые для того, чтобы язык можно было бы считать современным были подменены на современные конструкции.
Естественно, что современными их называть никак нельзя, но я не стал придираться к словам, хотя, как показала практика, напрасно.
Теперь, конечно, пойдут слухи, что Клапауций — неуч, и не знает когда появился pattern matching.
Отсюда мораль: если увидите ошибку у собеседника — необходимо без промедления, громко и неоднократно выразить свое отношение к этой ошибке, в противном же случае окружающие могут подумать, что эту ошибку вы сами разделяете. Поэтому: cave! А лучше даже сapiat qui сареrе potest!
... << RSDN@Home 1.2.0 alpha rev. 655>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, WoldemaR, Вы писали:
WR>Здравствуйте, Курилка, Вы писали:
К>>Непонятен смысл этого — сделать "безопасные" кодогенераторы?
WR>Непонял. Что значит "безопасные"? кто говорил об этом?
Тогда объясни — зачем вообще тебе это нужно: "текст который нельзя править".
Здравствуйте, AVC, Вы писали:
K>>Параметрические типы. K>>Функции как fco, ну и, соответственно, полноценные лексические замыкания и лямбды. K>>Алгебраические типы, кортежи, pattern matching. AVC>Спасибо.
Всегда пожалуйста.
AVC>Что любопытно, еще в середине 90-х для Оберона был предложен "легкий" вариант параметрического полиморфизма. AVC>Пока не знаю, почему он не прижился (т.е. были какие-то технические трудности или это была принципиальная позиция).
Как показывает практика — технически это задача вполне решаемая. В то время, как идеологическое обоснование было бы достаточно интересно услышать.
K>>Да чего там говорить? В Обероне, кажется, даже интерфейса как языковой сущности не существует. И множественной реализации нет, так ведь? AVC>Возможно, имя "Оберон" слишком много означает, что вызывает некоторую путаницу. AVC>Оберон (кроме, разумеется, литературных и астрономических ассоциаций) — это: AVC>1) операционная система (теперь, пожалуй, даже целое их семейство); AVC>2) язык программирования, использованный для создания этой операционки; AVC>3) семейство языков — "дериватов" Оберона (Оберон-2, Активный Оберон, Зоннон; на самом деле таких языков гораздо больше). AVC>В первоначальном Обероне-языке не было (множественных) интерфейсов, но в Активном Обероне и Зонноне есть их аналог — definition. (Т.е. не все "оберонщики" такие же минималисты, как Вирт. )
Насколько я знаю, definition не полный аналог интерфейса потому, что возможно множественное наследование defenition-ов, но реализация все равно единичная. Если вспомнить, что я говорил именно про множественную реализацию, то понять смысл возражения довольно сложно. Если я по данному вопросу заблуждаюсь — прошу развеять мои заблуждения.
... << RSDN@Home 1.2.0 alpha rev. 655>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
WR>Удобно смотреть как работает генератор кода. Наслаждаться. WR>Можно комбинировать код сгенерённый и ручной.
Только вот кодогенераторами не решить всех вопросов про паттерны
WR>Красота.
Соглашусь полезно
WR>А теперь объясни про "безопасность". что ты имел ввиду?
То, что будут использоваться не нагенерённые файлы, которые любомой сможет править как хочет, а "безопасное" представление (может быть известное только во время компиляции).
Здравствуйте, Курилка, Вы писали:
К>Только вот кодогенераторами не решить всех вопросов про паттерны
Да вот и мне так кажется.
WR>>А теперь объясни про "безопасность". что ты имел ввиду?
К>То, что будут использоваться не нагенерённые файлы, которые любомой сможет править как хочет, а "безопасное" представление (может быть известное только во время компиляции).
В том то и дело, что не "как хочет", но кое-что может.
Мне представляется, что в ближайшем будущем файл "исходного" кода будет содержать большое количество разнообразных тегов содержащих документирование (уже есть), правила форматирования, редактирования и много чего ещё.
Re[9]: Паттерны суть слабости языков программирования
Здравствуйте, Klapaucius, Вы писали:
K>Легко видеть, что на данном этапе конструкции, необходимые для того, чтобы язык можно было бы считать современным были подменены на современные конструкции.
Ага. Это я подменил, исключительно для краткости.
И, действительно, зря: получилась путаница.
"Современными" могут быть как сами конструкции, так и их сочетание.
Речь, видимо, идет о втором варианте.
Из всего, что я здесь прочел, напрашивается вывод, что "современными" считаются императивные языки с включением отдельных функциональных конструкций.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Хоар
Re[16]: Паттерны суть слабости языков программирования
AVC>ИМХО, Трурль показал, в чем ошибка в приведенном примере. AVC>Сначала выходишь из процедуры, портишь стек, а затем сетуешь, что "контекст не сохранился".
"ошибка" там намереная чтобы показать что паскаль не подерживает замыкания.
Даже если вызывать вложенную функцию, все равно не работает:
program tst;
procedure main;
type pfunc = function() : integer;
function fget(n : integer) : pfunc;
function lget() : integer;
begin
lget := n;
end;
begin
fget := @lget;
end;
var func : pfunc;
begin
func := fget(1);
writeln(func());
func := fget(1234);
writeln(func());
end;
begin
main;
end.
Re[9]: Паттерны суть слабости языков программирования
Здравствуйте, Klapaucius, Вы писали:
K>Теперь, конечно, пойдут слухи, что Клапауций — неуч, и не знает когда появился pattern matching.
K>Отсюда мораль: если увидите ошибку у собеседника — необходимо без промедления, громко и неоднократно выразить свое отношение к этой ошибке, в противном же случае окружающие могут подумать, что эту ошибку вы сами разделяете. Поэтому: cave! А лучше даже сapiat qui сареrе potest!
