Julia: 功能请求:添加运算符以允许矩阵定义中的断行

创建于 2018-06-11  ·  52评论  ·  资料来源: JuliaLang/julia

嗨,大家好,

我在 Discourse [1] 中开始讨论我们如何在不创建新行的情况下定义带有折线的矩阵。 例如:

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

被转换为 2x5 矩阵,因为换行符被解释为第一行的结尾(这很好)。 但是,我实现了 MSIS 模型 [2],它需要定义具有 150 列的矩阵。 在这种情况下,如果我选择在源代码中硬编码这些矩阵以保持兼容性,我将不得不在一行中键入 150 个浮点数,这并不好。

Matlab 有...运算符:

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

转换为 1x10 矩阵。

最后,我想知道我们是否可以在 Julia 中拥有这样的东西。 目前,[1] 中提出的唯一解决方法是如下欺骗解析器:

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

这有效,但不是“最佳”。


[1] https://discourse.julialang.org/t/declare-a-matrix-with-break-lines/11568/18
[2] https://ccmc.gsfc.nasa.gov/pub/modelweb/atmospheric/msis/nrlmsise00/nrlmsise00_sub.for

design parser

最有用的评论

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

也可以工作,并且不涉及分配额外的临时[5]数组。 多行注释 (#69) FTW!

所有52条评论

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))

从数学的角度来看,那些括号没有意义。 有人可能会无意中删除它们,Julia 不会显示任何警告,代码将完全错误。

我能想到的最好的事情是\作为一行中的最后一个非空格,这将是一个重大变化,因为这是当前有效但奇怪的语法

出于同样的目的使用#怎么样? 解释是您正在注释掉换行符。 (感谢@oxinabox提出对 LaTeX 使用%作为注释/行延续的解释)

好吧,从我的角度来看,行尾的#没有任何字符跟随,应该非常好并且似乎破坏更少的东西。

我在这里看到的一个潜在问题是从

a=1 #because reasons
 +2

a=1 #
 +2

产生不同的结果。 不过这可能并不重要。

Julia 没有使用的东西,比如\\呢? 是不是太丑了?

我希望做乳胶风格的“评论新的喜欢”来打破东西。

除非它仅限于#没有任何非空格。
例如:

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 中没有任何新行。
空评论与非空评论的行为不同听起来很奇怪。

我实际上并不是为 julia 推荐它。
我认为\\不会那么混乱。
但我认为多行注释的@stevengj解决方案可能是最好的。 它非常明确地注释掉了新行

尽管制作巨大的多行文字似乎非常小众。
甚至比Array{T, 3}文字更重要。

人们应该能够使用vectcat命令同样有效地构造它们,这些命令无论如何都会降低。

我认为建议是有一个#后跟换行符(或可能只有空格)。

是的,我的意思是@StefanKarpinski建议#进行特殊处理,绝对不包括在#之后还有其他非空白内容的情况。 也许 LaTeX 的比较比澄清我想说的更令人困惑。

选择#对我来说似乎有风险。 我有时会在我的代码中散布# ,原因我不太记得了,我有点改变主意的评论等等。很容易无意中删除尾随的# s 在“清理”时。

我偶尔会错过一个行继续运算符,但希望它非常明显,例如\...#=[]看起来有点像 _trick_。

(如果不鼓励使用,也许有些丑陋的东西,比如\\\会起作用吗?)

在行继续操作符之后添加注释对我来说也是很正常的,所以我不想依赖它是行中的最后一个非空白字符。

不确定它们是否已经在其他地方使用,或者是否应该保留给特定于用户的运算符,但这些 Unicode 箭头之一可能会为显式行继续提供有吸引力的直观选项:

(例如使用一些有意义的制表符完成别名,例如\continueline

我认为幸运的是#= =#可以解决这个问题,我们应该把它留在那里。

我不同意在每行末尾放置反斜杠在某种程度上比添加括号或将运算符放在行尾更好。 我也不认为滥用反斜杠或#会有所改进; 那只会增加惊喜。 如果我们使用多字符的东西,那么它不会比#= =#有太大的改进。

我不同意在每行末尾放置反斜杠在某种程度上比添加括号或将运算符放在行尾更好。

这个问题被打开的原因是这些都不适用于矩阵文字。 不过,我同意我们可能不应该为此做任何事情,因为#= =#已经可以工作了。

既然我已经看到您可以使用#= =#来进行换行,这很有意义。 不过,老实说,我一个人肯定不会得出这样的结论。

也许最好的方法是在文档和 Julia 风格指南中添加一些内容,说行延续可以通过#= =#

只是为了结束讨论, @JeffBezanson@StefanKarpinski ,您是否认为即使@thchr提出的不会破坏任何内容的建议也不好实施? 我认为这会很好,例如:

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

#= =#更简洁,视觉上令人愉悦。

这读起来确实不错。 一个副作用是,这将提供一种在固定宽度显示器上以输出形成有效代码的方式打印长行代码的规范方式。

不过,我们已经将许多 Unicode 箭头解析为二元运算符。

我怀疑我们可以留一个。

恕我直言,不错的选择:

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

也许是时候让空白成为一个运算符了,我们可以用 Cassette 在大矩阵上下文中重载它。 令人高兴的是,Bjarne Stroustrup 已经为我们完成了艰苦的设计工作 – http://www.stroustrup.com/whitespace98.pdf

如果我们使用多字符的东西,那么它不会比#= =#有太大的改进。

我想提出三个反对这一点的论点。

首先,这可能会被误认为是评论。 即使我知道这一点,我的大脑也会记录“评论”。

其次,你必须把它放在两行,而不仅仅是一行。 (这将如何与缩进相互作用?)

第三,它是一个更复杂的按键组合(在我的电脑上是shift-3 shift-0 enter shift-0 shift-3 )。 我想可以使用某种键盘快捷键。 相比之下, \\是对同一个键的两次快速按下(然后是enter 。)

三岁半:恕我直言,它看起来有点别扭,感觉像是在耍花招。

即使\\不被接受,因为它可能“保留”以备将来使用,我真的认为@thchr 的建议看起来非常好。 看看会怎样:

            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 ...
       ...

我认为有一种明显的方式来编写跨越多行的表达式是很棒的,因为在这种格式中,整个生态系统的一致性比灵活性更重要。

这表明我们保持原样,除了一件事:在空白很重要的上下文中(宏,还有矩阵构造),目前有零个明显的方式来继续行。 多行注释 hack 很聪明,但也很丑陋,IMO。

我们可以通过添加仅在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

我已经在cjf/line-continuation分支中实现了 unicode ⤸ 用于行延续。 这是一个更简单的版本,不限于空间敏感的上下文,但通过一些重新排列应该很容易。

有一个明确的组合列分隔、行继续运算符会非常好。 它将解决 OP 的问题并增强带有公式的矩阵表达式的可读性。 使用|模拟示例,

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

为什么需要一个以上的续行符?

为了有一个具体的建议,我为此做了一个 PR - 见 #29273

@c42f ,恕我直言,我认为仅在特定场合允许行继续符会有些混乱。 为什么我们不能让它成为全球性的?

Stefan:仅用于可读性。 这只会建议允许行内的行延续字符在空格分隔的上下文中强调和强制字段分隔。

@ronisbr事实上,在大多数表达式中只有一种明显的方式来继续行,例如

x = a +
    b +
    c

对我很有吸引力,我不想改变这一点。

允许这也写为

x =   a  ⤸
    + b  ⤸
    + c

只是引入了不必要的变化 IMO。

该语言已经具有“空间敏感”上下文的概念,其中解析规则是不同的,并且这整齐地插入其中。

嗨,大家好!

现在我们有了 1.1,我们可以讨论 1.2 的这个特性吗? 至少,我们可以决定这最终会成为一个新功能还是应该关闭这个问题?

cc @JeffBezanson ,又名语法沙皇。

已经发现多行注释为所建议@stevengj完全足够用于此目的(和一般的),我不知道如果我们能够提这本手册中,从而解决问题没有任何变化的语言。 如果是的话,我很乐意在相关地方做一个 PR(一个用于矩阵,一个作为一般建议)。

我意识到有些语言对此有特殊的语法,这有时很有用。 但是,我不认为编写超长行或在源代码中包含大型文字矩阵应该成为语言鼓励的习惯,而不是我们在极少数情况下需要的一些支持。

我同意多行矩阵包装的情况非常不寻常,可以使用#= =#来涵盖,并且值得记录此选项以用于行延续。 对于多行宏调用,我使用这种语法,但我仍然觉得它丑陋而繁琐。

对于多行宏调用,您可以使用括号。

我很清楚为宏使用括号的选项,但我发现它不令人满意,正如我之前描述的那样。 也就是说,使用括号和逗号使宏调用在视觉上与大多数 juila 代码中宏“通常看起来”的方式截然不同。 看起来不同的代码更难阅读。

此页面是否有帮助?
0 / 5 - 0 等级

相关问题

tkoolen picture tkoolen  ·  3评论

StefanKarpinski picture StefanKarpinski  ·  3评论

TotalVerb picture TotalVerb  ·  3评论

omus picture omus  ·  3评论

dpsanders picture dpsanders  ·  3评论