- Glasgow-haskell-users

Record update for Higher-ranked or changing type via Has/get/set [was: Records in Haskell]
by AntC 13 Dec '11

13 Dec '11

> Firstly, thank you to SPJ for putting some detailed design into 'Overloaded record fields' [SPJ 1]. What I'm showing here draws heavily on the techniques he demonstrates. I wasn't happy with several parts of the design proposal; especially not with the amount of not-yet-available type machinery it involved (explicit type application, anonymous types, the kind system, String types). But then SPJ wasn't happy himself with the limitations on Record update for polymorphic fields: "This problem seems to be a killer: if record-update syntax is interpreted as a call to `set', ...". It's (too) easy to chuck rocks - the "glaring weakness" of (Haskell's record system) is still a swamp despite a pile of rocks (to mix my metaphors). This posting (as a .lhs) is the result of exploring within the "narrow issue: namespacing for record field names". I've used GHC + recent type extensions (v7.2.1). Findings in short: - I've followed SPJ with a `Has' class, and methods `get' and `set'. - I seem to have a way to update Higher-ranked fields, - and change the type of the record, - and even update Existentially-quantified fields (to a limited extent) - which should please the object-oriented oriented. I'd appreciate some feedback: - Have I misunderstood the results? - Are there still unacceptable limitations? (Certainly the error messages are impenetrable when you go wrong.) - The `Has' class, instances and type functions are ugly - can we be more elegant? (I expect the instances to be generated systematically from the data decl. So usually the application programmer won't have to see them. I like SPJ's 'Syntactic sugar for Has' to pretty-up Has constraints.) Disclaimer: - I'm keeping close to SPJ's objective of improving the situation w.r.t. name clashes for record fields. [SPJ 2] - I'm _not_ claiming this is a design for 'first class record types' /extensible records/record polymorphism. - I'm _not_ making a proposal for 'Records in Haskell'. (Not yet: if this is approach is deemed 'workable', then I have a design in mind.) - I'm _not_ envisaging anything like 'first-class labels'. (I think that idea is probably not the right objective, but that's a debate for another day.) The basic idea: - Field selection uses dot notation as reverse-application, applying a field selector via Has/get and resolving the instance to the record type and field, that is: r.fld ==> fld r, ==> get (undefined :: Proxy_fld) (r@DCons{fld}) = fld (I've used (.$) = flip ($) to fake the syntax for dot notation.) - Record construction and pattern matching with explicit data constructors works as with -XDisambiguateRecordFields - Record update uses H98 syntax, to be compiled to Has/set and resolving the instance to the record type and field with explicit data constructor: r {fld = val} ==> set fld val (r@DCons{..}) ==> DCons{fld = val, ..} -- using Puns and WildCards (I've used (.=) = set to fake the syntax for update: r.$(fld.=val).) - Of course, I can't use the field name itself, because that would clash with the H98 selector. Instead: _fld = undefined :: Proxy_fld -- for the update syntax fld_ = get (undefined :: Proxy_fld) -- for the (overloadable) -- selector function The approach uses a 'loose coupling' between the type arguments of Has/get/set, with type functions to control the linkage. (Some could be Associated Types -- a matter of taste?) The recipe needs: > {-# OPTIONS_GHC -XDisambiguateRecordFields -XNamedFieldPuns -XRecordWildCards #-} > {-# OPTIONS_GHC -XTypeFamilies #-} > {-# OPTIONS_GHC -XRankNTypes -XImpredicativeTypes -XGADTs -XEmptyDataDecls #-} > {-# OPTIONS_GHC -XMultiParamTypeClasses -XFlexibleInstances -XUndecidableInstances #-} > module HasGetSet where SPJ's example of a higher-ranked data type -- imported so that we have clashing declarations of `rev' > import HRrev > {- data HR = HR {rev :: forall a.[a] -> [a]} -} > data Tab a b where -- a different data type with a HR field `rev' > Ta :: {tag :: String, rev :: forall a_.([a_] -> [a_]), flda :: a } > -> Tab a b > Tb :: (Num n, Show b) => {tag :: String, fldn :: n, fldnb :: n -> b} > -> Tab a b > -- Existential fields (GADT syntax) overloadable definitions for field `rev': > data Proxy_rev -- phantom, same role as SPJ's String kind "rev" > _rev = undefined :: Proxy_rev > rev_ r = get (undefined :: Proxy_rev) r build some syntax to fake the dot notation, and assignment within record update > (.$) = flip ($) > infixl 9 .$ >-- (fld .= val) r = set fld val r -- sadly, this doesn't quite work > infix 9 .= -- so define (.=) as a method in Has test rig for higher-rank rev, per SPJ's example, and demos > testrev r = (r.$rev_ $ [True, False, False], r.$rev_ $ "hello") > -- dot notation would bind tighter than func apply > rHR0 = HR{} -- `rev' is undefined, to show we can update it > rHR1 = rHR0.$(_rev.=reverse) -- equivalent to rHR0{rev = reverse} > -- testrev rHR1 ==> ([False,False,True],"olleh") > rHR2 = rHR1.$(_rev.=(drop 1 . reverse)) > -- testrev rHR2 ==> ([False,True],"lleh") > rTab0 = Ta{tag="tagged"} -- `rev' is undefined, to show we can update it > rTab1 = rTab0.$(_rev.=reverse) > -- testrev rTab1 ==> ([False,False,True],"olleh") > rTab2 = rTab1.$(_flda.='a').$(_rev.=(reverse . take 3)) > -- rTab1 :: Tab a b ; rTab2 :: Tab Char b > -- testrev rTab2 ==> ([False,False,True],"leh") here's the mechanism -- declarations for Has/get/set, and type families > class Has r fld t where > get :: fld -> r -> GetTy r fld t > set, (.=) :: fld -> (forall a_.SetTy r fld t a_) -> r -> SetrTy r fld t > -- (fld .= val) r = set fld val r -- } sadly, neither of these work > -- (.=) = set -- } (trying to define a default) > type family GetTy r fld t :: * -- the type to get at `fld' in `r' > type family SetTy r fld t a_ :: * -- type to set at `fld' in updated `r' > type family SetrTy r fld t :: * -- the type to set for updated `r' The instance for field `rev' to be a Higher-ranked type. > instance (t ~ ([a_]->[a_])) => Has HR Proxy_rev t where > -- the constraint needs -XUndecidableInstances > get _ HR{rev} = rev > set _ fn HR{..} = HR{rev = fn, ..} > (_ .= fn) HR{..} = HR{rev = fn, ..} > type instance GetTy r Proxy_rev t = t > -- that is ([a_] -> [a_]) from the instance constraint > type instance SetTy r Proxy_rev t a_ = ([a_] -> [a_]) > -- that is ([a_] -> [a_]) from `set's forall a_ > type instance SetrTy r Proxy_rev t = r > -- updating `rev' doesn't change the type the above type instances apply for any record with field `rev', so also type `Tab' > instance (t ~ ([a_]->[a_])) => Has (Tab a b) Proxy_rev t where > -- the constraint needs -XUndecidableInstances > get _ Ta{rev} = rev > set _ fn Ta{..} = Ta{rev = fn, ..} > (_ .= fn) Ta{..} = Ta{rev = fn, ..} > data Proxy_flda -- `flda's type is a parameter to the data type > _flda = undefined :: Proxy_flda > flda_ r = get (undefined :: Proxy_flda) r > instance Has (Tab a b) Proxy_flda t where -- note no constraint on `t', > -- might be different to `a' for update > get _ Ta{flda} = flda > set _ x Ta{..} = Ta{flda = x, ..} > (_ .= x) Ta{..} = Ta{flda = x, ..} > type instance GetTy (Tab a b) Proxy_flda t = a > -- this is where we constrain `t' for the get > type instance SetTy (Tab a b) Proxy_flda t a_ = t -- type to set is whatever we're given > type instance SetrTy (Tab a b) Proxy_flda t = Tab t b -- set the result type: substitute `t' for `a' and Has/get/set for the other fields of Tab, including the Existential > data Proxy_tag > _tag = undefined :: Proxy_tag > tag_ r = get (undefined :: Proxy_tag) r > instance (t ~ String) => Has (Tab a b) Proxy_tag t where > -- constraint on `t', because tag is always a String > get _ Ta{tag} = tag > get _ Tb{tag} = tag > set _ x Ta{..} = Ta{tag = x, ..} > set _ x Tb{..} = Tb{tag = x, ..} > (_ .= x) Ta{..} = Ta{tag = x, ..} > (_ .= x) Tb{..} = Tb{tag = x, ..} > type instance GetTy (Tab a b) Proxy_tag t = String > type instance SetTy (Tab a b) Proxy_tag t a_ = String > type instance SetrTy (Tab a b) Proxy_tag t = Tab a b > -- changing the tag doesn't change the record's type > data Proxy_fldn -- } the Existential fields must be set together > data Proxy_fldnb -- } possible approach for multiple update > _fldn = undefined :: Proxy_fldn > _fldnb = undefined :: Proxy_fldnb > -- no point in a 'getter' function: the types would escape > instance (t ~ (tn, tn -> b'), Show b', Num tn) > -- needs -XUndecidableInstances > => Has (Tab a b) (Proxy_fldn, Proxy_fldnb) t where > -- the use case is: r{fldn = n, fldnb = nb} > -- get _ Tb{fldn, fldnb} = (fldn, fldnb) -- No! types would escape > set _ (n, nb) Tb{..} = Tb{fldn = n, fldnb = nb, ..} > (_ .= (n, nb)) Tb{..} = Tb{fldn = n, fldnb = nb, ..} > type instance GetTy (Tab a b) (Proxy_fldn, Proxy_fldnb) t = t > -- that is: (tn, tn -> b') from the instance constraint > type instance SetTy (Tab a b) (Proxy_fldn, Proxy_fldnb) t a_ = t > type instance SetrTy (Tab a b) (Proxy_fldn, Proxy_fldnb) (tn, tn -> b') > = Tab a b' > -- changing the fields changes the type demo > nb' Tb{fldn, fldnb} = fldnb fldn -- test rig > rTab3 = Tb{tag="tagged", fldn = 6 :: Double, fldnb = negate} > -- nb' rTab3 ==> -6.0 :: Double > rTab4 = rTab3.$((_fldn, _fldnb).=(5::Int, (6 +))) > -- rTab3{fldn = 5, fldnb = (6 +)} > -- nb' rTab4 ==> 11 :: Int Notes/difficulties: - Language options needs -XUndecidableInstances because the approach "uses a functional-dependency-like mechanism (but using equalities)" [SPJ 1] to 'improve' type inference for some instances. Since this _doesn't_ use FunDeps, can it safely exceed Paterson Conditions? - The inability to declare (.=) = set is curious/irritating. (Neither as a free-standing function, nor a method of Has with a default implementation. And even declaring (.=) with a type signature identical to `set'. From the error messages, GHC can't match the forall'd `a_'.) If you've managed to read this far: thank you! Refs: [SPJ 1] http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields [SPJ 2] http://hackage.haskell.org/trac/ghc/wiki/Records

1 0

Revert a CAF?
by wren ng thornton 09 Dec '11

09 Dec '11

So, I have an optimization/internals question. Does the GHC API have any hooks for being able to revert a CAF to the original expression, thus discarding the previously computed result? The reason I'm wanting this is that I have a particular CAF which is an infinite list. Unfolding that list takes a fair deal of work, so we want to share it whenever possible; however it doesn't take an overwhelming amount of work, so if we know we've evaluated more of the list than necessary (for a long while), it'd be nice to be able to revert the evaluation in order to save on memory overhead (e.g., by calling relax :: IO()). I could hack something together based on unsafePerformIO and top-level IORefs, and it's clear that this is in fact a safe thing to do, but I'm worried about the semantic issues inherent in unsafePerformIOed top-level IORefs (e.g., the fact that their scope isn't particularly well defined: is it per library instance? per runtime?...). Unfortunately, for what I'm doing, it isn't really feasible to just leave the IO type in there nor to pass around the infinite list so we can use scoping rules to decide when to free it. (Feel free to offer alternative suggestions to handling this situation too.) -- Live well, ~wren

5 6

Superclass Cycle via Associated Type
by Nicolas Frisby 07 Dec '11

07 Dec '11

(Sorry I'm so late to this dialogue.) In http://www.haskell.org/pipermail/glasgow-haskell-users/2011-July/020593.html, SPJ asks > The superclasses are recursive but > a) They constrain only type variables > b) The variables in the superclass context are all > mentioned in the head. In class Q => C a b c > fv(Q) is subset of {a,b,c} > > Question to all: is that enough? I just recently came upon my own desire for this capability, but I'm pretty sure my reply to SPJ's question is "No." I'd like to extend Sat's modeling capabilities to also cover superclass constraints. > type family Super a > class Sat (Super a) => Sat a where dict :: a This seems to necessitate recursive dictionaries — I'm not familiar enough with the dictionary-implementation details to understand how much of an understatement that might be. All I can say is that my own intuitions about those things don't yet deem this technique infeasible. Let's take a reification of Ord as an example. > data EmptyD a = EmptyD > type instance Super (EmptyD a) = EmptyD a > instance Sat (EmptyD a) where dict = EmptyD > > data EqD a where EqD :: Eq a => EqD a > type instance Super (EqD a) = EmptyD a > instance Eq a => Sat (EqD a) where dict = EqD > > data OrdD a where OrdD :: Ord a => OrdD a > type instance Super (OrdD a) = EqD a > instance Ord a => Sat (OrdD a) where dict = OrdD Now GHC can derive Sat (EqD a) from Sat (OrdD a). I'd bet this could be cleaned via Constraint Kinds [1] — if not totally subsumed by them: > type family Super a :: Constraint > class Super a => Sat a where dict :: a > > data OrdD a where OrdD :: Ord a => OrdD a > type instance Super (OrdD a) = Ord a > instance Ord a => Sat (OrdD a) where dict = OrdD With these definitions, there'd be an isomorphism between Sat (OrdD a) and Ord a. I don't know how difficult it would be for GHC to wield that isomorphism. At this point, though, perhaps Constraint Kinds simply deprecate Sat? [1] does, after all, define "one reified dictionary to rule them all". ----- [1] - http://blog.omega-prime.co.uk/?p=127

1 0

GHC HEAD build error
by Bas van Dijk 07 Dec '11

07 Dec '11

Hello, I'm trying to build GHC HEAD but get the following error: "inplace/bin/ghc-stage1" -H64m -O0 -fasm -Iincludes -Irts -Irts/dist/build -DCOMPILING_RTS -package-name rts -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -optc-O2 -c rts/HeapStackCheck.cmm -o rts/dist/build/HeapStackCheck.o rts/HeapStackCheck.cmm:159:305: parse error on input `(' The bug is in the GC_GENERIC macro on line 99: Capability_interrupt(MyCapability()) != 0 :: CInt However, I can't spot the problem. Bas

3 3

Re: [Haskell-cafe] More liberal than liberal type synonyms
by Dan Doel 07 Dec '11

07 Dec '11

On Wed, Dec 7, 2011 at 5:48 AM, Dmitry Kulagin <dmitry.kulagin(a)gmail.com> wrote: > I am still pretty new in Haskell, but this problem annoys me already. > > If I define certain monad as a type synonym: > > type StateA a = StateT SomeState SomeMonad a > > Then I can't declare new monad based on the synonym: > > type StateB a = StateT SomeOtherState StateA a > > The only way I know to overcome is to declare StateA without `a': > > type StateA = StateT SomeState SomeMonad > > But it is not always possible with existing code base. I'm afraid my proposal doesn't make this work. You could perhaps define StateB, but when you expand in a type you get: StateB a = StateT SomeOtherState StateA a which has a partially applied StateA, and is rejected. The only way to make this work is to eta reduce StateA manually, or make GHC recognize when a synonym can be eta reduced in this way (which might be both possible and useful as a separate proposal). My extension fell within the liberal type synonym space, which says that if you have: F G where F and G are both synonyms, and G is partially applied, then it is okay as long as expansion of F (and any subsequent expansions) cause G to become fully applied. My extension of this is just to allow partial application inside aliases as long as it meets these same criteria. The reason to disallow partially applied type aliases is that they make inference pretty much impossible, unless you only infer them in very limited circumstances perhaps. And if you can't get inference of them, you probably need to start having explicit annotations to tell the type checker what you want to happen, which has some of its own complications with the way quantifiers work in GHC and such. It'd cascade into some thorny issues. Hopefully that covers all the other subsequent stuff folks have been talking about. -- Dan

1 0

More liberal than liberal type synonyms
by Dan Doel 06 Dec '11

06 Dec '11

Greetings, In the process of working on a Haskell-alike language recently, Ed Kmett and I realized that we had (without really thinking about it) implemented type synonyms that are a bit more liberal than GHC's. With LiberalTypeSynonyms enabled, GHC allows: type Foo a b = b -> a type Bar f = f String Int baz :: Bar Foo baz = show because Bar expands to saturate Foo. However, we had also implemented the following, which fails in GHC: type Foo a b = b -> a type Bar f = f (Foo Int) (Foo Int) type Baz f g = f Int -> g Int quux :: Bar Baz quux = id That is: type synonyms are allowed to be partially applied within other type synonyms, as long as similar transitive saturation guarantees are met during their use. I don't know how useful it is, but I was curious if anyone can see anything wrong with allowing this (it seems okay to me after a little thought), and thought I'd float the idea out to the GHC developers, in case they're interested in picking it up. -- Dan

1 0

Why no multiple default method implementations?
by Bas van Dijk 24 Nov '11

24 Nov '11

Hello, Now that we have DefaultSignatures, why is it not allowed to have multiple default method implementations, as in: {-# LANGUAGE DefaultSignatures #-} class Foo a where foo :: a foo = error "foo" default foo :: Num a => a foo = 1 GHC complains: "Conflicting definitions for `foo'" The following use of multiple default signatures also gives the same error: class Foo a where foo :: a default foo :: Fractional a => a foo = 0.5 default foo :: Num a => a foo = 1 Couldn't GHC always pick the most specific default method, just as it does with instances when OverlappingInstances is enabled? Regards, Bas

2 2

Fwd: [commit: ghc] master: Relax the restriction on using abstract newtypes in FFI declarations. (c6b0fd6)
by Simon Marlow 24 Nov '11

24 Nov '11

This deserves a wider audience: if you've encountered failures when compiling FFI code with recent GHCs due to the new requirement that newtypes be non-abstract, note that this will now be a warning, not an error, in 7.4.1. We're deferring turning it into an error until 7.6.1. Cheers, Simon -------- Original Message -------- Subject: [commit: ghc] master: Relax the restriction on using abstract newtypes in FFI declarations. (c6b0fd6) Date: Thu, 24 Nov 2011 06:57:21 -0800 From: Simon Marlow <marlowsd(a)gmail.com> To: cvs-ghc(a)haskell.org Repository : ssh://darcs.haskell.org//srv/darcs/ghc On branch : master http://hackage.haskell.org/trac/ghc/changeset/c6b0fd62fc715aa6c666eb8afe090… >--------------------------------------------------------------- commit c6b0fd62fc715aa6c666eb8afe09073ac7b87a83 Author: Simon Marlow <marlowsd(a)gmail.com> Date: Thu Nov 24 14:04:23 2011 +0000 Relax the restriction on using abstract newtypes in FFI declarations. Given the high impact of this change, we decided to back off and make abstract newtypes give a warning for one release, before we make it an error in 7.6.1. Codec/Compression/Zlib/Stream.hsc:884:1: Warning: newtype `CInt' is used in an FFI declaration, but its constructor is not in scope. This will become an error in GHC 7.6.1. When checking declaration: foreign import ccall unsafe "static zlib.h deflate" c_deflate :: StreamState -> CInt -> IO CInt >--------------------------------------------------------------- compiler/typecheck/TcForeign.lhs | 22 +++++++++++++++++----- 1 files changed, 17 insertions(+), 5 deletions(-) diff --git a/compiler/typecheck/TcForeign.lhs b/compiler/typecheck/TcForeign.lhs index 886b84d..5a4bf77 100644 --- a/compiler/typecheck/TcForeign.lhs +++ b/compiler/typecheck/TcForeign.lhs @@ -121,17 +121,29 @@ normaliseFfiType' env ty0 = go [] ty0 panic "normaliseFfiType': Got more GREs than expected" _ -> return False - if newtypeOK - then do let nt_co = mkAxInstCo (newTyConCo tc) tys - add_co nt_co rec_nts' nt_rhs - else children_only + when (not newtypeOK) $ + -- later: stop_here + addWarnTc (ptext (sLit "newtype") <+> quotes (ppr tc) <+> + ptext (sLit "is used in an FFI declaration,") $$ + ptext (sLit "but its constructor is not in scope.") $$ + ptext (sLit "This will become an error in GHC 7.6.1.")) + + let nt_co = mkAxInstCo (newTyConCo tc) tys + add_co nt_co rec_nts' nt_rhs + | isFamilyTyCon tc -- Expand open tycons , (co, ty) <- normaliseTcApp env tc tys , not (isReflCo co) = add_co co rec_nts ty + | otherwise - = children_only + = return (mkReflCo ty, ty) + -- If we have reached an ordinary (non-newtype) type constructor, + -- we are done. Note that we don't need to normalise the arguments, + -- because whether an FFI type is legal or not depends only on + -- the top-level type constructor (e.g. "Ptr a" is valid for all a). where + children_only = do xs <- mapM (go rec_nts) tys let (cos, tys') = unzip xs return (mkTyConAppCo tc cos, mkTyConApp tc tys') _______________________________________________ Cvs-ghc mailing list Cvs-ghc(a)haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc

1 0

Re: Why not allow empty record updates?
by wren ng thornton 23 Nov '11

23 Nov '11

On 11/15/11 8:07 PM, wagnerdm(a)seas.upenn.edu wrote: > Quoting wren ng thornton <wren(a)freegeek.org>: >> So far I've just defined helper functions to adjust the phantom >> type[1], each of which is implemented by (\x -> x { foo = foo x }). >> It's a horrible hack, but at least it's hidden away in library >> functions instead of something I have to look at. The annoying part > > (a bit tongue-in-cheek, and hence not sent to the mailing list) Forwarding to the list, because I actually have a serious response :) > As long as we're writing hacks, why not use unsafeCoerce? ;-) In this particular case I don't care too much about representation sharing (though I do share Ed's concern), and I generally do my best to avoid unsafeFoo just so I can minimize my personal proof obligations / maximize the utility of the compiler's type checking. Though, yes, in other projects with similar considerations I've also gone the unsafeCoerce route. Other than invalidating type system guarantees, it does have the side effect that it can interfere with rewrite rules firing (since the coercion remains in the System Fc core). And the times when I really care about representation sharing are often also the times I really care about rewrite rules firing. Which in turn means I tend to add additional rewrite rules to push the unsafeCoerce around in order to get it out of the way so that other rules can fire. But I see no way of specifying these additional rules in full generality while retaining correctness--- without some additional mechanism to say things like "this newtype wrapper is opaque in these contexts (to preserve the abstract semantics), but is translucent in these other contexts (to abide by categorical laws like functorality). It's really unfortunate that these complementary goals of sharing representation and doing rewrites/fusion are at odds in current Haskell. I run into similar issues with needing to work around coercions in Coq, since they impede the evaluator and proofs of value equality due to the weakness of Coq's case analysis. That the issue shows up in Coq as well seems to imply that the root of the problem is something deeper than noone having implemented the convenience. Agda has a stronger case analysis and so doesn't run into quite the same issues, though I'm not entirely clear on the exact ways in which Agda's case analysis gains that extra power, so it's unclear whether we could (meaningfully) add the power to Haskell without going whole hog into dependent types. Of course, this all is related to the problem of strong updates; it just happens that the update is Curry-identical, yet Church-different. Given the general preference for Church-style lambda calculi, it's not surprising that this exact problem hasn't been tackled (to my knowledge). Another place this problem has come up for me is in wanting to ensure representation sharing for values constructed by data constructors which don't make use of their type parameters. A trivial example would be sharing the representation of Nothing between all the Maybe types, or sharing the empty list among all the list types. That example isn't especially motivating, but there are other cases where we can end up with a large structure for which the type parameters are 'phantom' even though they may not be phantom in general (because other data constructors make use of them). That we want type updates for records with phantom types is just a symptom of the larger issue of wanting type updates for all quasiphantom/pseudophantom types. -- Live well, ~wren

2 1

What makes GHC's GC good for purely functional workloads?
by Edward Z. Yang 23 Nov '11

23 Nov '11

Apologies if this has been asked before. In some ways GHC's garbage collectors are very traditional, so I was wondering what magic dust makes it do better in Haskelly workloads (e.g. whereas you'd need to do a bit more work in the JVM to make some allocation pattern play nice.) Edward

3 3