June 2014 - jhc - Haskell.org

Re: [jhc] [Haskell-cafe] improved jhc manual
by John Meacham 16 Jun '14

16 Jun '14

On Sun, Jun 15, 2014 at 10:10 PM, <musicdenotation(a)gmail.com> wrote: > The implementation of unboxed types and defined kinds in JHC appears to be incompatible with GHC (`Int_` instead of `Int#`, `data kind` instead of just `data` and promote every suitable type). Please fix this. They are different because they are somewhat different things. GHC and jhc have very different intermediate and back end languages, ghc's is based on system F with a backend distantly descended from the G machine and jhc has an intermediate language based on a PTS similar to the lambda-cube* and a backend descended from boquit's GRIN intermediate language and these decisions constrain the semantics of unboxed values for both compilers. Likewise, the type systems are different in some ways, for instance jhc supports polymorphism of unboxed types so there is no need for 1# and 1## being different types. It has a different kind hierarchy because in the back end 'evaluation' and 'case matching' are independent operations which in ghc they are intertwined, so you can directly branch on a value if you know it is already evaluated which is a particularly advantagous. jhc unboxed constructors are normal so no special Hash syntax is needed to denote them. Since jhc has no run-time it's unboxed values need to be at a lower level than GHC's to take advantage of optimizations based on that. For instance, ghc has independent types for unboxed Int's and Word's, however, as far as a CPU is concerned there are only values of a certain bit width and no signendedness information is on the type. Jhc follows CPU operations. It just happens that the instance Num Word in jhc uses unsigned primitives and the instance Num Int uses signed ones but they both are boxed 'Bits32_' underneath. The kind extensions were independently developed hence the different syntax, I am not a fan of eating syntax or filling the data tables with most likely unused kinds automatically... but I may change my mind on that in the future, User defined kinds are still fairly new so I want to see more how they are used in practice for a while, In any case, PolyKinds are next up in the kind system for implementation. *My IL is very similar to and was inspired by Henk actually (http://www.staff.science.uu.nl/~jeuri101/MSc/jwroorda/) -- John Meacham - http://notanumber.net/

1 0

Re: [jhc] [Rejected Paper] Experience Report: Writing NetBSD Sound Drivers in Haskell
by Kiwamu Okabe 11 Jun '14

11 Jun '14

Hi Henning, On Wed, Jun 11, 2014 at 6:33 AM, Henning Thielemann <schlepptop(a)henning-thielemann.de> wrote: > Since you are concerned with low-level Haskell programming, what do you > think about the Reduceron project? I also wondered whether it would be > possible to teach functional programming to processors with customizable > machine code like the Transmeta processors. I don't know whether comparable > projects are still alive. http://www.cs.york.ac.uk/fp/reduceron/ Oh, I hasn't know it. Thank's. I am not good to talk about HDL. However,a part of jhc's runtime can be designed with HDL, perhaps. Main part of jhc's runtime is GC. The GC clears bit marking array before marking. The clearing can be executed by HDL in parallel. Regards, -- Kiwamu Okabe at METASEPI DESIGN

1 0

[Rejected Paper] Experience Report: Writing NetBSD Sound Drivers in Haskell
by Kiwamu Okabe 10 Jun '14

10 Jun '14

Hi jhc-hackers, I have written a paper "Experience Report: Writing NetBSD Sound Drivers in Haskell". http://metasepi.org/papers.html It explains Ajhc customized jhc GC, and sometime useful to develop jhc. Thank's, -- Kiwamu Okabe at METASEPI DESIGN

2 10

jhc repo update
by John Meacham 09 Jun '14

09 Jun '14

Just an update on the recent changes in the repo: The good - completely rewritten from scratch deriving mechanism that actually, well, works in many cases the old one didn't. The old one relied on generating haskell source code that was then fed back into the compiler, the new one generates the AST directly. This is a drastic improvement. - standalone deriving now works for most classes, and multiple derived instances will not conflict. - deriving Typeable, Foldable, Traversable, Typeable, and Ix have been added. - LambdaCase extension implemented, this actually turned out to be extremely useful internally as it allows desugaring of do and list comprehensions directly without requiring a unique name source to be piped through, quite handy. The later I can move these desugarings the better the error messages jhc generates are. - -X extension handling revamped to be less ad-hoc. there is a map in src/Options/Map.hs to map -X flags to jhc internal feature flags. The bad - lamba case seems to tickle a bug in the type checker, I need to make special provisions to ensure it is applied Monomorphically just like a real lambda. - Read and Show formatting have slightly changed so break regtests but are still valid. need to tweak them. should probably just conform to what ghc does for whitespace in case anyone out there depends on the exact formatting. -- John Meacham - http://notanumber.net/

1 0

Newbie question...
by James Crayne 09 Jun '14

09 Jun '14

I appologize if this is the wrong forum for this question, but I couldn't find anyone to help on IRC and I don't know what mailing list this should go to otherwise. I installed ajhc from cabal, following the instructions in the manual, and everything compiled seemingly without a hitch, but when I tried to use the compiler to compile a simple helloworld, it complained about libraries. What is the quikest/simplest remedy? Also, It would seem to me that the manual needs an update? As is, it implies pretty strongly that this should just work. $ cat helloworld.hs main = putStrLn "hello world." $ ajhc helloworld.hs ajhc helloworld.hs ajhc 0.8.0.10 (66a602abc10dec74e2c0bb9289819a015bf21e4f) Finding Dependencies... Using Ho Cache: '/home/jim//.ajhc/cache' Libraries not found: haskell-extras haskell2010 haskell98 Technically, I intend to compile to C, but I get the same error message with -C.

2 1

improved jhc manual
by John Meacham 04 Jun '14

04 Jun '14

Hi all, I just wanted to show off the new jhc manual http://repetae.net/computer/jhc/manual.html If anyone has any feedback, that would be great, even better would be patches of course :) Manual writing is not my strong point. The entire manual is in the darcs repo as markdown formatted files or as literate code embedded in the source files. Something I need to figure out is how to get haddock to not barf on jhc's input files. A problem with haddock is that it tries to replicate ghc's module chasing algorithm and falls down when anything is slightly off, jhc's ability to handle recursive modules throws it for a loop. Now I can easily get jhc to spit out fully resolved module names, it does so with the --annotate-source option, but need some sort of hook into haddock saying "don't try to resolve module names, here they all are." Even haddock just having a 'keep going' option would be great to get something out there. Or even improving haddock to handle recursive module imports. John -- John Meacham - http://notanumber.net/

1 0

ANNOUNCE: jhc 0.8.2
by John Meacham 02 Jun '14

02 Jun '14

Lots of internal improvements in this one, so may be of more interest to developers http://repetae.net/computer/jhc/ - completely replaced the front end parser/lexer with a new more flexible one. My rewritten one is about 3,250 lines shorter. - The new one uses a general precedence parser for application as well as infix operators, allowing consistent handling of bang, irrefutable, and @ patterns and allows prefix and infix operators with a higher precedence than application to be defined. Incidentally, this allows for ~ and @ in expressions. (~) = negate (prefixr 11) gives us a nice strongly binding negative and @ (infixr 12) is perfect for type directed name resolution without further overloading the humble dot. they parse exactly the same as they do in patterns so no new magic is being added to the symbols other than allowing them in expressions. - Layout algorithm is fully in the lexer now, no lexer/parser interaction needed and useful transformations happen between the two simplifying the parser. - updated a lot of the external libraries to new versions - improvements to the build based on feedback, now gives much better error messages about what went wrong. - include an experimental utility to automatically download 3rd party packages from hackage and install them, it has some kinks, but even if it can't do it automatically, it provides a template for easily modifying the package to work. - removed the last of the cabal-cruft from the library build system. - fixed a lot of bugs relating to errors not being caught early by jhc so they produce a cryptic message from the compiler later, attach source location to more errors for better reporting. - ghc 7.8 compatibilty contributed by others. (thanks!) - infix type constructor extension supported - field punning extension now supported - new option -fno-sugar to turn off all desugaring that would introduce any hidden dependencies, all literals are unboxed under it. WYSIWYG. - unboxed kinds now more general, work in more places - record field names may overlap - more efficient binary representation using LEB128 - Data.String added with mild magic. -- John Meacham - http://notanumber.net/

1 0