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
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
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 i've
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. I'm
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 required
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
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
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-MUTVAR
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/=0 || y/=0
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 too
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 can be
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
(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 -
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
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
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
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:
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 as
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
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
20 matches
Mail list logo
