Re: [Haskell-cafe] haskore - lilypond - typesetting?
I think the big question is whether you are dealing with music or scores. a .ly file represents not the music, but the music plus typographic annotations (and I find that even lilypond quite often benefits from hints). Most gui programs represent scores, but I think lilypond stands alone in that among text formats. So the question, to me, is whether you need a representation of music, or of a score; if of music, I would choose an input format other than lilypond (abc recommends itself from my folk-music background), using an appropriate backend for rudimentary typesetting. But if you need the full layout flexibility, I doubt you can beat writing straight lilypond: I have yet to see a frontend produce easily hand-edited lilypond source (which I find very quickly becomes a featureless blob without judicious use of whitespace), nor one that exposes the flexibility of the lilypond engine (and I find lilypond much faster to write than Finale, and little slower than Mozart's superb keyboar d entry (not being a keyboardist, I cannot speak for midi entry)). haskore and hly I would reserve for internal representations for conversion or transformation programs; I think there are much better alternatives for human writing. I would also be careful with excessively mathematical representations; before finding lilypond, I had to discard more than one program for failure to handle irregular meters. From: Haskell-Cafe [haskell-cafe-boun...@haskell.org] on behalf of Rustom Mody [rustompm...@gmail.com] Sent: Wednesday, August 21, 2013 10:46 AM To: Johannes Waldmann Cc: Haskell Cafe Subject: Re: [Haskell-cafe] haskore - lilypond - typesetting? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] question about indentation conventions
I always preferred (I think going back to my lisp days) foo x y z indenting subsequent arguments to the same level as the first, but I have not convinced haskell-mode to do that for me. (The general rule here being that similar things should be at the same indent, which will always result in subexpressions being further indented, but is somewhat more specific.) The case I never quite know what to do with is a series of expressions connected with operators, e.g. foo | bar | baz Leaving operators at the beginning of lines (rather than trailing the previous line) seems preferable, but does one (where the layout rules apply) align the operator or the function? (the alternative being, if your mail client does not make a mess of it with a variable-width font) foo | bar | baz ~IRS From: haskell-cafe-boun...@haskell.org [haskell-cafe-boun...@haskell.org] on behalf of Richard Cobbe [co...@ccs.neu.edu] Sent: Monday, July 01, 2013 8:00 AM To: haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] question about indentation conventions On Mon, Jul 01, 2013 at 05:18:39PM +1200, Richard A. O'Keefe wrote: It looked pretty explicit to me: The golden rule of indentation ... you will do fairly well if you just remember a single rule: Code which is part of some expression should be indented further in than the beginning of that expression (even if the expression is not the leftmost element of the line). This means for example that f (g x y z) is OK but f (g x y z) is not. Sure. So my first question boils down to which of the two alternatives below does the community prefer? (To be clear about the intended semantics: this is the application of the function f to the arguments x, y, and z.) f x y z or f x y z Both are correct, in most contexts. And then there's the second question: if the second alternative is preferable, is there a way to get haskell-mode to do it automatically? As it is, it refuses to indent y any farther to the right than in the first alternative. I can space it in by hand, and then haskell-mode puts z under y, but that's annoying, and it gets in the way of reindenting large regions of code automatically. Richard ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Annotation problem after HP reinstalation
Looks to me as if you have OverloadedStrings enabled somewhere, in which case
that would be the correct behaviour.
IRS
From: haskell-cafe-boun...@haskell.org [haskell-cafe-boun...@haskell.org] on
behalf of Vlatko Basic [vlatko.ba...@gmail.com]
Sent: Wednesday, June 26, 2013 11:05 AM
Cc: Haskell-Cafe
Subject: [Haskell-cafe] Annotation problem after HP reinstalation
I uninstalled haskell-platform, deleted .cabal and .ghc dirs and reinstalled it
(on Ubuntu), but now the annotation (and other annotations)
{-# ANN module HLint: ignore Eta reduce #-}
produces error
Ambiguous type variable `a0' in the constraints:
(Data a0) arising from an annotation at src/Model.hs:82:1-45
(Data.String.IsString a0)
arising from the literal `HLint: ignore Eta reduce'
at src/Model.hs:82:16-41
Probable fix: add a type signature that fixes these type variable(s)
In the expression: HLint: ignore Eta reduce
In the annotation: {-# ANN module HLint: ignore Eta reduce #-}
Have I missed to install/configure something?
vlatko
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Accessing resource files in tests
If you are running the tests from cabal, they will always be started in the directory with the .cabal file, and relative paths from there are fine. If that is not the case, could you provide more details about how you are running the test? Ian R. Sturdy From: haskell-cafe-boun...@haskell.org [haskell-cafe-boun...@haskell.org] on behalf of Graham Berks [gra...@fatlazycat.com] Sent: Thursday, May 09, 2013 1:55 AM To: haskell-cafe@haskell.org Subject: [Haskell-cafe] Accessing resource files in tests Hi, whats the recommended way to access a resource file for a test within cabal. I have a text file containing data that I use in a test and want to be able to access it in a root path independent manner. Thanks ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hackage checking maintainership of packages
Being in favor of not needlessly harassing people, even for a few minutes, I would favor issuing such emails only when there is some reason to believe that the package is not maintained. The two situations I can see that would justify such an email: - A dependency exceeds the upper bound listed in the cabal file. - It fails to build on the most recent GHC with its listed dependencies. Every three months, issue one email per address listing packages that are in one of those conditions at the moment and have been for at least a week (or longer--I care little there). I think this strikes a good balance between bothering people needlessly and doing nothing (although it does not properly catch unmaintained packages that build but with serious bugs; I welcome any automatic ways to determine that with reasonably low false positive rates). --IRS ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] data types with overlapping component names (in one module)?
True, and thank you for clarifying that. I was thinking of the names of the
field data, not the type-level name of the field:
name = Field :: name ::: String
-IRS
From: acow...@gmail.com [acow...@gmail.com] on behalf of Anthony Cowley
[acow...@seas.upenn.edu]
Sent: Tuesday, April 16, 2013 6:13 PM
To: Sturdy, Ian
Cc: haskell-cafe@haskell.org
Subject: Re: [Haskell-cafe] data types with overlapping component names (in one
module)?
On Tue, Apr 16, 2013 at 4:05 PM, Sturdy, Ian sturdy...@mail.wlu.edu wrote:
'vinyl' uses type-level literal strings and is very slick (although all
fields with the same name have the same type)
This is not entirely true, depending on what you mean by name. The
following is just fine. You only have naming issues if you want to
give @Field::baz:::Int@ a name, that name is, unsurprisingly, tied
to the field type of Int.
{-# LANGUAGE DataKinds, TypeOperators #-}
import Data.Vinyl
type Foo = '[baz ::: Int]
type Bar = '[baz ::: String]
x :: PlainRec Foo
x = Field =: 2
y :: PlainRec Bar
y = Field =: Two
Anthony
-IRS
From: haskell-cafe-boun...@haskell.org [haskell-cafe-boun...@haskell.org] on
behalf of Johannes Waldmann [waldm...@imn.htwk-leipzig.de]
Sent: Tuesday, April 16, 2013 8:17 AM
To: haskell-cafe@haskell.org
Subject: [Haskell-cafe] data types with overlapping component names (in one
module)?
What is the current situation: can we have two types
with overlapping component names in one module?
module M where
data T1 = C1 { foo :: Int }
data T2 = C2 { foo :: String }
It seems not (ghc says: Multiple declarations of 'foo'). This comes close:
http://www.haskell.org/ghc/docs/7.6.2/html/users_guide/syntax-extns.html#disambiguate-fields
but still requires the definitions to reside in different modules?
This is a major pain (it forces me to spread the source over several files),
and also a show-stopper when selling Haskell to OO folks, who naturally
assume that a class also denotes a scope. (And that you could nest them.)
Are/were there plans/proposals to address this?
- J.W.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] data types with overlapping component names (in one module)?
I have seen some talk about fixing this, but none anywhere close to reality. As
far as what you can use now, there are several libraries implementing
alternatives to records; 'vinyl' uses type-level literal strings and is very
slick (although all fields with the same name have the same type), while
'fields' uses template Haskell (and I think there are some others as well). I
have used 'vinyl' a fair amount with great success; the others I cannot
evaluate from experience.
-IRS
From: haskell-cafe-boun...@haskell.org [haskell-cafe-boun...@haskell.org] on
behalf of Johannes Waldmann [waldm...@imn.htwk-leipzig.de]
Sent: Tuesday, April 16, 2013 8:17 AM
To: haskell-cafe@haskell.org
Subject: [Haskell-cafe] data types with overlapping component names (in one
module)?
What is the current situation: can we have two types
with overlapping component names in one module?
module M where
data T1 = C1 { foo :: Int }
data T2 = C2 { foo :: String }
It seems not (ghc says: Multiple declarations of 'foo'). This comes close:
http://www.haskell.org/ghc/docs/7.6.2/html/users_guide/syntax-extns.html#disambiguate-fields
but still requires the definitions to reside in different modules?
This is a major pain (it forces me to spread the source over several files),
and also a show-stopper when selling Haskell to OO folks, who naturally
assume that a class also denotes a scope. (And that you could nest them.)
Are/were there plans/proposals to address this?
- J.W.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Prolog-style patterns
I am somewhat skeptical of this extension; guards seem to work, and while I use syntax extensions somewhat liberally I am not certain this provides enough benefit to restrict code to GHC. I used it extensively in Erlang, but I find myself doing much less pattern matching in Haskell. That said, I am unconvinced by most of the arguments against it. Accidental variable collisions from refactoring would usually produce a type error or a partial function warning, and in any event I have never seen Erlang programmers complaining about this feature causing problems (and Haskell has far better compile-time tools for identifying its misuse). As far as the use of Eq goes, Eq is already enshrined in pattern matching by pattern matching against literals. And yes, with OverloadedStrings you can pattern match against anything with an IsString instance. If a type has a nonsensical Eq instance, I do not think that the programmer is any more likely to absentmindedly try `f x x = ` than the equivalent `f x y | x == y =`. Bad Eq instances have enough pitfalls already that I do not see much problem with adding another. Ian From: haskell-cafe-boun...@haskell.org [haskell-cafe-boun...@haskell.org] on behalf of Daniel Trstenjak [daniel.trsten...@gmail.com] Sent: Tuesday, April 09, 2013 9:07 AM To: haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] Prolog-style patterns Hi Jan, On Tue, Apr 09, 2013 at 01:32:33PM +0200, Jan Stolarek wrote: Thanks for pointing me to earlier discussions on this subject - they are enlightening :) One particular argument against seems to be very convincing to me: From a language design point of view, it should be noted that turning non-left linear patterns into ones with == guards elevates the class Eq to built-in status - but the compiler has no semantic control over it. Yes, I can see the point, but in the case of Haskell with its ability to automatically derive the Eq instance, there's some kind of semantic control, and if an user writes a nonsense Eq instance, than he just really asks for some hurting ;). Regarding the possibility of making accidental mistakes during refactoring etc. This could be implemented as a language extension, requiring explicit LANGUAGE pragma. So people using it would know they have semantics slightly changed and need to be aware that there is a possibility of making these kind of mistakes. I'm a bit torn between all these GHC extensions. If your code doesn't compile, did you really made a mistake or just forgot to include a GHC extension ... But I also have the feeling, that the extension perhaps might not be worth it, because the difference between foo x x = ... and foo x y | x == y = ... is just IMHO too small. Greetings, Daniel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] cabal install...
The latest version of cabal-dev on Hackage does not seem to have had its dependencies updated for GHC 7.6. Try installing off github (https://github.com/creswick/cabal-dev). Ian Sturdy From: haskell-cafe-boun...@haskell.org [haskell-cafe-boun...@haskell.org] on behalf of Eric Velten de Melo [ericvm...@gmail.com] Sent: Tuesday, November 20, 2012 7:54 PM To: Johan Tibell Cc: Gregory Guthrie; haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] cabal install... I have a dream of one day being able to install leksah without having to downgrade ghc. Right now I can't even install cabal-dev with cabal. It will break ghc if I do. 2012/11/20 Johan Tibell johan.tib...@gmail.com: On Tue, Nov 20, 2012 at 1:10 PM, Gregory Guthrie guth...@mum.edu wrote: Hmm, Now when I tried to run Leksah, I get not only some broken packages (which I can avoid for my current project), but: command line: cannot satisfy -package-id base-4.5.1.0-7c83b96f47f23db63c42a56351dcb917: base-4.5.1.0-7c83b96f47f23db63c42a56351dcb917 is unusable due to missing or recursive dependencies: integer-gmp-0.4.0.0-c15e185526893c3119f809251aac8c5b (use -v for more information) So I tried to install base, then re-install it, but both fail; Any hints? From this email and some of the previous emails it seems that your package DB is in a pretty bad state, most likely from using --force-reinstalls. When Cabal warns you that this will break stuff it actually means it. :) My suggestion is that you rm -rf ~/.ghc/x86_64-linux-7.6.1 # or equivalent on your system. Then reinstall all the packages you want by listing them all at once cabal install pkg1 pkg2 pk3 By listing them all together cabal-install tries to come up with an install plan that is globally consistent for all of them. -- Johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Compilers: Why do we need a core language?
* It can also be easier to apply high level optimization techniques; if you go straight from the highest level code to the lowest level, you are likely to miss optimization opportunities that are only revealed (or only sanely implementable) at intermediate levels. Not to mention that since optimizations are often expressed as replacements (note how stream fusions are implemented), optimizing after desugaring reduces the number of patterns an optimization needs to match against. By my understanding, GHC does not compile to core and then reparse the core file; 'core' is merely the name given to a certain stage in syntax tree manipulations. Thus, a compiler with no analogue of core would forego all syntax tree manipulations, instead taking the raw parse tree and running the code generator on that. And while that can be done for a sufficiently simple language, for a language with the complexity of Haskell I dare say that it is impossible: Because... have you ever tried to write a type-checker for character sequence? I'm sure some mad genius can do it, but I don't want to be that mad genius. -- Ian Sturdy sturdy...@mail.wlu.edu From: haskell-cafe-boun...@haskell.org [haskell-cafe-boun...@haskell.org] on behalf of Albert Y. C. Lai [tre...@vex.net] Sent: Tuesday, November 20, 2012 12:47 PM To: haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] Compilers: Why do we need a core language? On 12-11-20 06:54 AM, c...@lavabit.com wrote: I know nothing about compilers and interpreters. I checked several books, but none of them explained why we have to translate a high-level language into a small (core) language. Is it impossible (very hard) to directly translate high-level language into machine code? Let the overall distance be fixed. More steps over that same distance means each step is smaller, easier to design, easier to understand, easier to correct if there are mistakes. Forget code generation. Just parse and validate and then discard. Already there are like 4 steps. Translate character sequence into token sequence. Translate token sequence into grammar tree, while checking grammar. Translate grammar tree into declaration groups, identifier lookup tables, etc., while checking whether every used identifier is declared or imported. Translate those groups and tables into type-annotated groups and tables, while checking types. Whew! After 4 steps of translating this to that, we still haven't reached the core language! Why? Because... have you ever tried to write a type-checker for character sequence? I'm sure some mad genius can do it, but I don't want to be that mad genius. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
