[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Scheme-reports] Some comments after reading the r7rs public draft
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 06/11/2012 09:07 AM, Emmanuel Medernach wrote:
> On Mon, Jun 11, 2012 at 7:57 AM, Per Bothner <per@x>
> wrote:
>
>> In Kawa:
>>
>> Implicit forcing happens for: ...
>>
>
> I agree that making a promise with an immediate value could
> evaluate to that immediate instead of creating a promise. But in
> general I think that a promise have to be opaque until forced and
> that it is worth to have a disjoint type for promises and to be
> able to check if an object is a promise or not. IMHO for any other
> usage auto-forcing in primitives strongly sounds as being in the
> "it seems a good idea at that time" department: auto-forcing means
> that primitives have to check if something is a promise and forcing
> it in that case, adding this check add a cost and it has deep
> impact on the language semantics.
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.
Bear
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJP1khdAAoJEAOzWkqOibfNi2IH/2DGJm4DPtiYatTevmK2UbXv
fcyu4WYDDLb8ESptQGo17KkRYF14rc1Cz9r4C0jvTu+tCNEgkaYRJ1zf7S0NwemV
aeDNo0d33yXz1nNgZnnjYSOkeMolce4axq+x9pQ/B0yOctxn4AjC7R2+pou95rkA
+qbWYTgP9cWCKOvI6Ea37BmigZ0VbvXIqvQJzLRdkS6XNidu0APRPtFpyATKKmY4
7tTsVyngRYgFOA+dIuoOgpz6njFW5GLYe2yPN6sNXmVY9Eje+6CZeaqLUvHx47vD
X4jPqR2X3D643V18Tp53bWca60uUEFLphUWDNWjscanIrIfiyE8goigswt8E9Og=
=Y1ym
-----END PGP SIGNATURE-----
_______________________________________________
Scheme-reports mailing list
Scheme-reports@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports