Я так понимаю, что в данных нотациях в expression я не могу использовать инструменты императивного языка позволяющие управлять потоком исполнения (flow control), а именно if, for. А в statement могу. Но это ограничение легко обойти. Я могу в expression вызвать метод, в котором уже if и for будут.
В связи с этим возникает вопрос насколько справедливо что if в Haskell равносильно тернарному оператору в императивных языках.
Возможно expression в императивных языках не эквивалентно expression в функциональных.
Если не эквивалентно, я тогда не понимаю разницы между expression и statement.
30.05.13 05:42: Перенесено модератором из 'Декларативное программирование' — VladD2
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания http://rsdn.ru/Info/rules.xml
Здравствуйте, igor-booch, Вы писали:
IB>Тут в дотнетах развернулась жаркая дискуссия про функционалльной програмирование IB>http://rsdn.ru/forum/dotnet/5179867.1
Здравствуйте, igor-booch, Вы писали:
IB>Если не эквивалентно, я тогда не понимаю разницы между expression и statement.
А что непонятного ?
Формула проста:
statement = expression возвращающий void.
В языках типа C# невозможно создать переменную из statement.
Вот и получается:
var a = true ? 1 : 2; // OKvar a = if(true) 1 else 2; // Error, if-else "возвращают" void.void a = ... // Такое вообще нельзя
В функциональных языках и в гибридных языках понятие statement как отдельный элемент просто отсутствует.
В таких языка как правило отсутствует явное ключевое слово 'return' в понимании C (в Хаскелле это означает совсем другое если что),
И всегда последнее выражение используется как результат.
Это не отменяет возможность эмуляции 'return' стиля C.
Возьмем нефункциональный Ruby в котором, однако, все является выражением:
if true then 2 else 3 end; # Результат игнорируем
a = if true then 2 else 3 end; # Результат используем
S>Жарите там в основном вы
Вы хотите сказать что я Вас жарю?
Не я не садист.
Я стремлюсь к совершенству, а Вы мне помогаете в этом
И сами чему-то учитесь (возможно).
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания http://rsdn.ru/Info/rules.xml
Здравствуйте, igor-booch, Вы писали:
IB>>>Тут в дотнетах развернулась жаркая дискуссия про функционалльной програмирование IB>>>http://rsdn.ru/forum/dotnet/5179867.1
S>>Жарите там в основном вы IB>Вы хотите сказать что я Вас жарю?
Нет, что вы Жарите в смысле "поддаете жару".
IB>Не я не садист. IB>Я стремлюсь к совершенству, а Вы мне помогаете в этом IB>И сами чему-то учитесь (возможно).
Не исключено
Здравствуйте, _NN_, Вы писали:
IB>>Если не эквивалентно, я тогда не понимаю разницы между expression и statement.
_NN>А что непонятного ? _NN>Формула проста: _NN>statement = expression возвращающий void.
Грубое и, в общем случае, неверное утверждение.
statement — это утверждение. Например, определение переменной — это тоже statement.
Стейтменты, управляющие потоком (ветвления, циклы, переходы) проблематично рассматривать как выражения.
Кстати говоря, void-выражения можно утилизировать в операторе последовательности ",". Попробуйте туда мысленно подставить goto — и станет ясно, что не всякий стейтмент есть выражение.
_NN>В языках типа C# невозможно создать переменную из statement. _NN>Вот и получается:
_NN>
_NN>var a = true ? 1 : 2; // OK
_NN>var a = if(true) 1 else 2; // Error, if-else "возвращают" void.
_NN>void a = ... // Такое вообще нельзя
_NN>
В С++ (стандарт 2003 и далее) можно делать return f() где void f().
В питоне тип None (аналог void) — обычное значение.
Так что это вопрос синтаксиса, в большей степени, нежели вопрос семантики.
_NN>Возьмем нефункциональный Ruby в котором, однако, все является выражением:
В руби и питоне "всё есть выражение" — это способ упрощения модели языка.
Там даже объявление класса — это не статическая конструкция, а интерпретируемая последовательность.
Здравствуйте, Кодт, Вы писали:
К>Стейтменты, управляющие потоком (ветвления, циклы, переходы) проблематично рассматривать как выражения.
Строго говоря, как выражения проблематично использовать только циклы и операторы перехода. Потому что идея о том, что значением цикла является значение последнего прохода несколько контринтуитивна, IMHO.
Здравствуйте, Pzz, Вы писали:
Pzz>Строго говоря, как выражения проблематично использовать только циклы и операторы перехода. Потому что идея о том, что значением цикла является значение последнего прохода несколько контринтуитивна, IMHO.
Она "несколько" контр-интуитивна постольку, поскольку у цикла может оказаться ноль проходов — и непонятно, что возвращать в этом случае.
Либо обёртывать в какой-то моноид с пустым элементом (например, nullable значение или список всех итераций);
либо вводить в синтаксис цикла ветку "иначе", как это сделано в питоне (там, правда, она отрабатывает всегда);
либо сделать теневой моноид: бросок исключения в качестве пустого элемента (и опять же, так сделано в питоне).
Если же мы рассмотрим цикл как некую свёртку, то ноль проходов — это ноль применений к исходному значению: вернём его; любое ненулевое количество проходов — вернём результат последнего прохода.
Но как это красиво в синтаксис оформить...
Скажем, так
x = 1234 and_for range(k) { |i| i*100 } # при k<1, x=1234; иначе, x=(k-1)*100
Здравствуйте, Кодт, Вы писали:
_NN>>statement = expression возвращающий void.
К>Грубое и, в общем случае, неверное утверждение.
В большинстве случаев оно подходит.
Если statement возвращает void, то все просто и логично.
Просто языки не умеют или не хотят оперировать с 'void' типами.
К>statement — это утверждение. Например, определение переменной — это тоже statement.
Почему в этом случае нельзя рассматривать как выражение с результатом void ?
Скажем, в Nemerle как раз так и есть:
def a = def b = 1;
// b = 1
// a = ()
Возможно где-то в ML семействе есть такая фишка тоже.
К>Стейтменты, управляющие потоком (ветвления, циклы, переходы) проблематично рассматривать как выражения.
В Nemerle аналогично определению переменной.
def a = foreach(x in []) {};
// a = ()
К>Кстати, в питоне 2.x — print является не выражением, а стейтментом.
Это не противоречит утверждению.
print возвращает void, а Python просто не умеет с ним работать.
К>Написать x = (print "foo") нельзя.
Также как и
Здравствуйте, Кодт, Вы писали:
К>Она "несколько" контр-интуитивна постольку, поскольку у цикла может оказаться ноль проходов — и непонятно, что возвращать в этом случае.
Согласен.
К>Но как это красиво в синтаксис оформить... К>Скажем, так К>
Здравствуйте, Кодт, Вы писали:
К>Она "несколько" контр-интуитивна постольку, поскольку у цикла может оказаться ноль проходов — и непонятно, что возвращать в этом случае. К>Либо обёртывать в какой-то моноид с пустым элементом (например, nullable значение или список всех итераций); К>либо вводить в синтаксис цикла ветку "иначе", как это сделано в питоне (там, правда, она отрабатывает всегда); К>либо сделать теневой моноид: бросок исключения в качестве пустого элемента (и опять же, так сделано в питоне).
К>Если же мы рассмотрим цикл как некую свёртку, то ноль проходов — это ноль применений к исходному значению: вернём его; любое ненулевое количество проходов — вернём результат последнего прохода. К>Но как это красиво в синтаксис оформить... К>Скажем, так К>
Здравствуйте, igor-booch, Вы писали:
IB>Я так понимаю, что в данных нотациях в expression я не могу использовать инструменты императивного языка позволяющие управлять потоком исполнения (flow control), а именно if, for.
Вместо if ты можешь использовать все тот же тернарный оператор, а for/foreach по своей сути — мутабельная конструкция, и заталкивать ее в выражение — крайне фиговая идея. Вместо for в функциональном стиле используют linq выражения.
IB>В связи с этим возникает вопрос насколько справедливо что if в Haskell равносильно тернарному оператору в императивных языках.
Справедливо.
... << RSDN@Home 1.2.0 alpha 5 rev. 99 on Windows 8 6.2.9200.0>>
Здравствуйте, Кодт, Вы писали:
К>Она "несколько" контр-интуитивна постольку, поскольку у цикла может оказаться ноль проходов — и непонятно, что возвращать в этом случае.
Это если считать что цикл возвращает скалярное выражение. А если он возвращает итератор, то все становится предельно логично.
К>Если же мы рассмотрим цикл как некую свёртку
Не, это слишком узкая семантика для цикла.
... << RSDN@Home 1.2.0 alpha 5 rev. 99 on Windows 8 6.2.9200.0>>
AVK>Вместо for в функциональном стиле используют linq выражения.
Жалко только что http://stackoverflow.com/questions/4814242/linq-recursion-function
IB>>В связи с этим возникает вопрос насколько справедливо что if в Haskell равносильно тернарному оператору в императивных языках. AVK>Справедливо.
Если императивным языком считать C#, то
я для себя на этот вопрос ответил так:
если не считать, что в first_expression и second_expression в тернарном операторе можно вызвать императивный метод (грязную функцию), то да
если не считать, что в first_expression и second_expression в тернарном операторе не обладают всеми возможностями функциональных языков (напр. carring, lazy evaluation)
то справедливо
Возможно в других языках expressions более приближены к возможностям (и ограничениям) функциональных языков.
Но концептуально expressions во всех языках означают означают одно.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания http://rsdn.ru/Info/rules.xml
Здравствуйте, igor-booch, Вы писали: IB>— Без них компилятор (точнее парсер, не важно кого компилятора или интерпретатора) не построить
То есть? Почему?
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Ну да, есть отдельные моменты, C# все таки не чисто функциональный язык.
IB>если не считать, что в first_expression и second_expression в тернарном операторе можно вызвать императивный метод (грязную функцию), то да
Ну это в любом случае считать не надо, иначе сравнивать шарп с хаскелом просто бессмысленно.
IB>Зачем вообще expressions в императивных языках, если они такие "неполноценные" в свете функциональных языков?
CAB>Здравствуйте, igor-booch, Вы писали: IB>>— Без них компилятор (точнее парсер, не важно кого компилятора или интерпретатора) не построить CAB>То есть? Почему?
А вы представьте парсинг statement'а (императивного) if :
if (expression)
statement1
[else
statement2]
Если попустить, что в expression может быть другой if,
То есть это будет уже не expression, а statement,
то вплывут фундаментальные проблемы.
Не спрашивайте только какие именно, это все на уровне интуиции.
Если сам пойму сам напишу.
Единственно, то могу пока уточнить, опять же на уровне интуиции:
парсинг в принципе возможен,
невозможен парсинг в структуру данных, которую можно преобразовать в последовательности инструкций процессора.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания http://rsdn.ru/Info/rules.xml
IB>>>— Без них компилятор (точнее парсер, не важно кого компилятора или интерпретатора) не построить CAB>>То есть? Почему? IB>А вы представьте парсинг statement'а (императивного) if : IB>
IB>Если попустить, что в expression может быть другой if,
Если в вашем ЯП if это statement(т.е. не возвращает какого-то значения), то он не может быть там где требуется expression, это ошибка.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
По моему мы друг-друга не поняли.
IB>>— Без них (expression'ов) компилятор (точнее парсер, не важно кого компилятора или интерпретатора) не построить CAB>То есть? Почему?
Я подумал, что Вы своим вопросом (Почему?) хотели сказать, что без expression'ов ЯП возможен.
Судя по Вашему предыдущему ответу вопрос "Почему?" касался чего-то другого.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания http://rsdn.ru/Info/rules.xml
IB>Я подумал, что Вы своим вопросом (Почему?) хотели сказать, что без expression'ов ЯП возможен.
Ассемблер?
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Жарите в смысле "поддаете жару".
Перекуём баги на фичи!
