> I haven't read the underlying proposals, so I apologize if the following is
> covered, but my understanding of the discussion is that the x.f notation is
> intended to disambiguate f to be a field name of the type of x and therefore
> be advantageous over "f x" notation where f is presently in th
I brought up an idea on another thread, but it was a bit off subject
and I think it got buried. Anyway, I'm curious to know if there are
any obvious problems with this idea, or if it could be pursued
further:
It could be called Tagged Type Directed Name Resolution.
The idea is a # prefix for ide
On Wed, Feb 8, 2012 at 2:47 PM, Malcolm Wallace wrote:
> On 8/02/2012, at 14:16, Steve Horne wrote:
>
>>
>> I haven't given a lot of thought to updates.
>>
>
> I very much fail to see the point of replacing prefix function application
> with postfix dots, merely for field selection. There are a
> How about § then? Surely at this late date we can allow ourselves *one*
> non-ASCII character?
> The very name of it (*section* sign) suggests taking a part; and if you are
> totally in love
> with dot, think of it as a dot with ponytails.
I suggest record的field, or record之field for the more
On Thu, Feb 9, 2012 at 12:49 PM, Donn Cave wrote:
> Quoth Evan Laforge ,
> ...
>> The non-composing non-abstract updates are what bug me, and
>> make me scatter about tons of 'modifyThis' functions, both for
>> composability and to protect from field renames.
>
On Thu, Feb 9, 2012 at 10:03 PM, Donn Cave wrote:
> Quoth Evan Laforge ,
>> On Thu, Feb 9, 2012 at 12:49 PM, Donn Cave wrote:
> ...
>>> For example, in a better world you could write stuff like
>>>
>>> modifyConfig :: (Config -> a) -> (a -> a) -&
> OK, we could implement lenses, make `tempo' a lens instead of a selector,
> desugar the update syntax to call the update 'method' out of the lens, ...
> And of course somehow arrange the sugar that when `tempo' appears in other
> contexts we take the select 'method'.
implement lenses - Done, of
I've wondered if it's faster to insert many keys by successive
insertion, or by building another map and then unioning, and likewise
with deletion. I eventually decided on successive, thinking a log n
build + merge is going to be slower than a m*log n for successive
insertion. So I wound up with:
[ ccing the list because the wiki page was flawed and I made a bunch
of changes, hope you don't mind ]
> Thanks Evan, but I think that wiki page isn't doing your
> proposal justice. There seem to be several typos in critical
> places that make it hard to follow (for me at least).
Sorry about the
> Thanks Evan, I've had a quick read through.
Thanks for reading and commenting!
> It's a bit difficult to compare to the other proposals.
>
> I can't see discussion of extracting higher-ranked functions and applying them
> in polymorphic contexts. (This is SPJ's `rev` example.)
>
> Putting h-r f
I've been trying to get my head around the Wadler-Leijen pretty
printing combinators for a while now and having some trouble.
Specifically, I have trouble getting them to pick optimal line breaks.
The existing combinators like 'sep' (and everything built from it)
merge all elements with <$> and t
On Tue, Mar 20, 2012 at 2:24 AM, Stephen Tetley
wrote:
> A quick suggestion - does setting the ribbon_frac to something like
> 0.8 improve things?
Nope. The ribbon (IMO both an undescriptive name and underdocumented)
only constraints the number of non-indent characters per line. So it
makes the
On Tue, Mar 20, 2012 at 6:52 AM, Stephen Tetley
wrote:
> Hi Ivan
>
> I haven't found any bugs in WL, however I do find the API somewhat
> confusing regarding line breaking (I would need to consult the manual
> to tell you the difference between linebreak, softline etc.). This is
> likely my failin
I just uploaded a new version to hackage. This improves the
heuristics for guessing the right module quite a bit, and adds a local
config file where you can prioritize or de-prioritize packages or
module prefixes. It's also a bit faster.
>From the hackage description:
A small standalone program
A while back I was complaining about the profusion of poorly
documented tags generators. Well, there is still a profusion of
poorly documented tags generators... I was able to find 5 of them.
So, that said, here's my contribution to the problem: fast-tags,
haskell tag generator #6.
Why not use o
On Sat, Mar 31, 2012 at 5:11 PM, dag.odenh...@gmail.com
wrote:
> On 1 April 2012 00:23, Evan Laforge wrote:
>>
>> So, that said, here's my contribution to the problem: fast-tags,
>> haskell tag generator #6.
>
> I like that it doesn't give duplicate entri
> * haskell-src-exts is not slow. It can parse a 769 module codebase racking up
> to 100k lines of code in just over a second on my machine. That's
> good. Also, I don't think speed of the individual file matters, for
> reasons I state below.
Wow, that's faster than my machine.
> * Broken sour
On Sun, Apr 1, 2012 at 3:27 AM, Roman Cheplyaka wrote:
> It's useful to mention the limitations of this package, so that people
> know what to expect and don't spend their time testing it to understand
> that it doesn't suit their needs.
Good point, I'll put the limitations and TODO stuff into th
On Mon, Apr 2, 2012 at 5:41 AM, Michael Snoyman wrote:
> On Mon, Apr 2, 2012 at 3:38 PM, Alp Mestanogullari
> wrote:
>> Lesson learned: for next year, write a Haskell program that tells if a given
>> -cafe thread or reddit discussion is a April Fool's joke or not.
>
> import Data.Time
>
> main =
I recently uploaded fast-tags-0.0.3. The main thing is that all the
performance problems I was able to find have been fixed---hopefully
will no longer be mistaken as an April Fools joke! Here's copy and
paste from the hackage description:
Changes since 0.0.2:
Lots of speed ups, especially when
I love the idea of easier to use FFI, but isn't the haskell FFI
intentionally very low level, and intended to be used with tools?
In that light, maybe it would be easier to extend hsc2hs with fancier
macros and the ability to generate wrappers to directly call C++
methods and construct C++ objects
On Thu, Apr 12, 2012 at 6:22 PM, Antoine Latter wrote:
> Hi Warren,
>
> On Thu, Apr 12, 2012 at 6:31 PM, Warren Harris
> wrote:
>> I wrote a parsec parser that does symbols lookups during the parsing process
>> (ParsecT String Store IO a). Now I'd like to write a pretty printer that
>> does th
I use a custom Pretty class along with HughesPJ, ala ghc's Outputable.
It means I can omit data or print it out in a more readable form
(even just rounding floats to %.03f can help a lot), and also get nice
layout and wrapping. The downside is a certain amount of boilerplate
to write output routi
> And then have the compiler automatically include (optional) package
> name, module name, and line number where `headContext` was called. How
> about we borrow a bit from rewrite rules, and have a pragma such as:
>
> {-# WITH_CONTEXT head headContext #-}
This seems similar to the SRCLOC_ANNOTA
On Thu, Apr 26, 2012 at 12:20 AM, Simon Peyton-Jones
wrote:
> Tristan Allwood got quite a long way with this a couple of years ago.
> http://research.microsoft.com/en-us/um/people/simonpj/papers/stack-trace/DebugTraces.pdf
While stack traces are undoubtably useful, I think this is a different
pro
So I wanted to find the first index in a vector whose running sum is
greater than a given number.
The straightforward way is to create the running sum and then search:
Vector.findIndex (>=target) (Vector.scanl' (+) 0 vector)
But vectors are strict so it could do extra work, and what if I don't
w
ut my impression was that stream fusion can't handle early aborts,
which was why I was wondering why Vector lacks a foldAbort type
function.
On Wed, May 23, 2012 at 5:13 AM, Jake McArthur wrote:
> Have you already verified that stream fusion won't just do this for you?
>
> On May
On Tue, May 29, 2012 at 12:52 PM, Roman Leshchinskiy
wrote:
> On 29/05/2012, at 19:49, Evan Laforge wrote:
>
>> Good question.. I copied both to a file and tried ghc-core, but it
>> inlines big chunks of Data.Vector and I can't read it very well, but
>> it looks li
On Mon, Jun 11, 2012 at 1:29 PM, Roman Leshchinskiy
wrote:
> Hmm, which version of GHC and what compiler flags are you using? I'm not
> familiar with ghc-core, maybe that's doing something wrong. Just run ghc -O2
> -ddump-simpl and look at the output. Below is the code I'm getting for
> find_b
he recent discussion of whether storablevector should be deprecated in
favor of vector reminded me: vector supports storable arrays, but it
doesn't support lazy arrays. While storablevector has lazy arrays and
a builder, it doesn't support boxed types (it would be become misnamed
if it did!).
So
>> I can think of two cases where I'd want something like this.
>> One is manipulating file extensions, where I'd want to use
>> System.FilePath.splitExtension or something like that anyway.
>> The other is suffix stripping for text processing, where I'd
>> want to use a trie to match a whole lot o
On Thu, Aug 2, 2012 at 9:00 AM, Jonathan Geddes
wrote:
>
> Richard O'Keefe Said:
>>> Ouch! And that's not even very deeply nested.
>>> Imagine 4 or 5 levels deep. It really makes
>>> Haskell feel clunky next to `a.b.c.d = val`
>>> that you see in other languages.
>>
>>I was taught that this kind o
On Sun, Aug 12, 2012 at 6:18 PM, Niklas Hambüchen wrote:
> I just came across the fact that running
>
> createProcess (proc "asdfasdf" [])
>
> with non-existing command "asdfasdf" returns perfectly fine handles.
> I would expect an exception.
> You can even hGetContents on stdout: You just get
On Tue, Sep 11, 2012 at 9:36 AM, Eric Velten de Melo
wrote:
> Any thoughts? Hopefully I'm not saying anything really stupid.
You can intersperse decoding errors in the output, e.g. output is
[Either Error DecodedChunk]. Then all the processors have to deal
with it, but if you just want to pass t
> With shake I'm not sure exactly how to get started. Should I have a
> separate project where I create the build system for the webapp? Or
> can I setup something similar to sbt?
>
> Also, how do I handle dependencies with shake? cabal will pull in
> packages from hackage and do the needful, is
I wonder if people who like one giant window maybe don't use the REPL?
I keep 3 windows open: one with the editor, one with ghci, and one
with a shell. The shell I use for compiles, darcs records, diffs,
grepping, moving files around, etc. I don't understand how people are
able work with fewer..
Ever since upgrading to 7.6.1 I regularly get panics like this:
seq: internal error: evacuate: strange closure type -1958168540
(GHC version 7.6.1 for x86_64_apple_darwin)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
I've seen some variations, but basically I th
Thanks for the response.
On Sat, Dec 1, 2012 at 5:23 PM, Alexander Kjeldaas
wrote:
>
> What I've mostly done in similar circumstances (jni)
>
> 1. Create an interface (virtual functions or template) for the FFI in C++
> that covers everything you use. Then create one test implementation and one
>
> Shelly is cool, as I said, but I imagine it would be more valuable to
> have another language that is actually separate from Haskell, with an
> interpreter that is more lightweight and changes much less frequently
> (than GHC). Something that could be nearly as portable as Bash or Perl.
Hugs? I
It so happens that on 64 bit OS X, haskell's Int is 64 bits, while C's int is
32 bits. hsc2hs's #poke does no typechecking at all, so if you have
(#poke Struct, int_field) structp int -- where int :: Int
Then you probably are going to corrupt memory, and in a particularly
pernicious way (since c
> surprisingly, deepseq is not used as much as I thought.
> http://packdeps.haskellers.com/reverse/deepseq lists a lot of packages,
> but (after grepping through some of the code) most just define NFData
> instances and/or use it in tests, but rarely in the „real“ code. For
> some reason I expected
> Today I thought it was about time to simplify how new 'things' of a certain
> kind are added to the system. These things are some a cross between an event
> and an assertion of a fact in a rule based system. There are many different
> kinds of these things. I already have more than a dozen com
I also get stack overflows from HughesPJ if I format something too big.
LW is more efficient by construction than HughesPJ. The only reason I
switched to HPJ from LW is that I could never get LW to behave as I
wanted, but I'll probably wind up writing my own simpler formatter due
to the HPJ stack
I have a couple of problems with attoparsec which I think are related
to its always backtrack nature, but maybe there's some other way to
solve the same problems.
The first is that it's hard to get the right error msg out. For
instance, I have a parser that tries to parse a number with an
optiona
> I think the mistake here is to parse something and then decide if
> its it valid. It should be the parser which decides whether its
> valid. So rather than:
>
> suffix <- A.option "" ((:"") <$> A.letter_ascii)
>
> try:
>
> typ <- A.choice [ {- list or valid suffix parsers -} ]
> re
On Fri, Mar 15, 2013 at 8:49 PM, Niklas Hambüchen wrote:
> Is it not possible to add an alternative (no pun intended) to <|> that
> supports the semantics Evan wants?
I assume it's the performance thing. Presumably it would need to pass
an extra flag with to the failure continuation to tell it t
> Brent, my use case is not particularly complicated. I am trying to model the
> pdf spec - which says that pdf contains Objects that could of of types
> Number, String, Name, Array and Dictionary - while array is list of objects,
> the Disctionary is a list of tuples (Name, Object) not (Object, Ob
Can't we just add some features to haddock? There are a lot of ways
to improve haddock a lot, and no one is doing them, so my impression
is that haddock doesn't really have active maintainers. Adding a
whole new backend seems risky, unless it results in new maintainers
joining.
For my personal b
On Mon, Apr 8, 2013 at 3:49 PM, Ivan Lazar Miljenovic
wrote:
> On 9 April 2013 05:08, MigMit wrote:
>>
>>
>> Отправлено с iPad
>>
>> 08.04.2013, в 21:44, Evan Laforge написал(а):
>>
>>> Can't we just add some features to haddock?
>&g
I tried to colorize a haskeline prompt by putting control characters
in it, but line editing was hopelessly confused, presumably because
haskeline doesn't understand control characters and thought the prompt
was longer than it really was. From looking at
Haskeline.promptedInput, it seems like ther
I've had a strange bug that's baffled me for a long time. I finally
got serious about tracking it down, and managed to reduce it to a
small program that exhibits the unexpected behaviour, namely that a
createProcess seems to block writing to and closing a socket.
Here's the example program:
---
On Sun, Apr 21, 2013 at 9:25 PM, Donn Cave wrote:
> Quoth Evan Laforge ,
>
>> sleep = Process.createProcess (Process.proc "sleep" ["5"])
>
> sleep = Process.createProcess
> ((Process.proc "sleep" ["5"]) {Process.cl
On Mon, Apr 22, 2013 at 7:39 PM, Donn Cave wrote:
> quoth Evan Laforge ,
> ...
>> Oh I see, because the subprocess inherits the socket connection. That
>> makes sense, though it's tricky. Tricky tricky unix. Why does fork()
>> have to be so complicated?
>
I wrote a ghc-server that starts a persistent process for each cpu.
Then a 'ghc' frontend wrapper sticks each job in a queue. It seemed
to be working, but timing tests didn't reveal any speed-up. Then I
got a faster computer and lost motivation. I didn't investigate very
deeply why it didn't spe
> Yes, it would break code. Probably a lot of code.
So of course I volunteer to fix my code, but that's not much help,
since it's a small minority of the code on hackage. So that made me
think, maybe we should organize a kind of hackage community service
brigade, which, when the time is right, w
I hadn't seen anyone with this particular concern, so:
The page says "Using qualified names works, but it is just
sufficiently inconvenient that people don't use it much", with which I
disagree. Since I use qualified names, it seems like I wouldn't be
able to use TDNR without compromising. So it i
> This motivated my original reply this post. The trouble is, what
> constitutes better records? There are as many views as users of Haskell, I
> bet.
>
> My main motivation is:
>
> As mentioned in my original post: better name space management.
>
> Surprisingly enough, I find the current record sy
Yeah, I know this has been discussed a number of times, but I have
some concrete questions I haven't seen asked before. And the "parsec
3 is now as fast as parsec 2" thing I've seen around doesn't seem to
be true for me.
I have an app that does a lot of parsing of small expressions. It's
current
Lately I've been seeing this error occasionally when recompiling:
Undefined symbols:
"_UiziTrackC_d26DB", referenced from:
_UiziTrackC_d26DB$non_lazy_ptr in TrackC.o
ld: symbol(s) not found
If I delete the .o file for the mentioned module and recompile, it
links fine. This makes me think
On Thu, Dec 23, 2010 at 12:01 PM, Evan Laforge wrote:
> Yeah, I know this has been discussed a number of times, but I have
> some concrete questions I haven't seen asked before. And the "parsec
> 3 is now as fast as parsec 2" thing I've seen around doesn't
> I've uploaded attoparsec-text and attoparsec-text-enumerator to
> Hackage. I've written those packages late last week and asked for
Very nice! I'll download this and try it out. Attoparsec has a bit
different combinators than parsec so it'll take some rewriting, but
it's work I'd have to do a
On Wed, Jan 5, 2011 at 1:27 PM, Gregory Collins wrote:
> On Wed, Jan 5, 2011 at 9:02 PM, Jonathan Geddes
> wrote:
>
>> Despite all this, I suspect that since Haskell is at a higher level of
>> abstraction than other languages, the tests in Haskell must be at a
>> correspondingly higher level than
On Wed, Jan 5, 2011 at 7:31 PM, Chung-chieh Shan
wrote:
> Besides those example inputs and expected outputs, what about:
> If two signals are (in)compatible then after applying some simple
> transformations to both they remain (in)compatible? A certain family of
> signals is always compatible wit
> I should say that this reimplementation would be good. If you can
> compare two implementations (one in plain Haskell and second in
> declarative QuickCheck rules) you will be better that with only one.
This presumes I know how to write a simple but slow version. Clearly,
that's an excellent si
On Mon, Dec 27, 2010 at 6:51 AM, Evan Laforge wrote:
>> I've uploaded attoparsec-text and attoparsec-text-enumerator to
>> Hackage. I've written those packages late last week and asked for
>
> Very nice! I'll download this and try it out. Attoparsec has a
> Now attoparsec-text is more than twice faster, allocates even less
> memory and the total memory figures seem right.
>
> Bottom line: I think this benchmark doesn't really represent the kind
> of workload your parser has. Can you reproduce these results on your
> system?
I spent quite a bit of
One of the first things I did when starting a larger haskell project
was to write a preprocessor that would replace certain tokens with
(token_srcpos (filename, func_name, lineno)) and then write x and
x_srcpos versions of the various 'throw' and logging functions. This
is extremely handy to have,
> Now your consumers can write:
>
> getSourceLoc assert :: String
>
> And you will have a value that describes where you are. You can then
> use this to implement logging, throw errors etc. The annoying part is
> that you have to explicitly pass in assert from the call site to make
> sure that you
On Thu, Jan 20, 2011 at 12:47 AM, Max Bolingbroke
wrote:
> On 19 January 2011 23:59, Evan Laforge wrote:
>> Another thing is that performance in logging is pretty critical. When
>> I profile, logging functions wind up in the expensive list if I'm not
>> car
>> I think my short term solution is going to be remove -auto-all from
>> attoparsec's cabal---I'm not profiling attoparsec and so I don't want
>> my entire profile output to be internal attoparsec functions. But
>> presumably the flag was added there for a reason, so maybe there are
>> people who
On Fri, Jan 28, 2011 at 8:39 AM, Henning Thielemann
wrote:
> Evan Laforge schrieb:
>> One of the first things I did when starting a larger haskell project
>> was to write a preprocessor that would replace certain tokens with
>> (token_srcpos (filename, func_name, lineno))
On Tue, Feb 1, 2011 at 10:02 PM, John Millikin wrote:
> Is there any reasonable way to do this if I want to cast a monadic
> value? For example:
>
>> castState :: (Typeable a, Typeable s, Typeable1 m, Typeable b) => a -> Maybe
>> (StateT s m b)
>> castState = Data.Typeable.cast
>
> None of the co
On Thu, Feb 3, 2011 at 3:38 PM, Erik de Castro Lopo
wrote:
> I am a relative newcomer to Haskell, but I think I have a reasonable
> understanding of the executaion model. Enough to fix performance
> issues in simple code like the example given.
>
> However, one of the Haskell projects I work on is
On Sat, Feb 5, 2011 at 8:19 AM, Jesper Louis Andersen
wrote:
> On Sat, Feb 5, 2011 at 17:13, Andrew Coppin
> wrote:
>> On 05/02/2011 12:56 PM, Jesper Louis Andersen wrote:
>>
>> Presumably messages added to the channel appear immediately after the
>> transaction commits. The problem is, I think
> The distinction between let and letrec predates OCAML. Scheme does it too.
Haskell's choice of recursive everywhere is nice for the syntax, but
occasionally error prone. I don't actually use explicit recursion too
often because there are functions for that, but I still occasionally
typo a vari
>> The reason it's not in Data.List is because there are a bazillion
>> different splits one might want (when I was pondering the issue before
>> Brent released it, I had collected something like 8 different proposed
>> splits), so no agreement could ever be reached.
>
> It is curious though that t
I just got started on this because packages are starting to use mtl2.
I had hoped it would be simple, and hopefully it is, but...
Do I really have to add (Functor m) to the 300 or so functions with
(Monad m) on them? Or just not use fmap or applicative?
Ow. Not what I would call "small incompat
On Tue, Feb 15, 2011 at 7:58 PM, Ivan Lazar Miljenovic
wrote:
> On 16 February 2011 14:46, Evan Laforge wrote:
>> I just got started on this because packages are starting to use mtl2.
>> I had hoped it would be simple, and hopefully it is, but...
>>
>> Do I really hav
On Wed, Feb 16, 2011 at 7:01 AM, Ross Paterson wrote:
> On Tue, Feb 15, 2011 at 07:46:29PM -0800, Evan Laforge wrote:
>> Do I really have to add (Functor m) to the 300 or so functions with
>> (Monad m) on them? Or just not use fmap or applicative?
>
> If you're using
On Wed, Feb 16, 2011 at 11:28 PM, Sebastian Fischer wrote:
> On Thu, Feb 17, 2011 at 11:32 AM, Evan Laforge wrote:
>>
>> Or will there just be massive signature rewriting in the wake of mtl2?
>
> I must admit I still don't understand your exact problem. Could you help
I have a function 'justm' for this specific case:
-- | This is sort of like a monad transformer, but the Maybe is on the inside
-- instead of the outside.
--
-- What I really want here is MaybeT, but it requres explicit lifting...
justm :: (Monad m) => m (Maybe a) -> (a -> m (Maybe b)) -> m (Maybe
> parseConstant = Reference <$> try parseLocLabel
> <|> PlainNum <$> decimal
> <|> char '#' *> fmap PlainNum hexadecimal
> <|> char '\'' *> (CharLit <$> notChar '\n') <* char '\''
> <|> try $ (char '"' *> (StringLit . B.pack <$>
>
I have a few functions for operating on lists that take continuations:
-- | Like takeWhile but with a continuation, so you can chain takes without
-- copying.
takeWhileThen :: (a -> Bool) -> ([a] -> [a]) -> [a] -> [a]
takeWhileThen _ _ [] = []
takeWhileThen f cont (x:xs)
| f x = x : takeWhileT
> Generally, it shouldn't (and doesn't), but here some packages have to be
> reinstalled because they have to be built against different dependencies.
>
> I'd prefer cabal install to refuse here (overridable with a --force flag)
> because reinstalling boot libs (containers, filepath, directory, pro
On Thu, Mar 3, 2011 at 12:33 AM, Mark Lentczner
wrote:
> To make up for my total misunderstanding of what you were asking
> before, I hereby offer you the Plumbing module, available here:
> https://bitbucket.org/mtnviewmark/haskell-playground/src/2d022b576c4e/Plumbing.hs
>
> With it, I think you
On Wed, Mar 2, 2011 at 12:00 AM, Stephen Tetley
wrote:
> Maybe you've invented the ApoPrelude?
>
> If I were doing it I'd probably code them in terms of an apomorphism -
> unfoldr with flush. Unlike regular unfoldr which discards the final
> state, an apomorphism uses the final state to produce th
> I have to admit I really do not like having Applicative and MonadPlus with
> different behavior. Yes, one is redundant, but that is more an artifact of
> language evolution, than an intentional opportunity for diverging behavior.
> Every library I am aware of to date, save of course this one, has
On Fri, Apr 8, 2011 at 5:24 AM, Henning Thielemann
wrote:
> Magnus Therning schrieb:
>> AFAIK there is no way to do that, thouhg scion[1] may offer it.
>>
>> Personally I develop more complex local functions at the top-level,
>> and once I'm happy with it I perform some re-factoring and move it in
>> I would not write large local functions at all. I would leave them
>> top-level but do not export them. This also allows to test them from GHCi.
>
> The downside to this is when you want to use the worker/wrapper transform in
> order to capture some local variables for a recursive function, inst
Here's a simple issue that's been with me for a while. As do many
people, I use plural variable names for lists, so if a Block as called
'block' then [Block] is 'blocks'.
The other pattern that comes up a lot is 'Maybe Block'. When I have
to name it, I call it 'maybe_block', e.g.
maybe_block <-
> Of course, naming will always be a matter of taste. For instance I would not
> write maybe_something, because I prefer camel case, that is, maybeSomething.
> On the other hand, I already wrote some Wiki articles that you may read as
> suggestions for certain naming conventions:
> http://www.hask
> Most of the (non-IO) runtime errors I get using Haskell software is due to
> head or fromJust, it's actually quite annoying.
Just singling this one out because I've heard it before. I've never
gotten a runtime error from these. It seems quite easy to just not
use these functions.
It's alread
On Sat, Apr 23, 2011 at 5:57 PM, Ketil Malde wrote:
> Evan Laforge writes:
>
>>> Most of the (non-IO) runtime errors I get using Haskell software is
>>> due to head or fromJust, it's actually quite annoying.
>
>> Just singling this one out because I'
It's been remarked to me that relying on the Binary and Serialize
classes is dangerous, because there's no guarantee they won't maintain
a consistent format. So if my app uses the Serialize instances that
come with cereal, it could suddenly fail to read old saves after an
upgrade to cereal.
Howev
> When I need to comply with a specific binary format, I never rely on
> Binary/Serialize class instances - I always fall back on the primitive
> operations on Words of varying sizes (perhaps defining my own type
> classes for convenience). The 'Builder' type makes this pretty easy.
>
> If I were w
> I'm a bit skeptical of adding builders for different variable length
> encodings to the library, simply because there are so many
> possibilities. I think creating a binary-vle (for variable length
> encoding) package would be worthwhile. I have an implementation of the
> VLE used in protocol buf
On Tue, May 3, 2011 at 7:13 AM, Alberto G. Corona wrote:
> E1610With the exception of heavy serialization usage, for example, in very
> optimized RPC applications (and even there SOAP shows that this is not ever
> the case), text serialization is better. The unwritten rules of good design
> says
If you search for "cabal install", the first link is
http://hackage.haskell.org/trac/hackage/wiki/CabalInstall, which in
turn leads to http://haskell.org/cabal/download.html.
It looks very official and canonical and all that, but that page has
an old version of cabal install that will no longer co
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
> 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
201 - 300 of 367 matches
Mail list logo
