H>var factorial = function (x) { return x; }
H>var factorial = function (n) {
H>if (n == 0)
H> return 1;
H> else
H> return n * factorial(n-1); // на что ссылаемся?
H>}
H>
Что значит поступить? Открываем браузер и смотрим, логично что второе значение перезапишит первое. Правильно же делать что нибудь типа
immutable factorial = H>ML без сигнатуры rec возьмет первое определение, с rec — второе.
Я не понимаю зачем такое вообще делать, тут нужно выдавать ошибку компиляции.
VD>>>В прочем, все это никак не влияет на то, что лямбды и обычные функции можно и нужно отличать. D>>В чем же их концептуальное различие?
VD>В назначении. Лямбды, в основном, предназначены для передачи небольших кусков кода в другие функции. Функции же для декомпозиции и инкапсуляции кода. А уж глобальные функции и методы зачастую отличаются еще и семантически.
Предполагая, что язык поддерживает ФВП:
Лямбды — это маленькие безымянные функции высшего порядка, инкапсулирующие какую-то мелкую функциональность. Могут передаваться в другие функции в виде параметров или возвращаться из функций в качестве результата.
Функции — это маленькие и большие именованные функции высшего порядка, инкапсулирующие какую-то мелкую и крупную функциональность. Так же могут передаваться в другие функции в виде параметров или возвращаться из функций в качестве результата.
function func1(param){
print(param);
}
var func2 = func1;
var func3 = function(param){
printf(param);
}
/* ------------ */function test_f(func){
// какая здесь разница, что мы сюда передаем — функцию или лямбду?
// никакой
func(1);
}
// какая здесь разница, что мы сюда передаем — функцию или лямбду?
// никакой
test_f(func1);
test_f(func2);
test_f(func3);
test_f(function(param){ print(param); });
Единственная «разница» между ними — это, возможно, желание писать меньше букв в месте определения лямбды.
Здравствуйте, dotneter, Вы писали:
D>Здравствуйте, hardcase, Вы писали:
H>>А как поступать в этом случае?
H>>
H>>var factorial = function (x) { return x; }
H>>var factorial = function (n) {
H>>if (n == 0)
H>> return 1;
H>> else
H>> return n * factorial(n-1); // на что ссылаемся?
H>>}
H>>
D>Что значит поступить? Открываем браузер и смотрим, логично что второе значение перезапишит первое. Правильно же делать что нибудь типа D>immutable factorial =
Возможно это логично с точки зрения JS, что переменная factorial перезапишется (т.е. это будет одна и та же переменная), а вот с точки зрения Nemerle первое определение factorial попадет в замыкание:
def factorial = fun(x) { x } // (1)
def factorial = fun (n) {
if (n == 0)
1
else
n * factorial(n - 1) // вызов функции (1)
}
H>>ML без сигнатуры rec возьмет первое определение, с rec — второе. D>Я не понимаю зачем такое вообще делать, тут нужно выдавать ошибку компиляции.
Я лишь пытаюсь показать, что унификация объявления функций и лямбд так или иначе приведет к необходимости дополнительных синтаксических изощрений.
Здравствуйте, VladD2, Вы писали:
XC>>функции (как глобальные так и локальные) просто описываются, а лямбды — как описываются, так и вызываются в месте своего описания.
VD>Это заблуждение становится весьма распространенным. VD>На самом деле лямбды не вызываются в месте описания.
Забавно, я на самом деле конечно знал это и имел в виду... Но написал глупость.
Да, лямбды конечно же не "вызываются", а "передаются".
Здравствуйте, hardcase, Вы писали:
D>>Я не понимаю зачем такое вообще делать, тут нужно выдавать ошибку компиляции.
H>Я лишь пытаюсь показать, что унификация объявления функций и лямбд так или иначе приведет к необходимости дополнительных синтаксических изощрений.
Я пока вижу только надуманые сценарии, для которых нужны синтаксические изощрений. Такое просто не должно компилироваться
Func<int, int> factorial = x => ...
Func<int, int> factorial = x => ... compile error
Здравствуйте, dotneter, Вы писали:
D>Здравствуйте, hardcase, Вы писали:
D>>>Я не понимаю зачем такое вообще делать, тут нужно выдавать ошибку компиляции.
H>>Я лишь пытаюсь показать, что унификация объявления функций и лямбд так или иначе приведет к необходимости дополнительных синтаксических изощрений. D>Я пока вижу только надуманые сценарии, для которых нужны синтаксические изощрений. Такое просто не должно компилироваться
D>
D>Func<int, int> factorial = x => ...
D>Func<int, int> factorial = x => ... compile error
D>
H>def x = [1,2,3];
H>def x = x.Map(_.ToString());
H>
Помоему с этим будет больше проблем при чтении кода чем сомнительных бенефитов, особенно если они идут не последовательно, а разделены кодом.
def x =
def yForSomething =
H>>Я лишь пытаюсь показать, что унификация объявления функций и лямбд так или иначе приведет к необходимости дополнительных синтаксических изощрений. D>Я пока вижу только надуманые сценарии, для которых нужны синтаксические изощрений. Такое просто не должно компилироваться
D>
D>Func<int, int> factorial = x => ...
D>Func<int, int> factorial = x => ... compile error
D>
В ML ноги этого растут из того что let по сути синтаксический сахар для безымянных лямбд, предназначенный для связывания лямбды с именем. Поэтому никаких ограничений по повторному использованию вносить нет смысла, и никаких неоднозначностей (кроме рекурсии которую надо явно указывать) это не вызывает. Кроме того механизм вывода типов в ML использует let-полиморфизм.
Я вот продумываю идею в свободное время набросать компилятор языка, в котором синтаксис функций будет синтаксисом меток:
name(arg:type, arg:type, ...):
При этом вызов функции это просто сохранение контекста, размещение параметров и переход, а восстановление контекста осуществляется по ближайшему return. В таком языке единственным возвращаемым типом был бы int, более сложные передавались бы через out-параметры. Мне кажется что такая идея позволяла бы в императивном стиле очень вкусный data-driven, потому что один return мог бы в зависимости от потока данных возвращать из одной-из-нескольких функций. Кроме того оптимизация такого кода была бы очень интересной -- написать хотя бы loop unrolling и tail-call recursion в таком случае превращается в весьма нетривиальный анализ зависимостей. Ведь разумеется я бы оставил вызов функции по указателю на неё любой косвенности.
Но всё руки не доходят.
Здравствуйте, dotneter, Вы писали:
D>inc = x -> x + 1 D>и вот у нас появилось имя, зачем нужно понятие функции если его можно постоить на базисе лямбды и переменной?
Затем же, зачем в большинстве языков можно кроме переменных описывать и константы. Обычное описание функции — это описание константы.
Здравствуйте, dotneter, Вы писали:
VD>>В назначении. Лямбды, в основном, предназначены для передачи небольших кусков кода в другие функции. Функции же для декомпозиции и инкапсуляции кода. А уж глобальные функции и методы зачастую отличаются еще и семантически. D>Как же тогда живется схеме у которой afaik функции — сахар поверх D>(define inc (lambda (x) (+ x 1))
Нормальные люди так не пишут, а используют специализированный синтаксис.
Потом языки разные бывают. Схема не даром не пользуется особой популярностью.
В Немереле, например, лямбды определены через локальные функции. Но методы являются отдельными сущностями. Они не поддерживают замыкания и поддерживают перегрузку. А раз так, то смысла в унификации синтаксиса нет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, dotneter, Вы писали:
VD>>>В назначении. Лямбды, в основном, предназначены для передачи небольших кусков кода в другие функции. Функции же для декомпозиции и инкапсуляции кода. А уж глобальные функции и методы зачастую отличаются еще и семантически. D>>Как же тогда живется схеме у которой afaik функции — сахар поверх D>>(define inc (lambda (x) (+ x 1))
VD>Нормальные люди так не пишут, а используют специализированный синтаксис.
VD>Потом языки разные бывают. Схема не даром не пользуется особой популярностью.
VD>В Немереле, например, лямбды определены через локальные функции. Но методы являются отдельными сущностями. Они не поддерживают замыкания и поддерживают перегрузку. А раз так, то смысла в унификации синтаксиса нет.
Конечно можно придумать язык у которого на каждый чих будет по сущности, но лично мне импонирует идея о минимальном базисе поверх которого макросами делается все остальное, по сути та же схема.
Здравствуйте, dotneter, Вы писали:
D>Конечно можно придумать язык у которого на каждый чих будет по сущности, но лично мне импонирует идея о минимальном базисе поверх которого макросами делается все остальное, по сути та же схема.
От того что методы, локальные функции и лямбды имеют немного разный синтаксис минималистичность базы особо не страдает.
Наличие пяти видов циклов на это куда больше влияет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, x-code, Вы писали:
XC>Вопрос касается скорее "эргономики синтаксиса языка", чем философии... Два варианта: XC>
int func(int x)
XC>vs XC>
def func(int x) int
XC>Второй вариант немного длиннее, но ИМХО более удобен... XC>Что думаете?
Удобнее, не удобнее, какая разница? Это не си-подобный синтаксис, и программирующие массы его отвергнут.
Если бы Nemerle назывался С## и типы записывались спереди, для него все могло бы сложиться по-другому. А так... боюсь, ПМ, everything is expression и макросы будут введены в обиход каким-нибудь C# 6.
Здравствуйте, VladD2, Вы писали:
VD>Когда я в первый раз увидел Nemerle, то меня покоробило использование такой "паскалевской" нотации. Но со временем я понял, что это действительно удобно и хорошо (и что это не паскалевская, а ML-ная нотация ).
А остальные 99% видят "паскалевскую" нотацию, говорят "шозанах" и закрывают мануал. И остаются в убеждении, что это паскалевская нотация.
Если это было больше, чем дипломная работа, а именно — попытка популяризовать язык, большим просчетом было отличаться одновременно в большом, и в мелочах.
Здравствуйте, SV., Вы писали:
SV.>А остальные 99% видят "паскалевскую" нотацию, говорят "шозанах" и закрывают мануал. И остаются в убеждении, что это паскалевская нотация.
Мне кажется, что если человек видя паскалевскую нотацию закрывает "мануал" и говорит "шозанах", то оно и слава богу, так как он все равно дурак. А проку от дураков не много. Ну, а не дурак будет разбираться по существу.
SV.>Если это было больше, чем дипломная работа,
Ты депломной работой называешь немерл? Ну, это говорит исключительно о тебе. Вообще-то немерл — это труд более чем тридцати программистов на протяжении ~ семи лет.
SV.>а именно — попытка популяризовать язык, большим просчетом было отличаться одновременно в большом, и в мелочах.
Какая-то витиеватая мысль. Можно ее пояснить?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
SV.>>А остальные 99% видят "паскалевскую" нотацию, говорят "шозанах" и закрывают мануал. И остаются в убеждении, что это паскалевская нотация.
VD>Мне кажется, что если человек видя паскалевскую нотацию закрывает "мануал" и говорит "шозанах", то оно и слава богу, так как он все равно дурак. А проку от дураков не много. Ну, а не дурак будет разбираться по существу.
SV.>>Если это было больше, чем дипломная работа,
VD>Ты депломной работой называешь немерл? Ну, это говорит исключительно о тебе. Вообще-то немерл — это труд более чем тридцати программистов на протяжении ~ семи лет.
SV.>>а именно — попытка популяризовать язык, большим просчетом было отличаться одновременно в большом, и в мелочах.
VD>Какая-то витиеватая мысль. Можно ее пояснить?
Что тут пояснять? Все части связаны, просто не надо делать попытки нитпикинга.
Если разработка велась с академическими целями, то "оно", может, "и слава богу". Если целью была популярность, то начинать надо было помаленьку. Нововведений более, чем достаточно без смены нотации указания типа.
Здравствуйте, SV., Вы писали:
SV.>Если разработка велась с академическими целями, то "оно", может, "и слава богу". Если целью была популярность, то начинать надо было помаленьку. Нововведений более, чем достаточно без смены нотации указания типа.
Когда начинали писать Немерле средств вроде PEG-а еще не было. Неоднозначности грамматики серьезно усложняли разработку расширяемого языка. Как я понимаю, многие синтаксические решения были приняты в том числе и под давлением желания избавиться от неоднозначность. Описание типов одна из таких возможностей. От туда же растут ноги и квадратных скобок для указания параметров типов и приведения типов. Везде где были неоднозначности были выбраны решения из ML-подобных языков. Там же где это было возможно взяли решения из C#.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
SV.>Удобнее, не удобнее, какая разница? Это не си-подобный синтаксис, и программирующие массы его отвергнут.
Правда думаешь это решает? Программирующие массы пишут на чём им сказали, и не могут выбирать даже версию фреймворка. Тут вон люди которые понимают что за счёт Nemerle могут серьёзно выиграть, сетуют что всё супер, но им в конторе никто не даст на нём писать. Максимум выбивают на Nemerle всякие штуки по-мелочи вроде утилиток для внутреннего использования.
SV.>Если бы Nemerle назывался С## и типы записывались спереди, для него все могло бы сложиться по-другому. А так... боюсь, ПМ, everything is expression и макросы будут введены в обиход каким-нибудь C# 6.
Ну если в C#6 таки осилят что-либо дельное — то это же хорошо, меньше сил придётся потратить тем кто уже на Nemerle на популяризацию полезных вещей. Только вот как-то повелось что команда C# принимает вечно какието полу-решения, и ПМ в их реализации вполне может выродиться до switch/case по константам количеством от 1 до 3 .
