On Mon, Jun 11, 2012 at 11:09 PM, John Cowan <[email protected]> wrote:
> Emmanuel Medernach scripsit: > > > I agree that making a promise with an immediate value could evaluate > > to that immediate instead of creating a promise. > > That's where make-promise (formerly known as eager) comes in: it allows > you to return an object to your caller that is guaranteed to be a > promise. This allows promise-based APIs, where the caller knows he can > safely force the return value. > > Ok, thanks for reminding 'eager'. One minor point though, in the current draft it is said to be a procedure, but if it is it should evaluates its argument, making rather pointless to create a promise. I am now not sure if this is correct ? > > 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. > > Ticket #405 filed. > > Thanks ! > > 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. > > It does add a cost, but the cost is paid only by users of an > implementation (such as Kawa) that does auto-forcing. The impact > is actually quite shallow: it simply makes some functions mildly > polymorphic. > > I think that we should add in the report that applying primitives to promises is unspecified, just before the implicit forcing paragraph. One cannot rely on auto-forcing to write portable code. Kind regards, -- Emmanuel
_______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
