Oberon space
General Category => Общий раздел => Тема начата: DIzer от Январь 23, 2012, 04:52:22 am
-
Коль скоро в предыдущем топике все согласились с тем, что INC DEC -избыточны в определении языка , и даже был предложен способ регуляризации подпрограмм такого рода. Почему бы не обсудить здесь возможность "занять" опустевшее место :) - скажем, возможностью введения неименованных функций (по типу DELPHI) - это вполне может выглядеть так:
TYPE
MyProc= REFERENCE TO PROCEDURE(VAR i:INTEGER; j:INTEGER:=1);
VAR MyINC:MyProc; k:INTEGER;
BEGIN
......
MyINC:=PROCEDURE (VAR i:INTEGER; j:INTEGER:=1) BEGIN i:=i+j END;
MyINC(k,4); MyINC(k);
......
также можно обеспечить поддержку замыканий (сохранение ссылок на локальное окружение используемое в неименованных функциях - благо мусоросборник есть в наличии)
-
Замыкания - это тот случай, когда синтаксис имеет значение. Многословные замыкания не нужны, точнее они почти бесполезны.
-
Замыкания - это тот случай, когда синтаксис имеет значение. Многословные замыкания не нужны, точнее они почти бесполезны.
Это если относится к ним как синтаксическому сахару (аналог INC += ......). Впрочем, в моей пратике не было нужды ни в лямбдах, ни в замыканиях (хотя в делфях они с 2008)- с другой стороны, я не занимался серьезно компонентостроительством - чисто бизнес логика внедряемая в готовые фреймворки.... Так что весь вопрос в том, насколько такого рода конструкция РЕАЛЬНО востребована в приложениях области использования ЯВУ- ;) И видется мне, что от детального анализа области предполагаемого эффективного использования не уйти.
[from valexey: поправил кодировку]
-
Так что весь вопрос в том, насколько такого рода конструкция РЕАЛЬНО востребована в приложениях области использования ЯВУ- ;)
Если они есть, то мне с ними удобнее...
-
>REFERENCE TO PROCEDURE
Можно ли обойтись без подобных конструкций?
-
>REFERENCE TO PROCEDURE
Можно ли обойтись без подобных конструкций?
А за чем? - название АБСОЛЮТНО ТОЧНО передает смысл того , что будет создано по этому шаблону- равно как POINTER TO
-
Замыкания - это тот случай, когда синтаксис имеет значение. Многословные замыкания не нужны, точнее они почти бесполезны.
Это если относится к ним как синтаксическому сахару (аналог INC += ......). Впрочем, в моей пратике не было нужды ни в лямбдах, ни в замыканиях (хотя в делфях они с 2008)- с
В делфях замыкания и "неименованные функции" сделаны весьма неудачно. Поэтому безымянными функциями там никто особо и не пользуется.
Я лямбдами пользуюсь довольно активно в тех языках где они удобно сделаны и в тех случаях когда это уместно по задаче. В случае громоздкого синтаксиса лямбды (и порсто безымянные функции) никто использовать не будет.
-
В делфях замыкания и "неименованные функции" сделаны весьма неудачно. Поэтому безымянными функциями там никто особо и не пользуется.
Я лямбдами пользуюсь довольно активно в тех языках где они удобно сделаны и в тех случаях когда это уместно по задаче. В случае громоздкого синтаксиса лямбды (и порсто безымянные функции) никто использовать не будет.
Там они сделаны в соответствии с принципами построения ЯП (Паскаля). Из этого правилен ли вывод - лямбды, замыкания... не более чем синтаксический сахар в языках где программа имеет жесткую секционную структуру (разделы обьявлений -констант, переменных, типов)?
-
да любые языковые конструкции являются лишь синтаксическим сахаром для машинных команд
-
да любые языковые конструкции являются лишь синтаксическим сахаром для машинных команд
Это банально - но я говорю о другом - любой ЯВУ задает некоторое множество фундаментальных концепций с помощью которых моделируются решаемые задачи. В этой связи реформулирую вопрос- правильно ли то, что введение понятий "лямбда, карринг, замыкание"-в ЯП с жестко -фиксированной секционной организацией существенно НЕ облегчает процесс решения ТИПИЧНЫХ (лежащих в области наиболее эффективного использования) для ЯП задач?
-
Ну, жили ведь полвека без лямбд и замыканий -- и не тужили.
А сейчас мода и всё такое -- время покажет, будем ли мы через полвека удивляться языкам без лямбд или нет...
-
да любые языковые конструкции являются лишь синтаксическим сахаром для машинных команд
Вы слишком расширительно употребляете понятие "синтаксический сахар".
-
да любые языковые конструкции являются лишь синтаксическим сахаром для машинных команд
Вы слишком расширительно употребляете понятие "синтаксический сахар".
Не, ну а что, ведь жили же с ЭНИАКом, который программировался перемычками, не тужили.
А потом как начали выдумывать -- автокоды всякие, фортраны, коболы, лиспы...
Сахар...
-
Как я понимаю "сахар": это детали, которые не увеличивают мощность инструмента в той парадигме, для которой оный инструмент предназначен.
-
Как я понимаю "сахар": это детали, которые не увеличивают мощность инструмента в той парадигме, для которой оный инструмент предназначен.
Ну да, нет ничего более мощного, чем машинный код...
"Сахар" делает более удобным (приятным) решение задач.
-
Ну да, нет ничего более мощного, чем машинный код...
"Сахар" делает более удобным (приятным) решение задач.
Слова.. Конкретную задачу, решает алгоритм, что бы его составить- НЕОБХОДИМО понимание предметной области - без этих вещей ваша оценка "мощности" преувеличена.
Не, ну а что, ведь жили же с ЭНИАКом, который программировался перемычками, не тужили.
А потом как начали выдумывать -- автокоды всякие, фортраны, коболы, лиспы...
Сахар...
:) Ну да - и решали СООТВЕТСТВУЮЩИЕ задачи ;)