Здравствуйте, lomeo, Вы писали:
L>Насчет сахара и лямбд. Как ты запишешь абстракцию лямбды в ФЯ, в котором нет лямбд? Заметь, что именованные функции в этом случае не подходят — лямбды не подслащивают их использование (как в примерах с a[i] и foreach), они представляют другую абстракцию. Что же касается замыканий (мы говорим о лексическом замыкании?), то для меня это функция, использующая внешние переменные (на которые ей указали при создании). Функция ее создающая есть ФВП, и я плохо понимаю как можно иметь в языке ФВП и не иметь замыканий. Хотя, здесь я возможно ошибаюсь.
Легко.
Неммерле
foo () : void
{
def i = 234;
def addI = _ + i;
def x = addI(123);
}
А теперь тоже самое без замыканий
private sealed class _N_closure1425
{
internal _N_closure1425()
{
}
internal int _N_i1430;
}
private sealed class _N__N_l1189_1438 : Function<int, int>
{
public _N__N_l1189_1438(Test._N_closure1425 _N_foo_clo1442)
{
this._N_foo_clo1442 = _N_foo_clo1442;
}
public override int apply(int _N_1437)
{
return (_N_1437 + this._N_foo_clo1442._N_i1430);
}
private Test._N_closure1425 _N_foo_clo1442;
}
private static void foo()
{
Test._N_closure1425 _closure1 = new Test._N_closure1425();
_closure1._N_i1430 = 0xea;
Function<int, int> function1 = new Test._N__N_l1189_1438(_closure1);
function1.apply(0x7b);
}
(C)Reflector
Могу повторить все тоже самое на чистых сях. Только это будет выглядить еще страшнее.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, VladD2, Вы писали:
VD>Ясность — она и есть ясность. Например, i++ ничем не яснее чем i += 1 или i = i + 1, а даже наооборот.
Извините, что вмешиваюсь, но i++ не является эквивалентом ни i+=1, ни i=i+1. Это лаконичная запись: (t=i;i+=1;t). Поэтому нельзя сравнивать "ясность" i++ и i+=1. А вот ++i действительно эквивалентна i+=1 и i=i+1, но и ясность этих трех записей одинаковая.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, lomeo, Вы писали:
L>>Насчет сахара и лямбд. Как ты запишешь абстракцию лямбды в ФЯ, в котором нет лямбд? Заметь, что именованные функции в этом случае не подходят — лямбды не подслащивают их использование (как в примерах с a[i] и foreach), они представляют другую абстракцию. Что же касается замыканий (мы говорим о лексическом замыкании?), то для меня это функция, использующая внешние переменные (на которые ей указали при создании). Функция ее создающая есть ФВП, и я плохо понимаю как можно иметь в языке ФВП и не иметь замыканий. Хотя, здесь я возможно ошибаюсь. WH>Легко.
Ты похоже про что-то свое
Вроде просили показать как сделать лямбду, а ты показал что компилятор реализует замыкание с помощью классов, что есть демонстрирация убогости в этом отношении CLI.
WH>Неммерле WH>
Здравствуйте, WolfHound, Вы писали:
L>>Насчет сахара и лямбд. Как ты запишешь абстракцию лямбды в ФЯ, в котором нет лямбд? Заметь, что именованные функции в этом случае не подходят — лямбды не подслащивают их использование (как в примерах с a[i] и foreach), они представляют другую абстракцию. Что же касается замыканий (мы говорим о лексическом замыкании?), то для меня это функция, использующая внешние переменные (на которые ей указали при создании). Функция ее создающая есть ФВП, и я плохо понимаю как можно иметь в языке ФВП и не иметь замыканий. Хотя, здесь я возможно ошибаюсь.
WH>Легко.
А где во втором случае ФВП?
Мне кажется, что для замыканий нужна еще (кроме ФВП) сама возможность определения лексического контекста — вот в си, например, ФВП есть, а вложенных функций нет, поэтому замыкание не построишь.
private sealed class _N__N_l1193_1471 : Function<int, int>
{
// Methodspublic _N__N_l1193_1471(Test._N_closure1463 _N_combine_clo1475, Test._N_closure1437 _N_foo_clo1477)
{
this._N_combine_clo1475 = _N_combine_clo1475;
this._N_foo_clo1477 = _N_foo_clo1477;
}
public override int apply(int _N_1470)
{
return this._N_combine_clo1475._N_fn1468.apply(_N_1470, this._N_foo_clo1477._N_i1442);
}
// Fieldsprivate Test._N_closure1463 _N_combine_clo1475;
private Test._N_closure1437 _N_foo_clo1477;
}
private sealed class _N__N_l1200_1484 : Function<int, int, int>
{
public override int apply(int _N_1482, int _N_1483)
{
return (_N_1482 + _N_1483);
}
}
private sealed class _N_closure1437
{
internal int _N_i1442;
}
private sealed class _N_closure1463
{
internal Function<int, int, int> _N_fn1468;
}
private static Function<int, int> _N_combine1445(Test._N_closure1437 _N_foo_cp1444, Function<int, int, int> fn)
{
Test._N_closure1463 _closure1 = new Test._N_closure1463();
_closure1._N_fn1468 = fn;
return new Test._N__N_l1193_1471(_closure1, _N_foo_cp1444);
}
private static void foo()
{
Test._N_closure1437 _closure1 = new Test._N_closure1437();
_closure1._N_i1442 = 0xea;
Function<int, int, int> function1 = new Test._N__N_l1200_1484();
Test._N_combine1445(_closure1, function1).apply(0x7b);
}
L>Мне кажется, что для замыканий нужна еще (кроме ФВП) сама возможность определения лексического контекста — вот в си, например, ФВП есть, а вложенных функций нет, поэтому замыкание не построишь.
О том тебе и говорят что ФВП нафиг не упали без замыканий, а замыкания это всеголишь сахар.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
L>>А где во втором случае ФВП?
WH>Да пожалуйста
Ну и где там ФВП, то??
L>>Мне кажется, что для замыканий нужна еще (кроме ФВП) сама возможность определения лексического контекста — вот в си, например, ФВП есть, а вложенных функций нет, поэтому замыкание не построишь.
WH>О том тебе и говорят что ФВП нафиг не упали без замыканий, а замыкания это всеголишь сахар.
Неправду мне говорят, не слушай Я писал "как можно иметь в языке ФВП и не иметь замыканий", и скорее всего ошибался. Совершенно параллельная (и ложная, кстати) мысль о ненужности ФВП без замыканий никак из этого не вытекает. Также я просил показать, что именно подслащивают замыкания, чтобы являться сахаром. В качестве "доказательства" я вижу лишь — замыкания сахар — поэтому они всего лишь сахар.
Здравствуйте, lomeo, Вы писали:
L>Ну и где там ФВП, то??
Вобщето _N_combine1445 принимает функцию и возвращает функцию.
L>Покажи что замыкания — сахар.
Я уже показал вариант с сахаром и без...
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
L>>Ну и где там ФВП, то?? WH>Вобщето _N_combine1445 принимает функцию и возвращает функцию.
Неа, он принимает не функцию, а объект, который эмулирует функцию, и возвращает тоже объект.
Это неинтересно. Сэмулировать то все что угодно можно. Я видел на пхп эмуляцию замыканий
L>>Покажи что замыкания — сахар. WH>Я уже показал вариант с сахаром и без...
Первое был вариант с замыканиями, а не вариант с сахаром. От того, что их можно сэмулировать они не становятся сахаром. Иначе ВСЕ было бы сахаром — ведь все эмулируется машинными командами, верно?
Здравствуйте, lomeo, Вы писали:
L>Первое был вариант с замыканиями, а не вариант с сахаром. От того, что их можно сэмулировать они не становятся сахаром. Иначе ВСЕ было бы сахаром — ведь все эмулируется машинными командами, верно?
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, lomeo, Вы писали:
L>>Первое был вариант с замыканиями, а не вариант с сахаром. От того, что их можно сэмулировать они не становятся сахаром. Иначе ВСЕ было бы сахаром — ведь все эмулируется машинными командами, верно?
FR>Не я проникся они правы, ну сам посмотри: FR>
FR>тут же все кристально ясно, сразу видно и фвп и замыкание, все это чистый сахар
Угу, а сахар у нас, как известно, круче всего добавлять макросами, и только макросами. Так что макроассемблер должен порвать всех — а Немерле отстой. Это всего лишь сахар.
Здравствуйте, lomeo, Вы писали:
L>Неа, он принимает не функцию, а объект, который эмулирует функцию, и возвращает тоже объект. L>Это неинтересно. Сэмулировать то все что угодно можно. Я видел на пхп эмуляцию замыканий
На C/С++ устроит?
int f1(int i)
{
return i * 2;
}
int f2(int i)
{
return i + 20;
}
int fun1(int i);
typedef int (*FuncTypeIntToInt)(int);
FuncTypeIntToInt hof(FuncTypeIntToInt f)
{
return f2;
}
void main()
{
FuncTypeIntToInt funcVariable = hof(f1);
printf("%d\n", funcVariable(3));
}
L>>>Покажи что замыкания — сахар. WH>>Я уже показал вариант с сахаром и без...
L>Первое был вариант с замыканиями, а не вариант с сахаром.
Ну, согласен, что замыкания это сахар?
L> От того, что их можно сэмулировать они не становятся сахаром.
Становястя. Просто терминалогию нужно другую применять, а именно не "сэмулировать", а "использовал другие сретсва языка для получения той же семантики".
L> Иначе ВСЕ было бы сахаром — ведь все эмулируется машинными командами, верно?
Верно. Потому для ассемблера паттерном является if и while. И средствами некоторых макро-ассемблеров они с успхом воспроизводились.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, <Аноним>, Вы писали:
А>Извините, что вмешиваюсь, но i++ не является эквивалентом ни i+=1, ни i=i+1. Это лаконичная запись: (t=i;i+=1;t). Поэтому нельзя сравнивать "ясность" i++ и i+=1. А вот ++i действительно эквивалентна i+=1 и i=i+1, но и ясность этих трех записей одинаковая.
Это очень ценное замечание проясняющее суть проблемы.
В свою очередь могу тоже докапатсья до слов и сказаь, что есть языки в которых i++ не отличается от ++i потому как ни то ни другое не возвращает значение.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[26]: ФП против ООП
От:
Аноним
Дата:
28.09.06 04:04
Оценка:
Здравствуйте, VladD2, Вы писали:
VD>В свою очередь могу тоже докапатсья до слов и сказаь, что есть языки в которых i++ не отличается от ++i потому как ни то ни другое не возвращает значение.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, FR, Вы писали:
FR>>Вроде просили показать как сделать лямбду,
VD>Просили функции высшего порядка. Они в С есть штатно. Называются указатели на функции. Так что тут и показывать нечего.
Нет просили показать лямбду в виде сахара.
VD>А показал он реализацию замыканий и вложенных фунций на базе классов. То что кто-то не хочет это понимать — это проблемы его личного мозга.
таже самая реализация на x86 ассемблере (хороший компилятор у окамла, оптимизирующий ) если кто-то видит между этими реализациями большую разницу у того тоже проблемы с пониманием
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, lomeo, Вы писали:
L>>Неа, он принимает не функцию, а объект, который эмулирует функцию, и возвращает тоже объект. L>>Это неинтересно. Сэмулировать то все что угодно можно. Я видел на пхп эмуляцию замыканий
VD>На C/С++ устроит?
Это не замыкание, нет захвата свободных переменных.
VD>Становястя. Просто терминалогию нужно другую применять, а именно не "сэмулировать", а "использовал другие сретсва языка для получения той же семантики".
Не получается использовать не хватает семантики, получается именно эмуляция, никакого отличия от эмуляции классов средствами си.
Если бы другие средства давали бы те же результаты, я бы один раз написал class Closure и везде пользовался им как замыканием, а не писал каждый раз вручную реализацию.