Re: Happy / Alex description for Haskell2010
I do not know why you do need a Haskell parser, but the Utrecht Haskell Compiler contains a combinator based Haskell parser (using the uulib package, supporting the offside rule) which might serve your needs. It can easily be adapted if needed. Doaitse Swierstra > Op 25 okt. 2018, om 20:31 heeft Sam Halliday het > volgende geschreven: > > Hello all, > > Is there a Happy / Alex file describing Haskell2010? > > I can see the versions in the ghc source tree, but of course they > support all the ghc extensions. The link to the hsparser page [1] in > the Happy documentation doesn't seem to exist anymore. > > I would also love to hear if there is a Bison definition. > > Best regards, > Sam > > [1] > http://www.pms.informatik.uni-muenchen.de/mitarbeiter/panne/haskell_libs/hsparser.html > ___ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
FYI
> Begin doorgestuurd bericht: > > Van: Job Vranish > Onderwerp: Antw.: as far as I can see > Datum: 12 juli 2018 om 3:17:23 CEST > Aan: doai...@swierstra.net > > Wow thanks! > > I’ve updated both. Thanks for letting me know and your help fixing it :) > > - Job > >> On Jul 11, 2018, at 4:44 PM, Doaitse Swierstra wrote: >> >> Dear Job, >> >> I made lenses compatible with the new version of GHC. can you put it on >> hackage if you approve and update the github too. It still contains an older >> version. >> >> Best, thanks, >> Doaitse Swierstra >> >> > ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
I discovered that the uu-options package does not compile due to a dependency on lenses, which does not compile with GHC 8.4
In case you want to try here is an updated lenses package. Best, Doaitse PS: I contacted Job (the author) in order to get things updated lenses.cabal Description: Binary data Setup.hs Description: Binary data LICENSE Description: Binary data <> ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
status of rebindable syntax for arrows
The GHC manual already for quite a number of version states:
• Arrow notation (see Section 7.17, “Arrow notation ”) uses whatever
arr, (), first, app, (|||) and loop functions are in scope.
But unlike the other constructs, the types of these functions must
match the Prelude types very closely. Details are in flux; if you want to use
this, ask!
When using this feature we get the error:
Var/Type length mismatch:
[s{tv aVL} [tv]]
[]
ghc: panic! (the 'impossible' happened)
(GHC version 7.8.3 for x86_64-apple-darwin):
tcTyVarDetails s{tv aVL} [tv]
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug;
So our question is whether we should really report this as a bug, and/or what
we can do about this.
Thanks for your help,
Doaitse
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
question about GADT's and error messages
Given the following code:
{-# LANGUAGE GADTs #-}
data Any a where
AInt :: Int - Any Int
-- demo 1 does not compile
{-
demo1 a = do case a of
(AInt i) - print i
Couldn't match expected type ‘t’ with actual type ‘IO ()’
‘t’ is untouchable
inside the constraints (t1 ~ Int)
bound by a pattern with constructor
AInt :: Int - Any Int,
in a case alternative
at /Users/doaitse/TryHaskell/TestGADT.hs:6:17-22
‘t’ is a rigid type variable bound by
the inferred type of demo1 :: Any t1 - t
at /Users/doaitse/TryHaskell/TestGADT.hs:5:1
Relevant bindings include
demo1 :: Any t1 - t
(bound at /Users/doaitse/TryHaskell/TestGADT.hs:5:1)
In the expression: print i
In a case alternative: (AInt i) - print i
Failed, modules loaded: none.
-}
-- all the following go through without complaints:
a = AInt 3
demo2 = do case a of
(AInt i) - print i
demo3 :: IO ()
demo3 = do case a of
(AInt i) - print i
demo4 = do case AInt 3 of
(AInt i) - print i
demo5 :: Any Int - IO ()
demo5 a = do case a of
(AInt i) - print i
I do not see why the error message in demo1 arises. It claims it can't match
some t with the type IO (), but when I tell that the result is IO () it can?
I think at least the error message is confusing, and not very helpful. I would
have in no way been able to get the clue that add a type signature as in the
case of demo5 would solve the problem.
What am I overlooking?
Doaitse
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
Although it will definitely solve all problems, it would help if hackage would automatically send out mails to maintainers of packages which do not compile with specific ghc versions. I have ran a couple of time into the situation where new GHC releases did nor compile my packages anymore, and I only found out by this being pointed out to me. I do not go over the hackage pages of my packages on a daily basis. The changes I had to make were usually minor, and fixing the problems was easy (except for the case where I had to a add a complicated local type, when let bindings were no longer polymorphic), Doaitse On Feb 10, 2013, at 10:50 , Manuel M T Chakravarty c...@cse.unsw.edu.au wrote: Simon Peyton-Jones simo...@microsoft.com: If there's a path to having a release strategy as Manuel suggests, and having an intermediate release with the new vector primops, type extensions and such goodness, then I'm all for it. A lot of these bits are things ill start using almost immediately in production / real software, esp if I'm not needing to patch every stable library beyond maybe relaxing versioning constraints. Let me suggest once more a possible path, along the lines you suggest ·For people who value stability: use the Haskell Platform. Ignore GHC releases. ·For people who want as many features as possible: use GHC releases. ·For people who want to live on the bleeding edge: build HEAD from source The Haskell Platform decides which GHC release to use, advertises that to package authors who do whatever updates are needed. HP may perfectly sensibly skip an entire release entirely. In short, I think we already have the situation that you desire. Perhaps we just need to market it better? Or am I mistaken? There is one kink: for GHC releases to be *useful* substitutes for the HP for people who want medium stability, they must not change (expect maybe add to) the APIs in GHC versions that do not coincide with HP releases. Why? If they change APIs, many of the packages on Hackage will not build with these intermediate GHC releases, which makes them useless for anything, but testing GHC. Otherwise, I am perfectly happy with your suggestion. However, this is not the status quo. All (major) GHC releases do break critical packages on Hackage. Manuel -- You received this message because you are subscribed to the Google Groups parallel-haskell group. To unsubscribe from this group and stop receiving emails from it, send an email to parallel-haskell+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Release plans
Just to show what kind of problems we are currently facing. The following type checks in our EHC compiler and in Hugs, but not in the GHC: module Test where data T s = forall x. T (s - (x - s) - (x, s, Int)) run :: (forall s . T s) - Int run ts = case ts of T g - let (x,_, b) = g x id in b Doaitse Swierstra On Apr 17, 2007, at 12:41 AM, Stefan O'Rear wrote: On Mon, Apr 16, 2007 at 03:54:56PM +0100, Simon Marlow wrote: - left-to-right impredicative instantiation: runST $ foo This concerns me. With each ad-hoc extension of the type system, I worry that soon the GHC type system will become so byzantine and ill-specified that the type checker can only be cloned, not substantially improved on. I personally have a type checker idea I am working on, but I doubt I will ever be able to implement features such as this, because the type checking abstraction is now leaking badly. Once the Hindley-Damas-Milner algorithm is exposed, I fear programmers will rely on it and progress in Haskell typechecker implementation will be effectively halted. (Yes, I know I'm a bit late in complaining...) - list fusion Nitpick - you did mean stream fusion, right? We think the above feature set makes for a pretty strong 6.8 release. What do you think of this plan? Are there features/bug-fixes that you really want to see in 6.8? Good code generation for loops. I understand they are rare in practice, but it's kinda disheartening to write memset() and see in the asm loop 11 memory references, 9 to the stack (numbers from unreliable memory). I don't mind the plan, either. Stefan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Release plans
On Apr 17, 2007, at 2:57 PM, Simon Peyton-Jones wrote: | Just to show what kind of problems we are currently facing. The | following type checks in our EHC compiler and in Hugs, but not in the | GHC: | | module Test where | | data T s = forall x. T (s - (x - s) - (x, s, Int)) | | run :: (forall s . T s) - Int | run ts = case ts of | T g - let (x,_, b) = g x id | in b And indeed it should be rejected! If you think it should be rejected, can you give me the translation into System F + data types? I don't think there is one, and that's why GHC rejects it. Yes, but where is it written that what cannot be expressed in system- F is type incorrect? We think it is still type safe, and it is an extrcat of a larger program that is quite useful (if we managed to compile it), Doaitse Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
package lang
I had to witch rather urgently to a new machine (an Intel based Mac OS X), on which I need to get lhs2TeX running. I have installed the ghc version from the page: http://cvs.haskell.org/trac/ghc/wiki/X86OSXGhc but when i try to compile lhs2TeX I get the following error message: /usr/local/bin/ghc -O -package lang --make -o lhs2TeX Main.lhs TeXCommands.lhs TeXParser.lhs Typewriter.lhs Math.lhs MathPoly.lhs MathCommon.lhs NewCode.lhs Directives.lhs HsLexer.lhs FileNameUtils.lhs Parser.lhs FiniteMap.lhs Auxiliaries.lhs StateT.lhs Document.lhs Verbatim.lhs Value.lhs Version.lhs ghc-6.5.20060608: unknown package: lang which refers to a package called lang. I looked in the list of packages at: http://www.haskell.org/ghc/dist/stable/docs/libraries/index.html which does not mention a package by that name. Also at http://hackage.haskell.org/trac/ghc/wiki/GhcDarcs this package seems to be unknown. The list of packages that apparently was installed with the compiler are: /usr/local/lib/ghc-6.5.20060608/package.conf: ALUT-2.0, Cabal-1.1.4, GLUT-2.0, HGL-3.1, HUnit-1.1, OpenGL-2.1, QuickCheck-1.0, X11-1.1, base-1.0, fgl-5.2, (ghc-6.5.20060608), haskell-src-1.0, haskell98-1.0, mtl-1.0, network-1.0, parsec-2.0, readline-1.0, rts-1.0, stm-1.0, template-haskell-1.0, time-0.3.1, unix-1.0 So my questions are: - what did I do wrong (I apologize for not being an able installer) - where can I find a package by the name lang - what is the next step to take Doaitse ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: instance inference
I have not followed this completely, but do these new rules now allow: class F a b c where f: a - b - c and then instance F a a a where ... which gives currenly gives (using -fglasgow-exts): Test.hs:6:0: Illegal instance declaration for `F a a a' (There must be at least one non-type-variable in the instance head Use -fallow-undecidable-instances to permit this) In the instance declaration for `F a a a' I recently ran into this, and I thought it to be perfectly reasonable, but GHC complained. On the other hand: instance F [a] [a] [a] where ... posed no problem, although I still see no non-type-variable in the head, or is [] a non-type-variable? I assumed the complaint was a left-over from the single parameter classes, where indeed having a single variable in an instance declaration does not make much sense. The second example does not follow the old rule (2) below! So rule (2) below is either not correctly implemented or not correctly stated or the error message is confusing, or I am missing something completely. Who can enlighten me? Doaitse because of the old rule (2) below. When I On 2006 feb 06, at 12:35, Ross Paterson wrote: A patch implementing a relaxed termination constraint is at http://www.soi.city.ac.uk/~ross/instance-termination.patch Here is the description: With -fglasgow-exts but not -fallow-undecidable-instances, GHC 6.4 requires that instances be of the following form: (1) each assertion in the context must constrain distinct variables mentioned in the head, and (2) at least one argument of the head must be a non-variable type. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: User-defined operators and compound expressions using Happy
On 2004 nov 22, at 17:48, Frank-Andre Riess wrote: Hi there folks, once again, I've got a question related to Happy (I've got version 1.13 at the moment). Maybe, it's even more a question on formal languages, but well... How can I write a grammar that can cope with user-defined operators (of different precedences/associativities) and compound expression like function calls, if-then-else- and case-statements and the like. I tried to write it down straight forwardly, but failed terribly (alas, I didn't keep it, so I can't show you - if someone of you is versed in this issue, I can try to explain the language's constructs). One way of doing this using combinator based parsing (where you can generate parsers dynamically) is to read the fixity declarations, and to use the result of this to build the precedence parser. This idea has been sketched in: S. D. Swierstra and P. R. Azero Alcocer. Fast, Error Correcting Parser Combinators: a Short Tutorial. In J. Pavelka, G. Tel, and M. Bartosek, editors, SOFSEM'99 Theory and Practice of Informatics, 26th Seminar on Current Trends in Theory and Practice of Informatics, volume 1725 of LNCS, pages 111--129, November 1999. If you do not have access to this I will be happy to send it to you, Doaitse Swierstra == some text (created from the pdf) from this paper As an example of what can be done we will now show how to construct parsers dynamically by writing a parser for an expression language with infix operators. An example input is: (L+R*)a+b*(c+d) and the code we want to generate is: abcd+*+ which is the reversed Polish notation of the input expressions. The text (L+R*) indicates that + is left (L) associative and has lower priority than *, which is right (R) associative. In this way an unlimited number of operators may be specified, with relative priorities depending on their position in this list. We start by defining a function that parses a single character identifier and returns as its result that identifier in the form of a string: pVar = (\c - [c]) $ pAnyOf ['a'..'z'] . The next step is to define a function that, given the name of an operator, recognizes that operator and as a result returns a function that will concatenate the two arguments of that operator and postfix it with the name of the operator, thus building the reversed Polish notation: pOp name = (\ left right - left++right++[name]) $ pSym name Note that, by using the operator $ we indicate that we are not interested in the recognized operator; we already know what this is since it was passed as a parameter. Next we de ne the function compile. For this we introduce a new combinator @, that takes as its left hand side operand a parser constructor f and as its right hand side operand a parser g. The results v of parsing a pre x of the input with g, are used in calling f; these calls, in their turn, result in new parsers which are applied to the rest of the input: (f @ g) input = [ f v rest | (v, rest) - g input ] Since our input consists of two parts, the priority declarations and the expression itself , we postulate that the function compile reads: compile = pRoot @ pPrios First we focus on the function pRoot, that should take as argument the result of recognizing the priorities. Here we will assume that this result is a function that, given how to parse an operand, parses an expression constructed out of operands and the de ned operators: pRoot prios = let pExpr = prios (pVar | pParens pExpr) in pExpr There is a difference between an operator that occurs in the declaration part of the input and one in the expression part: the former may be any operator, whereas the latter can only be an operator that has been declared before. For the priority declaration part we thus introduce a new parser that recognizes any operator, and returns a parser that compiles the just recognized operator using the function pOp defined before: pAnyOp = pOp $ pAnyOf +*/-^ just some possible operators Now suppose we have recognized a left and a right associative operator resulting in operator compilers pLeft and pRight. Out of these we can construct a function that, given the operand parser, parses infix expressions containing pLeft and pRight occurrences: pLR factor = (pChainl pLeft . pChainr pRight) factor. Generalizing this pattern to an unlimited number of operators we now deduce the definition: pPrios = pParens $ pFoldr ((.), id) (( pChainl $ pSym 'L' | pChainr $ pSym 'R' ) * pAnyOp ) Let us now compare once more this approach with the situation where we would have used a special parser generator. In the combinator approach we can freely introduce all kinds of abbreviations by defining new combinators in terms of existing ones; furthermore we may de ne higher order combinators that take arguments and return values that may be parsers. This is a property we get for free here
type definition with strict products
Title: type definition with strict
products
I a file that is too large to post here completely, I have
used:
type Result val s = (# val, Steps s
#)
and I get the error message:
UU_Parsing.hs:391:
Illegal unboxed tuple
type as function argument: (# val, Steps s #)
In the type: (# val, Steps s #)
While checking the RHS of a type synonym
declaration `Result'
In the type synonym declaration for
`Result'
using version The Glorious Glasgow Haskell Compilation
System, version 5.02.2.
Runningan earlier version of the compiler I get on the same file
the following error message:
ghc-5.00.2: panic! (the `impossible'
happened, GHC version 5.00.2):
dsExpr: tuple pattern:
let {
fail_d9jc
= PrelErr.patError
@ (b r,
UU_Parsing.Steps a,
UU_Parsing.Steps a,
UU_Parsing.Exp a,
UU_Parsing.Steps a)
(PrelBase.unpackCString#
UU_Parsing.hs:735|case)
} in
case ds_d9iL of wild_B1 { (# v, ds_d9iR #) -
case ds_d9iR of wild_B1 {
UU_Parsing.Best l m f r - (v, l, m, f, r);
__DEFAULT - fail_d9jc
}
}
Please report it as a compiler bug to
[EMAIL PROTECTED],
or http://sourceforge.net/projects/ghc/.
which is not very informative either.
My questions are:
- is this type definition really forbidden, and what does the
phrase function argument in the error message refer
to?
- was there a restriction introduced about what one may write at
the rhs of a type defintion between version 5.00.2 and
5.02.2?
Thanks for looking into this,
Doaitse Swierstra
--
__
S. Doaitse Swierstra, Department of Computer Science, Utrecht
University
P.O.Box 80.089, 3508 TB UTRECHT, the Netherlands
Mail:
mailto:[EMAIL PROTECTED]
WWW: http://www.cs.uu.nl/
tel: +31 30 253 3962
fax: +31 30 251 3791
mobile: +31 6 2880 1680
__
