> 2) Languages like Python make it easy to write fast performing code in a few
> lines that will read/write files, split strings, and build lists or
> dictionaries/associative arrays. There are very clever ways of doing all
> these things Haskell, but it can involve several qualified imports and ti
On Thu, May 19, 2011 at 5:32 PM, Felipe Almeida Lessa
wrote:
> On Thu, May 19, 2011 at 9:23 PM, John Lask wrote:
>> A general problem with strategic response is they underestimate the effort
>> required due to the long range horizon and the uncertainties involved.
>
> The efforts in building a cr
Think of it this way:
-- Here is some data representing the typeclass 'Show'
data ShowDict a = ShowD (a -> String)
show :: ShowDict a -> a -> String
show (ShowD f) a = f a
-- Here's a sample implementation for Strings
showString :: ShowDict String
showString = ShowD (\s -> "\"" ++ escape s ++ "\"
On Thu, May 19, 2011 at 9:23 PM, John Lask wrote:
> A general problem with strategic response is they underestimate the effort
> required due to the long range horizon and the uncertainties involved.
The efforts in building a cross-platform GUI are not to be
underestimated. Otherwise nobody woul
Do GUIs or interactive graphics in Haskell work a lot better on
Windows and/or various Linux distro's?
On Tue, May 17, 2011 at 4:24 PM, Conal Elliott wrote:
> I still haven't found any way to do GUIs or interactive graphics in Haskell
> on a Mac that isn't plagued one or more of the following se
On 19/05/2011 10:31 PM, Heinrich Apfelmus wrote:
my comments for what their worth:
(1) wx and ghci: I successfully run wx in ghci (albeit) on windows. I
take an alternative path to that proscribed by the current build process
- I think principally so that I am able to run it in ghci, although
I only recently started learning Haskell and have had a difficult time
convincing other Python hackers to come on board. I see two things that
might help:
1) A resource to make informed decisions about different libraries.
Something that includes specific criteria like how long a library has been
On 5/19/11 5:51 PM, Antoine Latter wrote:
On Thu, May 19, 2011 at 3:06 PM, Simon Meier wrote:
The core problem that drove me towards this solution is the abundance
of different IntX and WordX types. Each of them requiring a separate
Write for big-endian, little-endian, host-endian, lower-case-
On 19 May 2011 10:53, Johan Tibell wrote:
> Long term we'd like to switch bytestring over
> from ForeignPtr to ByteArray#, if possible. There are currently some
> technical obstacles to such a switch
BTW I'm working with Roman Leshchinskiy to create the
vector-bytestring package which provides:
t
See the Haskell Platform.
Sent from my iPhone
On May 19, 2011, at 1:56 PM, Andrew Coppin wrote:
> On 19/05/2011 09:34 PM, vagif.ve...@gmail.com wrote:
>> Andrew, you are being non constructive.
>
> It seems I'm being misunderstood.
>
> Some people seem to hold the opinion that more librari
I too am not all that concerned about the library proliferation, and I
think such work can definitely help find the best design for certain
abstractions. There are no less than 3 iteratee libraries - 4
including liboleg's original IterateeM formulation - and a number of
FRP implementations as well,
Simon Meier schrieb:
> There are many providers of Writes. Each bounded-length-encoding of a
> standard Haskell value is likely to have a corresponding Write. For
> example, encoding an Int32 as a big-endian, little-endian, and
> host-endian byte-sequence is currently achieved with the following
>
The way I understand it, you're saying not that we shouldn't be doing it
this way (since it isn't centrally managed, it's the only possible way), but
that we shouldn't be "bragging" (for lack of a better word) that we have
lots of libraries that do a specific thing. Or if not that, then at least
th
On Thu, May 19, 2011 at 3:06 PM, Simon Meier wrote:
> The core problem that drove me towards this solution is the abundance
> of different IntX and WordX types. Each of them requiring a separate
> Write for big-endian, little-endian, host-endian, lower-case-hex, and
> uper-case-hex encodings; i.e
I wonder if it would be useful to be able to download and use only necessary
modules from Hackage. This way if someone writes, say a superior XML parsing
API, and someone else has better generating API, the user can pull just
those modules , write the glue and have the best of both worlds.
On the
Andrew Coppin writes:
> I'm trying to voice the opinion that there is such a thing as too many
> libraries. The article I linked to explains part of why this is the
> case, in a better way than I've been able to phrase it myself.
I don't think so, the article seems to talk more about social prob
> ultimately the ideal is to end up with one library that solves the problem
> well, which everybody can use.
>
>
Nonsense. One library that everyone can use with either end up being so small
in functionality that it's actually useless, or so general that either it
requires tons and tons of
On Thursday 19 May 2011 23:15:06, Andrew Coppin wrote:
> On 19/05/2011 10:11 PM, Artyom Kazak wrote:
> > And I can declare an instance for (x, y) which does NOT implies (Show
> > x):
> >
> > instance Show (x, y) where
> > show _ = "I'm tuple! Hooray!"
>
> Ah. So it's a feature.
>
> Fortunately I
If you have nested type, then it usually makes sense to have Show defined
for the inside types, too, but it's not a requirement. Technically, only
when you call 'show' for something in the data type you are defining Show
for, *then* you need a Show instance defined for that inside-type.
On Fri, Ma
On 19/05/2011 10:11 PM, Artyom Kazak wrote:
And I can declare an instance for (x, y) which does NOT implies (Show x):
instance Show (x, y) where
show _ = "I'm tuple! Hooray!"
Ah. So it's a feature.
Fortunately I refactored the program where this came up, so it's no
longer an issue. I just wa
And I can declare an instance for (x, y) which does NOT implies (Show x):
instance Show (x, y) where
show _ = "I'm tuple! Hooray!"
Andrew Coppin писал(а) в своём письме Fri,
20 May 2011 00:08:27 +0300:
Cannot deduce (Show x) from context (Show (x, y)).
Cannot deduce (Show y) from
Cannot deduce (Show x) from context (Show (x, y)).
Cannot deduce (Show y) from context (Show (x, y)).
Um... seriously?
From Prelude, we have
Show x, Show y => Show (x, y)
So clearly it works in the forward direction. But apparently not in the
reverse direction.
Is this a bug or a feat
A laugh a minute. I though of that and tried it but got the same response
(forgetting to :r my source) before rerunning. Time for a break.
Thanks!
Michael
--- On Thu, 5/19/11, aditya siram wrote:
From: aditya siram
Subject: Re: [Haskell-cafe] Trying to return a map from State monad
To: "michae
The problem is that the "all@(w1:words)" pattern-match fails when "all" is
empty. The quick and dirty fix is:
import Control.Monad.State
import Data.Map
import Debug.Trace
type Prefix = (String,String)
type GeneratorState = State ((Map Prefix [String]),Prefix,[String])
no
On 19/05/2011 09:34 PM, vagif.ve...@gmail.com wrote:
Andrew, you are being non constructive.
It seems I'm being misunderstood.
Some people seem to hold the opinion that more libraries = better. I'm
trying to voice the opinion that there is such a thing as too many
libraries. The article I li
On 19 May 2011 21:20, Andrew Coppin wrote:
> This is about all those people who think having multiple libraries which
> only solve half the problem is somehow a "good thing".
Och (number 2)
Those people are the Straw Men - you can wave at them from your car
window when you pass them as they sta
Hi Johan,
thanks for the extensive and motivating feedback.
2011/5/19 Johan Tibell :
> On Wed, May 18, 2011 at 7:32 PM, Simon Meier wrote:
>> In fact, one of my current goals with this work is to polish it such
>> that it can be integrated into the 'bytestring' library.
>
> We should definitely
Andrew, you are being non constructive.
You are saying "We" should.
Who "we", Andrew ? Who are you referring to ?
The developers who created those six different unicode libraries are not united
under any umbrella you can call "we".
The reason those six libraries existis is NOT because some myste
OK. Again, not sure what going on here. Pattern looks OK to me.
Michael
=
import Control.Monad.Stateimport Data.Map
type Prefix = (String,String)type GeneratorState = State ((Map Prefix
[String]),Prefix,[String])
non_word = "\n"
f key new old = new ++ old
buildMap ::
On 19/05/2011 08:58 PM, Don Stewart wrote:
This is classic community trolling behavior, Andrew.
And publicly calling somebody a troll isn't trolling behaviour?
I'm going to answer the rest of this off-list. I'm sure nobody else
wants to hear it.
_
On 19/05/2011 08:39 PM, Stephen Tetley wrote:
Och Mr Coppin
Lisp is a fine language, but all "Lisp" essays you'll find on the
internet except Richard Gabriel's "Worse is Better" are absolute tosh.
This wasn't an attempt to bash Lisp.
This is about all those people who think having multiple li
On 19/05/2011 07:56 PM, Gilberto Garcia wrote:
I think what Andrew meant is that it's not a good idea to have big
pile of different implementations of the same library, and all trying
to solve the very same problem.
I'm glad somebody understood what I was trying to get at.
I'm not saying that
Hi Antoine, thanks for your feedback.
2011/5/18 Antoine Latter :
> On Wed, May 18, 2011 at 12:32 PM, Simon Meier wrote:
>> Hello Haskell-Cafe,
>>
>
>
>
>>
>> There are many providers of Writes. Each bounded-length-encoding of a
>> standard Haskell value is likely to have a corresponding Write. Fo
This is classic community trolling behavior, Andrew.
You post something inflammatory, questioning the core value of our
project, without a clear argument about why it article relevant, and
then step away to let a monster thread consume everything, as people
try to work out what your point was, not
Och Mr Coppin
Lisp is a fine language, but all "Lisp" essays you'll find on the
internet except Richard Gabriel's "Worse is Better" are absolute tosh.
Read Olin Shiver's introduction to SRE regex notation for an
intelligent contribution to the "6 different libraries" problem you
seem to be having
On Thu, May 19, 2011 at 3:50 PM, Serguey Zefirov wrote:
> The solution... I think that some ratings, like "used directly by ###
> packages/projects and indirectly by ###" would be nice, but not much.
>
> As for me, I like the diversity of packages. They attack close
> problems from different front
On Thu, May 19, 2011 at 3:21 PM, Henning Thielemann <
lemm...@henning-thielemann.de> wrote:
>
> On Thu, 19 May 2011, Nicholas Tung wrote:
>
> Hi all,
>> I am curious if there is an avenue to make suggestions / comments
>> about libraries?
>> For example, "proc" in System.Process conflicts wit
On Thu, 19 May 2011, Nicholas Tung wrote:
Hi all,
I am curious if there is an avenue to make suggestions / comments about
libraries?
For example, "proc" in System.Process conflicts with the Arrows notation "proc",
yielding confusing error messages.
For the base libraries, you may e-mail
Correct my ignorance as I'm rather new around here, but I'm not sure if I
actually think this happens that much.
Different approaches are often put forth, which does mean that there are
incompatible libraries that fill the same space for a while, but it seems that
once it becomes clear what th
Hi all,
I am curious if there is an avenue to make suggestions / comments about
libraries? For example, "proc" in System.Process conflicts with the Arrows
notation "proc", yielding confusing error messages.
thanks,
Nicholas — https://ntung.com — CS and Mathematics major @ UC Berkeley
On Thursday 19 May 2011 20:27:16, Andrew Coppin wrote:
> >> This is basically the reason I asked. Currently Cabal assumes that
> >> Haddock is the only tool of its kind. If somebody built a better
> >> Haddock, you wouldn't be able to use it. (Unless you named the
> >> executable "haddock" and made
I think what Andrew meant is that it's not a good idea to have big
pile of different implementations of the same library, and all trying
to solve the very same problem.
I see this kind of problem in the java community. It seems that
developers have a need to create everything from scratch more tha
2011/5/19 Vo Minh Thu :
> 2011/5/19 Andrew Coppin :
>> http://www.winestockwebdesign.com/Essays/Lisp_Curse.html
>>
>> Some of you might have seen this. Here's the short version:
>>
>> Lisp is so powerful that it discourages reuse. Why search for and reuse an
>> existing implementation, when it's s
I think this is much less applicable to Haskell than to Lisp.
I think that most of intra-incompatibilities of Lisp stem from side
effects. The rest is mostly due to (relatively) weak type system which
let some errors slip.
And remaining percent or two can be attributed to the power of Lisp. ;)
2
2011/5/19 Andrew Coppin :
> http://www.winestockwebdesign.com/Essays/Lisp_Curse.html
>
> Some of you might have seen this. Here's the short version:
>
> Lisp is so powerful that it discourages reuse. Why search for and reuse an
> existing implementation, when it's so trivially easy to reimplement
On Thu, May 19, 2011 at 7:29 PM, KC wrote:
> For Euler 25; What is the first term in the Fibonacci sequence to
> contain 1000 digits?; the following seems to work.
>
>
> -- For number of digits being 5 or more.
> fibNdigits :: Int -> Int
> fibNdigits nDigits = floor (((fromIntegral nDigits) - 1.0
http://www.winestockwebdesign.com/Essays/Lisp_Curse.html
Some of you might have seen this. Here's the short version:
Lisp is so powerful that it discourages reuse. Why search for and
reuse an existing implementation, when it's so trivially easy to
reimplement exactly what you want yourself?
On 18/05/2011 11:25 PM, Ivan Lazar Miljenovic wrote:
On 19 May 2011 08:09, Daniel Fischer wrote:
On Wednesday 18 May 2011 23:39:47, Andrew Coppin wrote:
(It also requires you to have somewhere to host, which not
everybody has.
Haskellwiki, bitbucket, github, ...
Also if you have a project
This is basically the reason I asked. Currently Cabal assumes that
Haddock is the only tool of its kind. If somebody built a better
Haddock, you wouldn't be able to use it. (Unless you named the
executable "haddock" and made it accept the same command options.)
Or maybe support for that tool wou
For Euler 25; What is the first term in the Fibonacci sequence to
contain 1000 digits?; the following seems to work.
-- For number of digits being 5 or more.
fibNdigits :: Int -> Int
fibNdigits nDigits = floor (((fromIntegral nDigits) - 1.0) / (logBase
10 phi)) + 2
where
sq5 = sqrt 5 :: Dou
Ok, I see I left out the "State" word.
Should be:type GeneratorState = State (Map Prefix [String],Prefix,[String])
Thanks,
Michael
--- On Thu, 5/19/11, Thedward Blevins wrote:
From: Thedward Blevins
Subject: Re: [Haskell-cafe] Trying to return a map from State monad
To: "michael rice"
Cc: hask
On Thu, May 19, 2011 at 11:03, michael rice wrote:
> type GeneratorState = (Map Prefix [String],Prefix,[String])
> buildMap :: GeneratorState (Map Prefix [String])
You are trying to use a type alias (GeneratorState) as a type constructor.
There may be other problems, but that leaps out.
__
I'm not sure what's going on BELOW. Was working with mapAccumL earlier and
decided to move over to State monad for more control.
:m + Data.Map:m + Data.ListPrelude Data.List Data.Map> let f key new old = new
++ oldPrelude Data.List Data.Map> let moby2 = "Moby Dick is a great book. Moby
Dick was
Conal Elliott wrote:
Last I heard, wx still had the problem of crashing its host the second time
one opens a window (which is typical in ghci). And last I heard, Jeremy
O'Donoghue (cc'd) was exploring solutions but had very little time to pursue
them. - Conal
Last I remember, the latest proble
Jason Dagit wrote:
As you point out we also need better libraries for creating the OpenGL
context. I wrote up my searches on that front here:
http://blog.codersbase.com/2011/03/picking-gui-library-to-use-with-opengl.html
My conclusion was that GLFW-b (on hackage) is the best we have right
now.
On May 19, 2011 4:57 AM, "Henk-Jan van Tuyl" wrote:
>
> On Wed, 18 May 2011 23:21:27 +0200, Antoine Latter
wrote:
>
>> I don't have a problem with these extensions being in the Haskell
>> Platform, as the platform currently only targets GHC, but the
>> bytestring package itself might have a highe
On Wed, 18 May 2011 23:21:27 +0200, Antoine Latter
wrote:
I don't have a problem with these extensions being in the Haskell
Platform, as the platform currently only targets GHC, but the
bytestring package itself might have a higher standard of portability.
So you want the packages that use
Hi Simon,
On Wed, May 18, 2011 at 7:32 PM, Simon Meier wrote:
> In fact, one of my current goals with this work is to polish it such
> that it can be integrated into the 'bytestring' library.
We should definitely add a builder monoid in the bytestring package.
Since Write mentions IO, I thought
> My conclusion was that GLFW-b (on hackage) is the best we have right
> now. I think we could do even better than the C libraries out there
> by writing the GLUT/GLFW/etc implementation purely in Haskell. We
> already have x11 and gtk bindings for the linux support. We have
> win32 api bindings
Hi,
i am really happy about this lively discussion around Haskell (Mac) GUIs.
I might hint to two other options:
1) Eclipse's SWT wraps the native platform's toolkits quite sucessfully.
The platform-dependent bindings are mostly automatically generated, afaik.
Some time ago i summarized my th
60 matches
Mail list logo
