Особенности (или баги?) с receive, send и вопрос про короткий вариант if/else

[ZakarumXiZ]

Я столкнулся с еще несколькими особенностями (а некоторые вполне могут быть багами) в Pr:

1. если написать что-то вроде a[i]:=a[i]+receive(i), то будет выдавать ошибку can only assign with receive, а если записать это во вроде бы эквивалентном виде a[i]+=receive(i), то ошибка не появляется. Т.е., если писать только := или только +=, то ничего такого, а если одновременно := и +, то выдает ошибку, даже если это эквивалентная запись для +=. Возможно, это является защитой от случая, если бы слева или справа было бы, например a[i-1] или a[i+1] (и если заменить так ровно с одной из сторон), но меня смущает, что интерпретатор ругается на другой вид записи +=, или, может быть, именно так и было задумано?

2. И еще - мне кажется, что в описании языка стоит явно указать, что через send можно передавать массивы лишь поэлементно, через циклы, а напрямую - нельзя; или не стоит? Вроде, в описании указано, что можно несколько чисел за один вызов, но в условии явно не написано, что количество передаваемых переменных должно быть равным количеству аргументов минус 1.

3. И я не совсем понимаю, а какая именно короткая версия if/else должна работать, вроде в языке можно только через отступы? Если это про версию, где идет присваивание, и оно идет перед if/else в одной строке (почти как в Python), то у меня это не работает, но, видимо, в документации имелось в виду другое

[GassaFM]

В цепочке вида if <cond1>: ... else: if <cond2>: ... можно использовать сокращённую запись без лишних вложенных отступов: if <cond1>: ... elif <cond2>: ....

Имеется в виду ровно то, что написано: вместо else: отступ if: ещё отступ можно написать elif и один отступ. Версии ифа в одну строчку нет. Если она нужна -- можно написать отдельный feature request.

[GassaFM]

Функция send может посылать одно или несколько целых чисел, их следует разделять запятыми.

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

[GassaFM]

<var> <assignOp> receive (<from>)

Именно так выглядит описание receive в readme, и именно так приходится этой функцией пользоваться.

Почему: правильно вычислить произвольное выражение с receive гораздо сложнее, чем сейчас. Например, в выражении x := receive (0) + receive (1) * receive (0) первое и второе сообщения могут уже быть, а третье ещё нет. То есть нужно сначала проверять, что всё выражение уже вычислимо, а потом только его вычислять. Или вообще перейти от состояний вида "курсор в начале строки" к состояниям вида "курсор в середине дерева разбора выражения".

[GassaFM]

В общем, я считаю, что все три пункта достаточно хорошо описаны, если читать readme внимательно. Но, возможно, readme можно сделать лучше, чтобы понять это всё было проще.

[ZakarumXiZ]

В цепочке вида if <cond1>: ... else: if <cond2>: ... можно использовать сокращённую запись без лишних вложенных отступов: if <cond1>: ... elif <cond2>: ....

Имеется в виду ровно то, что написано: вместо else: отступ if: ещё отступ можно написать elif и один отступ. Версии ифа в одну строчку нет. Если она нужна -- можно написать отдельный feature request.

Наверное, да, стоит написать отдельную короткую версию, как в Python. У меня были ситуации, когда мне приходилось дополнительное присваивание писать перед if/else, чтобы переменная была в подходящей области видимости, не очень удобно.

Например, в этом фрагменте кода потребовалось две лишние строки с присваиванием, чтобы переменные были в подходящей области видимости
start:=0
if id < remainder:
start := id * chunk_size # внутри условия if
else:
start := remainder * (elements_per_proc + 1) + (id - remainder) * elements_per_proc # внутри else
хотя при короткой версии можно было бы записать
start := id * (elements_per_proc + 1) if id < remainder else remainder * (elements_per_proc + 1) + (id - remainder) * elements_per_proc

И получается, что в описании опечатка про использование сокращенной записи if/else, потому что такая запись не работает?
например, в следующем случае выдает ошибку, если писать в одной строке, даже если там дальше ставить else, elif и т.д.
line 10: extra token at end of line: lo
if lo >= n: lo := n

То есть, на самом деле поддерживается только со вложенными отступами версия?

[ZakarumXiZ]

@ZakarumXiZZakarumXiZ edited Apr 5, 2025

<var> <assignOp> receive (<from>)

Именно так выглядит описание receive в readme, и именно так приходится этой функцией пользоваться.

Почему: правильно вычислить произвольное выражение с receive гораздо сложнее, чем сейчас. Например, в выражении x := receive (0) + receive (1) * receive (0) первое и второе сообщения могут уже быть, а третье ещё нет. То есть нужно сначала проверять, что всё выражение уже вычислимо, а потом только его вычислять. Или вообще перейти от состояний вида "курсор в начале строки" к состояниям вида "курсор в середине дерева разбора выражения".

Это да, но вопрос скорее про то, должно ли это распространяться именно на строки вида a[i]:=a[i]+receive(i) и a[i]+=receive(i), считая это двумя различными записями, когда в обычном случае (т.е. если бы вместо receive стояла бы, например, переменная или элемент массива) это было бы практически одним и тем же?[+] (должно ли это быть исключением из правила с единственным присваиванием?)

[ZakarumXiZ]

Функция send может посылать одно или несколько целых чисел, их следует разделять запятыми.

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

Да, наверное можно написать явно об этом, на всякий случай, чтобы было понятно, что прям так не получится написать, и нужно будет пересылать поэлементно массив.
Либо разрешить написать что-то наподобие send(i, global_dp, a_1, a_2, ...), подразумевая примерно следующее:
for k :=0 until n: # n - длина массива global_dp
send(i,global_dp[k]) # внутри цикла по длине массива, пишу на случай, если пробелы не отображаются
send(i,a_1) # вне цикла по длине массива
send(i,a_2)
...
Хотя еще не очень понятно, не слишком ли испортит это язык, или все-таки можно добавить (даже если будет только массив)?

[GassaFM]

Либо разрешить написать что-то наподобие
send(i, global_dp, a_1, a_2, ...),
подразумевая примерно следующее:
for k :=0 until n:
send(i,global_dp[k])

Важное свойство синтаксиса -- каждое действие занимает столько времени, сколько токенов в строке. Если разрешить передавать массивы одной командой, это свойство нарушится. Даже не очень понятно, как тогда мерить время, в какой момент приходит какой элемент массива. В общем, опять модель происходящего придётся менять на более сложную. А то, что она сейчас простая, ценно для учебных целей.

пишу на случай, если пробелы не отображаются

У комментария есть Preview. А ещё можно пять минут почитать хелп по форматированию, и после этого общаться гораздо понятнее =)

[GassaFM]

Наверное, да, стоит написать отдельную короткую версию, как в Python. У меня были ситуации, когда мне приходилось дополнительное присваивание писать перед if/else, чтобы переменная была в подходящей области видимости, не очень удобно.

Запись X if Y else Z -- довольно неочевидная фича Питона. Она переводится на большинство других языков как Y ? X : Z, в другом порядке, что затрудняет понимание. Не уверен, что именно её -- а не обычный в других языках тернарный оператор -- стоит добавлять в учебный язык, даже если что-то добавлять.

В любом случае пока не хочу его добавлять. Потому же, почему нет &&, || и receive + receive: будет сложнее посчитать количество тактов в строке, придётся усложнять модель.

Например, в этом фрагменте кода потребовалось две лишние строки с присваиванием, чтобы переменные были в подходящей области видимости

А вот что можно сделать -- так это явно сказать в readme правила видимости переменных.
Если переменная используется в первый раз, она создаётся в самой вложенной области видимости.

Это работает так же, как фигурные скобки в Си-подобных языках: фигурная скобка закрылась -- переменная исчезла. Нужна переменная вне фигурных скобок -- нужно объявить её раньше (в нашем языке объявлений нет, но можно, например, присвоить 0).

Это работает не так, как в Питоне. Поэтому, видимо, и кажется удивительным. Может быть, явное упоминание в readme тут помогло бы. Хотя такое обычно не воспринимаешь, пока не наткнёшься -- так что, может, и оно бы не помогло.

И получается, что в описании опечатка про использование сокращенной записи if/else, потому что такая запись не работает?

Ещё раз процитирую, что написано в readme.

В цепочке вида if : ... else: if : ... можно использовать сокращённую запись без лишних вложенных отступов: if : ... elif : ....

Сокращённая запись цепочки -- это не запись if..else в одну строку. Что это такое -- объяснено в том же предложении.

[GassaFM]

Это да, но вопрос скорее про то, должно ли это распространяться именно на строки вида a[i]:=a[i]+receive(i) и a[i]+=receive(i), считая это двумя различными записями, когда в обычном случае (т.е. если бы вместо receive стояла бы, например, переменная или элемент массива) это было бы практически одним и тем же? (должно ли это быть исключением из правила с единственным присваиванием?)

На мой взгляд, эта фича не приносит достаточно пользы, чтобы оправдать свою реализацию.
В конкретном приведённом примере команда a[i]:=a[i]+receive(i), казалось бы, вообще строго хуже, чем a[i]+=receive(i): она и длиннее, и дольше, и не DRY.

[ZakarumXiZ]

Это да, но вопрос скорее про то, должно ли это распространяться именно на строки вида a[i]:=a[i]+receive(i) и a[i]+=receive(i), считая это двумя различными записями, когда в обычном случае (т.е. если бы вместо receive стояла бы, например, переменная или элемент массива) это было бы практически одним и тем же? (должно ли это быть исключением из правила с единственным присваиванием?)

На мой взгляд, эта фича не приносит достаточно пользы, чтобы оправдать свою реализацию. В конкретном приведённом примере команда a[i]:=a[i]+receive(i), казалось бы, вообще строго хуже, чем a[i]+=receive(i): она и длиннее, и дольше, и не DRY.

Видимо, да, она не очень полезна, несмотря на то, что кажется верной(

[ZakarumXiZ]

Либо разрешить написать что-то наподобие
send(i, global_dp, a_1, a_2, ...),
подразумевая примерно следующее:
for k :=0 until n:
send(i,global_dp[k])

Важное свойство синтаксиса -- каждое действие занимает столько времени, сколько токенов в строке. Если разрешить передавать массивы одной командой, это свойство нарушится. Даже не очень понятно, как тогда мерить время, в какой момент приходит какой элемент массива. В общем, опять модель происходящего придётся менять на более сложную. А то, что она сейчас простая, ценно для учебных целей.

пишу на случай, если пробелы не отображаются

У комментария есть Preview. А ещё можно пять минут почитать хелп по форматированию, и после этого общаться гораздо понятнее =)

Получается, что в документации стоит указать, что из этого следует, что массивы передаются поэлементно через цикл, поскольку здесь нужно соблюдать свойство синтаксиса, ну или как-то намекнуть на это свойство?

[ZakarumXiZ]

Наверное, да, стоит написать отдельную короткую версию, как в Python. У меня были ситуации, когда мне приходилось дополнительное присваивание писать перед if/else, чтобы переменная была в подходящей области видимости, не очень удобно.

Запись X if Y else Z -- довольно неочевидная фича Питона. Она переводится на большинство других языков как Y ? X : Z, в другом порядке, что затрудняет понимание. Не уверен, что именно её -- а не обычный в других языках тернарный оператор -- стоит добавлять в учебный язык, даже если что-то добавлять.

В любом случае пока не хочу его добавлять. Потому же, почему нет &&, || и receive + receive: будет сложнее посчитать количество тактов в строке, придётся усложнять модель.

Например, в этом фрагменте кода потребовалось две лишние строки с присваиванием, чтобы переменные были в подходящей области видимости

А вот что можно сделать -- так это явно сказать в readme правила видимости переменных. Если переменная используется в первый раз, она создаётся в самой вложенной области видимости.

Это работает так же, как фигурные скобки в Си-подобных языках: фигурная скобка закрылась -- переменная исчезла. Нужна переменная вне фигурных скобок -- нужно объявить её раньше (в нашем языке объявлений нет, но можно, например, присвоить 0).

Это работает не так, как в Питоне. Поэтому, видимо, и кажется удивительным. Может быть, явное упоминание в readme тут помогло бы. Хотя такое обычно не воспринимаешь, пока не наткнёшься -- так что, может, и оно бы не помогло.

И получается, что в описании опечатка про использование сокращенной записи if/else, потому что такая запись не работает?

Ещё раз процитирую, что написано в readme.

В цепочке вида if : ... else: if : ... можно использовать сокращённую запись без лишних вложенных отступов: if : ... elif : ....

Сокращённая запись цепочки -- это не запись if..else в одну строку. Что это такое -- объяснено в том же предложении.

Возможно, можно было бы добавить слово global или добавить просто определение переменной, по умолчанию присваивая ей 0, хотя тут опять же могут быть вопросы с усложнением модели, наверное первый вариант лучше смотрится?

Наверное, да, стоит написать отдельную короткую версию, как в Python. У меня были ситуации, когда мне приходилось дополнительное присваивание писать перед if/else, чтобы переменная была в подходящей области видимости, не очень удобно.

Запись X if Y else Z -- довольно неочевидная фича Питона. Она переводится на большинство других языков как Y ? X : Z, в другом порядке, что затрудняет понимание. Не уверен, что именно её -- а не обычный в других языках тернарный оператор -- стоит добавлять в учебный язык, даже если что-то добавлять.

В любом случае пока не хочу его добавлять. Потому же, почему нет &&, || и receive + receive: будет сложнее посчитать количество тактов в строке, придётся усложнять модель.

Например, в этом фрагменте кода потребовалось две лишние строки с присваиванием, чтобы переменные были в подходящей области видимости

А вот что можно сделать -- так это явно сказать в readme правила видимости переменных. Если переменная используется в первый раз, она создаётся в самой вложенной области видимости.

Это работает так же, как фигурные скобки в Си-подобных языках: фигурная скобка закрылась -- переменная исчезла. Нужна переменная вне фигурных скобок -- нужно объявить её раньше (в нашем языке объявлений нет, но можно, например, присвоить 0).

Это работает не так, как в Питоне. Поэтому, видимо, и кажется удивительным. Может быть, явное упоминание в readme тут помогло бы. Хотя такое обычно не воспринимаешь, пока не наткнёшься -- так что, может, и оно бы не помогло.

И получается, что в описании опечатка про использование сокращенной записи if/else, потому что такая запись не работает?

Ещё раз процитирую, что написано в readme.

В цепочке вида if : ... else: if : ... можно использовать сокращённую запись без лишних вложенных отступов: if : ... elif : ....

Сокращённая запись цепочки -- это не запись if..else в одну строку. Что это такое -- объяснено в том же предложении.

Возможно, да, подошел бы тернарный оператор, если он не сильно тронет модель.

Здесь так и есть, наверное стоит тоже явно указать, что области видимости берутся от C++, а не Python, как большинство других деталей.

Если я правильно понимаю, то имеется в виду, что внутри if следующие elif/else можно писать на одном уровне с внешним if?

[GassaFM]

Если я правильно понимаю, то имеется в виду, что внутри if следующие elif/else можно писать на одном уровне с внешним if?

Имеется в виду, что вместо кода

if cond1:
    work
else:
    if cond2:
        work more

с двумя отступами для work more можно написать

if cond1:
    work
elif cond2:
    work more

с одним отступом для work more.
Если так расписывать, readme сильно разъедется по вертикали в этом месте. Поэтому написано кратко в одну строку.

[GassaFM]

Либо разрешить написать что-то наподобие
send(i, global_dp, a_1, a_2, ...),
подразумевая примерно следующее:
for k :=0 until n:
send(i,global_dp[k])

Важное свойство синтаксиса -- каждое действие занимает столько времени, сколько токенов в строке. Если разрешить передавать массивы одной командой, это свойство нарушится. Даже не очень понятно, как тогда мерить время, в какой момент приходит какой элемент массива. В общем, опять модель происходящего придётся менять на более сложную. А то, что она сейчас простая, ценно для учебных целей.

пишу на случай, если пробелы не отображаются

У комментария есть Preview. А ещё можно пять минут почитать хелп по форматированию, и после этого общаться гораздо понятнее =)

Получается, что в документации стоит указать, что из этого следует, что массивы передаются поэлементно через цикл, поскольку здесь нужно соблюдать свойство синтаксиса, ну или как-то намекнуть на это свойство?