cond-expand

[lassik]

People should be able to do things like this:

(package
 (name (cond-expand 
         ((or chicken gauche)
          foo)
         (guile
          bar)
         (else
          baz)))
 ...)

We should think of a good way to allow a cond-expand almost anywhere.

[diamond-lizard]

It seems to me that just about every field in the package be different for every Scheme.

Dependencies, test dependencies, installed files, even the manual url could be different. For a case of the latter, see Chicken's package manuals, which are on the Chicken wiki and sometimes contain Chicken-specific information. I'm sure that must be the case for other Schemes as well.

As the number of Schemes grows we might wing up with huge metadata files.

[lassik]

It seems to me that just about every field in the package be different for every Scheme.

You may be right! Portability is the classic achilles heel of Scheme; this gives one more impetus to work on it :)

As the number of Schemes grows we might wing up with huge metadata files.

That's true. However, all of that information has to go somewhere. If one git repo hosts the same package for 3 Scheme implementations, it either has to have 3 metadata files, or one metadata file with the information for all three. I'd prefer the latter, since it allows us to gradually work toward merging things that are the same.

True to its name, cond-expand can always be expanded for any given feature set, and you can then work with the expanded data if that's more convenient. It's just an extra filter added to the pipeline.

[lassik]

It might make sense to support (include "another-file") in addition to cond-expand. Then we'd have the same capabilities for conditionalizing the file as in R7RS define-library forms.

[lassik]

More generally, in all Schemedoc endeavors, "any problem can be solved by appending another filter" :) The really important thing is to encode the authoritative source data into a form that is comprehensive and extensible. If we have that, we can freely generate endless combinations and subsets of that information according to what it convenient for each purpose.

[The original joke is "Any problem in Computer Science can be solved with another level of indirection." ]

[diamond-lizard]

It might make sense to support (include "another-file") in addition to cond-expand. Then we'd have the same capabilities for conditionalizing the file as in R7RS define-library forms.

I was thinking the same thing about the include.

I'm not so sure about the cond-expand, however. Are thinking this format should be executable?

I like giving the users options, but not entirely sold on the file format being a program.

[diamond-lizard]

More generally, in all Schemedoc endeavors, "any problem can be solved by appending another filter" :) The really important thing is to encode the authoritative source data into a form that is comprehensive and extensible. If we have that, we can freely generate endless combinations and subsets of that information according to what it convenient for each purpose.

[The original joke is "Any problem in Computer Science can be solved with another level of indirection." ]

Solved... or caused...

There's a price to pay for indirection and fragmentation. After a while, things get hard to reason about.

This is why I'm kind of leaning towards narrowing the focus rather than trying to provide every possible thing imaginable and coming out with a gigantic standard that's hard to implement and competes with existing package formats.

If it's small, simple, and elegant (Scheme's motto), people might participate.

If it's large and unwieldy, there's bound to be resistance and lack of compliance.

[lassik]

I was thinking the same thing about the include.

Nice :)

I'm not so sure about the cond-expand, however. Are thinking this format should be executable?

Nope, I agree that the format should be declarative.

cond-expand is not inherently imperative and doesn't require a full eval; the only part of it that needs to be evaluated are the boolean expressions for selecting which clause to use. In Scheme, the body of each cond-expand clause is Scheme code, but it's possible to make a format where the body is just declarations in that format.

include is actually more complex than cond-expand in many cases because it implies we may have to download another file if we got the original file from the internet.

Solved... or caused...

That's the joke :) Caching is the most infamous example.

This is why I'm kind of leaning towards narrowing the focus rather than trying to provide every possible thing imaginable and coming out with a gigantic standard that's hard to implement and competes with existing package formats.

If it's small, simple, and elegant (Scheme's motto), people might participate.

If it's large and unwieldy, there's bound to be resistance and lack of compliance.

That's the beauty of making everything optional. People are free to use a trivially simple subset.

It's true that the cond-expand and include machinery would force some complexity on everyone. (Well, simple programs can give up if they encounter those things, but it's not ideal.)

The trouble is that the fundamental problem is intrinsically complex. We can scatter it around many simple solutions or have it in one solution that gets quite complex when you add everything up. However, we can make most of the complexity optional.

Empirically, the information about packages is now scattered around many simpler files, and trying to curate it into one place is a very messy problem.

[lassik]

Chicken 5 egg metadata files already support cond-expand. Here's an example from the udp egg:

((synopsis "An interface to User Datagram Protocol sockets")
 (category net)
 (license "BSD")
 (dependencies srfi-1 srfi-18)
 (test-dependencies test)
 (author "Category 5")
 (maintainer "Ivan Raikov")
 (version "1.18")
 (components (extension udp
                        (cond-expand
                         (windows (csc-options "-O2" "-d1" "-L" "-lws2_32"))
                         (else (csc-options "-O2" "-d1"))))))

This would indicate that it makes sense to have a generic format with cond-expand support. The Chicken files are quite simple and they are already finding a need for it. find eggs-5-latest -name "*.egg" | xargs grep cond-expand | wc -l shows that cond-expand is used 24 times across all Chicken 5 .egg files.