On Wed, Sep 26, 2007 at 11:25:30AM +0100, Tony Finch wrote:
> On Wed, 26 Sep 2007, Aaron Denney wrote:
> > It's true that time-wise there are definite issues in finding character
> > boundaries.
>
> UTF-16 has no advantage over UTF-8 in this respect, because of surrogate
> pairs and combining char
On 2007-09-27, Deborah Goldsmith <[EMAIL PROTECTED]> wrote:
> On Sep 26, 2007, at 11:06 AM, Aaron Denney wrote:
>>> UTF-16 has no advantage over UTF-8 in this respect, because of
>>> surrogate
>>> pairs and combining characters.
>>
>> Good point.
>
> Well, not so much. As Duncan mentioned, it's a
On 26 Sep 2007, at 7:05 pm, Johan Tibell wrote:
If UTF-16 is what's used by everyone else (how about Java? Python?) I
think that's a strong reason to use it. I don't know Unicode well
enough to say otherwise.
Java uses 16-bit variables to hold characters.
This is SOLELY for historical reasons,
I have often found myself wishing for a small extension to the syntax of
Haskell 'data' declarations. It goes like this:
data
=
| ...
|
+++where type =
type =
...
deriving
Even something like b
On 26 Sep 2007, at 8:32 am, Brian Hulley wrote:
Aha! but this is using section syntax which is yet another
complication. Hypothesis: section syntax would not be needed if the
desugaring order was reversed.
Binary operators have two arguments. That's why sections are needed.
This is one of
On 9/26/07, Graham Hutton <[EMAIL PROTECTED]> wrote:
> Salary will be within the range 25,134 - 32,796 pounds per year,
> depending on qualifications and experience. The post is available
> immediately, and will be offered on a fixed-term contract for 3 years.
I don't mean to diminish
On Wed, 2007-09-26 at 17:23 -0700, Dan Weston wrote:
> Not to beat a dead horse, but I wasn't suggesting to rename the fix
> function that everyone knows and loves:
>
> fix :: (a -> a) -> a
> fix f = let f' = f f' in f'
>
> I was merely trying to suggest that it would be wise to rename the
> fu
On Wed, 2007-09-26 at 18:50 -0400, Steven Fodstad wrote:
> Andrew Coppin wrote:
> > Chaddaï Fouché wrote:
> >> 2007/9/25, Andrew Coppin <[EMAIL PROTECTED]>:
> >>
> >>> This is why I found it so surprising - and annoying - that you can't
> >>> use
> >>> a 2-argument function in a point-free expres
On Wed, Sep 26, 2007 at 05:23:58PM -0700, Dan Weston wrote:
> It is this latter function which I suggested to be renamed limit, since
> it returns the limit (converged value) of f^n x, where n -> inf, and
> doesn't even have the same type or arity as the standard fix function.
>
> Somehow this (
On Sep 26, 2007, at 11:06 AM, Aaron Denney wrote:
UTF-16 has no advantage over UTF-8 in this respect, because of
surrogate
pairs and combining characters.
Good point.
Well, not so much. As Duncan mentioned, it's a matter of what the most
common case is. UTF-16 is effectively fixed-width f
Not to beat a dead horse, but I wasn't suggesting to rename the fix
function that everyone knows and loves:
fix :: (a -> a) -> a
fix f = let f' = f f' in f'
I was merely trying to suggest that it would be wise to rename the
function in http://haskell.org/haskellwiki/Reference_card that redefin
On Wed, 2007-09-26 at 17:09 -0500, Derek Elkins wrote:
> On Wed, 2007-09-26 at 14:12 -0700, Jonathan Cast wrote:
> > On Wed, 2007-09-26 at 11:43 -0700, Dan Weston wrote:
> > > It seems no one liked idea #2. I still think fix is the wrong name for
> > > this, maybe limit would be better.
> >
> > I
2007/9/26, Adrian Hey <[EMAIL PROTECTED]>:
> Chaddaï Fouché wrote:
> > There can't be alternatives, unsafeIO throw by the window most
> > guarantee that Haskell can give you and you have to provide them
> > yourself (with a proof of this part of your program), but it's
> > inherent to the nature of
Andrew Coppin wrote:
> Chaddaï Fouché wrote:
>> 2007/9/25, Andrew Coppin <[EMAIL PROTECTED]>:
>>
>>> This is why I found it so surprising - and annoying - that you can't
>>> use
>>> a 2-argument function in a point-free expression.
>>>
>>> For example, "zipWith (*)" expects two arguments, and yet
> jmuk's HaskellNet project from last year?
>
> http://darcs.haskell.org/SoC/haskellnet/HaskellNet/IMAP.hs
sweet! was there any documentation created for this? examples?
anything? have people tried to make this work with ssl/tls libs?
by the way there looks like some other gems in the haske
You could do this:
r :: IORef [a]
r = unsafePerformIO $ newIORef []
cast :: a -> b
cast a = unsafePerformIO $ do
writeIORef r [a]
x <- readIORef r
return $ head x
On 9/26/07, Dan Piponi <[EMAIL PROTECTED]> wrote:
>
> On 9/26/07, Lennart Augustsson <[EMAIL PROTECTED]> wrote:
> > Thin
On Wed, 2007-09-26 at 14:28 -0700, Dan Piponi wrote:
> On 9/26/07, Lennart Augustsson <[EMAIL PROTECTED]> wrote:
> > Things can go arbitrarily wrong if you misuse unsafePerformIO, you can even
> > subvert the type system.
>
> So...if I was in a subversive kind of mood (speaking hypothetically),
>
On 9/26/07, Lennart Augustsson <[EMAIL PROTECTED]> wrote:
> Things can go arbitrarily wrong if you misuse unsafePerformIO, you can even
> subvert the type system.
So...if I was in a subversive kind of mood (speaking hypothetically),
what would I have to do?
--
Dan
>
>
> On 9/26/07, Jorge Marques
On Wed, 2007-09-26 at 11:43 -0700, Dan Weston wrote:
> It seems no one liked idea #2. I still think fix is the wrong name for
> this, maybe limit would be better.
It calculates least fixed points. `fix' is as good a name as any.
`limit' is terrible; the argument to fix, a -> a, is neither a seq
Chaddaï Fouché wrote:
There can't be alternatives, unsafeIO throw by the window most
guarantee that Haskell can give you and you have to provide them
yourself (with a proof of this part of your program), but it's
inherent to the nature of the beast, it's what it do !
What about ..
http://www.
Peter Verswyvelen wrote:
> Paul L wrote:
>
>> We recently wrote a paper about the leak problem. The draft is at
>> http://www.cs.yale.edu/~hl293/download/leak.pdf. Comments are welcome!
> I'm trying to understand the following in this paper:
>
> (A) repeat x = x : repeat x
> or, in lambdas:
> (B
clawsie:
> an IMAP library might make for a good bounty project...i figure that
> you would indeed need to pay someone to untangle that standard
jmuk's HaskellNet project from last year?
http://darcs.haskell.org/SoC/haskellnet/HaskellNet/IMAP.hs
-- Don
___
++
POSTDOCTORAL RESEARCH FELLOW IN FUNCTIONAL PROGRAMMING
School of Computer Science
University of Nottingham, UK
Applications are invited for a 3-year postdoctoral research fel
an IMAP library might make for a good bounty project...i figure that
you would indeed need to pay someone to untangle that standard
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Peter Verswyvelen wrote:
Let me see if I understand this correctly. Since I'm an imperative
programmer, I'll try a bit of C++ here.
struct Cell : Value
{
Value* head;
Value* tail;
};
So in (A) and (B), a Cell c1 is allocated, and c1->head would be a
pointer to x, and c1->tail would be a point
Paul L wrote:
We recently wrote a paper about the leak problem. The draft is at
http://www.cs.yale.edu/~hl293/download/leak.pdf. Comments are welcome!
I'm trying to understand the following in this paper:
(A) repeat x = x : repeat x
or, in lambdas:
(B) repeat = λx → x : repeat x
This requires
Jorge Marques Pelizzoni wrote:
Hi, all!
This is a newbie question: I sort of understand what unsafePerformIO does
but I don't quite get its consequences. In short: how safe can one be in
face of it? I mean, conceptually, it allows any Haskell function to have
side effects just as in any imperati
It seems no one liked idea #2. I still think fix is the wrong name for
this, maybe limit would be better.
Dan Weston wrote:
One suggestion:
Section 3.6 defines a function "fix":
fix :: Eq x => (x -> x) -> x -> x
fix f x = if x == x' then x else fix f x'
where x' = f x
This confusingl
At Wed, 26 Sep 2007 22:11:12 +0700,
Peter Gammie wrote:
>
> Hello,
>
> Does anyone have a library for sending email from a Haskell program?
> I'd like something portable and cabalised.
>
> I note there is code in darcs to send email on Windows and UNIX-y
> systems, and also something in WASH
Things can go arbitrarily wrong if you misuse unsafePerformIO, you can even
subvert the type system.
On 9/26/07, Jorge Marques Pelizzoni <[EMAIL PROTECTED]> wrote:
>
>
> Hi, all!
>
> This is a newbie question: I sort of understand what unsafePerformIO does
> but I don't quite get its consequences.
On Wed, 26 Sep 2007, Don Stewart wrote:
And don't forget these three games that got mentioned during the week.
Octane Mech:
http://berlinbrowndev.blogspot.com/2007/09/octane-mech-opengl-haskell-based-mech.html
OpenGL Tetris:
http://myawesomeblag.blogspot.com/2007/03/opengl-tetris
On 2007-09-26, Tony Finch <[EMAIL PROTECTED]> wrote:
> On Wed, 26 Sep 2007, Aaron Denney wrote:
>>
>> It's true that time-wise there are definite issues in finding character
>> boundaries.
>
> UTF-16 has no advantage over UTF-8 in this respect, because of surrogate
> pairs and combining characters.
Thanks! That's very clarifying.
Bulat Ziganshin escreveu:
> Hello Jorge,
>
> Wednesday, September 26, 2007, 6:43:15 PM, you wrote:
>
>> This is a newbie question: I sort of understand what unsafePerformIO
>> does
>> but I don't quite get its consequences. In short: how safe can one be in
>> face
On 2007-09-26, Johan Tibell <[EMAIL PROTECTED]> wrote:
> On 9/26/07, Aaron Denney <[EMAIL PROTECTED]> wrote:
>> On 2007-09-26, Johan Tibell <[EMAIL PROTECTED]> wrote:
>> > If UTF-16 is what's used by everyone else (how about Java? Python?) I
>> > think that's a strong reason to use it. I don't know
2007/9/26, Adrian Hey <[EMAIL PROTECTED]>:
> Sebastian Sylvan wrote:
> > Rule of thumb: If your name isn't Simon*, you shouldn't use unsafePerformIO.
> If this is so, maybe it's time someone (who may or may not be called
> Simon) gave us a realistic alternative.
>
There can't be alternatives, unsaf
On Wed, 2007-09-26 at 18:46 +0100, Duncan Coutts wrote:
> In message <[EMAIL PROTECTED]> Jonathan Cast <[EMAIL PROTECTED]> writes:
> > On Wed, 2007-09-26 at 09:05 +0200, Johan Tibell wrote:
>
> > > If UTF-16 is what's used by everyone else (how about Java? Python?) I
> > > think that's a strong re
Hello Jorge,
Wednesday, September 26, 2007, 6:43:15 PM, you wrote:
> This is a newbie question: I sort of understand what unsafePerformIO does
> but I don't quite get its consequences. In short: how safe can one be in
> face of it?
i redirect you to http://haskell.org/haskellwiki/IO_inside
and "
In message <[EMAIL PROTECTED]> Jonathan Cast <[EMAIL PROTECTED]> writes:
> On Wed, 2007-09-26 at 09:05 +0200, Johan Tibell wrote:
> > If UTF-16 is what's used by everyone else (how about Java? Python?) I
> > think that's a strong reason to use it. I don't know Unicode well
> > enough to say otherw
paul.hudak:
> Henning Thielemann wrote:
> >On Wed, 26 Sep 2007, Peter Verswyvelen wrote:
> >>I hope I won't come to the conclusion that after one year learning
> >>the cool lazy functional programming language Haskell (which I want
> >>to use for making simple videogames in a clean way for teachi
On Wed, 2007-09-26 at 09:05 +0200, Johan Tibell wrote:
> > I'll look over the proposal more carefully when I get time, but the
> > most important issue is to not let the storage type leak into the
> > interface.
>
> Agreed,
>
> > From an implementation point of view, UTF-16 is the most efficient
On Tue, 2007-09-25 at 17:19 -0700, Dan Weston wrote:
> One suggestion:
>
> Section 3.6 defines a function "fix":
>
> fix :: Eq x => (x -> x) -> x -> x
>
> fix f x = if x == x' then x else fix f x'
> where x' = f x
>
> This confusingly differs in both type and meaning from the traditio
Sebastian Sylvan wrote:
Rule of thumb: If your name isn't Simon*, you shouldn't use unsafePerformIO.
If this is so, maybe it's time someone (who may or may not be called
Simon) gave us a realistic alternative.
:-)
Regards
--
Adrian Hey
___
Haskell
On Wed, Sep 26, 2007 at 11:43:15AM -0300, Jorge Marques Pelizzoni wrote:
>
> Hi, all!
>
> This is a newbie question: I sort of understand what unsafePerformIO does
> but I don't quite get its consequences. In short: how safe can one be in
> face of it? I mean, conceptually, it allows any Haskell
On 26/09/2007, Jorge Marques Pelizzoni <[EMAIL PROTECTED]> wrote:
>
> Hi, all!
>
> This is a newbie question: I sort of understand what unsafePerformIO does
> but I don't quite get its consequences. In short: how safe can one be in
> face of it? I mean, conceptually, it allows any Haskell function
Hello,
Does anyone have a library for sending email from a Haskell program?
I'd like something portable and cabalised.
I note there is code in darcs to send email on Windows and UNIX-y
systems, and also something in WASH (I know not what). Apparently
there is an SMTP server of some kind (
Hi, all!
This is a newbie question: I sort of understand what unsafePerformIO does
but I don't quite get its consequences. In short: how safe can one be in
face of it? I mean, conceptually, it allows any Haskell function to have
side effects just as in any imperative language, doesn't it? Doesn't
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Peter
> Verswyvelen
>
> I retrieved the latest version of YI, but I failed to compile
> it for Windows (GHC 6.6.1, and I got alex-2.1.0, haddock-0.8,
> HsColour, GTK, but not VTY)
>
> Before even pasting the error log, is it s
Hello folks,
Using Haddock 0.8, if I use haddock to document a module like this..
module MyModule
( module MyOtherModule
) where
import MyOtherModule hiding (foo)
I still get foo documented in the API for MyModule, despite the
fact that foo is not really made available by importing MyModule.
I retrieved the latest version of YI, but I failed to compile it for Windows
(GHC 6.6.1, and I got alex-2.1.0, haddock-0.8, HsColour, GTK, but not VTY)
Before even pasting the error log, is it supported in Windows?
I see that "make" gave the error "ghc.exe: unknown package: unix" and some
Super, really looking forward to GHC 6.8.1 then. Is it ready for primetime
on Windows?
Again, someone should really build an IDE around all these goodies, but yes,
that is a massive undertaking.
Cheers,
Peter
> The debugger in 6.8.1 can also help to track down loops and deadlocks.
Set
> -fbreak
Thanks for the nice feedback. I think I know enough to tackle these papers
now, although I'm sure it will take a while ;)
For a really simple and easy approach that only uses basic Haskell,
http://www.geocities.jp/takascience/haskell/monadius_en.html
This is a remake of the Konami game that was t
Gee you are right, how embarrasing. I mistakenly read the signature of ***
just above &&&, which is
(***) :: Arrow a ⇒ a b c → a b’ c’ → a (b,b’) (c,c’)
Now just to me sure I get it right, *** results in an arrow that has two
inputs (b,b') and two outputs (c,c')?
> (&&&) :: Arrow (~>) => (b ~> c
Henning Thielemann wrote:
On Wed, 26 Sep 2007, Peter Verswyvelen wrote:
I hope I won't come to the conclusion that after one year learning
the cool lazy functional programming language Haskell (which I want
to use for making simple videogames in a clean way for teaching),
I haven't tested it,
Stefan O'Rear wrote:
On Wed, Sep 19, 2007 at 10:24:24PM +0100, Neil Mitchell wrote:
Hi Peter,
So I grabbed ghc-6.7.20070824 (=the latest one for Windows I could find)
and the "extra-libs", compiled and installed the GLUT package (which I
needed), but when I compile my library, I get
Cou
Peter Verswyvelen wrote:
> Paul L wrote:
> A minor detail in your paper: on page 7, you represent *(d) sf1 &&& sf2 *as
> a big box taking one input and producing two outputs. The input is
> internally split using a Y. This does not seem consistent with the other
> boxes (e.g. *first *or *loop *i
Henning Thielemann wrote:
See also
http://www.haskell.org/haskellwiki/Things_to_avoid#Forget_about_quot_and_rem
OTOH, since quot/rem are the primitives in GHC, and div/mod are implemented
in terms of them, then you might prefer to use quot/rem all other things
being equal.
Cheers,
That looks nice, but HGL does not work on Windows anymore does it?
Thanks,
Peter
-Original Message-
From: Henning Thielemann [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 26, 2007 11:44 AM
To: Peter Verswyvelen
Cc: Haskell-Cafe
Subject: Re: [Haskell-cafe] Troubles understanding me
On Wed, 26 Sep 2007, Aaron Denney wrote:
>
> It's true that time-wise there are definite issues in finding character
> boundaries.
UTF-16 has no advantage over UTF-8 in this respect, because of surrogate
pairs and combining characters. Code points, characters, and glyphs are
all different things,
On Wed, 26 Sep 2007, ChrisK wrote:
ok wrote:
There are a number of interesting issues raised by mbeddoe's
Math.Statistics.
data (Floating a, Ord a)
=> Simple_Continuous_Variate a
= SCV [a] Int a a (Array Int a)
list_to_variate xs = SCV xs n m s o
where n = length x
On 9/26/07, Aaron Denney <[EMAIL PROTECTED]> wrote:
> On 2007-09-26, Johan Tibell <[EMAIL PROTECTED]> wrote:
> > If UTF-16 is what's used by everyone else (how about Java? Python?) I
> > think that's a strong reason to use it. I don't know Unicode well
> > enough to say otherwise.
>
> The internal
On Wed, 26 Sep 2007, apfelmus wrote:
ok wrote:
I believe the author may have misunderstood "numerically stable".
The obvious (sum xs)/(fromIntegral $ length $ xs) is fine for
the mean,
That's probably my fault, out of ignorance. Do you know a good online
resource about numeric
On Tue, 25 Sep 2007, Brian Hulley wrote:
Ryan Ingram wrote:
A couple off the top of my head:
(:) :: a -> [a] -> [a]
Yes that's one that had totally slipped my mind ;-)
I like to add 'div' and 'mod' as examples for wrong argument order.
___
Hask
On Wed, 26 Sep 2007, Peter Verswyvelen wrote:
I hope I won't come to the conclusion that after one year learning the
cool lazy functional programming language Haskell (which I want to use
for making simple videogames in a clean way for teaching),
I haven't tested it, but know of the existenc
On Tue, 25 Sep 2007, Brian Hulley wrote:
Of course the problem disappears if you just discard multiple clause syntax
and use:
(list :: a List) (f :: a -> b) map :: b List =
case list of
Empty -> Empty
h t PushF -> (h f) (t f map) PushF
This would also have the adv
I wonder why nobody mentioned this (yet; recently):
Andrea Asperti and Giuseppe Longo
Categories, Types and Structures. Category Theory for the working computer
scientist. M.I.T. Press, 1991
You don't have to buy it. Go here, and fetch the book:
http://www.di.ens.fr/~longo/download.html
Paul L wrote:
We recently wrote a paper about the leak problem. The draft is at
http://www.cs.yale.edu/~hl293/download/leak.pdf. Comments are welcome!
Interesting. Now that I know the "basic Haskell" stuff these arrows make
much more sense. However, they look *very* similar to a visual
programm
Another opinion in case you need more:
TAPL is excellent for self-study. There are solutions for most
interesting exercises. And every type system presented comes with a
downloadable implementation. You can practice with it and change it.
Do not hesitate to get it. I also recommend Cardelli's pape
ok wrote:
I believe the author may have misunderstood "numerically stable".
The obvious (sum xs)/(fromIntegral $ length $ xs) is fine for
the mean,
That's probably my fault, out of ignorance. Do you know a good online
resource about numeric stability? (I don't have the Knuth at ho
On Tue, 25 Sep 2007, Dan Piponi wrote:
It's not so clear to me what the syntax for types should be in a postfix
language.
Postfix, of course! So you'd write
data a Tree = Leaf | a a Tree
Confusingly, ocaml does something like this, with postfix notation for
types and prefix notation for fu
On Tue, 25 Sep 2007, Brian Hulley wrote:
To be consistent this would also have to apply to the use of (->) in types to
get:
a -> b === (->) b a
Since there are many type class instances for the Reader Monad, in this
case the order of argument seems to be appropriate.
__
On Tue, 25 Sep 2007, Brian Hulley wrote:
Jonathan Cast wrote:
Of course, this is all a consequence of the well-known failure of
natural language: verbs come before their objects. It is thus natural
to write f(x), when in fact it is the object that should come first, not
the function. Switch
On 2007-09-26, Johan Tibell <[EMAIL PROTECTED]> wrote:
> If UTF-16 is what's used by everyone else (how about Java? Python?) I
> think that's a strong reason to use it. I don't know Unicode well
> enough to say otherwise.
The internal representations don't matter except in the case of making
FFI l
On Wed, 26 Sep 2007, ok wrote:
[Concerning the fact that fmod(x,y) = -fmod(-x,y)]
I wrote:
Interesting, perhaps. Surprising, no. fmod() is basically there for
the sake of sin(), cos(), and tan() (or any other periodic and
either symmetric or antisymmetric function).
On 25 Sep 2007, at 8:58
> I'll look over the proposal more carefully when I get time, but the
> most important issue is to not let the storage type leak into the
> interface.
Agreed,
> From an implementation point of view, UTF-16 is the most efficient
> representation for processing Unicode. It's the native Unicode
> r
74 matches
Mail list logo