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

Re: updating an icon label in DUIM


John Whittaker wrote:
[...]
>[...] I saw a recent
> post about timing of continuation based threads versus native OS threads in
> comp.lang.scheme.  The continuation based threads just ran rings around most
> native OS threads in terms of both speed and resource usage (as I recall),
> with the absolute worst being native Linux threads. 

 Linux is not known for having good threading support. And it seems that
Linux Torvald's beliefs in the rightness of the Linux process/thread design
is blocking efforts to change this. It would be interesting to
provide a similar comparison on other OSes.

 To be fair, it also seems that the comparison involved a user-level threading
package (continuations) vs. a kernel-level threading package. Those are different
beasts and the trade-offs are well documented in the CS literature. Was
the continuation package "fair" (guarantees that every thread will run eventually),
pre-emptive ? Could it take advantage of more than one processor ? How does it scale ?
These differences are easily overlooked when comparisons are not done with
high-end servers in mind. Testing on an OS supporting a M*N thread implementation
would also be interesting.

 I would however suggest that interoperating with pthread-based threading
libraries is a more reasonnable approach as soon as you want to mix Dylan with
any other language (which is likely to be "always" on OSes where libc
provides the only supported interface to the kernel).

> Another addition I would like to have: named parameters.  They're similar to
> keyword parameters, but you can use them for any parameter.  Ada has alway
> had them, and I think that's one of its simpler but nicer features.  It
> makes code both easier to read and write.

 I like named parameters (used them in PL/SQL quite a bit), especially
for their code documentating values. However how do you propose to reconcile
them with the usage of higher-level programming (e.g.: apply()) ?

 Do you revert to argument order when no parameter name is given ? What
if only some of the names are given (not in order) plus some unnamed parameters ?
etc.

 define method foo (bar => bar-value :: <integer>, baz => baz-value :: <integer>);

 foo (baz => 1, 2);       == ?
 curry(foo, baz => 1) (2) == ?
 curry(foo, bar => 1) (2) == ?

>  The problem I've had with keyword
> parameters is that it seems Dylan will accept ANY keyword in a call, even
> ones the called function doesn't know about.  For example, I could call
> oo( keyword-that-doesnt-even-exist: #f ) and foo would just ignore it.  I
> would prefer for the compiler to catch that error.

 I am guessing here that it is not an error if you did not declare the
generic for foo(). IIRC, the generic defined by default will accept
any keyword parameter. There isn't much the compiler can do, maybe a
Dylan lint could provide a warning though.

 Interesting ideas, keep them coming !

 Regards - Eric

-- 
Eric Gouriou                             egouriou@cup.hp.com
Follow-Ups: References: