guix-parameters/DRAFTS/updated-syntax.org

Renaming parameter-type~'s ~universe to accepted-values

Addition of default in parameter-type

Renaming morphisms to parameteric-variants (or something better)

Redo of morphism-match

A field known as default will be added to the parameter-type record. By default, it will be the second value in the accept-values list if negation is supported, and the first value otherwise.

  (parameter-spec-parameteric-variant-match ; no more + or ->
    ((-O2 -O3) #:build-system (gnu-build-system lisp-build-system)
               #:transform (without-tests #:package-name)))

Removing / and replacing it with -

Renaming universal to works-with-all-packages?

No parameter-type/lambda macro

No -> in dependency-match, follow parameteric-variants-match syntax

No more ~!~. Use #:off to signal negation instead.

Look into ways to avoid using a global hash-table for global parameters

Regarding parameter-list syntax

Since we are using ~#:keywords~ for transforms, procedures etc. anyways, we could use these for build systems too. This will make the syntax more lisp-y. Personally would still prefer ~/~ since it adds clarity, perhaps worth discussing with concrete examples. This could cause confusions and misunderstandings. Could perhaps be added to the ease-of-use DSL later on, but will not be a part of this patch. in Scheme ~!~ is usually reserved for operations with side-effects, so it's a lot more sensible to use something like ~(psym #:off)~ for generic negation. Could later on add it to the ease-of-use DSL, but this patch will not have it. Arun's suggestion: Guile's parameterize
• parameterize uses continuations and it could be a problem? as far as I know, guix does not use continuations anywhere due to memory leak concerns
For the time being, we could stick to the hash-table as it is an implementation detail and will not affect the syntax. As of now ~define-global-parameter~ adds global parameters, and if a parameter with the given name already exists it throws an error. Global parameters can then be accessed by their names alone. This is very important as *all* of the parameter functions operate on *symbols*, and the only other way to get something from the symbol with its name is to use ~eval~, which is extremely taboo. A lot of fields accept lists of parameters, be it parameteric conditionals or the fields in the parameter-spec. They all share a common syntax:

(list (cons 'parameter-symbol 'parameter-value) (cons 'another-symbol 'another-value) ...

As this can be a bit hard to write, any of the following are acceptable:

  '((a v) (b v2) (c _)...)
  '((a . v) (b . v2) (c . _) ...)
  '((a v) (b v2) c ...) ; by default sym means (sym _)

Note that using ~.~ inside a list does not in fact generate an associated list. It creates a list of lists instead of a list of cons cells. In Scheme the only way to create an alist is to either use alist functions from ice-9 or to specify it with list and cons like in the previous example. No need to fret though, the processor converts all of these lists into lists of cons cells internally, and yes this feature has been implemented :)