Is there some way to use any of the various regex packages on hackage via yhc? Has anyone installed one them successfully? I'd like regex-tdfa, but would settle for regex-posix, or really, anything that brings the convenience of regex to yhc. In general, is there a straightforward way to install "extralibs" type packages for universal "import" availability in yhc? Is there a cabal equivalent for yhc? Documentation pointer would be appreciated; I searched but couldn't find anything. Maybe not using the right keywords... t. --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
On a related note... is there some easy way to be sure that a program I am compiling uses only haskell 98? (Because any pure haskell 98 should always compile on yhc... right?) Say I have module M where import A ... I compile this with ghc, no options, and iIt doesn't have any {-#-#} options, so according to what I understand, it is using pure haskell 98. So I might think this was a candidate for using on yhc. However what if module M uses non-haskell 98 features, and I would want the compile to fail because it uses something beyond h98? (Which would warn me that attempting to migrate this to yhc is going to be Work at the least, maybe not doable at all at the worst.) Is there a way to do that? t. Thomas Hartman/ext/dbcom@DBAmericas Sent by: haskell-cafe-bounces@haskell.org 12/06/2007 03:21 PM To yhc@haskell.org, haskell-cafe@haskell.org cc Subject [Haskell-cafe] regex package for yhc? Is there some way to use any of the various regex packages on hackage via yhc? Has anyone installed one them successfully? I'd like regex-tdfa, but would settle for regex-posix, or really, anything that brings the convenience of regex to yhc. In general, is there a straightforward way to install "extralibs" type packages for universal "import" availability in yhc? Is there a cabal equivalent for yhc? Documentation pointer would be appreciated; I searched but couldn't find anything. Maybe not using the right keywords... t. --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
On Thu, 6 Dec 2007, Thomas Hartman wrote:
On a related note... is there some easy way to be sure that a program I am compiling uses only haskell 98? (Because any pure haskell 98 should always compile on yhc... right?)
You can for instance use 'haskell98' as dependent package instead of 'base' in the Cabal description. If you import other modules, I don't know how to check that these are Haskell 98. I weakly remember corner cases where GHC accepts more than Haskell 98 in Haskell 98 mode. (At least it sometimes suggests fixes for errors that are not Haskell 98, e.g. class constraints in signatures. :-)
I compile this with ghc, no options, and iIt doesn't have any {-#-#} options, so according to what I understand, it is using pure haskell 98. So I might think this was a candidate for using on yhc.
I could not always pass a GHC-certified module to Hugs or even Haddock. I remember there is some difference with respect to the trailing 'where' in the 'instance' head, if the instance declaration is empty. Haddock expect some spaces in infix operators (I believe ( # ) instead of (#)), which are not required by Hugs and GHC.
On Thu, 6 Dec 2007, Henning Thielemann wrote:
On Thu, 6 Dec 2007, Thomas Hartman wrote:
On a related note... is there some easy way to be sure that a program I am compiling uses only haskell 98? (Because any pure haskell 98 should always compile on yhc... right?)
You can for instance use 'haskell98' as dependent package instead of 'base' in the Cabal description. If you import other modules, I don't know how to check that these are Haskell 98. I weakly remember corner cases where GHC accepts more than Haskell 98 in Haskell 98 mode. (At least it sometimes suggests fixes for errors that are not Haskell 98, e.g. class constraints in signatures. :-)
Now I have an example: GHC-6.4.1 accepts multi parameter type class constraints without '-fglasgow-exts'.
I compile this with ghc, no options, and iIt doesn't have any {-#-#} options, so according to what I understand, it is using pure haskell 98. So I might think this was a candidate for using on yhc.
I could not always pass a GHC-certified module to Hugs or even Haddock. I remember there is some difference with respect to the trailing 'where' in the 'instance' head, if the instance declaration is empty. Haddock expect some spaces in infix operators (I believe ( # ) instead of (#)), which are not required by Hugs and GHC.
Thomas Hartman wrote:
Is there some way to use any of the various regex packages on hackage via yhc? Has anyone installed one them successfully?
I'd like regex-tdfa, but would settle for regex-posix, or really, anything that brings the convenience of regex to yhc.
In general, is there a straightforward way to install "extralibs" type packages for universal "import" availability in yhc?
Is there a cabal equivalent for yhc? Documentation pointer would be appreciated; I searched but couldn't find anything. Maybe not using the right keywords...
t.
I put the regex-* packages on hackage. I have had no reports of use with yhc. Some of the convenience comes from the regex-base font end. The high level (=~) and 'match' regex API depends on the MPTC's of regex-base, and these currently use functional dependencies. This works on GHC and Hugs. I cannot quickly find on http://www.haskell.org/haskellwiki/Yhc what YHC supports. The regex-posix package is a backend, the oldest. It exposes the platform's POSIX regex.h library through the FFI calls in Text/Regex/Posix/Wrap.hsc. This C api is further layered in the data type specific modules: Text/Regex/Posix/String.hs Text/Regex/Posix/Sequence.hs Text/Regex/Posix/ByteString.hs Text/Regex/Posix/ByteString/Lazy.hs And all of that is re-exported in Text/Regex/Posix.hs A similar design is followed by the regex-pcre backend (and the deprecated regex-tre backend). One _could_ refactor regex-posix into two packages. One would give standalone accesses to the backend and simply be Haskell98 + FFI. The other would declare the instances to make this available though regex-base. The regex-tdfa backend is my own creation, and is not a wrapper for another library. It uses some non-Haskell98 syntax, such as the "mdo" syntactic sugar for MonadFix (aka recursive do). Cheers, Chris
Hi
I cannot quickly find on http://www.haskell.org/haskellwiki/Yhc what YHC supports.
From the (just modified) FAQ: http://www.haskell.org/haskellwiki/Yhc/FAQ#Language_Support
Q) What extensions does it support? A) Very few. Existentials and pattern guards are supported. Rank-2 types, multiparameter type classes and most other extensions are not. Thanks Neil
On Thu, 2007-12-06 at 15:21 -0500, Thomas Hartman wrote:
Is there a cabal equivalent for yhc?
One day we hope Cabal will support yhc. It currently supports ghc, hugs and has partial support for nhc98 and jhc. The main thing holding it back is dependency chasing in Cabal or the lack thereof. Cabal relies on the build-in dep chasing in hugs, ghc --make. It uses hmake for nhc98. We hope to replace this hodge-podge with proper dependency chasing support in Cabal, that's also extend to pre-processors etc. If anyone is interested in helping with this project, subscribe to cabal-devel and get involved. Duncan
participants (5)
-
ChrisK -
Duncan Coutts -
Henning Thielemann -
Neil Mitchell -
Thomas Hartman