This site is a static rendering of the Trac instance that was used by R7RS-WG1 for its work on R7RS-small (PDF), which was ratified in 2013. For more information, see Home.

Ticket 259: Specify module name in cond-expand as (module <name>) instead of <name>

2012-04-05 09:37:45
WG1 - Core
2011-08-16 22:52:18

In CondExpandCowan, the test for the existence/importability of a module is to specify the module name. However, this means module names can't begin with and, or, or not. Draft 3 instead specifies (module module-name), and I think this is better.

Now of course this is (library library-name).


The draft already specifies this, and there is currently no non-ambiguous alternative proposed, so closing the issue.


Reopening this, because even if there is no other proposal that resolves the ambiguity, it can be resolved by removing the feature. I want the feature, but the WG has to vote it in if we are to have it.

I'm not sure why there is an ambiguity here. Unless a library name is automatically considered a <feature identifier>, which doesn't appear to be true, then library must be wrapped around a library name in order to use it in a cond-expand clause.

John, when you say "I want the feature," which feature do you want? The ability to specify a library directly as a <feature identifier>, or just the ability to specify a library through a library clause?

What CondExpandCowan says, which is what we voted for in ballot 2
Library names can be used on the same level as feature identifiers (leads to unacceptable ambiguous BNF)
What the draft says, and what I now favor, but not what we voted for
Library names must be wrapped in a (library ...) form
The alternative
Don't allow library names at all

So the choice for this ticket is between the last two.


The WG voted to adopt this proposal.