Email list hosting service & mailing list manager


Re: Sockets Layer Counter Proposal Takashi Kato 13 Oct 2012 09:42 UTC

>> as or consistent names with well known names since R6RS has rename
>> import and export and R7RS will have the same mechanism.
>
> I don't get why rename import/export is related to my point.
> You're concerning that reading someone's code that renames
> identifiers defined in srfi?  Well, that happens anyway, but
> in reality most people don't bother to rename them.
If I understood your point correctly, the purpose to keep the name was
prevent double looking up. If it's not, sorry ignore the below.

Say if somebody creates a new abstract layer but just export some
variables with renamed names from the lower layer, because of the
author's preference or other APIs consistency. Then when the users
need to know what those variables mean, first they need to look up the
document for the abstract layer, if it just indicates the lower layers
document then they, again, need to look it up.

My point of view for this problem, there is no silver bullet for it,
even if we keep the name. In reality, people try to avoid this but not
100%, it's because in some context it might not be the same name but the
same behaviour, then proper solution could be rename it.

With this SRFI, this might not be applied since socket APIs are de-facto
standard.

--
_/_/
Takashi Kato
E-mail: xxxxxx@ymail.com