On Mon, Jun 11, 2012 at 9:34 PM, Ray Dillinger <[email protected]> wrote:
> > Honestly, I wouldn't even go that far. I think that a promise made > with an immediate value should always be distinguishable from the > immediate value, and that "auto-forcing" - ever - is to muddy the > language semantics. It has to be understood as allowing convenience > to trump formality. This is not necessarily bad, but it becomes bad > if you leave no way to get at the formal primitives. > > I am a big fan of simplistic, deterministic primitives. I have > nothing against convenience functions that have additional stuff > built in, but they aren't primitives. If you make a '+' function > that forces promises by default that's okay for most uses, but it > isn't a primitive. > > Sooner or later someone will need a '+' function that does *NOT* > force promises, or that keeps track of the number of promises it > forces and the time it spends forcing them, or something, and > you've got to be careful to leave a way to define one. And if > the simplest way is some ridiculous construction involving the > exception mechanism and a monitor on the "force" procedure that > gets turned on and off by a dynamic-wind around the '+' procedure, > or something like that, then I think you have the kind of baroque > workaround that indicates you've made a mistake in defining your > primitives. > Thanks for your convincing and well written argument, I mostly agree with it. My only objection is that creating a promise out of some immediate value seems pointless. That's why I accept it to evaluate to that immediate rather than a promise. But I understand and appreciate your point. Best regards, -- Emmanuel
_______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
