Hello Joel,
Thursday, December 08, 2005, 1:12:07 AM, you wrote:
JR> Is there a less verbose way of doing this:
data (Show a, Eq a) => State a
= Start
| Stop
| State a
deriving (Show, Eq)
--
Best regards,
Bulatmailto:[EMAIL PROTECTED]
On Wed, Dec 07, 2005 at 09:11:44PM +, Robin Green wrote:
> On Wednesday 07 December 2005 20:19, you wrote:
> > On Wed, Dec 07, 2005 at 07:47:46PM +, Robin Green wrote:
> > > > Some day you may thank for this verbosity, because it encourages
> > > > you do program in a purely functional way
I wrotted some messages on fa.haskell newsgroup but then I've figured that
people
actually read mailing lists :)
So this is digest of mine recent messages on this newsgroup.
First I want to say about OpenSSL thread safety. It is not thread safe by
default.
Who wants to import and use OpenSLL fu
On Wed, Dec 07, 2005 at 10:12:07PM +, Joel Reymont wrote:
> data State a
> = Start
> | Stop
> | (Show a, Eq a) => State a
you arn't using existential types here. an example with an existential
type would be (in ghc syntax)
> data forall a . State
> = Start
> | Stop
> |
Joel Reymont wrote:
> Folks,
>
> Is there a less verbose way of doing this:
>
> data State a
> = Start
> | Stop
> | (Show a, Eq a) => State a
>
I'm curious, what is the difference between the above and...
data State a = Start
| Stop
On Wed, Dec 07, 2005 at 04:38:19PM +0300, Bulat Ziganshin wrote:
> may be, John Meacham can say something about it? his JHC compiler uses
> region analysis to avoid garbage collection - may be these techniques
> has something in common?
By the time jhc makes any decisions regarding memory manageme
Folks,
Is there a less verbose way of doing this:
data State a
= Start
| Stop
| (Show a, Eq a) => State a
instance Eq a => Eq (State a) where
(State a) == (State b) = a == b
Start == Start = True
Stop == Stop = True
instance Show a => Show (State a) where
show (Stat
> On Tue, Dec 06, 2005 at 10:58:45PM +0300, Bulat Ziganshin wrote:
> > the third-priority problem is language itself. in particular, i hate
> > Haskell school of imperative manipulations:
> >
> > x' <- readIORef x
> > y' <- readIORef y
> > writeIORef z (x'*y')
Here's a way to make some of this l
On Wednesday 07 December 2005 21:11, Robin Green wrote:
> seqPair :: (Monad m) => (m a, m b) -> m (a, b)
Sorry, that line should read:
seqPair :: (Monad m) => m a -> m b -> m (a, b)
--
Robin
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http:
On 12/7/05, Robin Green <[EMAIL PROTECTED]> wrote:
> Let's say you want to write a function
>
> seqPair :: (Monad m) => (m a, m b) -> m (a, b)
>
> which returns a computation which does the left computation followed by the
> right computation (i.e. it's like the sequence function, but for pairs
> i
Am Mittwoch, 7. Dezember 2005 20:53 schrieb Sebastian Sylvan:
> [...]
> It may make it harder for people to grasp the difference between an
> IORef and a regular value though...
And this might be a big problem. It reminds me of languages which do a lot of
automatic type conversion, including au
- Original Message -
From: "Sebastian Sylvan - [EMAIL PROTECTED]"
Sent: Wednesday, December 07, 2005 8:36 PM
>
> > Maybe you'd be interested in Hacle?
> >
> > http://www-users.cs.york.ac.uk/~mfn/hacle/
Yep, I am. :) I've discovered it a while ago.
> >
> > " The aim was to develop a t
On Wednesday 07 December 2005 20:19, you wrote:
> On Wed, Dec 07, 2005 at 07:47:46PM +, Robin Green wrote:
> > > Some day you may thank for this verbosity, because it encourages
> > > you do program in a purely functional way making your program more
> > > friendly for SMP execution.
> >
> > Yo
On Wed, Dec 07, 2005 at 07:47:46PM +, Robin Green wrote:
> > Some day you may thank for this verbosity, because it encourages
> > you do program in a purely functional way making your program more
> > friendly for SMP execution.
>
> You are mistaken. The verbosity is necessary if you want "vis
On Wed, Dec 07, 2005 at 05:59:55PM +0100, [EMAIL PROTECTED] wrote:
> > I liked the concept of UT in Clean, but I haven't ever got comfortable
> > with using it to write real programs.
>
> Clean-like _explicit_ uniqueness typing is not what I'm asking for in Haskell.
So you want implicit, automati
On 12/7/05, Robin Green <[EMAIL PROTECTED]> wrote:
> On Wednesday 07 December 2005 19:35, Tomasz Zielonka wrote:
> > On Tue, Dec 06, 2005 at 10:58:45PM +0300, Bulat Ziganshin wrote:
> > > the third-priority problem is language itself. in particular, i hate
> > > Haskell school of imperative manipul
On Wednesday 07 December 2005 19:35, Tomasz Zielonka wrote:
> On Tue, Dec 06, 2005 at 10:58:45PM +0300, Bulat Ziganshin wrote:
> > the third-priority problem is language itself. in particular, i hate
> > Haskell school of imperative manipulations:
> >
> > x' <- readIORef x
> > y' <- readIORef y
> >
On Tue, Dec 06, 2005 at 10:58:45PM +0300, Bulat Ziganshin wrote:
> the third-priority problem is language itself. in particular, i hate
> Haskell school of imperative manipulations:
>
> x' <- readIORef x
> y' <- readIORef y
> writeIORef z (x'*y')
Some day you may thank for this verbosity, because
On 12/7/05, Greg Buchholz <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > It might be possible to get extremely fast code out of ghc, but as an
> > overall
> > impression, it's not easy, whilst Clean sort of gives it for granted (well,
> > struggeling with wrongly assigned uniqueness att
[EMAIL PROTECTED] wrote:
> It might be possible to get extremely fast code out of ghc, but as an overall
> impression, it's not easy, whilst Clean sort of gives it for granted (well,
> struggeling with wrongly assigned uniqueness attributes aside).
> programs generated by ghc generally need mult
- Original Message -
From: "Tomasz Zielonka - [EMAIL PROTECTED]"
Sent: Tuesday, December 06, 2005 9:18 PM
>
> We can get similar performance from Haskell using various features of
> GHC (unboxed arrays, mutable arrays, ST monad, soon SMP, etc) and one
> can argue that they are even nice
I want to thank all who provided insight and understanding to my
inquiry. This has been a very nice and helpful community.
I look forward to the progress Haskell makes.
I do a lot of text processing. I currently have a few million files and
4-6gb of data to process. I need excellent string sup
- Original Message -
From: "Jan-Willem Maessen - [EMAIL PROTECTED]"
Sent: Wednesday, December 07, 2005 2:21 PM
>
> Wearing my "Fortress language designer" hat, we've given serious
> thought to these techniques for very large arrays. Copying such
> structures is terribly expensive, or even
Am Dienstag, 6. Dezember 2005 20:58 schrieb Bulat Ziganshin:
> [...]
> i already sayed about lacking of OOP features.
This is the old discussion again. Do we need OOP features? Or do we want to
avoid OOP features? I would like to avoid them. Maybe I have not enough
experience with situation
Am Mittwoch, 7. Dezember 2005 14:21 schrieb Jan-Willem Maessen:
> [...]
> The principle obstacles are the same as for any reference counting scheme:
> It imposes more run-time overhead than GC does, unless the data structures
> involved are large.
Why? I think the point with uniqueness typing/an
Hello Joel,
Tuesday, December 06, 2005, 8:30:32 PM, you wrote:
JR> Assuming I typed events like that I think I would need a typed sink
JR> for them as well. I only have one sink for the events and that is my
JR> message queue.
i don't understand you. remember that i'm not native English spea
Hello Robert,
Wednesday, December 07, 2005, 2:19:22 AM, you wrote:
>> In Clean, you can (and often are required to) assign uniqueness attributes
>> to some parts of a function's type signature. The extended type checker
>> ensures that none of those parts is referred to more than once during a
>>
Hello Tomasz,
Tuesday, December 06, 2005, 11:01:45 PM, you wrote:
>> Is there a good standard way of supplying a read-eval prompt in a
>> program?
TZ> Some time ago I was thinking about implementing a Haskell telnet
TZ> server module, but now I think that this would be a difficult
TZ> solution f
On Wed, Dec 07, 2005 at 08:21:42AM -0500, Jan-Willem Maessen wrote:
> Yes, this could be done. The principle obstacles are the same as for any
> reference counting scheme: It imposes more run-time overhead than GC
> does, unless the data structures involved are large. Let me repeat that:
> accura
Hello Wolfgang,
Tuesday, December 06, 2005, 10:16:08 PM, you wrote:
>> so, in my feel, Haskell is better in areas where there is no standard
>> quick-and-dirty solutions and all languages are in equal conditions,
>> but it can't compete with Visual Basic in user interfaces, Erlang in
>> distribut
On Dec 6, 2005, at 9:17 AM, [EMAIL PROTECTED] wrote:
Hi all,
being occupied with learning both languages, I'm getting curious if
Haskell couldn't achieve most of the performance gains
resulting from uniqueness typing in Clean by *automatically*
determining the reference count of arguments
Jimmie Houchin wrote:
> Haskell looks like a very interesting language. I am only so-so with
> Python and I thought that maybe if instead of spending sufficient time
> to get proficient with Python, I could invest a similar time (more or
> less) and get reasonably (pragmatically speaking) proficien
Jimmie Houchin <[EMAIL PROTECTED]> writes:
> I have been perusing the haskell.org site and reading some of the
> tutorials. I just didn't want to expend lots of time just to find out
> that my math skills were woefully inadequate. I am grateful to learn
> that I can continue pursuing Haskell.
Lo
33 matches
Mail list logo
