Perhaps.  But one might have the library without the feature, that is, if the syntax-rules in (scheme base) and/or (rnrns base) was not SRFI 149 compatible.  So the essence of the feature is not that SRFI 149 is not available, but that you can get SRFI 149 behavior without importing SRFI 149, hence "srfi-149-compatible".

On Sat, Jul 29, 2017 at 5:04 PM, Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
John Cowan <xxxxxx@ccil.org> schrieb am Sa., 29. Juli 2017 um 20:28 Uhr:


From: "Marc Nieper-Wißkirchen" <xxxxxx@nieper-wisskirchen.de>

<p>
Therefore, the author of this SRFI now recommends that implementers ignore this extra requirement so that <code>(srfi 149)</code> may export a version of <code>syntax-rules</code> compatible with this SRFI and <code>(scheme base)</code> may exports another.  Instead, it is recommended that implementations provide a feature identifier <code>srfi-149</code> in case the implementation of <code>syntax-rules</code> in <code>(scheme base)</code> has the semantics as specified in this SRFI.
</p>

Marc

My only objection is to the name of the feature identifier.  I think it would be easy to misunderstand "srfi-149" as meaning the same as "(library (srfi 149))" in cond-expand. 

Even if people misunderstood this, this wouldn't be much of a problem. An implementation providing the feature identifier srfi-149 would also provide the library (srfi 149), so if one wrote srfi-149 instead of (library (srfi 149)) in a cond-expand, it would do no harm.

Don't you think?
 
So I would suggest "srfi-149-compatible" or perhaps "srfi-149-ellipsis".

--
John Cowan          http://vrici.lojban.org/~cowan        xxxxxx@ccil.org
If I have not seen as far as other giants, it’s because I have been
standing on my head.  --Trond Engen 


To unsubscribe from this list please go to http://www.simplelists.com/confirm.php?u=HPnO69Ijc0fnLAmtlfwu0Yu43aG4fvix