It's sad to see the OpenGL binding being dropped from GHC binary
installers starting from 6.10. Though this issue has been brought up
and discussed before, I'm sure a lot of people who based their work on
OpenGL would share the same sympathy.
$ cabal install OpenGL
Nice except that:
You only need an account for uploading packages. If you do not want to
have to enter your user name or password interactively when you run
cabal upload then you can put them in the config file:
username:
password:
That sounds like a very bad idea, and should not be encouraged!
Any compromised
Any compromised uploader machine with stored passwords can
be used to upload compromising code, which will propagate to all
downloaders.
It doesn't really matter whether a compromised machine stores a password or
not. If you upload anything using a compromised machine, the attacker
has the
One problem is that Haskell collections are lazy by default. I'm
aware of a few use cases where laziness lets you formulate a very
elegant recursive population of a collection, but I think that in
general, strictness is what you want,
While I strongly agree with the gist of your post, I
main :: IO ()
main = do { content - readFile in.txt
; let -- change this following type annotation
-- to change different type of the dictionary
-- dict :: DM.Map S.ByteString Int
-- dict :: IM.IntMap Int
dict :: Trie Int
dict = fromList
Do you have an example of a mutable state/ IO bound application, like,
hmm, a window manager or a revision control system or a file system...?
If you're looking for a challenge, how about this one (there used to
be lots of Haskellers into this game, any of you still around?-):
Haskell's great strength is its equational semantics. I would like
Haskell programmers to think equationally, mathematically, rather than
operationally, when writing Haskell programs. If I were to teach a
course in Haskell, I would like to launch off of denotational
semantics, hopefully without
equational /= denotational
Nonetheless, Haskell has equational semantics which are derived from
its denotational ones. But when I said equational semantics I
really meant something more like equations :-).
Unlike Standard ML, for instance, Haskell does not have standard
semantics - a
by the way, a nice feature of ghc would be a --clean option to remove
.hi, .o files. and maybe a --veryclean to recompile all dependencies. i
have more than once rm'd my .hs files by typo...
add yourself to http://hackage.haskell.org/trac/ghc/ticket/2258 ?-)
btw, ghc head has this new option:
I have a standard Data.Map.Map as the base structure for one of my
macid data tables (jobs), but I noticed something
that is probably causing problems for me.
Even a simple 20 million record with int/int key values causes an out
of memory error for me in ghci,
Int keys, Int values eh?
Does
(hint to ghc hackers: 'Data.Map.Map Int !Int' and '[!a]' would really be
useful!-),
I can't figure out what that means though. Strictness is not a
property of types or of values, it is a property of functions. [!]
is not a subtype of [] ; IOW, there is no a such that [a] = [!Int]
(where
Where do the semantics of haskell say this? How does it interact with
fixing bugs (which means changing mathematical and universal constant
functions--since all functions are constants)?
What semantics of haskell?-) But if there was one, it might not talk
about separate compilation (it should,
I'm not advocating existential types in this case. I rarely use them myself.
I was just pointing out that the mechanism for doing the OO thing
exists in Haskell too, albeit looking a little different.
I don't think there's anything weird about existential types, except
an unfamiliar name.
If you want to make Haskell more widely used, do pick a name for
Haskell Prime that starts with an A. I first heard of Haskell when
exploring the list of computer languages that Gedit could highlight.
Just imagine going through all those A,B,C,D,E,F,G before I came to
Haskell.
That is a simple
I was wondering if it was possible to implement synchronous channels
within STM. In particular, I'd like to have CSP-like send and recv primitives
on a channel that each block until the other side arrives to complete
the transaction.
Assuming that retry blocks until something changes, you could
-- erase_range :: (Sequence s) = RangeTrait s - IO (RangeTrait s)
This can't work, as you can see after desugaring:
-- erase_range :: (Sequence s,RangeTrait s~rs) = rs - IO rs
There is nowhere to get 's' from, unless you start applying type families
backwards, from results to parameters.
(writeFile output.csv) = (liftM printCSV $ liftM (map
updateLine) $ parseCSVFromFile input.csv)
Um... Does anybody else find it interesting that we are showing the
beauty of Haskell by attempting to construct the most terse, cryptic,
unmaintainable tangle of point-free code
I don't agree at
for the libraries?
* http://haskell.org/haskellwiki/Haskell_Platform
You might have mentioned that there is finally a tracker (*) and
an approximate .cabal meta-package (for dependencies only).
- is the programs are not registered by Cabal issue going to be
fixed before platform
- is the programs are not registered by Cabal issue going to be
fixed before platform release?
No. Not the right thing for cabal the package system to do.
Huh? Having tool availability out in the open, as updateable packages,
would be more flexible than the current built-in stuff in
I posted a snippet of code which included the phrase
mapM_ (\(n,v) - putStrLn $ [ ++ show n ++ ] = ++ show v) (zip [0..] vs)
Don't do that, then?-)
mapM_ putStrLn $
map (\(n,v) - [ ++ show n ++ ] = ++ show v)
(zip [0..] vs)
-
mapM_ putStrLn $
map (\(n,v) - [ ++ show n ++ ]
Now that is real world - problems even before release!-)
Seriously, though, what is the RWH authors' plan for tackling
the eternal frustration of Haskell book authors, a moving target?
There used to be a time when one could guess the poster's
Haskell book from their question topics:
- 'HGL'
Seriously, though, what is the RWH authors' plan for tackling
the eternal frustration of Haskell book authors, a moving target?
Other tech books face the same problem, which, if they sell
successfully and the authors haven't moved into caves afterwards to
recover, they address with subsequent
Well, I was thinking that way when I was starting learning Haskell.
But then I realized that this feature would make code much harder to
read. Suppose you have different thing all named insertWith. You've
got one somewhere in your program; how do YOU know when looking at the
code after a
Cabal doesn't have to pass on ghc's messages uninterpreted. That's
a lot like implementing a map as a list and complaining about empty
list instead of element not found.
I see what you're saying, but in practise it's just not possible. GHC
can return a non-zero exit code for a multitude of
So when ghc finds that one of your modules needs to import something
that is not in one of the given packages it says that it's in another
package that is 'hidden'. Of course it's only hidden because Cabal told
ghc to hide them.
Yes, it is one of those unfortunate error messages that says I
It would be useful if some darcs 2 hackers, contributors could help the
ghc people evaluate if darcs 2 is still in the running. That would mean
identifying the key bugs (eg windows case-insensitive file bugs, slow
pulls) and seeing how hard they are to fix. Also doing a test conversion
to darcs 2
Could darcs 2 performance be improved by making use of the
order of patches in the reference repo, to identify reference
versions and reign in exponential permutation issues? In other
words, all repos are equal, all patches are equal, but once a patch has made the
roundtrip through the reference
Scott, I couldn't have said it better. My impression has always been
that HOpenGL looks like OpenGL would have looked like if they'd had a
flexible language to work with when they desgned it. My only quibble
would be with the documentation. Is there any way out there for
haddock to produce a
FYI: Haskell's OpenGL binding has just been dropped from GHC's
extralibs, which means that it will no longer be kept in sync with GHC
development, at least not by GHC HQ.
GHC HQ has its hands full and -generally speaking - extralibs are to
be replaced by H(L)P, the Haskell (Library) Platform:
So, if one of you wanted to step forward and offer to keep these
Haskell bindings for OpenGLco maintained, perhaps steward them
into the H(L)P, now would probably be a good time.
Just thought I'd forward this, for those not following cvs-ghc,
Claus
Note the OpenGL are still just as maintained
outStanza | (isMessage) = outMessage
| (isPresence) = outPresence
| (isIQ) = outIQ
Why such a style doesn't work, so I must write ugly code like that:
outStanza a | (isMessage a) = outMessage a
| (isPresence a) = outPresence a
| (isIQ a) = outIQ a
Since a term can occur both as a pattern on the left-hand side of the
equation and also as expression on the right-hand side, I need to keep
track of this, too.
So in fact, I have to anti-unify the patterns, 'translate' the resulting
state (Data.Map [Pat] Pat) to (Data.Map [Body] Body) and
I'm working on an abstract algebra library, using the types are sets
strategy. For the algebraists out there, I'm trying to implement as much as
I can of Abstract Algebra by Dummit Foote in Haskell. I've got a Ring
class definition that looks approximately like
You might find this interesting:
I agree this feature would be cool, I'm just not sure the possible
memory/performance problems associated with loading all interfaces of
all exposed modules in all packages (it would be most helpful but even
more of a performance problem to even scan non-exposed packages) would
be worth it.
rlwrap adds readline support to everything.
Well, yes, see the GHCi wiki for how to augment 'rlwrap ghci' with
some basic completion support (filenames, flags, module names):
M. is not allowed as a prefix of a function, which makes resolving
ambiguities hard unless the compiler solves the issue for you (as Hugs
and Yhc do)
See also:
http://www.haskell.org/pipermail/haskell-prime/2008-April/002569.html
http://hackage.haskell.org/trac/ghc/ticket/2237
Claus
combineWith :: b - (b - a - b) - a - a - a - a - b
n `combineWith` f = \tl tr bl br - n `f` tl `f` tr `f` bl `f` br
instance Foldable T where
foldMap f = foldT mempty $ \_ x - f x `combineWith` mappend
-- But 'traverse' won't typecheck:
instance Traversable T where
traverse f = foldT
GHC gives the error:
Couldn't match expected type `T f1 f1 a'
against inferred type `T f f a'
In the expression: blah x
In the definition of `wrapper': wrapper x = blah x
actually, GHC gives me could not deduce Blah f a from Blah f1 a
first. It seems that desugaring type
actually, GHC gives me could not deduce Blah f a from Blah f1 a
first. It seems that desugaring type function notation into an additional
constraint helps, so there's something odd going on:
Silly me, I didn't paste the whole type error. Yes, GHC gives both. I should
add that I tested this
Assuming I get it included, is there any features in particular you'd want to
see in there? Note that if I do have it produce visualisations, they'll be
static images as part of an analysis report rather than being interactive.
I'd like the ability to show individual module dependencies, and
If you wanted to go down that route, try using 'ghc --make -v2'
and translate that dependency graph to dot.
Also, if you want to get a quick 'n dirty list of which of your own
files depend on which others, ghc -M $main.hs works quite well. I've
had some success in the past shoving this stuff
I have approx. 100+ source files and I was wondering if anyone has a tool
that would let me see a visual call graph for the source files; i.e. a
visual hierarchy of which module is imported by what, and so forth.
Hi Chris,
Programatica used to have such a thing for the module graph
It would be nice to have blogs for all Haskell GSoC projects
on Planet Haskell.
Infrequent updates (such as Neil's weekly summaries) would
be quite okay - details can always be followed up in email,
provided that interested parties are aware of them in the
first place;-)
Otherwise, we end up
In the specific case of parsing --version strings, I'm not sure regexes
are any easier. Using words and then selecting the Nth word seems to do
pretty well.
for comparison, see the examples below:-) There's no reason
this can't be massaged further, but it already allows for IO if
necessary (I
The main point of the Program abstraction is about configuring and
running programs. As it happens some programs are provided by some
haskell packages (but not all, eg ld, ar, etc).
option to get version info and code to extract it (with one apparently
very special case being hsc2hs).
And
Duncan Coutts wrote:
If we get a proper way to export a non-flat namespace then Gtk2Hs will
certainly switch to using it. Using 'buttonBlah' is horrible but there
is currently nothing better.
Whilst I'm sure anyone who's used deep module structures has wondered
about this feature, I've seen
http://hackage.haskell.org/trac/hackage/ticket/227
One problem is that not all build-tools correspond to haskell
packages. Some do some don't. We have a hard coded list of them
at the moment (which can be extended in Setup.hs files) so we
could extend that with what
To summarize: Monad isn't the proper abstraction for failable/Maybe.
Maybe is an algebraic data type that *exactly* represents the spirit of
what you're trying to do: e.g. Conor McBride said: Maybe is the most
general abstraction. Requiring (=), or even (*) seems excessive.
What we need is any
http://thread.gmane.org/gmane.comp.lang.haskell.libraries/9082
..
that Maybe is not the most general abstraction - it loses information
wrt to (Either String), for instance:
Prelude let {f [] = fail empty; f [_] = fail singleton; f l =
return l }
okay, I see, it's just that most partial
short answer: use newtype instead of type (and check the
language spec for the difference between the two).
Why does the code below not pass the type checker?
because of the type error?-) seriously, though, it is useful to
accompany such questions with some indication of what you're
trying to
Well, that's true. I guess what I'm really objecting to in Claus's message
is the implication that we should always use a Haskell Installation
Manager, even on systems with good built-in package management.
what was implied was that haskell installation manager (HIM)
and native package
I think that's fundamentally the wrong approach. We shouldn't have to
build a Haskell installation manager. Would you also want installation
managers for Perl, Python, Ruby, C, C++, etc. each with their own different
user interfaces and feature sets? I think not - you want a single package
https://bugs.launchpad.net/ubuntu/+source/gtk2hs/+bug/229489 this
is almost identical to my problem. I am just trying to help others on
this list who are using Ubuntu Linux to avoid my predicament!
I had that problem upgrading too.
I posted a workaround:
It's not that simple with bits. They lack consistency just like the
usual US date format and the way Germans read numbers.
So you claim that you pronounce 14 tenty-four? In German pronunciation
is completely uniform from 13 to 99.
http://www.verein-zwanzigeins.de/
So I've always wondered,
could collect all of them
On Fri, May 9, 2008 at 8:30 PM, Claus Reinke [EMAIL PROTECTED] wrote:
Ah, I didn't think about the GHC options that change the lexical
syntax. You're right, using the GHC lexer should be easier.
and, if you do that, you could also make the GHC lexer
squirrel away
Ah, I didn't think about the GHC options that change the lexical
syntax. You're right, using the GHC lexer should be easier.
and, if you do that, you could also make the GHC lexer
squirrel away the comments (including pragmas, if they aren't
already in the AST) someplace safe, indexed by, or
2008/5/2 Simon Marlow [EMAIL PROTECTED]:
David Waern wrote:
No it doesn't, but it's on the TODO list. It needs a fix in GHC.
By the way, I'm going to experiment with doing the parsing of comments
on the Haddock side instead of in GHC.
If that works out, we won't have to fix these things in
consider
class FD a b | a - b
instance CFD a b = FD a b
class CFD a b
instance CFD Bool Char
and the constraint 'CFD Bool c'.
logically, we know that if we have 'CFD Bool c', we also have 'FD Bool c',
which implies that 'c' is uniquely determined, which implies that 'c~Char'.
class C a b c | a - b, a - c
instance C a b b = C [a] [b] [b]
Suppose we encounter the constraint C [x] y z
interesting example. splitting improvement into two rules
seems to lose the (b1=b2) constraint that spans both:
[O]
C [x] y z = y=[b1].
C [x] y z = z=[b2].
my first thought was
how to account for [5], even with
a refined ruleset that accounts for [4].
suggestions?-)
claus
- Original Message -
From: Claus Reinke [EMAIL PROTECTED]
To: Martin Sulzmann [EMAIL PROTECTED]; Mark P Jones [EMAIL PROTECTED]
Cc: Tom Schrijvers [EMAIL PROTECTED]; Haskell-cafe Café
haskell
Sorry to be picky but there is no violation of the FD here. Note that
the class D has only a single ground instance and to violate an FD you
need at least two.
perhaps you are thinking of functional dependencies as
being defined extensionally, over the extent of the type
relations specified
Hi Marc,
when i first encountered Shim, i thought it was a nice idea, but
with a lot less emphasis on the vim side than on the emacs side.
also, iirc, Shim uses python's interprocess communication and i
didn't want to ask vim users to install python to get haskell
functionality. so i found
To make it legal: If foo' with a type signature doesn't type check,
try to infer a type without a signature. If this succeeds then
check that the type that was inferred is alpha-convertible to the
original signature. If it is, accept foo'; the signature doesn't
add any information.
The point is that the GHC type checker relies on automatic inference.
Hence, there'll
always be cases where certain reasonable type signatures are rejected.
..
To conclude, any system with automatic inference will necessary reject
certain type signatures/instances
in order to guarantee
type family Id a
type instance Id Int = Int
foo :: Id a - Id a
foo = id n
foo' :: Id a - Id a
foo' = foo
type function notation is slightly misleading, as it presents
qualified polymorphic types in a form usually reserved for
unqualified polymorphic types.
rewriting foo's type helped me
|Another notion I was interested in was to be able to reproduce a
|sequence of multi-module refactorings even in the absence of the
|initial module. It would allow to present a kind of interface diff
|for a distribution which would allow the developer of a module which
|depends on the
Well, we still need normal subject reduction (i.e., types don't change
under value term reduction), and we have established that for System
FC (in the TLDI paper).
In addition, type term normalisation (much like value term
normalisation) needs to be confluent; otherwise, you won't get a
again, i gave a concrete example of how ghc behaves as i would
expect, not as that decomposition rule would suggest.
Maybe you can explain why you think so. I didn't understand why you
think the example is not following the decomposition rule.
Actually, see
type family F a :: * - *
F x y ~ F u v = F x ~ F u /\ y ~ v
why would F x and F u have to be the same functions?
shouldn't it be sufficient for them to have the same result,
when applied to y and v, respectively?
Oh, yes, that is sufficient and exactly what is meant by F x ~ F
u. It means,
was hoping for. in fact, the decomposition rule seems to be
saying that type function results cannot matter, only the
structure of type family applications does:
F x y ~ F u v = F x ~ F u /\ y ~ v
or do you have a specific type rule application order in mind
where all type-level reductions
type family F a :: * - *
F x y ~ F u v = F x ~ F u /\ y ~ v
words, in a type term like (F Int Bool), the two parameters Int and
Bool are treated differently. Int is treated like a parameter to a
function (which is what you where expecting), whereas Bool is treated
like a parameter to a
type family F a :: * - *
F x y ~ F u v = F x ~ F u /\ y ~ v
why would F x and F u have to be the same functions?
shouldn't it be sufficient for them to have the same result,
when applied to y and v, respectively?
Oh, yes, that is sufficient and exactly what is meant by F x ~ F u.
It
type family F a :: * - *
..
We made the design
choice that type functions with a higher-kinded result type must be
injective with respect to the additional paramters. I.e. in your case:
F x y ~ F u v = F x ~ F u /\ y ~ v
i'm still trying to understand this remark:
- if we are talking
type family F a :: * - *
..
We made the design
choice that type functions with a higher-kinded result type must be
injective with respect to the additional paramters. I.e. in your case:
F x y ~ F u v = F x ~ F u /\ y ~ v
actually, i don't even understand the first part of that:-(
why
Let me summarize :-)
The current design for type functions with result kinds other than *
(e.g. * - *) has not gotten very far yet. We are currently stabilizing
the ordinary * type functions, and writing the story up. When that's done
we can properly focus on this issue and consider different
About 7 years ago such a tool existed:
http://www.cs.kent.ac.uk/people/staff/cr3/toolbox/haskell/GHood/
GHood was never intended to visualize graph reduction
directly (*). instead, it visualized observations - ie, you
could see if and when which parts of an observed data
structure was
[cc-ed to hopengl list; are there many haskell opengl users
not on that list, btw?]
a standard package for easy-to-use, high-quality, portable
font support would make a great addition to haskell's
otherwise nice opengl bindings!
is there a reason for going directly to freetype? from the
old
Maybe hardened Haskell programmers don't notice these things, but
there's a wall that goes up when Haskell is presented to
non-functional programmers. There are significant barriers for them to
cross (some of them imaginary): there's the infamous type system,
there's the mystique around monads,
if you want to make something like this for haskell (and
i'd very much like to use it!-), there are several issues,
including:
1 handling code:
- going for a portable intermediate representation,
such as bytecode, is most promising, especially
if the code representation is
hi,
with the large number of just chatting messages on
haskell-cafe, it is all too easy to miss problem reports
here. you might have a better chance asking on more
specific lists, eg. for ghc use, or library issues
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Is there any plugin system for haskell? For example, in Java, I can
load all compiled classes from given directory, check their interfaces
and run some methods through reflection etc. Is it possible in
haskell, to load modules from given directory, and if in module there
is instance of class
Granted, I'm lazy. I read release notes only and only few first pages
to see what's new. Couldn't GHCI be improved to at least give some
hints?
it does!-) watch the prompt, which says '*M', if all of M's top-level
is in scope, or 'M', if only M's exports are in scope. check here:
For technical reasons, GHCi can only support the *-form for modules
which are interpreted, so compiled modules and package modules can
only contribute their exports to the current scope. But it does mean
the interpreter isn't referentially transparent, which is weird for a
language that puts so
From my point of view, the difference between 0b10111011 and
(bin[1,0,1,1,1,0,1,1]) is 22-10 that is 12 characters.
how about using ghc's new overloaded strings for this?
10111011::Binary
there used to be a way to link to ghc head's docs, but
i can't find it right now. the test is
It has been noted in a few places that the 2 line quicksort demo in the
Introduction section of the haskell wiki
http://www.haskell.org/haskellwiki/Introduction
isn't a real quicksort, and wouldn't scale well with longer lists.
Interested, and wanting to put my recently learned test data
Hi Mark,
Declaration Formula
--- ---
class Eq a = Ord a forall a. Ord a = Eq a
instance Eq a = Eq [a] forall a. Eq a = Eq [a]
class C a b | a - b forall a, b. C a b /\ C a c = b = c
This correspondence between declarations and
Which reminds me that it would be nice to be able to ask for a list
of what imports I need to specify (i.e. what names from the module
are actually used). A case in point would be the example of non-
monadic I/O I sent to the list the other day: I wanted to specify
minimal imports, but
These two cases could be solved by re-exports, no extra mechanism is required.
yes, good support for re-export would be nice to have. the
reason it has so many applications is that it is a way to explain
connections between providers, apis, and clients to the package
manager.
- consider
Incedentally, this reminds me that GHC should have a warning for not using
explicit import lists (perhaps only for external package imports).
for package-level imports/exports, that sounds useful.
claus
___
Haskell-Cafe mailing list
the idea was for the cabal file to specify a single provided api,
but to register that as sufficient for a list of dependency numbers.
so the package would implement the latest api, but could be used
by clients expecting either the old or the new api.
I don't see how that could work. If the
if that is your definition of compatible, you can never throw any
packages away
Is this a problem?
apparently, yes. no two versions of base with ghc, only the
newest set of core packages with each ghc release. and how
much time do you want to spend on finding, re-building, and
re-installing
Be happy: we're about 15 years ahead of the lisp guys. 'cabal install
xmonad' works, for example.
- not on windows (and since it is popular, it will seduce more
good haskellers not to bother with windows compatibility.. :-(
- from xmonad.cabal (version 0.3, from hackage):
build-depends:
- if you provide a 'base' configuration that pulls in the stuff that
used to be in base, the package will work
I don't know of a way to do that. The name of the package is baked into
the object files at compile time, so you can't use the same compiled module
in more than one package.
1. Document the version numbering policy.
agreed. just making everybody's interpretation explicit has
already exposed subtle differences, so documenting common
ground will help.
We should have done this earlier, but we didn't. The proposed policy, for
the sake of completeness is: x.y where:
If the convention for modifying package versions of form x.y.z is:
- increment z for bugfixes/changes that don't alter the interface
- increment y for changes that consist solely of additions to the interface,
parts of the interface may be marked as deprecated
- increment x for changes that
I have another concrete proposal to avoid things breaking so often. Let us
steal from something that works: shared library versioning on unixy systems.
indeed!-) there are established workarounds that are needed to
make that system work as it does, so it is a good idea to check
whether cabal
are those tricks necessary in this specific case? couldn't we
have a list/range of versions in the version: field, and let cabal
handle the details?
I don't understand what you're proposing here. Surely just writing
version: 1.0, 2.0
isn't enough - you need to say what the 1.0 and 2.0 APIs
but calling split-base base goes directly against all basic
assumptions of all packages depending on base.
The new base will have a new version number. There is no expectation of
compatibility when the major version is bumped; but we do have an informal
convention that minor version bumps
You need a way to specify foo 1.2 foo 2, which is a
suggestion that was tossed around here recently.
but what does such a version range say? that i haven't tested any
versions outside the range (because they didn't exist when i wrote
my package)? or that i have, and know that later
but the name that is everywhere does not stand for what the new version
provides! any place that is currently referring to 'base' will have to be
inspected to check whether it will or will not work with the reduced
base package. and any place that is known to work with the new
base package
201 - 300 of 545 matches
Mail list logo
