guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fluids vs parameters: which API is better?


From: BT Templeton
Subject: Re: Fluids vs parameters: which API is better?
Date: Sun, 24 Jul 2011 10:52:04 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

Andy Wingo <address@hidden> writes:

> Hi Mark,
>
> On Mon 18 Jul 2011 23:57, Mark H Weaver <address@hidden> writes:
>
>> From an efficiency perspective, it is much more straightforward and
>> reliable for a compiler to understand what operation is done by
>> (fluid-ref x) than (x).
>
> This is true.
>
>> More generally, from a perspective of semantics and security, it is
>> preferable for a program to apply a known operation (e.g. `fluid-ref')
>> to some data, than to call the `data' as a procedure and ask it to do
>> something.  Yes, there are cases when the flexibility of message passing
>> is worthwhile, but there are significant disadvantages.  Once you do
>> this, you can no longer analyze the behavior of a procedure without
>> knowing a lot about the data itself.
>
> Here I disagree.  From the perspective of semantics and security, it's
> important to be able to make assertions as to the type of value returned
> by a procedure -- that (current-input-port) returns a port.  The same
> goes for (current-language) and all the other dynamic parameters.
> Parameters allow us to make guarantees like that.

Why is it uniquely useful to be able to make these guarantees for
dynamically-bound values? Static/soft typing would be more generally
useful than parameters.

Also, I'd prefer it if parameters used a type predicate or a type
specifier object instead of a conversion procedure. ISTM that the
current interface conflates type checking and coercion.

-- 
Inteligenta persono lernas la lingvon Esperanton rapide kaj facile.
Esperanto estas moderna, kultura lingvo por la mondo. Simpla, fleksebla,
belsona, Esperanto estas la praktika solvo de la problemo de universala
interkompreno. Lernu la interlingvon Esperanton!




reply via email to

[Prev in Thread] Current Thread [Next in Thread]