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
alexshinn
major
cowan
fixed
source
closed
2011-08-16 22:52:18
defect

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).

resolutionfixed
statusnewclosed

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

resolutionfixed
statusclosedreopened

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.

statusreopeneddecided

The WG voted to adopt this proposal.

resolutionfixed
statusdecidedclosed