2017-07-26 2:48 GMT+02:00 Shiro Kawai <xxxxxx@gmail.com>:
On Tue, Jul 25, 2017 at 2:09 AM, Panicz Maciej Godek <xxxxxx@gmail.com> wrote:
I did trace the suggestions for using _ instead of <>, but I failed to find any rationale for preferring <> over _ -- neither in the SRFI itself,
nor in the discussion archive.

You're right that there's no trace why '_' is dropped over '<>'.  I don't recall why either.
I do have one reason though.  I frequently use '_' as an argument in lambda list when I don't care what is passed, e.g. (map (lambda (_) #t) lis).   But inside such functions I won't be able to use (is _ < x) for the '_' here won't match the literal '_'. 

I see the problem now. As a matter of fact, I've also used _ in this role sometimes, but it didn't occur to me that it will shadow the syntactic keyword.

It shouldn't be a problem to modify the convention slightly, though, and use, say, '__' to name a single ignored argument, but I agree that this can be error prone.

Perhaps more robust is to provide meaningful names to ignored arguments, and perhaps suffix them with /ignored or /unused mark, as in

(lambda (width height weight/unused) ...)

but I agree that's not always plausible.

It is indeed a problem that the users of SRFI-156 would need to take into account that they can accidentally bind the syntactic keyword.
But again, I think this problem appears in other contexts too. It happens to me sometimes that I accidentally bind the names like "list" or "values"
 
It isn't a showstopper; after all, It can happen for any other literal macro keywords such as else or =>.  We do need to consider the convention, though.  It's less frequent that someone accidentally use <> as a parameter variable.

You have a point. But it may be the case that someone wishes to use <> to mean inequality. I think that the use (is <> <> 10) would look rather puzzling.
 

If we go with '_' as a placeholder, a better future direction would be to establish a convention to use _ as a syntactic keyword to show don't care argument in the lambda list.  E.g. make (lambda (x _ _) something) valid if you only use the first argument.  Then, as far as srfi-156 definition imports the same syntactic keywords, shadowing won't be a problem.


I kinda like this idea, but I think it is risky to treat any particular symbol as special in the context of lambda. It is sufficient that this convention manifests itself in the context of pattern matching