From: Zach B. <xa...@xa...> - 2011-03-02 19:31:55
|
When I evaluate this in CLISP 2.49: (compile nil (lambda () (directory "/" 'xach t :allow-other-keys t))) I get this WARNING: WARNING: keyword XACH is not allowed for function DIRECTORY. The only allowed keywords are :IF-DOES-NOT-EXIST, :CIRCLE and :FULL. I expected the presence of :allow-other-keys to prevent any warning about keyword allowed-ness. Should this warning be eliminated if :allow-other-keys is passed? Thanks, Zach |
From: Sam S. <sd...@gn...> - 2011-03-02 21:58:42
|
> * Zach Beane <knpu@knpu.pbz> [2011-03-02 14:31:43 -0500]: > > When I evaluate this in CLISP 2.49: > > (compile nil (lambda () (directory "/" 'xach t :allow-other-keys t))) > > I get this WARNING: > > WARNING: keyword XACH is not allowed for function DIRECTORY. > The only allowed keywords are :IF-DOES-NOT-EXIST, :CIRCLE and > :FULL. > > I expected the presence of :allow-other-keys to prevent any warning > about keyword allowed-ness. Should this warning be eliminated if > :allow-other-keys is passed? note that (compile nil (lambda () (directory "/" :allow-other-keys t 'xach t))) only says WARNING : DIRECTORY: ignored keyword XACH T Obviously, the behavior should be the same in both cases. (Please file a bug report on SF!) Also, the warning should be a style-warning (since the allow-other-keys argument is a constant and we know for a fact that there will be no problems at run time). One might argue that the explicit :allow-other-keys should disable the warning altogether. I am not sure that this is the case. If you want to avoid the warning, write (directory .... #+cmu :cmu-specific-option #+cmu cmu-specific-option-argument) instead of (directory .... :cmu-specific-option cmu-specific-option-argument :allow-other-keys t) -- Sam Steingold (http://sds.podval.org/) on CentOS release 5.3 (Final) X http://camera.org http://pmw.org.il http://mideasttruth.com http://iris.org.il http://palestinefacts.org http://jihadwatch.org http://memri.org "A pint of sweat will save a gallon of blood." -- George S. Patton |
From: Zach B. <xa...@xa...> - 2011-03-03 15:12:03
|
Sam Steingold <sd...@gn...> writes: > note that > (compile nil (lambda () (directory "/" :allow-other-keys t 'xach t))) > only says > WARNING : > DIRECTORY: ignored keyword XACH T > > Obviously, the behavior should be the same in both cases. > (Please file a bug report on SF!) I tried, but it looks like SourceForge's bug tracker is broken at the moment. I'll try again later. > Also, the warning should be a style-warning (since the allow-other-keys > argument is a constant and we know for a fact that there will be no > problems at run time). > > One might argue that the explicit :allow-other-keys should disable the > warning altogether. I am not sure that this is the case. A style-warning would be better, but I'd prefer no warning. To me, :allow-other-keys at the call site is a way for me to explicitly pass a keyword I *know* is not part of the interface in some contexts, but have the implementation accept the code anyway. I can understand the desire to prevent typo-related bugs with a style-warning, but I think passing :allow-other-keys signals a willingness to take that chance. > If you want to avoid the warning, write > > (directory .... #+cmu :cmu-specific-option #+cmu cmu-specific-option-argument) In an ideal world (for me), there would be no need for reader conditionals and also no warning. Zach |
From: Pascal J. B. <pj...@in...> - 2011-03-03 16:26:05
|
Zach Beane <xa...@xa...> writes: > Sam Steingold <sd...@gn...> writes: > >> note that >> (compile nil (lambda () (directory "/" :allow-other-keys t 'xach t))) >> only says >> WARNING : >> DIRECTORY: ignored keyword XACH T >> >> Obviously, the behavior should be the same in both cases. >> (Please file a bug report on SF!) > > I tried, but it looks like SourceForge's bug tracker is broken at the > moment. I'll try again later. > >> Also, the warning should be a style-warning (since the allow-other-keys >> argument is a constant and we know for a fact that there will be no >> problems at run time). >> >> One might argue that the explicit :allow-other-keys should disable the >> warning altogether. I am not sure that this is the case. > > A style-warning would be better, but I'd prefer no warning. To me, > :allow-other-keys at the call site is a way for me to explicitly pass a > keyword I *know* is not part of the interface in some contexts, but have > the implementation accept the code anyway. > > I can understand the desire to prevent typo-related bugs with a > style-warning, but I think passing :allow-other-keys signals a > willingness to take that chance. > >> If you want to avoid the warning, write >> >> (directory .... #+cmu :cmu-specific-option #+cmu cmu-specific-option-argument) > > In an ideal world (for me), there would be no need for reader > conditionals and also no warning. I think we must distinguish compilation time from run-time. Neither: (funcall (compile nil (lambda (args) (apply (function directory) "/" :allow-other-keys t args))) '(xach t)) nor: (funcall (compile nil (lambda (args) (apply (function directory) "/" args))) '(xach t :allow-other-keys t)) produce any warning. At compilation time, the style-warning sounds good. -- __Pascal Bourguignon__ http://www.informatimago.com/ A bad day in () is better than a good day in {}. |
From: Zach B. <xa...@xa...> - 2011-03-03 16:29:03
|
"Pascal J. Bourguignon" <pj...@in...> writes: > I think we must distinguish compilation time from run-time. Indeed, that's why I structured my example the way I did. > Neither: > > (funcall (compile nil (lambda (args) (apply (function directory) "/" > :allow-other-keys t args))) > '(xach t)) > nor: > > (funcall (compile nil (lambda (args) (apply (function directory) "/" args))) > '(xach t :allow-other-keys t)) > > produce any warning. > > > At compilation time, the style-warning sounds good. I disagree, for the reasons mentioned previously. Zach |
From: Sam S. <sd...@gn...> - 2011-03-03 17:48:48
|
> * Zach Beane <knpu@knpu.pbz> [2011-03-03 10:11:52 -0500]: > >> (Please file a bug report on SF!) > > I tried, but it looks like SourceForge's bug tracker is broken at the > moment. I'll try again later. wfm. please login first. -- Sam Steingold (http://sds.podval.org/) on CentOS release 5.3 (Final) X http://jihadwatch.org http://camera.org http://truepeace.org http://iris.org.il http://openvotingconsortium.org http://www.memritv.org http://dhimmi.com Russian roulette: `dd if=/dev/urandom of=/dev/kmem bs=1 count=1 seek=$RANDOM` |
From: Zach B. <xa...@xa...> - 2011-03-03 17:58:36
|
Sam Steingold <sd...@gn...> writes: >> * Zach Beane <knpu@knpu.pbz> [2011-03-03 10:11:52 -0500]: >> >>> (Please file a bug report on SF!) >> >> I tried, but it looks like SourceForge's bug tracker is broken at the >> moment. I'll try again later. > > wfm. > please login first. Thanks, that changes the result from a 500 internal server error to the form. Bug report is here: https://sourceforge.net/tracker/?func=detail&aid=3198722&group_id=1355&atid=101355 Thanks, Zach |