Iavor Diatchki wrote:
- option 3: GHC 6.6 style rank-N types. This one I am less familiar
with but here is my understanding:
* Based on "Boxy types: type inference for higher-rank types and
impredicativity"
* Impredicative (type variables may be bound to schemes)
* Sometimes we c
Hello,
(Apologies for the two emails, I accidentally hit the send button on
my client before I had finished the first e-mail...)
* Rank-2 vs Rank-n types. I think that this is the most important
issue that we need to resolve which is why I am placing it first :-)
Our options (please feel free to
Hello,
Thanks to everyone who took time to comment on my notes. My & Isaac's
previous post spawned a few separate discussions so I though I'd send
a separate message to summarize the status of what has happened so far
with regard to polymorphic components.
* Rank-2 vs Rank-n types. I think that
On 2007 Feb 1, at 4:53 PM, Malcolm Wallace indited:
I find the "program-generated code" argument rather weak. In that
past it was used to justify all kinds of minor horrors like excess
commas in lists and so on.
...
That only encourages humans to use sloppy practices in hand-written
code a
On Thu, Feb 01, 2007 at 04:51:39PM +, David House wrote:
> I think that's too safe-looking. Anything that translates to something
> involving unsafe* should be tagged with 'unsafe' somewhere as well.
> Also, as unsafe* is still compiler specific, I think a pragma is
> probably most appropriate:
Malcolm Wallace wrote:
If you restrict yourself to programs entirely written by humans, I
agree completely. But if you consider programs written by programs
(say Template Haskell to be specific, but it could be via many other
means), such degenerate types occur rather often.
I find the "pr
Malcolm Wallace wrote:
I find the "program-generated code" argument rather weak.
One might satisfy both camps by having a compiler flag to allow
auto-generated ugliness.
--
Ashley Yakeley
___
Haskell-prime mailing list
Haskell-prime@haskell.org
h
On 1 Feb 2007, at 21:31, Jacques Carette wrote:
Stephanie Weirich wrote:
I don't think we want to allow types like:
forall . Int or forall a b. Int
These types are mostly bugs. Furthermore, rejecting them doesn't
limit expressiveness:
If you restrict yourself to programs entire
Hello Jacques,
Friday, February 2, 2007, 12:31:22 AM, you wrote:
> If there were a standard library of type-simplifiers, that could
> preprocess "forall a b. Int" to "Int", I again would be fine with only
> allowing Int.
i think that we shouldn't reduce reliability in order to make tools
author
Hello David,
Friday, February 2, 2007, 12:14:05 AM, you wrote:
>> Why is this unsafe? What could go wrong?
> ref :: IORef [a]
> ref <- newIORef []
it could be easily fixed by disallowing polymorphic types here. if
someone really need polymorphism, he can continue to use old trick
--
Best rega
Stephanie Weirich wrote:
I don't think we want to allow types like:
forall . Int or forall a b. Int
These types are mostly bugs. Furthermore, rejecting them doesn't limit
expressiveness: they should both be "equivalent" to Int, so user could
just write Int. I can't really think ho
(CCing the list as this is of general concern.)
On 01/02/07, Yitzchak Gale <[EMAIL PROTECTED]> wrote:
Why is this unsafe? What could go wrong?
It could segfault due to the type safety properties that unsafePerformIO breaks:
import System.IO.Unsafe
import Data.IORef
ref :: IORef [a]
ref <- ne
Here are some of my comments to Iavor's proposals:
> Notation for Schemes
> PROPOSAL: be liberal:
> allow empty quantifier lists
> allow variables that are not mentioned in the body of a type (but
warn)
> allow predicates that do not mention quantified variables (but warn?)
For the reasons
On Thu, Feb 01, 2007 at 09:12:02AM -0800, David Roundy wrote:
> On Wed, Jan 31, 2007 at 09:28:30PM +0300, Bulat Ziganshin wrote:
> > Next, i don't think that ability to use any functions in view buy
> > something important. pattern guards can be used for arbitrary
> > functions, or such function ca
On 2007 Feb 1, at 11:51 AM, David House indited:
On 01/02/07, Bulat Ziganshin <[EMAIL PROTECTED]> wrote:
there is common proposal that i support. example of its use:
i :: IORef Int
i <- newIORef 1
with a semantics equivalent to current use of usafePerformIO
+INLINE in GHC
I think that's to
On Wed, Jan 31, 2007 at 09:28:30PM +0300, Bulat Ziganshin wrote:
> Wednesday, January 31, 2007, 7:12:05 PM, you wrote:
> >> data Coord = Coord Float Float
> >> view of Coord = Polar Float Float where
> >> Polar r d= Coord (r*d) (r+d)-- construction
> >> Coord x y | x
On Thu, 1 Feb 2007, David House wrote:
> I think that's too safe-looking. Anything that translates to something
> involving unsafe* should be tagged with 'unsafe' somewhere as well.
> Also, as unsafe* is still compiler specific, I think a pragma is
> probably most appropriate:
>
> {-# GLOBAL-MUTV
On 01/02/07, Bulat Ziganshin <[EMAIL PROTECTED]> wrote:
there is common proposal that i support. example of its use:
i :: IORef Int
i <- newIORef 1
with a semantics equivalent to current use of usafePerformIO+INLINE in GHC
I think that's too safe-looking. Anything that translates to something
Hi Bulat,
You wrote:
there is common proposal that i support. example of its use:
i :: IORef Int
i <- newIORef 1
with a semantics equivalent to current use of usafePerformIO+INLINE in GHC
Are the details of this posted anywhere? Is there a ticket
for this?
I assume you mean that this will w
Hello Arie,
Thursday, February 1, 2007, 2:08:33 PM, you wrote:
> The ability to reason about your program is vital in about every part of
> the programming cycle, and is one of the things that make Haskell work.
when i say what i don't use reasoning, you can trust me :)
> Another of those thing
Hello Yitzchak,
Thursday, February 1, 2007, 1:13:48 PM, you wrote:
there is common proposal that i support. example of its use:
i :: IORef Int
i <- newIORef 1
with a semantics equivalent to current use of usafePerformIO+INLINE in GHC
--
Best regards,
Bulatmailto:[
Taral wrote:
On 1/31/07, Conor McBride <[EMAIL PROTECTED]> wrote:
So, as far as Haskell' is concerned, I'd favour forbidding non-empty
cases, but only because I favour having some more explicit syntax for
empty cases, further down the line.
I see nothing wrong with "case x of {}", with require
Bulat Ziganshin
<[EMAIL PROTECTED]>
writes:
> > Yes - you've reiterated Wadler's original design, with
> > an automatic problems with equational reasoning raised
> > by this approach.
>
> ok, i can live without it. i mean reasoning :)
That's probably not good, but I don't follow that problem
yet
Bulat Ziganshin wrote:
> ok, i can live without it. i mean reasoning :)
>
> i guess that anything more complex than Turing machine makes reasoning
> harder. 18 years ago Haskell fathers chosen to simpilfy language in
> order to make reasoning easier. may be now we can change this
> decision? that
The trick of controlling allocation of external
resources by using NOINLINE, unsafePerfromIO,
and IORef to create global variables has become
an indispensable technique in Haskell. It seems to
work well enough with most current compilers.
However, it is well known that the semantics of
NOINLINE a
Hello J.,
Thursday, February 1, 2007, 1:36:33 AM, you wrote:
> Yes - you've reiterated Wadler's original design, with an automatic
> problems with equational reasoning raised by this approach.
ok, i can live without it. i mean reasoning :)
i guess that anything more complex than Turing machine
26 matches
Mail list logo