garbas
commented
3 years ago I would add my thoughts
Typing
I do like that Nix does not require to use any special word to start writing a function. Using fun feels weird if you are coming from Nix. I understand we can not use the same syntax as it is with Nix, but using an Haskell way of defining functions seems much nicer.
I kinda dislike having types embedded with the function definition (I really hate that Rust did it this way). Specifying types inside the function definition makes it much harder to think in terms of types and how they relate. Even now I first write types even if in a comment before writing any Nix code.
I guess I'm trying to propose the Haskell or Elm like syntax here.
f : Num -> Num
f a b = a * bAbove only covers named functions. There should be also a syntax for anonymous functions. In this case I would allow inline type definitions. The important use case to consider is a file level anonymous functions that are quite popular in Nix.
\{ a : Num
, b : Num
} = mkDerivation {
name = "hello"
}Records
It would also use the same delimiter as in Records and Lists. This deviates from how Nix, but it brings the syntax closer to be JSON-like which I think is going to be more familiar.
edolstra
mboes
yannham
n87
Profpatsch
ggPeti
milahu
silverraven691
ammkrn
@garbas asked me if the function syntax was final. Since nothing is final yet, I think it is a good idea to create a dedicated issue for the basic constructs of the language, even if most seem non controversial, such that people can voice concerns or make alternative proposals.
Functions
Definition
Currently, Nickel uses an ML-like anonymous function syntax
fun arg1 .. argn => body. There are other possibilities:arg1: arg2: ..: body, but:will be used for typing, so it's probably a bad idea (see section below).fun(arg1,..,argn) ... ReasonML does this for example, although they also adopt the corresponding call syntaxf(arg1,..,argn)which looks less natural in languages with currying. This can be confused with tuples, but Nickel does not have tuples currently... { body }. Independently from the syntax of arguments, the body could be written as a block.fun:fn,def, etc.We could also define a non-anonymous function in a more concise way. For example, in OCaml, you can do:
Typing
It has not been discussed, but a nice thing to have is a syntax to define the arguments, their type and the return type directly. In ML-derived languages, you can usually write:
As in the previous section, there are many variations and possible choices:
let f (x: Num) (y: Num) (z: Num) -> Num = bodyOne Nickel-specific issue would be to have a similar syntax for function contracts. For example, we can replace
: Numwith| type Numor| contract Num(see #183):to indicate that pre and post-conditions must be checked at run-time, but that we don't wish to statically typecheck the body.
Note that there's the issue #81 for destructuring, which would also be available directly on function arguments.
Records and Lists
Nickel uses Nix-like record definition:
We should stay close to JSON syntax. Pure JSON syntax using
:would clash with typing annotations, and thefield = contentsyntax is pretty standard among languages that don't use:(C++, OCaml, Haskell, Dhall, etc.). The delimiter;could be changed for,or something else, but note that,is already used for lists and more (which is not blocking, but can become confusing).Lists use exactly the JSON syntax:
Comments
There are currently no comments. I propose the ubiquitous C-like line and block comments:
One could argue that long documentation belongs to meta-values, and that we may do fine without block comments, eliminating the issue of nested comments (how to parse
/* /* /* foo */ */ */?) at the same time.Others
I've left
let indeclaration out, as it will have their own round of bike-shedding.