- the module paths a bit weird (I’d find slash or dot separated more obvious)
- some values needed to be constructed with a call to list
- weird dsl for building was mixed in there
- it’s probably not obvious what should be string/symbol/whatever
I’m not sure anything should change though. It still feels a bit weird to me that it’s a program generating the package rather than a more direct ‘just data’ format.
- the module paths a bit weird (I’d find slash or dot separated more obvious)
There's no special syntax for any of those dot slash whatever stuff. (Program item) paths are always lists (like in CSS selectors). Likewise we don't use shell strings and then have to weirdly escape them, we just use an argv list to begin with. And so on. What's the use in pretending it's something it's not?
- some values needed to be constructed with a call to list
It depends on how good you are with quoting; if you want to avoid quasiquote, "list" is easier to understand. Otherwise, (almost) no values need to be constructed with a call to "list".
(list 1 2 3) is equal to `(1 2 3)
(list 1 2 b) is equal to `(1 2 ,b)
(list 1 'b b) is equal to `(1 b ,b)
>- weird dsl for building was mixed in there
If you mean what I think you mean then it's a program running in the build container (in an extra process) (so it's quoted in the scm file of guix).
- it’s probably not obvious what should be string/symbol/whatever
I’m not sure anything should change though. It still feels a bit weird to me that it’s a program generating the package rather than a more direct ‘just data’ format.
It will always end up like that, even in packaging systems that start with a "just data" config format. They will always grow their own weird language for #if, #cfg, function calls and so on in the config format. Then they have weird generator scripts generating the config files, and there they are right where we are, just shittier.
To the last point: since it is a lisp, data = code and all that. Fundamentally I think that is at the heart of a lot of the power here with package definitions and the system itself being the same.
Ok, so mostly just variations on the “unfamiliar with lisp” theme. Though I have to say that it would be a bit silly to invent a new way to write lists just to name packages, when Lisp already has an excellent way of writing lists. :)
Oh, and how can a package manager avoid dealing with build systems? There are almost as many different build systems as there are packages!
I was trying to answer the question of why the lisp config might be difficult to read so I deliberately tried to not rely on my own intuition about how lisps work. In particular, I think it is possible to design a format for s-expression package definitions that is more approachable to people who don’t know lisp.
I continue to find it slightly odd that the package definition is not some serialisation of a package object but rather a full program that outputs a package object, and I think this is the root of a bunch of the confusing things about the definition. Consider that the commenter at the top of this thread thought yaml might be preferable. I think that means they didn’t realise they were looking at a program outputting the package definition but rather that they thought they were just looking at the definition itself.
If the whole thing were just data instead of data that’s actually code whose evaluation produces data, I think things would be more obvious. For example, some symbols are just syntax (e.g. in the alist syntax for constructing the package definition) whereas others are references to values of which some are other packages, some are just scheme functions, and some are guix-specific functions. And symbols have other meanings in the build-steps reader macro.
Building package definitions in this way can also make errors harder to pinpoint as the author can write any program they like rather than being restricted to a more limited configuration language. Needing to evaluate programs to get packages can also, I think, make the collection of all packages as a whole pretty opaque and hard to reason about compared to e.g. being able to have a database that contains all the package definitions.
I don’t think the ‘unfamiliar with lisp’ argument is good. I’m pretty familiar with lisp (though not so much guile/scheme) and I’ve been writing it for over ten years and I think this way of specifying packages is not great in the average case, though perhaps there are some complexities that cannot be handled without this general mechanism.
YAML’s excesses are exactly why a real programming language is preferable to a mere serialization format. Aliases and overrides are only useful in YAML because it is not a real programming language.
As for error messages, I don’t think that using a real programming language forces the error messages to be bad, or to be too generic. If the error messages are not good it is only because nobody has put in the time and elbow grease to make them good, not because of any fundamental limitation of turing–complete languages.
Comments
I think when I skimmed it, I found:
- the module paths a bit weird (I’d find slash or dot separated more obvious)
- some values needed to be constructed with a call to list
- weird dsl for building was mixed in there
- it’s probably not obvious what should be string/symbol/whatever
I’m not sure anything should change though. It still feels a bit weird to me that it’s a program generating the package rather than a more direct ‘just data’ format.
There's no special syntax for any of those dot slash whatever stuff. (Program item) paths are always lists (like in CSS selectors). Likewise we don't use shell strings and then have to weirdly escape them, we just use an argv list to begin with. And so on. What's the use in pretending it's something it's not?
It depends on how good you are with quoting; if you want to avoid quasiquote, "list" is easier to understand. Otherwise, (almost) no values need to be constructed with a call to "list".
>- weird dsl for building was mixed in thereIf you mean what I think you mean then it's a program running in the build container (in an extra process) (so it's quoted in the scm file of guix).
It will always end up like that, even in packaging systems that start with a "just data" config format. They will always grow their own weird language for #if, #cfg, function calls and so on in the config format. Then they have weird generator scripts generating the config files, and there they are right where we are, just shittier.
https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule :)
To the last point: since it is a lisp, data = code and all that. Fundamentally I think that is at the heart of a lot of the power here with package definitions and the system itself being the same.
Ok, so mostly just variations on the “unfamiliar with lisp” theme. Though I have to say that it would be a bit silly to invent a new way to write lists just to name packages, when Lisp already has an excellent way of writing lists. :)
Oh, and how can a package manager avoid dealing with build systems? There are almost as many different build systems as there are packages!
I was trying to answer the question of why the lisp config might be difficult to read so I deliberately tried to not rely on my own intuition about how lisps work. In particular, I think it is possible to design a format for s-expression package definitions that is more approachable to people who don’t know lisp.
I continue to find it slightly odd that the package definition is not some serialisation of a package object but rather a full program that outputs a package object, and I think this is the root of a bunch of the confusing things about the definition. Consider that the commenter at the top of this thread thought yaml might be preferable. I think that means they didn’t realise they were looking at a program outputting the package definition but rather that they thought they were just looking at the definition itself.
If the whole thing were just data instead of data that’s actually code whose evaluation produces data, I think things would be more obvious. For example, some symbols are just syntax (e.g. in the alist syntax for constructing the package definition) whereas others are references to values of which some are other packages, some are just scheme functions, and some are guix-specific functions. And symbols have other meanings in the build-steps reader macro.
Building package definitions in this way can also make errors harder to pinpoint as the author can write any program they like rather than being restricted to a more limited configuration language. Needing to evaluate programs to get packages can also, I think, make the collection of all packages as a whole pretty opaque and hard to reason about compared to e.g. being able to have a database that contains all the package definitions.
I don’t think the ‘unfamiliar with lisp’ argument is good. I’m pretty familiar with lisp (though not so much guile/scheme) and I’ve been writing it for over ten years and I think this way of specifying packages is not great in the average case, though perhaps there are some complexities that cannot be handled without this general mechanism.
YAML’s excesses are exactly why a real programming language is preferable to a mere serialization format. Aliases and overrides are only useful in YAML because it is not a real programming language.
As for error messages, I don’t think that using a real programming language forces the error messages to be bad, or to be too generic. If the error messages are not good it is only because nobody has put in the time and elbow grease to make them good, not because of any fundamental limitation of turing–complete languages.