This page is part of the web mail archives of SRFI 50 from before July 7th, 2015. The new archives for SRFI 50 contain all messages, not just those from before July 7th, 2015.
>>>>> "Thomas" == Thomas Bushnell <tb@xxxxxxxxxx> writes: Thomas> felix <felix@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> writes: >> Not only that. It allows the *implementor* maximal flexibility, which >> I consider more important in this case. Allowing a form to be a function >> may tempt users to do weird stuff like taking it's address, etc. Thomas> That's exactly the flexibility I thought we should give the user. SRFI 50 indeed generally subscribes to the view that it tries to give the implementor maximal flexibility, mainly because of all the implementations that are already out there, and that we'd like to be amenable to it. I'll admit it's not the only reasonable view to take, but it's the one represented in SRFI 50. A strong reason to prefer C macros over functions in this kind of settings is that functions live in a global namespace, while the macros (can) live in a local one. In principle, macros allows, say, hooking up two Scheme systems, while functions wouldn't. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla