- 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

The Wonders of generic applicative traversal routines
by John Meacham 13 May '14

13 May '14

Before http://repetae.net/drop/TypeSyns_old.hs and after http://repetae.net/drop/TypeSyns_new.hs that's right, the work of a 550 line complicated file done in a few lines. The magic is in FrontEnd.Syn.Traverse where I have a class that recurses over arbitrary source syntax and takes a data HsOps m = HsOps { opHsDecl :: HsDecl -> m HsDecl, opHsExp :: HsExp -> m HsExp, opHsPat :: HsPat -> m HsPat, opHsType :: HsType -> m HsType, opHsStmt :: HsStmt -> m HsStmt } as an argument, by recursively defining your ops by 'tying the knot' each of the routines will recurse down the others. quite handy. Now I have about 2500 lines of code to excise from FrontEnd/. Many improvements to the front end have been put off due to the sheer amount of traversal code that has to modified for every new syntax construct. good times. John -- John Meacham - http://notanumber.net/

2 8

Re: [jhc] darcs patch: src/Support/Inst.hs: don't define instances present in...
by John Meacham 13 May '14

13 May '14

Cool. thanks. I was actually wondering why those instances didn't exist as they seemed pretty obvious and I almost made them conditional. I'll modify your patch to be an actual feature check with the HAS_TRAVERSABLE_TUPLE check. On Tue, May 13, 2014 at 11:20 AM, Sergei Trofimovich <slyfox(a)community.haskell.org> wrote: > 1 patch for repository http://repetae.net/repos/jhc: > > Tue May 13 21:19:19 FET 2014 Sergei Trofimovich <slyfox(a)community.haskell.org> > * src/Support/Inst.hs: don't define instances present in ghc-7.8 > > [ 85 of 183] Compiling Support.Inst ( src/Support/Inst.hs, src/Support/Inst.o ) > > src/Support/Inst.hs:7:10: > Duplicate instance declarations: > instance [overlap ok] Foldable ((,) a) > -- Defined at src/Support/Inst.hs:7:10 > instance Foldable ((,) a) -- Defined in 'Data.Foldable' > > src/Support/Inst.hs:9:10: > Duplicate instance declarations: > instance [overlap ok] Traversable ((,) a) > -- Defined at src/Support/Inst.hs:9:10 > instance Traversable ((,) a) -- Defined in 'Data.Traversable' > > > [src/Support/Inst.hs: don't define instances present in ghc-7.8 > Sergei Trofimovich <slyfox(a)community.haskell.org>**20140513181919 > Ignore-this: 846e90c9a24c9eccc5c7358078529a72 > > [ 85 of 183] Compiling Support.Inst ( src/Support/Inst.hs, src/Support/Inst.o ) > > src/Support/Inst.hs:7:10: > Duplicate instance declarations: > instance [overlap ok] Foldable ((,) a) > -- Defined at src/Support/Inst.hs:7:10 > instance Foldable ((,) a) -- Defined in 'Data.Foldable' > > src/Support/Inst.hs:9:10: > Duplicate instance declarations: > instance [overlap ok] Traversable ((,) a) > -- Defined at src/Support/Inst.hs:9:10 > instance Traversable ((,) a) -- Defined in 'Data.Traversable' > ] hunk ./src/Support/Inst.hs 1 > +{-# LANGUAGE CPP #-} > module Support.Inst where > > import Control.Applicative > hunk ./src/Support/Inst.hs 8 > import Data.Foldable > import Data.Traversable > > +#if __GLASGOW_HASKELL__ < 708 > instance Foldable ((,) a) where > foldMap = foldMapDefault > instance Traversable ((,) a) where > hunk ./src/Support/Inst.hs 13 > traverse f (x,y) = (,) x <$> f y > +#endif > > instance Functor ((,,) a b) where > fmap = fmapDefault > > -- John Meacham - http://notanumber.net/

1 0

Re: [jhc] [Haskell] ANNOUNCE: jhc-0.8.1
by John Meacham 13 May '14

13 May '14

I modified it so all packages depended on are listed in only a single spot in the configuration to make it easier to change and give much better error messages. see the new http://repetae.net/repos/jhc/configure.ac and the NEEDS_PACKAGE macros. Possibly existing instances are pretty easy to work around, see USE_MONOID_DOC in the config file. I'll make the show instance for identity conditionally defined too, since that seems to be floating around. Having to specify specific versions in the script would be hacky, much better to actually identify the reasons for incompatibility and choose based on that. John On Mon, May 12, 2014 at 10:36 PM, Krzysztof Skrzętnicki <gtener(a)gmail.com> wrote: > Hmm, I'll give it a try, thanks! > As for the other errors for sure there is missing Binary instance for strict > ByteStrings in newest binary package. > Another one is instance for Show (Identity a) which in turn needed to be > commented out because it appeared in newer version of some other package, > don't know which one. > Lastly I get a lot of errors caused by mixing library versions. I *think* > that the problem is that, unlike Cabal, the Makefile specifies -package foo > without specific versions. The result is that, given the fact that I have > more than 1 version of many libraries installed, it tries to build with two > different versions of same library, or so would it seem: 1 is dependency of > other library, the other is from -package specification. I think this is the > case. > This is why I asked for specific versions of all the libraries involved. The > idea was to simply specify *all* of them on command line and/or Makefile. > > Right now I don't have time to replicate the errors, but I will try again > building jhc later. > > > Best regards, > Krzysztof > > > On Tue, May 13, 2014 at 5:09 AM, John Meacham <john(a)repetae.net> wrote: >> >> Yeah, there was a bug in the way it detected editline/readline which >> has been fixed in the repo. >> >> You can run configure with --disable-line to work around it. or change >> the word USE_NOLINE to USE_READLINE in src/Util/Interact.hs >> >> always some silly typo that works its way in somewhere. I should stop >> the version number shift and declare it 1.0.0 and use the third digit >> for actual point releases rather than keep the perpetual 0.x.y wasting >> the first digit. but then I can't hide behind the 'beta' shield >> anymore. :) >> >> John >> >> On Mon, May 12, 2014 at 7:56 PM, Jens Petersen >> <juhp(a)community.haskell.org> wrote: >> > Thank you for the new release. :) >> > >> > On 13 May 2014 04:40, John Meacham <john(a)repetae.net> wrote: >> >> >> >> as for the packages i've been testing with >> >> >> >> >> >> >> >> fgl,regex-compat,bytestring,binary,mtl,containers,unix,utf8-string,zlib,HsSyck,filepath,process,syb,old-time,pretty. >> > >> > >> > and editline ? >> > >> > For me it fails to build on Fedora 20 with the readline package but >> > completes with editline. >> > >> > Krzysztof: maybe try removing or hiding the readline package or posting >> > your >> > build error. :) >> > >> > Jens >> > >> >> >> >> -- >> John Meacham - http://notanumber.net/ > > -- John Meacham - http://notanumber.net/

2 5