- jhc - Haskell.org

Functional Reactive Programming
by jorge.pelizzoni＠gmail.com 13 Feb '12

13 Feb '12

1 0

new extension in jhc: explicit namespaces in import/export lists
by John Meacham 13 Feb '12

13 Feb '12

Hi, I implemented an extension in jhc that I thought the community might have feedback on and feel that a variant of it would be a candidate for future standardization. Here is the section from the jhc manual describing it. The 'kind' information is specific to jhc, and with this extension I'd really like to get rid of the wart in haskell 98 that names in 'hiding' lists are treated differently than names otherwise. I will likely make that change in jhc in the future once I work out the details of the best way to be backwards compatible. I have seen this exact proposal more-or-less come up on the lists periodically, so I guess I am just pointing to a concrete implementation now. # Explicit namespaces in import/export lists jhc allows explicit namespaces in import export lists. In haskell 98, a name such as 'Foo' in an export list will indicate that all of a class named Foo, a type named 'Foo' and a data constructor named 'Foo' shoud be exported. Jhc allows finer grained control by prefixing exports with a namespace indicator. The valid namespace indicators are * 'type' - The name is a type, as in something defined by type , newtype , or data , or the constructors of a kind declaration. * 'class' - Specifies that the name is that of a class. * 'data' - Specifies that the name is a data constructor. * 'kind' - specifies that the name is a user defined kind. In addition, classes and types are in independent namespaces, so a type and a class of the same name may be in scope and not conflict. When an unqualified name is given in a import/export list then all names that match it that are in scope are matched. The only exception is a holdover from haskell 98 where in hiding lists data constructors are not matched. This behavior may change in the future when explicit namespaces are used, so it should not be relied upon when using explicit namespaces. John

1 0

darcs patch: allow being explicit in export/import lists by specify...
by John Meacham 13 Feb '12

13 Feb '12

Fri Feb 10 21:21:57 PST 2012 John Meacham <john(a)repetae.net> * allow being explicit in export/import lists by specifying 'kind', 'class', 'type', or 'data'. add PTS rule to allow proper typing of Complex_

1 0

darcs patch: added user defined kind extension (and 1 more)
by John Meacham 13 Feb '12

13 Feb '12

Fri Feb 10 20:22:48 PST 2012 John Meacham <john(a)repetae.net> * added user defined kind extension Fri Feb 10 18:49:09 PST 2012 John Meacham <john(a)repetae.net> * fix Options.hs makefile dependency

1 0

darcs patch: add c-- types for complex and vector values (and 2 more)
by John Meacham 13 Feb '12

13 Feb '12

Thu Feb 9 21:10:26 PST 2012 John Meacham <john(a)repetae.net> * add c-- types for complex and vector values Thu Apr 14 00:39:38 PDT 2011 Sergei Trofimovich <slyfox(a)community.haskell.org> * added mingw32-gcc to MINGW search Wed Feb 8 22:53:34 PST 2012 Sergei Trofimovich <slyfox(a)community.haskell.org> * Add missing src/Options.hs to jhc tarball

1 0

ANNOUNCE: jhc-0.8.0
by John Meacham 12 Feb '12

12 Feb '12

I am happy to announce jhc 0.8.0 There have been A lot of major changes in jhc with this release. - http://repetae.net/computer/jhc - A brand new and sanified library description file format. Now it is a true YAML file. The previous quasi-cabal files are supported but deprecated. - new standard library 'bytestring' :) - jhc can now embed C code and header files directly into hl libraries. The code will automatically be unpacked and linked when needed transparently. This allows 'bytestring' to carry around its fpsstring.c low level implementaton for instance without having to coordinate the install of C headers/code along with the jhc haskell library. - the library description files now can affect pretty much any aspect of compilation, so it is much easier to make a self-contained build or for tools like configure/cabal to interface to jhc. They just need to spit out an appropriate yaml file rather than care about passing the right options to jhc in addition to creating a description file. See the user manual for the set of fields that can be set. - jhc now understands ghc-style LANGUAGE pragmas and -X options and will translate them into the appropriate jhc extensions as needed. - jhc transparently handles '.hsc' files (assuming you have hsc2hs installed). It even does the right thing when cross compiliing and will use the target architectures types rather than the hosts. - the bang patterns extension has been implemented. - the primtive libraries have been re-done, now there is a truely absolutely minimal jhc-prim library that is everything that must exist for jhc to work but brinsg in no code on its own. Everything else is implemented in user replaceable normal haskell code. Want to create a varient of haskell that has 16 bit Ints, ASCII 8 bit Chars and pervasively uses null terminated C style strings? just create a base-tiny library and link it against jhc-prim. - The standalone deriving extension has been partially implemented, this greatly improves the ability to re-arrange the libraries logically. - Better haskell 2010 compatibility. - Haskell object files and the --ho-dir have been fully removed in favor of pervasive use of the code cache. This allows jhc to cache compilation results with finer granularity than individual files would allow. Command line options have been renamed accordingly, we have --cache-dir, --no-cache, --readonly-cache and --ignore-cache to modify jhcs behavior with respect to the cache. Additionally a --purge-cache option has been added. - rather than trying to stuff everything in a monolithic .c file, jhc now builds a tree containing all the source needed to compile the final executable or shared library. This will help people porting jhc to new architectures and allows the embedding of c code in the haskell libraries. - Many programs typecheked in the past that were in fact, invalid. most now fail properly with an informative message. - pulled in most of the ghc typechecking regression tests. - internal class representation completely re-worked. - unboxed characters now supported, with the obvious syntax. John

2 1

jhc 0.8 internal error (LetFloat)
by Roman Cheplyaka 11 Feb '12

11 Feb '12

jhc --build-hl regex-applicative.yaml jhc 0.8.0 (mydniquipepo-32) Creating library from description file: "regex-applicative.yaml" Reading: "regex-applicative.yaml" Finding Dependencies... Using Ho Cache: '/home/feuerbach/.jhc/cache' Text.Regex.Applicative [./Text/Regex/Applicative.hs] Text.Regex.Applicative.Interface [./Text/Regex/Applicative/Interface.hs] Text.Regex.Applicative.Object [./Text/Regex/Applicative/Object.hs] Text.Regex.Applicative.Compile [./Text/Regex/Applicative/Compile.hs] <~/.jhc/cache/kb3lu73uegff4f51c0lq30kqlr.ho> Text.Regex.Applicative.Types [./Text/Regex/Applicative/Types.hs] <~/.jhc/cache/kgtlpnnmdsr78aljjmcqn6s0ti.ho> Text.Regex.Applicative.StateQueue [./Text/Regex/Applicative/StateQueue.hs] <~/.jhc/cache/sp3vi8t4kqgsfurdlkpa71sjp9.ho> Fresh: <~/.jhc/cache/kgtlpnnmdsr78aljjmcqn6s0ti.ho> Fresh: <~/.jhc/cache/kb3lu73uegff4f51c0lq30kqlr.ho> Fresh: <~/.jhc/cache/sp3vi8t4kqgsfurdlkpa71sjp9.ho> Typechecking... [1 of 3] Text.Regex.Applicative.Object(.............................................) [2 of 3] Text.Regex.Applicative.Interface(.............................................) [3 of 3] Text.Regex.Applicative(.............................................) Compiling... [1 of 3] Text.Regex.Applicative.Object<..................... >>> Exception thrown Writing: hs.out_lint-before-FloatOutward-Init.jhc_core LetFloat: could not find x38630396::Unknown Internal Error I attached the generated core file. I can also publish the source code that triggered the bug, if it helps. -- Roman I. Cheplyaka :: http://ro-che.info/

2 3

New Extension: foreign C imports that return multiple values
by John Meacham 11 Feb '12

11 Feb '12

I just implemented a new extension for jhc that I thought the community might have feedback on, it allows foreign imports of c routines to automaticall marshall multiple return values using the common fill in the pointer idiom used by the stardard C libraries. This completely removes most of the need for unsafePerformIO and the related Storable dependencies. Notably, many low lever floating point routines use this which really should be inlined and the optimizer can't see through the unsafePerformIO. here are the docs # foreign imports with multiple return values. foreign C imports may return multiple values. To indicate this is the case, use an unboxed tuple as the return value. The first return value will be the value the function directly returns, the rest will be passed as pointers at the end of the functions argument list. Only pure (non IO) functions may return multiple values. ~~~~ -- frexp has C prototype -- double frexp(double x, int *exp); -- so it would normally have an import like so, requiring the IO module and -- Storable to call what is otherwise a pure function. foreign import ccall "math.h frexp" c_frexp :: Double -> Ptr CInt -> IO Double -- This extension allows it to be declared as so foreign import ccall "math.h frexp" c_frexp :: Double -> (# Double, CInt #) -- The second return value is added as the last 'exp' parameter then read out -- of the allocated memory. The contents of the memory passed into the function -- is undefined. ~~~~ John

3 2

type of main
by Daniel Gorín 11 Feb '12

11 Feb '12

Hi I noticed that jhc is not checking what the type of the main function is. In particular, it rejects this module: > main = return () because the inferred type, Monad m => m () is not monomorphic. This may typically happen if the most general type for main is MonadIO m => m (). On the other hand, the following module is accepted: > main :: [()] > main = return () The resulting program does not crash (as I had expected!) but prints [()] instead. In any case, according to the Haskell 98 Report (sec. 5), main has to be "a computation of type IO t, for some type t". I'm attaching a patch that enforces this (I think) by unifying, during the type-checking, the type of the main function with IO t. Daniel

1 0

darcs patch: add extension to allow multiple return v... (and 1 more)
by John Meacham 11 Feb '12

11 Feb '12

Thu Feb 9 06:22:28 PST 2012 John Meacham <john(a)repetae.net> * add extension to allow multiple return values from c functions Thu Feb 9 12:13:51 PST 2012 John Meacham <john(a)repetae.net> * add documentation for the multi-return ccall extension, clean up code.

1 0