Julia: Запрос функции: добавить оператор, чтобы разрешить разрыв строк в определении матрицы

A = [1 2 3 4 5  #=
  =# 6 7 8 9 10]

также работает и не требует выделения дополнительного временного массива [5] . Многострочные комментарии (# 69) FTW!

(Хотя, честно говоря, я не вижу проблемы с наличием 150 чисел с плавающей запятой в одной строке. Разве в наши дни редакторы не имеют горизонтальных полос прокрутки? Если у вас есть матрица 150 × 150 в вашем коде, это просто стена из 22500 чисел в любом случае, и прокрутка кажется таким же хорошим способом взглянуть на это в вашем коде. Вы также можете включить мягкую упаковку в своем редакторе, если вам нравятся короткие строки.)

Я не знаю, используются ли где-то две точки .. , но я думаю, что это очень подходит для продолжения строки, или \dots ( … ), -- и т. Д. Здесь можно найти сравнение разных языков .

Привет @stevengj!

Я до сих пор использую для переноса моего кода в столбец 80. ИМХО, код становится намного более читаемым и с ним легче работать, потому что вы можете разделить свой редактор на две части и по-прежнему видеть весь код без прокрутки.

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

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

(Для большей части языка Julia вы можете вставлять разрывы строк без взлома, например, после любого парного знака, запятой или двоичного оператора. Литеральные матрицы - редкое исключение.)

Две точки (..) и многоточие (…) уже анализируются как бинарные операторы, и в целом операторы гораздо более полезны, чем синтаксис продолжения, который возникает редко (и уже возможен с # = = #).

Привет @stevengj

Я использую vim (на самом деле neovim), я могу делать мягкую упаковку, но обычно это ломает такие вещи, как несколько строчных курсоров и макросы. Вот почему я всегда предпочитаю фактически разрывать линии.

Однако не стесняйтесь закрыть эту проблему, если считаете, что такая функция не работает с языковым дизайном Julia.

Я думаю, что нам действительно нужно нечто более общее: способ продолжить любую строку, не относящуюся к синтаксису матрицы. Лучшее, что я смог придумать, - это \ в качестве последнего непробельного символа в строке, что было бы критическим изменением, поскольку в настоящее время это действительный, но странный синтаксис:

x = y \
    z

Мы могли бы даже продолжать поддерживать такое использование \ в контекстах, не чувствительных к пробелам, поскольку y z является недопустимым синтаксисом, но, вероятно, это слишком умно. Я не уверен, что это того стоит, но в большинстве языков есть способ продолжить строки. Трюк с многострочным комментарием тоже работает, но он немного подробен.

Очень ломается ...

julia> 2\
       10
5.0

julia> 2#=
       =#10
20

Это определенно ломается, но я был бы удивлен, если \ будет так часто использоваться.

Может быть, #\ ? Конечно, связывание нового поведения с ранее проигнорированным комментарием также является нарушением, но использование #\ в качестве комментария, вероятно, даже реже, чем разрыв строки после \ (используется как оператор).

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

Привет @stevengj!

Я не уверен, почему людям следует отговаривать использовать разрывы строк. См., Например, этот код:

            xndot = d2201 * sin(2ω + xli  - G22) +
                    d2211 * sin(   + xli  - G22) +
                    d3210 * sin(+ω + xli  - G32) -
                    d3222 * sin(-ω + xli  - G32) -
                    d5220 * sin(+ω + xli  - G52) +
                    d5232 * sin(-ω + xli  - G52) +
                    d4410 * sin(2ω + 2xli - G44) -
                    d4422 * sin(     2xli - G44) +
                    d5421 * sin(+ω + 2xli - G54) +
                    d5433 * sin(-ω + 2xli - G54)

ИМХО, знак операции в конце не так хорош, как в начале:

            xndot = + d2201 * sin(2ω + xli  - G22) \
                    + d2211 * sin(   + xli  - G22) \
                    + d3210 * sin(+ω + xli  - G32) \
                    - d3222 * sin(-ω + xli  - G32) \
                    - d5220 * sin(+ω + xli  - G52) \
                    + d5232 * sin(-ω + xli  - G52) \
                    + d4410 * sin(2ω + 2xli - G44) \
                    - d4422 * sin(     2xli - G44) \
                    + d5421 * sin(+ω + 2xli - G54) \
                    + d5433 * sin(-ω + 2xli - G54)

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

Кажется, в этом случае проще просто поставить дополнительную пару заключающих скобок.

Да, это может быть сделано. Но, опять же ИМХО, это не обычное дело. Допустим, кто-то видит это:

            xndot = (+ d2201 * sin(2ω + xli  - G22)
                     + d2211 * sin(   + xli  - G22)
                     + d3210 * sin(+ω + xli  - G32)
                     - d3222 * sin(-ω + xli  - G32)
                     - d5220 * sin(+ω + xli  - G52)
                     + d5232 * sin(-ω + xli  - G52)
                     + d4410 * sin(2ω + 2xli - G44)
                     - d4422 * sin(     2xli - G44)
                     + d5421 * sin(+ω + 2xli - G54) 
                     + d5433 * sin(-ω + 2xli - G54))

С математической точки зрения эти скобки не имеют значения. Кто-то может случайно удалить их, Юля не будет показывать никаких предупреждений, и код будет совершенно неправильным.

Лучшее, что я смог придумать, - это \ в качестве последнего непробельного символа в строке, что было бы критическим изменением, поскольку в настоящее время это действительный, но странный синтаксис

Как насчет использования # для той же цели? Интерпретация состоит в том, что вы комментируете разрыв строки. (спасибо @oxinabox за эту интерпретацию использования LaTeX % качестве продолжения комментария / строки)

Что ж, с моей точки зрения, # в конце строки без каких-либо следующих за ним символов должно быть очень приятным и, кажется, ломает меньше вещей.

Единственная потенциальная проблема, которую я здесь вижу, заключается в том, что от

a=1 #because reasons
 +2

к

a=1 #
 +2

дает разные результаты. Хотя это, вероятно, не имеет значения.

А что насчет того, что Джулия не использует, например \\ ? Это слишком некрасиво?

Я ожидал, что использование стиля латекса «Комментируя новый лайк» сломает вещи.

Если только он не был ограничен только # без каких-либо непробелов после.
Например:

colors = [ 0.5 0.2 0.1 0.9 # Red
                0.4 0.4 0.1 0.6 # Green
                0.1 0.2 0.1 0.1] # Blue

В LaTeX нет никаких новых строк.
И то, что пустой комментарий действует иначе, чем непустой, звучит странно.

На самом деле я не предлагал это Джулии.
Я думаю, что \\ будет гораздо менее запутанным.
Но я думаю, что решение

Хотя создание гигантских многострочных литералов кажется довольно нишевой.
Даже больше, чем наличие литералов для Array{T, 3} .

Их можно построить так же эффективно, используя команды vect и cat которые в любом случае опускаются до буквального значения.

Я думаю, что предложение заключалось в том, чтобы за # следовало только символ новой строки (или, возможно, только пробелы).

Да, я имел в виду выполнение предложения @StefanKarpinski о специальной обработке # в конце строки, определенно не считая случая, когда после # есть другие непробельные вещи. Возможно, сравнение LaTeX больше сбивало с толку, чем проясняло то, что я пытался сказать.

Кооптация # кажется мне рискованной. Иногда в моем коде разбросаны # s по причинам, которые я не совсем помню, комментарии, о которых я вроде как передумал, и т. Д. Было бы очень легко случайно удалить завершающий # s при уборке.

Иногда я пропускаю оператор продолжения строки, но предпочел бы, чтобы он был очень очевидным, например \ или ... . #= или [] кажутся слишком похожими на трюк.

(Если не рекомендуется использовать, может быть, что-нибудь немного уродливое, например \\\ , подойдет?)

Для меня также вполне нормально помещать комментарии после оператора продолжения строки, поэтому мне не хотелось бы полагаться на то, что он является последним непробельным символом в строке.

Не уверен, что они уже используются где-то еще или должны быть зарезервированы для пользовательских операторов, но одна из этих стрелок Unicode может сделать привлекательные, интуитивно понятные варианты для явного продолжения строки:

↩ , ⬎ или ⤸

(становится доступным, например, с помощью значимого псевдонима, заполненного табуляцией, например \continueline )

Я думаю, что это удачно, что #= =# работает для этого, и мы должны оставить все как есть.

Я не согласен с тем, что ставить обратную косую черту в конце каждой строки лучше, чем добавлять круглые скобки или просто помещать операторы в конец строки. Я также не думаю, что злоупотребление обратной косой чертой или # будет улучшением; это только добавило бы сюрпризов. Если бы мы использовали что-то многосимвольное, это не было бы большим улучшением по сравнению с #= =# .

Я не согласен с тем, что ставить обратную косую черту в конце каждой строки лучше, чем добавлять круглые скобки или просто помещать операторы в конец строки.

Причина, по которой эта проблема была открыта, заключалась в том, что ни один из них не работает с матричными литералами. Тем не менее, я согласен с тем, что нам, вероятно, не следует ничего делать для этого, поскольку #= =# уже работает.

Теперь, когда я увидел, что вы можете использовать #= =# для продолжения строки, это имеет смысл. Однако, если честно, я бы точно не пришел к такому выводу в одиночку.

Возможно, лучший способ продвинуться вперед - добавить что-нибудь в документацию и руководство по стилю Julia, в котором говорится, что продолжение строки может быть достигнуто с помощью #= =# .

В завершение обсуждения, @JeffBezanson и @StefanKarpinski , считаете ли вы, что даже предложение, предложенное @thchr , которое ничего не сломает, не годится для реализации? Думаю, будет приятно что-то вроде:

A = [1 2 3 4 5 ⤸
     6 7 8 9 10]

Менее подробный, чем #= =# и визуально приятный.

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

Однако мы уже разбираем многие стрелки Unicode как бинарные операторы.

Я подозреваю, что мы могли бы сэкономить.

Хорошие варианты ИМХО:

⤸ (2938) ↩ (8617) ↵ (8629) 

Возможно, пора сделать пробел оператором, и мы можем перегрузить его в контекстах с большой матрицей с помощью Cassette. К счастью, Бьярн Страуструп уже проделал для нас тяжелую дизайнерскую работу - http://www.stroustrup.com/whitespace98.pdf

Если бы мы использовали что-то многосимвольное, это не было бы большим улучшением по сравнению с #= =# .

Я хотел бы выдвинуть против этого три аргумента.

Во-первых, это можно принять за комментарий. Даже если я это знаю, мой мозг регистрирует «Комментарий».

Во-вторых, вы должны поместить его на две строки, а не только на одну. (Как это будет взаимодействовать с отступом?)

В-третьих, это более сложная комбинация нажатий клавиш (на моем компьютере это shift-3 shift-0 enter shift-0 shift-3 ). Я предполагаю, что можно использовать какое-то сочетание клавиш. Напротив, \\ - это два быстрых нажатия одной и той же клавиши (за которыми следует enter .)

Три с половиной: ИМХО это выглядит немного неуклюже и похоже на трюк.

Даже если \\ не принимается, потому что он, возможно, «зарезервирован» для использования в будущем, я действительно думаю, что предложение очень хорошо. Посмотрите, как это будет:

            xndot = + d2201 * sin(2ω + xli  - G22) ⤸
                    + d2211 * sin(   + xli  - G22) ⤸
                    + d3210 * sin(+ω + xli  - G32) ⤸
                    - d3222 * sin(-ω + xli  - G32) ⤸
                    - d5220 * sin(+ω + xli  - G52) ⤸
                    + d5232 * sin(-ω + xli  - G52) ⤸
                    + d4410 * sin(2ω + 2xli - G44) ⤸
                    - d4422 * sin(     2xli - G44) ⤸
                    + d5421 * sin(+ω + 2xli - G54) ⤸
                    + d5433 * sin(-ω + 2xli - G54)

И, кроме того, этим никого не заставят и он ничего не сломает. Но я уверен, что для этого найдутся хорошие варианты использования (большие матрицы, которые заставили меня открыть эту проблему, - это одна из них):

pd = [
     1.09979E+00 -4.88060E-02 -1.97501E-01 -9.10280E-02 -6.96558E-03 ⤸ 
     2.42136E-02  3.91333E-01 -7.20068E-03 -3.22718E-02  1.41508E+00 ⤸
     1.68194E-01  1.85282E-02  1.09384E-01 -7.24282E+00  0.00000E+00 ⤸
     2.96377E-01 -4.97210E-02  1.04114E+02 -8.61108E-02 -7.29177E-04 ⤸
     1.48998E-06  1.08629E-03  0.00000E+00  0.00000E+00  8.31090E-02 ⤸
     1.12818E-01 -5.75005E-02 -1.29919E-02 -1.78849E-02 -2.86343E-06 ⤸
     0.00000E+00 -1.51187E+02 -6.65902E-03  0.00000E+00 -2.02069E-03 ⤸
     0.00000E+00  0.00000E+00  4.32264E-02 -2.80444E+01 -3.26789E-03 ⤸
     2.47461E-03  0.00000E+00  0.00000E+00  9.82100E-02  1.22714E-01 ⤸
    -3.96450E-02  0.00000E+00 -2.76489E-03  0.00000E+00  1.87723E-03 ⤸
    -8.09813E-03  4.34428E-05 -7.70932E-03  0.00000E+00 -2.28894E-03 ⤸
    -5.69070E-03 -5.22193E-03  6.00692E-03 -7.80434E+03 -3.48336E-03 ⤸
    -6.38362E-03 -1.82190E-03  0.00000E+00 -7.58976E+01 -2.17875E-02 ⤸
    -1.72524E-02 -9.06287E-03  0.00000E+00  2.44725E-02  8.66040E-02 ⤸
     1.05712E-01  3.02543E+04  0.00000E+00  0.00000E+00  0.00000E+00 ⤸
    -6.01364E+03 -5.64668E-03 -2.54157E-03  0.00000E+00  3.15611E+02 ⤸
    -5.69158E-03  0.00000E+00  0.00000E+00 -4.47216E-03 -4.49523E-03 ⤸
     4.64428E-03  0.00000E+00  0.00000E+00  0.00000E+00  0.00000E+00 ⤸
     4.51236E-02  2.46520E-02  6.17794E-03  0.00000E+00  0.00000E+00 ⤸
    -3.62944E-01 -4.80022E-02 -7.57230E+01 -1.99656E-03  0.00000E+00 ⤸
    -5.18780E-03 -1.73990E-02 -9.03485E-03  7.48465E-03  1.53267E-02 ⤸
     1.06296E-02  1.18655E-02  2.55569E-03  1.69020E-03  3.51936E-02 ⤸
    -1.81242E-02  0.00000E+00 -1.00529E-01 -5.10574E-03  0.00000E+00 ⤸
     2.10228E-03  0.00000E+00  0.00000E+00 -1.73255E+02  5.07833E-01 ⤸
    -2.41408E-01  8.75414E-03  2.77527E-03 -8.90353E-05 -5.25148E+00 ⤸
    -5.83899E-03 -2.09122E-02 -9.63530E-03  9.77164E-03  4.07051E-03 ⤸
     2.53555E-04 -5.52875E+00 -3.55993E-01 -2.49231E-03  0.00000E+00 ⤸
     0.00000E+00  2.86026E+01  0.00000E+00  3.42722E-04  0.00000E+00 ⤸
     0.00000E+00  0.00000E+00  0.00000E+00  0.00000E+00  0.00000E+00 ⤸
     0.00000E+00  0.00000E+00  0.00000E+00  0.00000E+00  0.00000E+00;
     1.02315E+00 -1.59710E-01 -1.06630E-01 -1.77074E-02 -4.42726E-03 ⤸
     3.44803E-02  4.45613E-02 -3.33751E-02 -5.73598E-02  3.50360E-01 ⤸
     6.33053E-02  2.16221E-02  5.42577E-02 -5.74193E+00  0.00000E+00 ⤸
     1.90891E-01 -1.39194E-02  1.01102E+02  8.16363E-02  1.33717E-04 ⤸
     6.54403E-06  3.10295E-03  0.00000E+00  0.00000E+00  5.38205E-02 ⤸
     ...

вместо того

pd = [
     1.09979E+00 -4.88060E-02 -1.97501E-01 -9.10280E-02 -6.96558E-03 #= 
 =#  2.42136E-02  3.91333E-01 -7.20068E-03 -3.22718E-02  1.41508E+00 #=
 =#  1.68194E-01  1.85282E-02  1.09384E-01 -7.24282E+00  0.00000E+00 #=
 =#  2.96377E-01 -4.97210E-02  1.04114E+02 -8.61108E-02 -7.29177E-04 #=
 =#  1.48998E-06  1.08629E-03  0.00000E+00  0.00000E+00  8.31090E-02 #=
 =#  1.12818E-01 -5.75005E-02 -1.29919E-02 -1.78849E-02 -2.86343E-06 #=
 =#  0.00000E+00 -1.51187E+02 -6.65902E-03  0.00000E+00 -2.02069E-03 #=
 =#  0.00000E+00  0.00000E+00  4.32264E-02 -2.80444E+01 -3.26789E-03 #=
 =#  2.47461E-03  0.00000E+00  0.00000E+00  9.82100E-02  1.22714E-01 #=
 =# -3.96450E-02  0.00000E+00 -2.76489E-03  0.00000E+00  1.87723E-03 #=
 =# -8.09813E-03  4.34428E-05 -7.70932E-03  0.00000E+00 -2.28894E-03 #=
 =# -5.69070E-03 -5.22193E-03  6.00692E-03 -7.80434E+03 -3.48336E-03 #=
 =# -6.38362E-03 -1.82190E-03  0.00000E+00 -7.58976E+01 -2.17875E-02 #=
 =# -1.72524E-02 -9.06287E-03  0.00000E+00  2.44725E-02  8.66040E-02 #=
 =#  1.05712E-01  3.02543E+04  0.00000E+00  0.00000E+00  0.00000E+00 #=
 =# -6.01364E+03 -5.64668E-03 -2.54157E-03  0.00000E+00  3.15611E+02 #=
 =# -5.69158E-03  0.00000E+00  0.00000E+00 -4.47216E-03 -4.49523E-03 #=
 =#  4.64428E-03  0.00000E+00  0.00000E+00  0.00000E+00  0.00000E+00 #=
 =#  4.51236E-02  2.46520E-02  6.17794E-03  0.00000E+00  0.00000E+00 #=
 =# -3.62944E-01 -4.80022E-02 -7.57230E+01 -1.99656E-03  0.00000E+00 #=
 =# -5.18780E-03 -1.73990E-02 -9.03485E-03  7.48465E-03  1.53267E-02 #=
 =#  1.06296E-02  1.18655E-02  2.55569E-03  1.69020E-03  3.51936E-02 #=
 =# -1.81242E-02  0.00000E+00 -1.00529E-01 -5.10574E-03  0.00000E+00 #=
 =#  2.10228E-03  0.00000E+00  0.00000E+00 -1.73255E+02  5.07833E-01 #=
 =# -2.41408E-01  8.75414E-03  2.77527E-03 -8.90353E-05 -5.25148E+00 #=
 =# -5.83899E-03 -2.09122E-02 -9.63530E-03  9.77164E-03  4.07051E-03 #=
 =#  2.53555E-04 -5.52875E+00 -3.55993E-01 -2.49231E-03  0.00000E+00 #=
 =#  0.00000E+00  2.86026E+01  0.00000E+00  3.42722E-04  0.00000E+00 #=
 =#  0.00000E+00  0.00000E+00  0.00000E+00  0.00000E+00  0.00000E+00 #=
 =#  0.00000E+00  0.00000E+00  0.00000E+00  0.00000E+00  0.00000E+00;
     1.02315E+00 -1.59710E-01 -1.06630E-01 -1.77074E-02 -4.42726E-03 #=
 =#  3.44803E-02  4.45613E-02 -3.33751E-02 -5.73598E-02  3.50360E-01 #=
 =#  6.33053E-02  2.16221E-02  5.42577E-02 -5.74193E+00  0.00000E+00 #=
 =#  1.90891E-01 -1.39194E-02  1.01102E+02  8.16363E-02  1.33717E-04 #=
 =#  6.54403E-06  3.10295E-03  0.00000E+00  0.00000E+00  5.38205E-02 #=
     ...

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

pd = [ 1.09979E+00 -4.88060E-02 -1.97501E-01 -9.10280E-02 -6.96558E-03 2.42136E-02  3.91333E-01 -7.20068E-03 -3.22718E-02  1.41508E+00 1.68194E-01  1.85282E-02  1.09384E-01 -7.24282E+00  0.00000E+00 2.96377E-01 -4.97210E-02  1.04114E+02 -8.61108E-02 -7.29177E-04 1.48998E-06  1.08629E-03  0.00000E+00  0.00000E+00  8.31090E-02 1.12818E-01 -5.75005E-02 -1.29919E-02 -1.78849E-02 -2.86343E-06 0.00000E+00 -1.51187E+02 -6.65902E-03  0.00000E+00 -2.02069E-03 0.00000E+00  0.00000E+00  4.32264E-02 -2.80444E+01 -3.26789E-03 2.47461E-03  0.00000E+00  0.00000E+00  9.82100E-02  1.22714E-01 -3.96450E-02  0.00000E+00 -2.76489E-03  0.00000E+00  1.87723E-03 -8.09813E-03  4.34428E-05 -7.70932E-03  0.00000E+00 -2.28894E-03 -5.69070E-03 -5.22193E-03  6.00692E-03 -7.80434E+03 -3.48336E-03 -6.38362E-03 -1.82190E-03  0.00000E+00 -7.58976E+01 -2.17875E-02 -1.72524E-02 -9.06287E-03  0.00000E+00  2.44725E-02  8.66040E-02 1.05712E-01  3.02543E+04  0.00000E+00  0.00000E+00  0.00000E+00 -6.01364E+03 -5.64668E-03 -2.54157E-03  0.00000E+00  3.15611E+02 -5.69158E-03  0.00000E+00  0.00000E+00 -4.47216E-03 -4.49523E-03 4.64428E-03  0.00000E+00  0.00000E+00  0.00000E+00  0.00000E+00 4.51236E-02  2.46520E-02  6.17794E-03  0.00000E+00  0.00000E+00 -3.62944E-01 -4.80022E-02 -7.57230E+01 -1.99656E-03  0.00000E+00 -5.18780E-03 -1.73990E-02 -9.03485E-03  7.48465E-03  1.53267E-02 1.06296E-02  1.18655E-02  2.55569E-03  1.69020E-03  3.51936E-02 -1.81242E-02  0.00000E+00 -1.00529E-01 -5.10574E-03  0.00000E+00 2.10228E-03  0.00000E+00  0.00000E+00 -1.73255E+02  5.07833E-01 -2.41408E-01  8.75414E-03  2.77527E-03 -8.90353E-05 -5.25148E+00 -5.83899E-03 -2.09122E-02 -9.63530E-03  9.77164E-03  4.07051E-03 2.53555E-04 -5.52875E+00 -3.55993E-01 -2.49231E-03  0.00000E+00 0.00000E+00  2.86026E+01  0.00000E+00  3.42722E-04  0.00000E+00 0.00000E+00  0.00000E+00  0.00000E+00  0.00000E+00  0.00000E+00 0.00000E+00  0.00000E+00  0.00000E+00  0.00000E+00  0.00000E+00
       1.02315E+00 -1.59710E-01 -1.06630E-01 -1.77074E-02 -4.42726E-03 3.44803E-02  4.45613E-02 -3.33751E-02 -5.73598E-02  3.50360E-01 6.33053E-02  2.16221E-02  5.42577E-02 -5.74193E+00  0.00000E+00 1.90891E-01 -1.39194E-02  1.01102E+02  8.16363E-02  1.33717E-04 6.54403E-06  3.10295E-03  0.00000E+00  0.00000E+00  5.38205E-02 ...
       ...

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

Это предполагает, что мы оставляем все как есть, за исключением одного: в контекстах, где важны пробелы (макросы, но также и построение матриц), в настоящее время нет очевидных способов продолжить строки. Взлом многострочного комментария - это умно, но также и уродливо, ИМО.

Мы можем решить обе эти проблемы сразу, добавив продолжение строки, которое допустимо только в контекстах парсинга space-sensitive :

# Valid - space sensitive context
<strong i="10">@info</strong> "A message which could be rather long"  ⤸
      my_variable my_variable2                ⤸
      some_other_variable

# Invalid - there should only be one way to do this
x = some_variable ⤸
    + other_variable
# Valid - the current, perfectly good convention for writing this
x = some_variable +
    other_variable

Я реализовал Unicode ⤸ для продолжения строки в ветви cjf/line-continuation . Это более простая версия, не ограниченная контекстами, чувствительными к пространству, но это должно быть легко с небольшой перестановкой.

Было бы действительно хорошо иметь явное комбинированное разделение столбцов, оператор | ,

       [ x .+ 1 | 3*(x .+ 2) |
        12 + x | -x ]

Почему требуется более одного символа продолжения строки?

Ради конкретного предложения я сделал для этого пиар - см. №29273.

@ c42f , IMHO, я думаю, что будет несколько запутать разрешить символ продолжения строки только в определенных случаях. Почему мы не можем позволить этому быть глобальным?

Стефан: Только для удобства чтения. Это только предполагает, что символы продолжения строки внутри строки должны выделяться и принудительно разделять поля в контексте, разделенном пробелами.

@ronisbr факт, что есть только один очевидный способ продолжить строки в большинстве выражений, таких как

x = a +
    b +
    c

мне очень нравится, и я не хотел это менять.

Позволяя также записать это как

x =   a  ⤸
    + b  ⤸
    + c

просто вводит ненужные изменения ИМО.

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

Привет, народ!

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

cc @JeffBezanson , он же синтаксис czar.

Обнаружив, что многострочные комментарии, предложенные @stevengj, идеально каких-либо изменений языка. Если да, я буду рад сделать PR в соответствующих местах (один для матриц, один в качестве общего совета).

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

Я согласен с тем, что случай обертывания многострочной матрицы достаточно необычен, чтобы его можно было охватить с помощью #= =# и стоит задокументировать этот вариант для продолжения строки. Для многострочных вызовов макросов я использую этот синтаксис, но я все равно считаю его уродливым и громоздким.

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

Я хорошо осведомлен о возможности использовать парные символы для макросов, но нахожу это неудовлетворительным, как я уже описывал ранее. А именно, использование круглых скобок и запятых делает вызов макроса очень визуально отличным от того, как макросы «обычно выглядят» в большинстве программ juila. Код, который выглядит иначе, труднее читать.