John Meacham <[EMAIL PROTECTED]> writes:
> * Foreign concurrent calls, handle IO, and all IO actions that directly
> interact with the world outside the current process all must be
> yield-points. (in addition to any yield-points implied by the progress
> guarentee)
If an IO call includes a
Ashley Yakeley <[EMAIL PROTECTED]> writes:
> Is there a ticket for this? I would prefer that unsafePerformIO and
> friends not be part of the standard.
I would prefer otherwise. Every implementation supports it, which
proves that it's useful. And it's no less unsafe than FFI.
--
__("<
John Meacham <[EMAIL PROTECTED]> writes:
> Checking thread local state for _every_ foregin call is definitly
> not an option either. (but for specificially annotated ones it is
> fine.)
BTW, does Haskell support foreign code calling Haskell in a thread
which the Haskell runtime has not seen befor
Taral <[EMAIL PROTECTED]> writes:
> fast - takes very little time to execute
I was thinking about "quick". It seems to be less literal about speed
if my feeling of English is good enough; the effect is indeed not just
speed.
They fit both as a description of the foreign function, and as a
reques
John Meacham <[EMAIL PROTECTED]> writes:
> I object to the idea that concurrent calls are 'safer'. getting it
> wrong either way is a bug. it should fail in the most obvious way
> rather than the way that can remain hidden for a long time.
I wouldn't consider it a bug of an implementation if it m
John Meacham <[EMAIL PROTECTED]> writes:
> forkIO action = forkIO' action' where
> action' = do
> myThreadId >>= onExit . throwTo PleaseExit
> action
This would be a memory leak: even after the thread finishes,
its onExit handler would remain registered.
"Simon Marlow" <[EMAIL PROTECTED]> writes:
> How does "cancelling" a thread differ from sending it an exception?
It doesn't. By cancelling I mean just sending a particular async
exception.
> Can a thread be GC'd without being sent an exception first?
Yes, but I'm now changing this.
Unfortunate
"Simon Marlow" <[EMAIL PROTECTED]> writes:
> That sounds hard to program with - surely you want to stop the program
> in order to clean up? Otherwise the program is going to continue
> working, generating more exit handlers, and we might never get to exit.
Here is how I've done it in Kogut:
An
"Simon Marlow" <[EMAIL PROTECTED]> writes:
> BTW, I just realised a better way to express block. If block is
> supposed to count nesting, then we have a problem that you can still
> unblock exceptions even within a block by using sufficient number of
> unblocks, so the right way is to give block
"Simon Marlow" <[EMAIL PROTECTED]> writes:
> I think it's unnecessary to treat signals in the way you do - you're
> assuming that a signal interrupts the current thread and runs a new
> computation (the signal handler) on the same stack, completely blocking
> the interrupted thread until the signa
"Simon Marlow" <[EMAIL PROTECTED]> writes:
> I'm not sure whether asynchronous exceptions should be in Haskell'.
> I don't feel entirely comfortable about the "interruptible operations"
> facet of the design,
I designed that differently for my language. There is a distinct
"synchronous mode" wher
"Simon Marlow" <[EMAIL PROTECTED]> writes:
> I think it would be a mistake to relegate concurrency to an addendum;
> it is a central feature of the language, and in fact is one area where
> Haskell (strictly speaking GHC) is really beginning to demonstrate
> significant advantages over other langu
I think the following kinds of foreign calls wrt. concurrency are
sensible:
1. Other Haskell threads might get paused (but don't have to).
Examples: sqrt, qsort (we assume that qsort never needs a long time
between calls to the comparison function, so there is no need to
allow other thre
Malcolm Wallace <[EMAIL PROTECTED]> writes:
> But if contexts-on-datatypes worked correctly,
>
> data Set a = Ord a =>
>
> then even the "real" map from Data.Set:
>
> map :: (Ord a, Ord b) => (a -> b) -> Set a -> Set b
>
> could be an instance method of Functor.
fmap ($0) . fmap cons
"Claus Reinke" <[EMAIL PROTECTED]> writes:
> you mean as in "public static void main(String[] args) { ..}"
> instead of "main args = .."?-) there are such languages, and
> I'm happy to say Haskell isn't one of them!
In my language Kogut the default everywhere (modules, objects) is
public. I don't
"Simon Marlow" <[EMAIL PROTECTED]> writes:
> The main difference is that I'm doing away with parentheses, commas, and
> export specifiers, and using layout and full declaration syntax instead.
> (I don't really want to discuss this very rough idea any more though,
> it's just a distraction, and I'
Philippa Cowderoy <[EMAIL PROTECTED]> writes:
> Myself I'm of the view transformational patterns (as described in
> http://citeseer.ist.psu.edu/299277.html) are more interesting -
> I can't help wondering why they were never implemented?
Ah, so I wasn't first in implementing them in my language :
Ben Rudiak-Gould <[EMAIL PROTECTED]> writes:
>>> that i want to say is what the first variant allows to define type of
>>> 'x' in such way that the only Show-specific operations are allowed,
>> Why?
>
> Parametricity, what else? I'd much rather pass my precious String to a
> function of type [a] -
Bulat Ziganshin <[EMAIL PROTECTED]> writes:
> that i want to say is what the first variant allows to define type of
> 'x' in such way that the only Show-specific operations are allowed,
Why? A class is not a type. Haskell has no non-trivial subtyping.
If it's always a string, then it can be treat
In my language Kogut there are only pairs, and larger tuples are
expressed by nested pairs (biased in the same direction as lists,
without an end marker of course).
I wonder whether the performance difference is really that
significant. Short tuples seem to be much more common. Anyone could
gather
Haskell standard should get a strict foldl: either under some new
standard name (foldl' is most common), or just replacing foldl.
Is there a real-life case where a lazy foldl is desirable? I don't
mean a constructed artificial example, I know they exist, but
something which is really used.
Curren
Ben Rudiak-Gould <[EMAIL PROTECTED]> writes:
> I don't like the idea of using U+, because it looks like an ASCII
> control character, and in any case has a long tradition of being used
> for something else. Why not use a code point that can't result from
> decoding a valid UTF-8 string? U+
Axel Simon <[EMAIL PROTECTED]> writes:
> The solution of representing a file name abstractly is also used by
> the Java libraries.
I think it is not. Besides using Java UTF-16 strings for filenames,
there is the File class, but it also uses Java strings. The
documentation of listFiles() says that
Bulat Ziganshin <[EMAIL PROTECTED]> writes:
> if my idea was incorporated in Haskell, this change don't require
> even changing signatures of most functions working with arrays -
> just Array type become Array interface, what a much difference?
What would 'Eq -> Eq -> Ord -> Bool' mean?
'(Eq a, E
"Simon Marlow" <[EMAIL PROTECTED]> writes:
> Summary: 2 programs failed to compile due to type errors (anna, gg).
> One program did 19% more allocation, a few other programs increased
> allocation very slightly (<2%).
I wonder how many programs would fail to compile if local identifier
bindings w
"Simon Marlow" <[EMAIL PROTECTED]> writes:
> I've always liked the idea of saying 'class C' or 'type T' in
> import/export lists.
Type signatures too should be allowed in export lists.
--
__("< Marcin Kowalczyk
\__/ [EMAIL PROTECTED]
^^ http://qrnik.knm.org.pl/~qrcza
"Simon Marlow" <[EMAIL PROTECTED]> writes:
> on balance, I like the way it is now.
An opinion to the contrary:
http://www.uclic.ucl.ac.uk/harold/srf/javaspae.html
"Importing packages: A brief example of design issues"
--
__("< Marcin Kowalczyk
\__/ [EMAIL PROTECTED]
^^
John Hughes <[EMAIL PROTECTED]> writes:
> By the way, you leave out a lot of type signatures too. Your Djinn
> module contains 29 declarations with type signatures--and 17
> without. The 17 are local, but local declarations are precisely
> those where, without the M-R, a lack of sharing would be m
Johannes Waldmann <[EMAIL PROTECTED]> writes:
> With the module system, we should make a distinction between declaring
>
> (1) that we want to use a module
> (2) how to bring the module's names into scope
Perhaps 'import' should be allowed anywhere among definitions.
--
__("< Marcin
29 matches
Mail list logo
