用于定义命名函数的重复语法是否会成为错误的语言设计决策?


9

我正在为有趣的编程语言建模,并且语法在很大程度上受Scala的影响-特别是函数定义。

我遇到了一个设计问题,因为我的语言无法区分通过def语法定义的函数(类方法)和分配给值的匿名函数(使用创建的值=>)-它消除了实现行为上的差异。

结果是以下两个定义含义相同:

def square(x: Int) = x*x

val square = (x: Int) => x*x

没有任何理由在任何正常情况下都使用后一种形式(立即匿名函数赋值)- 可以使用它代替def形式。

具有用于定义命名函数的重复语法是否会损害语言或其他设计方面的正交性?

我更喜欢这种解决方案,因为它允许对方法和命名函数进行简短直观的定义(通过def),以及对匿名函数进行简短定义(使用=>)。

编辑:Scala 确实区分了两者 -匿名函数与defScala中定义的方法不同。不过,差异相对较细微-请参阅我之前链接的帖子。


However, assigning existing functions似乎缺少句子的结尾
Izkata 2014年

1
您可以使用val符号定义递归函数吗?
Giorgio 2014年

2
我确认这在Scala中也是可能的。在SML中不是,您必须使用它fun来定义递归函数。
Giorgio

3
第二种形式并不是一种特殊的语法结构,def而是这样。这只是以下事实的副作用:匿名函数(例如,(x : Int) => x + 1是一个对象),并且可以使用将该对象分配给值val f = ...。语言设计人员必须竭尽全力禁止语法。这与显式地支持两种(近似)做同一件事的语法不同。
KChaloux

3
用一种语言做多种事情的主要好处是,这是发起无用的宗教辩论的好方法,这种辩论分散了真正的问题(在这里思考C ++).......
mattnz 2014年

Answers:


3

我认为,具有两种含义相同但外观不同的结构应在一种语言中绝对减少。任何重复都会增加阅读(并由此编写/修改代码)语言的难度。在可以创建任意构造的语言中,消除所有重复是不可避免的(例如,迭代与递归等效)。

因此,在这种情况下,我认为这里可以进行更好的设计。定义函数的单一方法对我来说最有意义。在这种情况下,听起来您实际上拥有的两个scala语句的含义略有不同,这又可能不是一个好的设计(最好最好是清楚地说明一些区别,例如关键字)。

实际上,您不仅可以将这一原理应用于命名函数,还可以应用于任何函数。为什么在定义命名函数和匿名函数时有什么区别?在Lima中,函数总是这样定义的:fn[<arguments>: <statements>]。如果您希望将其命名为“ named”,则可以将其分配给变量:var x = fn[<arguments: <statements>],以及要将其匿名传递给另一个函数:function[fn[<arguments: <statements>]]。如果您要悬挂它,请使其恒定const var x = fn[<arguments: <statements>]。单一形式使它们很明显地意味着同一件事。


const引起吊起的过程非常有趣,但这是完全合理的。在JS中function myFunc可以起吊,但var myFunc =不会起吊,这可能不太直观,因为否则它们的行为几乎相同。
mpen

1
@mpen是的,实际上javascript本质上是做同样的事情。的function fnName()...形式事实上确实创建一个常数,这是什么使起重有效的东西,用它做。当您使用表格时,Javascript使事情变得非常混乱,var fn = function anotherFnName()...因为这会使名称anotherFnName 不正确,即使名称明显不变。
BT

2

您发布的内容是有效的scala,并且工作正常。

鉴于加倍并没有引起scala问题(据我所知),我要说的是这对您的语言也不会造成问题。


1
它在Scala中是有效的,它在大多数情况下都是相同的,但并不意味着相同的事情-如果您要编写更复杂的示例(例如,匿名函数不提供类型多态性),则区别将更加明显。
jcora 2014年

2

def在Scala中发现了lambda和方法之间的根本区别-我仍然不确定是否要实现。我必须对此做进一步研究,然后再汇报我的决定。

本质上,只有方法可以return-当从lambda中使用关键字时,实际上它是从包含方法中返回的。

如我所说,我不确定是否要这样做。但这对于这种语法来说可能是足够的。也许是太危险了,因为细微的差异会意外地造成伤害。

细节

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.