Выражение и инструкции

Приглашаются cvs-255, tailgunner, mashina, loz, at, unC0Rr, www_linux_org_ru.

Ты это statement «инструкцией» обозвал?!?

Неожиданный поворот спора=)

О терминах спорить не очень хочется, честно говоря. Да, имелся в виду statement(и expression для выражения, соответственно).

Срач «algol vs. Fortran» глуп и бесперспективен.

Инструкции вносят сложность и неоднозначность и должны быть сведены к минимуму.

В императивных языках — да, имеет смысл сделать специальный синтаксис для упорядоченной последовательности вычислений.

В декларативных логичнее использовать подход с выражениями.

/thread

зачем в императивных-то? Императивные скала, руби, раст вполне живут с выражениями и никто не жалуется

Но все-равно должны присутствовать?

имеет смысл сделать специальный синтаксис для упорядоченной последовательности вычислений.

Что мешает указать, что последовательность выражений в блоке выражений выполняется в порядке следования?

Императивные скала, руби, раст вполне живут с выражениями и никто не жалуется

а если в Скале — написать выражение и затем поставить точку-с-запятой — то в результате мы получаем инструкцию..

так ведь?

мне кажется, что это лишь следствие более общего(и интересного) вопроса: «разделять ли при проектировании ЯП понятия выражение и инструкция или же считать все выражением?».

Именно так. Возможность не ставить return - это одно из следствий выбора второго варианта.

Инструкции не нужны, как и return.

не нужны[...] return.

но если убрать из языка ``return`` — то как же тогда заставить программиста библиотеки — не забывать каждый раз писать слово ``nil`` перед концом функции? :-)

[в случаях когда функция обозначает действие, а не запрос информации]

``nil`` перед концом функции?

Никак не забывать. «Перед концом» «функции» и так будет выражение которое «возвращает» ``nil``.

но ведь тогда если был бы такой язык программирования — то тогда был бы огромный риск возникновения следующей ситуации:

(пишу фрагмент кода на импровизированном гипотетическом языке)

допустим есть некоторая функция в библиотеке:

require 'low_level_some'

def do_super_some(v)
    if v => 1000
        do_big_some(v)
    else
        do_small_some(v)
    end
end

как видим — программист библиотеки здесь забыл указать ``nil`` перед концом функции ``do_super_some()``

но допустим — это не страшно, так как ``do_big_some()`` всегда возвращает ``nil``, и ``do_small_some()`` тоже всегда возвращает ``nil``.

а теперь представим что неожиданно ``do_big_some()`` начинает возвращать в случае успеха что-то другое [допустим это случается после — после pacman -Syu # :)]

....и в результате — функция ``do_super_some()`` начинает возвращать непонятную почти-безсистемную ерунду..

а другой программист — позже может подумать что ``do_super_some()`` возвращает не безсистемную ерунду, а вполне определённое «успех если != nil».. и вот он баг на ровном месте!

:-( :-(

как видим — программист библиотеки здесь забыл указать ``nil`` перед концом функции ``do_super_some()``

Oh no, not this shit again.

и вот он баг на ровном месте!

И где же тут баг? Вывод типов тебе в помощь. А при динамической типизации на это вообще насрать.

И где же тут баг? Вывод типов тебе в помощь.

да. вывод типов — спас бы.

а теперь представим что неожиданно ``do_big_some()`` начинает возвращать в случае успеха что-то другое [допустим это случается после — после pacman -Syu # :)]

nil — всего лишь константа, такая же как и ноль (<type 'int'>). Можно подставить ноль на место nil, или лучше строку «pony.org.ru», чтобы увидеть что return тут не причем.

Я когда на перле писал, тыщу раз вместо планируемого андефа ловил последнее вычисление в редкой елсе-ветке. Теперь привычка всегда писать ретурны.

Что мешает указать, что последовательность выражений в блоке выражений выполняется в порядке следования?

Ничего. Это и есть тот самый специальный синтаксис.

Мифические примеры из головы такие мифические. Попиши на Руби что ле.

если был бы такой язык программирования

Он уже есть и не один.

как видим — программист библиотеки здесь забыл указать ``nil`` перед концом функции ``do_super_some()``

Ничего он не забыл. Результатом функции будет результат if'а, результатом которого в данном случае будет или do_big_some(v) или do_small_some(v). Если у if-elif'а нет ветки else, то логично считать результатом if'а в случае несоответствия всем ветвям некоторый None в динамических языках, а в языках со статической типизацией или считать весь такой if Unit'ом или же Option<тип результата ветвей>.

ретурны не нужны

-module(factorial).
-export([factorial/1]).

factorial(X) when X > 0 ->
  factorial(X, 1, 1).

factorial(X, X, A) ->
  A*X;

factorial(X, N, A) ->
  factorial(X, N+1, A*N).

/thread

Присоединяюсь

+/.*

начинает возвращать непонятную почти-безсистемную ерунду

Она начнет ее возвращать, только если программист идиот и под строчками его когда нет никакой человеко-понятной проблемной области.

Ключевое слово return, вне всяких сомнений нужно, так как оно приятно звучит на слух, несёт глубокий философский смысл (см. вечное возвращение) и вообще украшает код. Я уже не говорю о мелочах типа удобочитаемости кода и предотвращения ошибок. В связи с этим также отмечу чудовищную тенденцию по обрезанию слов (пусть и английских) в текстах программ. Так например на смену function приходят func (Go), fun (Kotlin) и даже fn (Rust). Объясните мне, зачем в современном мире нужна такая экономия на буквах? Ах да, чуть не забыл: явное разграничение function и procedure в Pascal'е было офигенным. есть ли ещё где-нибудь такой подход?

fun (Kotlin) и даже fn (Rust). Объясните мне, зачем в современном мире нужна такая экономия на буквах?

Нагло своровали из ML.

есть ли ещё где-нибудь такой подход

Вижуалбейсик же.

А на буквах экономят чтобы писать быстрее и психологический эффект от использования конструкции был иной.

вне всяких сомнений нужно, так как оно приятно звучит на слух, несёт глубокий философский смысл (см. вечное возвращение) и вообще украшает код.

Это аргумент, на ваш взгляд?

Я уже не говорю о мелочах типа удобочитаемости кода и предотвращения ошибок

Хороший код без ретурна читается лучше. Плохой с ретурном выглядит более приемлемо, согласен.

Объясните мне, зачем в современном мире нужна такая экономия на буквах?

Лучше читается.

Ах да, чуть не забыл: явное разграничение function и procedure в Pascal'е было офигенным.

Бессмысленным скорее. Чем вам не по душе тип Unit или его аналог?

Неважно<thread />

Чем вам не по душе тип Unit или его аналог?

Тем, что значения этого типа не принимаются и не возвращаются, это искусственный костыль.

Чем вам не по душе тип Unit или его аналог?

Тем, что значения этого типа не принимаются и не возвращаются, это искусственный костыль.

Тебе, небось, еще не по душе ноль в арифметике и пустое множество в математике?

Тем, что значения этого типа не принимаются и не возвращаются, это искусственный костыль.

Принимай и возвращай, кто мешает?

Ноль - это число, а не отсутствие числа. Когда пишут void a(void) - возвращаемое значение отсутствует, а не равно некоему нулю.

Принимаются и возвращаются.

В сишечке есть инструкции, поэтому там можно и так. А мы тут вроде о языках, где все выражение. Там Unit является полноправным типом.

есть ли ещё где-нибудь такой подход?

В Ada есть, причём функции могут иметь только входные, но не выходные аргументы, в отличие от процедур.

Тебе, небось, еще не по душе ноль в арифметике и пустое множество в математике?

Ноль - это число, а не отсутствие числа.

Насчет пустого множества возражений нет? Я так и думал.

Когда пишут void a(void) - возвращаемое значение отсутствует, а не равно некоему нулю.

void - это тип, у которого нет значений (ровно 0 штук).

Algol совершенно императивный, если что.

Попиши на Руби что ле.

а как на нём пописать-то, если там библиотек кот наплакал? (кроме web.. для web — там много всего, кажется)

Так много звёзд, а такой тупой, а.

Нет ни одного вменяемого аргумента за инструкции. Не зря и в новых языках почти всегда только выражения.

А зачем? Ведь это бессмысленно? Ради чего заводить полноценный отдельный тип? Ради экономии нескольких символов?

Инструкции вносят сложность

В чем? Наоборот, для разных понятий(вычислимое выражение и выполнение действий) используются разные подходы. Это упрощает понимание.

и неоднозначность

Где же там неоднозначность?

Инструкции не нужны, как и return.

Инструкции - это команды для выполнения. Как они могут быть не нужны абстрактному исполнителю? Выражение же нужны для вычислений чего-либо во что-либо. Какой смысл смешивать эти понятия в одно?

Напиши что-нибудь посложнее факториала.

Да хрен с ним. Но вот зачем плодить сущности без необходимости?

например?

зачем плодить сущности без необходимости?

Кстати да, зачем? Выражения в языке должны быть, функции тоже. Зачем нужны доказанно ненужные сущности вроде операторов (ты ведь операторы называешь «инструкциями», да?) и процедур?