Library for arrays, almost done. Related to arrays: primitives did require annotation for FFI calls, to know whether an ffi returns an evaluated value. By default this is true, but for the primitive reading a value from an array this is not, because arrays may store unevaluated thunks. For now it is a bit of ad-hoc solution, and the annotation really only is required for Grin code generation (because an explicit eval is required after the call) and by the eval elimination transformation (because it can only assume evaluation depending on the annotation). It has to be checked with full prog analysis and eval inlining. Fix of combination of a strict binding (via letstrict) and additional bindings for proven class predicates. The binding order here matters because there is an explicit evaluation order, but bindings were mixed up. Now the two kinds of bindings (strict and non strict) are separated and bound in the correct order. The problem did not arise until now because the bound expression usually consisted of a single non overloaded identifier. In the Data.Array library however, much work is done in the ST monad and requires explicit evaluation.
- Fix for polarity inference being too restrictive - Jazy backend works for major part of regression test examples - Some refactoring for info about types known by the compiler (builtin stuff) WARNING: modifications to the IO monad breaks the HPT analysis!!
… working around not-yet implemented stuff like Typeable (in order to be able to use unmodified ghc libraries). - introduced -c/--compile-only flag, to enable compilation without linking, for building libraries. WARNING: previously -c was used as an abbreviation for --code. Not so anymore! - the flag -P is not necessary anymore, it has been renamed to -i/--import-path to be compatible with ghc. - commandline can take a set of modules to compile instead of 1. - fixed a bug arising because of multiple commandline modules: name of file can differ from module name, which was ok for 1 module, but for many the dependency graph and internal admin got screwed up.
- build: scratch for building, may be thrown away harmlessly - install-for-build: (cabal) installed libraries, of which the manual removal would lead to a dangling package reference to the library - install: the structure needed for ehc to run, libraries, runtime system, etc In particular the install directory distinguishes between: - variant - target (for codegeneration) - package (not yet done, but prepared) with the following hierarchical structure: install <variant> bin lib shared <target> <package> include shared <target> Codegeneration targets can be specified with the option --target=<target>, where <target> may be (default 'bc'): bc: bytecode C: full program analysis C core: Core only With 'make <variant>/ehclib' a library for the default target is build. With 'make <variant>/ehclibs' libraries are built for a set of targets, currently 'bc', 'C', and 'core'. The makefile for libraries has hooks for tailoring the build for a target. The compiler (for e.g. variant 100) is located in install/100/bin/ehc, other stuff hopefully just as self evident. The idea is - to be able to use runtime+library for different codegeneration targets simultaneously, - to take install/<variant> and install/copy it at install time. - configuration of these locations is stored in a per user per application configuration file (system dependent, but portable), 'ehc --meta-dir-env' will tell which directory, the default is hardwired so no search paths (option -P) need to be given anymore. Additional issues: - do 3d party libraries (like gmp, bgc) survive an install without configure? this seems to be ok. UHC installation: type: make uhc sudo make install NOTE/WARNING: - bin/<variant>/ehc compiler location is now obsolete. - 'make <variant>/ehclib' now also must be run for codegen variants, because making the runtime system has been moved to that stage. Best to use 'make <variant>/ehclibs' as to build all. - before using this checked out version, it best is 'make clean' and then manually remove what remains of the top level 'install' directory. - internally, uhc compiles as variant 101, but the variant number is currently the only difference between the preceding variant 100. However, variant 100 is not used, because the configuration file is specific to the variant, so both can live alongside eachother. - uhc installation is done from the svn repository. In the future other ways of installing possibly will be offered: - from a binary, fully compiled install tree, only to be copied - from a source level non chunked version (via barebones building), no AG system required then, only ghc + uu libraries TODO: - aspect specific building must be checked - support for packages must be completed, in particular library building
- library modules can be in shuffle format, as to allow its incorporation into documentation - from the ghc distribution a set of library modules can be selected for incorporation into ehc (called frozen). This works as follows: - the ehc svn repo must has an archive containing these files (currently: ehclib/ehcbase/ehclib-ghc-sync-frozen.tgz). - from this archive all .hs files are extracted, compiled into ehc's library. - separately from the above 'make ehclib-ghc-sync' downloads the ghc distribution and extracts+builds the frozen version, which then with the next svn commit is put into the svn repo. - the file ehclib/files.mk has entrypoints for specifying which modules from which packages must be included. - all package structure is removed, so there is just a flat (w.r.t. packages) namespace for hierarchical modules. - for now only Data.Maybe is included. More to follow. - NOTE: consequences: - all library modules have to be preprocessed by cpp - ehc specific dependencies are not incorporated, hence now __HUGS__ is defined by ehc as the library structure mostly mimics that of hugs. - regression testing now assumes the appropriate ehclib is built
…le system etc. Not yet put to use by fitsIn, nor finished yet, but does not hinder either. - Fixes for polarity inferencing: - unnecessary substitutions, - inference for tuples (missing binding in environment for "_Rec" record constructor), - error messages for absent bindings (strictly not necessary, but helps debugging) - Feature interaction: - type synonyms - dependency on presence of 'error' for data types with fields caused Exception to be in the same binding group as error, leading to too strict polarity - Todo: - Had to turn off UUAGC strictness pragmas in EH/MainAG because of loop, unclear why as no cycles are reported. - Proper analysis for class predicates and type annotations 'e :: t', currently either too liberal or too strict - Other fixes/improvements: - mutual recursive type synonyms are allowed, infinite recursion was already checked during synonym expansion. - improved cyclic/infinite type reporting - rerun ./configure
…ake test-regress TEST_VARIANTS=101' thus can be used to test regress the installed uhc. A variant independent 'make test-regress TEST_VARIANTS=uhc' is also allowed.
… Prelude available), for <v> >= 99: - requires build of ehclib: make <v>/ehclib - usual interface: make test-regress/test-expect TEST_VARIANTS=<v> - NOTE: test behavior is different for <v> >= 99 (see test/files.mk) : run ./configure first Cleanup of GBM codegen.
…rectly. Proper use of internal lookup in type environment (not a problem but was unclear). Regression test also compiles+executes GBM code and full prog analysis code.
Except explicit passing of implicit parameters (moved to variant 12), higher order predicates (moved to variant 13), and extensible records (in variant 10). Not all relevant code has changed its shuffle variant number yet (syntax is still permitted). Test files have to move accordingly but svn enforces this to be done in multiple steps.
…ug fix in quantification
…s fixed, regress test of *.eh test files
…re testing), module stuff into new version 12 (11 will be type synonyms)
…to cater for WinXX)