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.
Lots of
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) proficient
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
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
distributed
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:
accurate
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 for a
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
single
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
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
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 situations
- 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
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
- 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 nicer.
[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).
snip
programs generated by ghc generally need
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 attributes
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 it
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
writeIORef z
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 manipulations:
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, automatically
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 visual
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.
You are
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
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 less messy:
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 (State
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
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 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
| (Show
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 making
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]
29 matches
Mail list logo
