This page is part of the web mail archives of SRFI 67 from before July 7th, 2015. The new archives for SRFI 67 contain all messages, not just those from before July 7th, 2015.
Sebastian Egner <sebastian.egner@xxxxxxxxxxx> writes:
> Maybe you already made it to the next level ("options suck").
That's a succinct way of putting it. :-)
> + a lot fewer procedure names to remember
Sure there are a lot less *names* to remember. But you still have to
remember the *operations*, which takes up the conceptual space in your
brain. Moreover, with overloading, you need to remember the calling
conventions. As far as looking up things goes, the same holds:
- If you're trying to find out the name for a given operation, it
doesn't matter if different operations have different names.
- If you're trying to find out what a given name does, you have less
names in the index, but you need to sub-index by the calling
convention.
I'd say having different names eases the burden on your brain (on
mine, anyway). That's why it's better if optional arguments are
purely optional arguments with default values.
> Let's be concrete: How would you set it up the interface?
> Would your design still qualify as a replacement for < = char<?
> etc. of R5RS? Are you really willing to pay the price of writing
> (<? integer-compare x y) everywhere, or are there other solutions?
Solution #1:
Ditch the curry overload; make the comparison an optional last
argument.
Solution #2:
Make the comparison a mandatory first argument.
I would like either of them better than the current situation.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla