Email list hosting service & mailing list manager

Don't be irritated by silly mistakes in draft #1 taylanbayirli@xxxxxx (08 Sep 2015 21:43 UTC)
Re: Don't be irritated by silly mistakes in draft #1 John Cowan (09 Sep 2015 01:10 UTC)
Re: Don't be irritated by silly mistakes in draft #1 taylanbayirli@xxxxxx (09 Sep 2015 14:19 UTC)
Re: Don't be irritated by silly mistakes in draft #1 John Cowan (09 Sep 2015 15:26 UTC)
Re: Don't be irritated by silly mistakes in draft #1 taylanbayirli@xxxxxx (09 Sep 2015 16:28 UTC)
Re: Don't be irritated by silly mistakes in draft #1 John Cowan (14 Sep 2015 02:02 UTC)

Don't be irritated by silly mistakes in draft #1 taylanbayirli@xxxxxx 08 Sep 2015 21:43 UTC

I've been making hasty changes, as usual, after I already pointed people
to "draft 1" in my email.  I should get rid of that habit.  Now it
contains some minor mistakes in the "R6RS additions summary" at the top
and "Implementation" at the bottom.  These are fixed on the meanwhile
and will be in draft #2.

On the meanwhile I also scrapped the weird overloaded semantics for
hashtable-ref and separated them into hashtable-lookup (replacing the
old hashtable-lookup that used to take procedures to call; now it just
returns those two result/found? values).  I would nevertheless be
interested in people's comments on the "weird overloaded semantics" so
I'll wait a bit before making a pull request for draft #2.

I decided against that overloading especially because it's very
unconventional and will likely confuse tools that work with meta-data
about code, which are likely to expect a clear "signature" for every
procedure.  Some human minds might also work similarly.  And lastly, it
would be annoying to get a values mismatch error at run-time when you
could have gotten a wrong-number-of-arguments warning at compile-time,
when you simply forgot to pass the 'default' argument in your code.

Taylan