On Sun, 2009-04-26 at 10:42 +0200, Michele Simionato wrote: > On Sun, Apr 26, 2009 at 9:49 AM, Derick Eddington > <[email protected]> wrote: > > > > Explaining implementation-specific subtleties is not at all necessary > > for explaining *portable* macros, no mater how advanced. What I meant > > was: they can learn about implementation-specific differences if/when > > they care to know and are able to understand in relation to what they > > really need to know: portability. Explaining the differences isn't > > going to help them understand what I think they want to understand: how > > to make portable macros. > > But in order to explain how to write portable macros I have to talk about > the differences!
No you don't. You only have to talk about the portable intersection. Why do they need to know the differences if they're not going to use them? Unneeded info will distract them from absorbing what they need to know. > For instance, I must say why > > (import (only (my-module some-helper-function-to-be-used-in-a-macro))) > > works in Ikarus but does not work on PLT/Larceny, That's the type of thing they do not need to know to write portable libraries. Yes, I want implicit phasing to win, but right now, promoting portability is more important, especially to newcomers. > and I have to > explain phase separation. You do need to explain that. But just describe the portable intersection of phase separation. > > I would be angry at you if I learned you wasted my time with > > explanations of implementation differences which I don't need to know to > > make portable macros so that you could advance your understanding and > > practice your writing. I'd just want to know: there is not consensus > > about the entirety of library semantics and implementations have > > different extended semantics, but the portable semantics is enough to > > make many useful real-world things and that semantics is this and that. > > Do you think episode 20 is wasting time explaining non-significant > differences between implementations? I think it's wasting time explaining significant differences which aren't (yet, maybe never) relevant to the readers. > I do not think so, it is > explaining *conceptual* differences between different models of > execution, by keeping concrete implementations as practical examples. Why would I want to know about the differences if I just want an introduction to these crazy macros and how to make libraries which will work on all R6RS systems? I don't need to know. I only need to know what works for all the systems. > This is the attitude I want to keep even for future episodes: explain > the *conceptual* differences in the world the of possible design choices > for a module system (with phases, without phases, with single > instantiation, with multiple instantiation, etc); moreover, to show how the > different choices are realized in concrete implementations. Maybe I'm misunderstanding your target audience, but I wouldn't want to know about that stuff until I was *way* into Scheme. > I do want to make an exhaustive summary of the details of the > implementations: but I would like to give a sense of how large > is the spectrum of the possibilities. That's a noble desire, but I'm convinced it's way too much for people who are just being introduced to what they need to know for most purposes. I say that should be done in a different series. Maybe name that series: Adventures on Magic Mushrooms to the Bottom of the Rabbit Hole Where Your Brain Explodes. > Everybody who wants > to write portable code involving macros has to be aware > that the way his implementation of choice works is not the > only possible way. I entirely disagree. I didn't understand the differences for a while and I made lots of useful macros. All they need to know is the portable intersection -- how to make libraries work on all systems. Who cares if systems can do other non-portable things also (from their perspective). Don't even mention the non-portable things and talk as if the portable intersection is all that exists. We'll sell them on Ikarus later, and it will work better because there will be more amazement saved for later when they can appreciate it more ;-) -- : Derick ----------------------------------------------------------------
