Re[2]: Priorities
Hello John, Friday, February 03, 2006, 12:00:32 PM, you wrote: JM If we had a good standard poll/select interface in System.IO then we JM actually could implement a lot of concurrency as a library with no JM (required) run-time overhead. I'd really like to see such a thing get JM into the standard. Well, mainly it would just be a really useful thing JM to have in general. If others think it is a good idea I can try to come JM up with a suitable API and submit it to the repo. i have delayed answering to this letter until i announced my Streams library. now i can say that such API already exists - in terms of my library you need just to write an transformer that intercepts vGetBuf/vPutBuf calls and pass them to the select/poll machinery. so you can write such transformer just now and every program that uses Streams will benefit from its usage. Converting programs that use Handles to using Streams should be also an easy task. of course, Streams library is not some standard just now, and moreover - it is not compatible with JHC. the greatest problem is what i using type classes extensions available in GHC/Hugs what is not in H98 standard. so, i'm interested in pushing Haskell' to accept most advanced possible extensions in this area and, of course, in actual implementing these extensions in the Haskell compilers. alternative way to make Streams available to wider range of Haskell compilers is to strip support of streams working in monads other that IO. if you can make select/poll transformer, at least for testing purposes, that will be really great. -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
RE: Bang patterns, ~ patterns, and lazy let
I've updated the Wiki to add your strict proposal, but rather briefly. If you want to add stuff, send it to me and I'll add it. Meanwhile: | And as a consequence, it is no longer possible to transform a pair of | bindings into a binding of a pair. In Haskell 98, | | p1 = e1 | p2 = e2 | | is always equivalent to | | (~p1, ~p2) = (e1,e2) In your strict proposal, I'm sure you hope that the above pair would be equivalent to (p1,p2) = (e1,e2) which would be even nicer. But sadly I don't think it is, because that'd change the strongly connected component structure. Somehow that smells wrong. Simon ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Bang patterns, ~ patterns, and lazy let
Simon Peyton-Jones wrote: I've updated the Wiki to add your strict proposal, but rather briefly. If you want to add stuff, send it to me and I'll add it. Meanwhile: | And as a consequence, it is no longer possible to transform a pair of | bindings into a binding of a pair. In Haskell 98, | | p1 = e1 | p2 = e2 | | is always equivalent to | | (~p1, ~p2) = (e1,e2) In your strict proposal, I'm sure you hope that the above pair would be equivalent to (p1,p2) = (e1,e2) which would be even nicer. But sadly I don't think it is, because that'd change the strongly connected component structure. Somehow that smells wrong. Simon What have you got in mind? ANY tupling of bindings may change the SCC structure, and hence the results of type inference--I'm taking that as read. But that still leaves the question of whether the dynamic semantics of the program is changed. Let's assume for the time being that all bindings carry a type signature--then the SCC structure is irrelevant, isn't it? Or am I missing something here? I'm under the impression that the *dynamic* semantics of p1 = e1 p2 = e2 *would* be the same as (p1,p2) = (e1,e2) under my strict matching proposal. I don't see how the SCC structure can affect that. John ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Scoped type variables
On Tue, Feb 07, 2006 at 08:15:19PM +, Ben Rudiak-Gould wrote: Simon PJ thinks that Haskell' should include scoped type variables, and I tend to agree. But I'm unhappy with one aspect of the way they're implemented in GHC. What I don't like is that given a signature like x :: a - a there's no way to tell, looking at it in isolation, whether a is free or bound in the type. A second problem with GHC's provision of scoped type variables is the confusing variety of ways of doing it. Some of them address the same problem that partial type signatures aim at (e.g. by allowing signatures for parts of arguments and/or the result of functions). Partial type signatures may well not be ready in time for Haskell', but we should still try to avoid overlap. I think we should do the simplest thing that could possibly work, and then see if we really need more. By work, I mean a compatible extension of H98 that makes it possible to add type signatures for local bindings (which isn't always possible in H98). How about: * no implicit binding of type variables: to bind, use forall. * pattern type annotations allowed only at the top level of pattern bindings and lambda arguments (not on sub-patterns or arguments of function bindings). * no result type annotations (except on pattern bindings, where they're equivalent to top-level pattern type annotations). ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
RE: Scoped type variables
| I think we should do the simplest thing that could possibly work, | and then see if we really need more. By work, I mean a compatible | extension of H98 that makes it possible to add type signatures for | local bindings (which isn't always possible in H98). How about: | | * no implicit binding of type variables: to bind, use forall. | | * pattern type annotations allowed only at the top level of pattern |bindings and lambda arguments (not on sub-patterns or arguments of |function bindings). | | * no result type annotations (except on pattern bindings, where they're |equivalent to top-level pattern type annotations). | I agree with the simplest thing plan. But if HPrime is to include existentials, we MUST have a way to name the type variables they bind, otherwise we can't write signatures that involve them. Stephanie and Dimitrios and I are working on this scheme: * Scoped type variables stand for type *variables*, not types. * Type variables are brought into scope only by one of two ways: a) The forall'd variables of a declaration type signature f :: forall a b. type f x y = e b) A pattern type signature may bring into scope a skolem bound in the same pattern: data T where MkT :: a - (a-Int) - T f (MkT (x::a) f) = ... The skolem bound by MkT can be bound *only* in the patterns that are the arguments to MkT (i.e. pretty much right away). The idea is that scoped type variables can be bound either at, or very close to, the point at which they are actually abstracted. This is a good topic to debate. S+D+I will try to put forth a set of rules shortly. Simon ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Re[2]: Tuple-like constructors
Robert Dockins [EMAIL PROTECTED] writes: instance (Bin a,Bin b,Bin c,Bin d) = Bin (a,b,c,d) See the problem? Sooner or later (probably sooner) I'll get tired of typing. I have to write down an 'instance' declaration for each value of n. Clearly this can't generalize to all n. There has been a suggestion that the 'deriving' mechanism be de-coupled from the datatype declaration. Together with a generic default definition, that means you could write something like deriving Bin for () and hence not need to write the tedious instance header yourself, since the compiler can easily infer it. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Priorities
On Wed, Feb 08, 2006 at 12:03:54PM +0300, Bulat Ziganshin wrote: JM If we had a good standard poll/select interface in System.IO then we JM actually could implement a lot of concurrency as a library with no JM (required) run-time overhead. I'd really like to see such a thing get JM into the standard. Well, mainly it would just be a really useful thing JM to have in general. If others think it is a good idea I can try to come JM up with a suitable API and submit it to the repo. i have delayed answering to this letter until i announced my Streams library. now i can say that such API already exists - in terms of my library you need just to write an transformer that intercepts vGetBuf/vPutBuf calls and pass them to the select/poll machinery. so you can write such transformer just now and every program that uses Streams will benefit from its usage. Converting programs that use Handles to using Streams should be also an easy task. I was actually asking for something much more modest, which was the routine needed to pass them to the select/poll machinery. but yeah, what you say is one of my expected uses of such a routine. Once a standard IO library settles down, then I can start working on the exact API such a routine would have. of course, Streams library is not some standard just now, and moreover - it is not compatible with JHC. the greatest problem is what i using type classes extensions available in GHC/Hugs what is not in H98 standard. so, i'm interested in pushing Haskell' to accept most advanced possible extensions in this area and, of course, in actual implementing these extensions in the Haskell compilers. alternative way to make Streams available to wider range of Haskell compilers is to strip support of streams working in monads other that IO. Don't take the absence of a feature in jhc to mean I don't like or want that feature. There are a lot of things I don't have but that I'd definitly want to see in the language simply because I was only shooting for H98 to begin with and was more interested in a lot of the back end stuff. You should figure out the nicest design that uses just the extensions needed for the design you want. it could help us decide what goes into haskell-prime to know what is absolutely needed for good design and what is just nice to have. if you can make select/poll transformer, at least for testing purposes, that will be really great. Yeah, I will look into this. the basic select/poll call will have to be pretty low level, but hopefully it will allow interesting higher level constructs based on your streams or an evolution of them. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
exported pattern matching
Sometimes I'd like to use a smart constructor but have pattern matching as well. There has been talk elsewhere of allowing export of data constructors for /matching/ but not for /construction/: module One- data Picky a = Nil | One a picky x = if some_complex_thing x then One x else Nil module Two- f x = g $ picky x g Nil y = y g (One x) y = x h Nil = One True - I'd like for the function g to be fine and the function h to get a complaint like error: no constructor 'One' or, even better, error: 'One' only works in pattern matching Jim ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re[2]: Java-like
Hello Ian, Wednesday, February 08, 2006, 9:28:51 PM, you wrote: nonrecursive let in Haskell so that I could write let x = ...x... in ..., IL I would argue that the language should discourage variable shadowing, so IL that shadow warnings can be used to find bugs. i use such shadowing to change variable meaning in a part of code -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
