- ghc-devs - Haskell.org

clang warnings with unregisterised
by Gabor Greif 29 Aug '14

29 Aug '14

Devs, I have built an UNREGISTERISED GHC, and the C-compiler used behind the scenes is clang. Now I get literally millions of warnings of the below kind: +/var/folders/k9/fj_1d5h17m7c4gbyp2srqrhm0000gq/T/ghc11601_0/ghc11601_4.hc:688:1: + warning: attribute declaration must precede definition [-Wignored-attributes] +II_(s4Vv_closure); +^ + +/Users/ggreif/ghc-head/includes/Stg.h:213:63: + note: expanded from macro 'II_' +#define II_(X) static StgWordArray (X) GNU_ATTRIBUTE(aligned (8)) + ^ + +/Users/ggreif/ghc-head/includes/Stg.h:175:42: + note: expanded from macro 'GNU_ATTRIBUTE' +#define GNU_ATTRIBUTE(at) __attribute__((at)) + ^ + +/var/folders/k9/fj_1d5h17m7c4gbyp2srqrhm0000gq/T/ghc11601_0/ghc11601_4.hc:588:16: + note: previous definition is here +static StgWord s4Vv_closure[] = { + ^ It seems like the "II_" and "EI_" prototypes *follow* the real thing, and because clang is more picky with attribute placement, we get all those warnings. compiler/cmm/PprC.hs:pprExternDecl is the function that puts together the "II_(...)" and "EI_(...)", but where does the "static StgWord s4Vv_closure[] = {" come from? I just want to flip the order of their occurrence. Thanks, Gabor

2 1

Raft of optimizer changes
by David Feuer 29 Aug '14

29 Aug '14

On Thu, Aug 28, 2014 at 8:00 AM, simonpj wrote > I've just pushed a bunch of Core-to-Core optimisation changes that have been sitting in my tree for ages. The aggregate effect on nofib is very modest, but they are mostly aimed at corner cases, and consolidation. Thanks for trying to do that. Unfortunately, this seems to have introduced some other sort of corner case. Making reverse (and unfoldr, but I'm pretty sure that's unused and hence irrelevant) fusible now makes n-body allocate 1100% more. I haven't looked into why yet. David

1 0

Why isn't (.) CONLIKE?
by David Feuer 28 Aug '14

28 Aug '14

Speaking of CONLIKE, I'd have expected (.) to be CONLIKE, since it looks much like a constructor. Would that be bad for some reason? Or is it already treated well enough not to need that? On Aug 28, 2014 11:56 AM, "Simon Peyton Jones" <simonpj(a)microsoft.com> wrote: > Actually the CONLIKE thing still allows them to float, but makes RULES > continue to work even though they’ve been floated. See the user manual. > > > > *From:* Dan Doel [mailto:dan.doel@gmail.com] > *Sent:* 28 August 2014 16:48 > *To:* Simon Peyton Jones > *Cc:* John Lato; David Feuer; ghc-devs > *Subject:* Re: Why isn't ($) inlining when I want? > > > > Okay, so marking things as conlike will make GHC avoid floating them? > > I'm pretty sure that in most vector cases, this is a straight > pessimization. There is no way to avoid the extra allocation of integers, > because most intermediate vector types are unboxed, so the integer > allocation will be performed regardless. Only boxed vectors might be an > exception. > > > > On Thu, Aug 28, 2014 at 4:14 AM, Simon Peyton Jones <simonpj(a)microsoft.com> > wrote: > > I remember doing some work on the “floating of constant lists” question. > > > > First, [1..n] turns into (enumFromTo 1 n), and if enumFromTo was > expensive, then sharing it might be a good plan. So GHC would have to know > that it was cheap. > > > > I did experiment with “cheapBuild” see > https://ghc.haskell.org/trac/ghc/ticket/7206, but as you’ll see there, > the results were equivocal. By duplicating the [1..n] we were allocating > two copies of (I# 4), (I# 5) etc, and that increased allocation and GC time. > > > > So it’s unclear, in general, whether in these examples it is better to > share the [1..n] between all calls of ‘loop’, or to duplicate it. > > > > All that said, Dan’s question of why X fuses and very-similar Y doesn’t > was a surprise to me; I’ll look into that. > > > Simon > > > > *From:* John Lato [mailto:jwlato@gmail.com] > *Sent:* 28 August 2014 00:17 > *To:* Dan Doel > *Cc:* Simon Peyton Jones; David Feuer; ghc-devs > > > *Subject:* Re: Why isn't ($) inlining when I want? > > > > I sometimes think the solution is to make let-floating apply in fewer > cases. I'm not sure we ever want to float out intermediate lists, the cost > of creating them is very small relative to the memory consumption if they > do happen to get shared. > > > > My approach is typically to mark loop INLINE. This very often results in > the code I want (with vector, which I use more than lists), but it is a big > hammer to apply. > > > > John > > > > On Thu, Aug 28, 2014 at 5:56 AM, Dan Doel <dan.doel(a)gmail.com> wrote: > > I think talking about inlining of $ may not be addressing the crux of > the problem here. > > The issue seems to be about functions like the one in the first message. > For instance: > > loop :: (Int -> Int) -> Int > > loop g = sum . map g $ [1..1000000] > > Suppose for argument that we have a fusion framework that would handle > this. The problem is that this does not actually turn into a loop over > integers, because the constant [1..1000000] gets floated out. It instead > builds a list/vector/whatever. > > By contrast, if we write: > > loop' :: Int > > loop' = sum . map (+1) $ [1..1000000] > > this does turn into a loop over integers, with no intermediate list. > Presumably this is due to there being no work to be saved ever by floating > the list out. These are the examples people usually test fusion with. > > And if loop is small enough to inline, it turns out that the actual code > that gets run will be the same as loop', because everything will get > inlined and fused. But it is also possible to make loop big enough to not > inline, and then the floating will pessimize the overall code. > > So the core issue is that constant floating blocks some fusion > opportunities. It is trying to save the work of building the structure more > than once, but fusion can cause the structure to not be built at all. And > the floating happens before fusion can reasonably be expected to work. > > Can anything be done about this? > > I've verified that this kind of situation also affects vector. And it > seems to be an issue even if loop is written: > > loop g = sum (map g [1..1000000]) > > -- Dan > > > > On Wed, Aug 27, 2014 at 3:38 PM, Simon Peyton Jones <simonpj(a)microsoft.com> > wrote: > > You'll have to do more detective work! In your dump I see "Inactive > unfolding $". So that's why it's not being inlined. That message comes > from CoreUnfold, line 941 or so. The Boolean active_unfolding is passed in > to callSiteInline from Simplify, line 1408 or so. It is generated by the > function activeUnfolding, defined in SimplUtils. > > But you have probably change the "CompilerPhase" data type, so I can't > guess what is happening. But if you just follow it through I'm sure you'll > find it. > > Simon > > > | -----Original Message----- > | From: David Feuer [mailto:david.feuer@gmail.com] > | Sent: 27 August 2014 17:22 > | To: Simon Peyton Jones > | Cc: ghc-devs > | Subject: Re: Why isn't ($) inlining when I want? > | > | I just ran that (results attached), and as far as I can tell, it > | doesn't even *consider* inlining ($) until phase 2. > | > | On Wed, Aug 27, 2014 at 4:03 AM, Simon Peyton Jones > | <simonpj(a)microsoft.com> wrote: > | > It's hard to tell since you are using a modified compiler. Try running > | with -ddump-occur-anal -dverbose-core2core -ddump-inlinings. That will > | show you every inlining, whether failed or successful. You can see the > | attempt to inline ($) and there is some info with the output that may > | help to explain why it did or did not work. > | > > | > Try that > | > > | > Simon > | > > | > | -----Original Message----- > | > | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of > | David > | > | Feuer > | > | Sent: 27 August 2014 04:50 > | > | To: ghc-devs; Carter Schonwald > | > | Subject: Why isn't ($) inlining when I want? > | > | > | > | tl;dr I added a simplifier run with inlining enabled between > | > | specialization and floating out. It seems incapable of inlining > | > | saturated applications of ($), and I can't figure out why. These are > | > | inlined later, when phase 2 runs. Am I running the simplifier wrong > | or > | > | something? > | > | > | > | > | > | I'm working on this simple little fusion pipeline: > | > | > | > | {-# INLINE takeWhile #-} > | > | takeWhile p xs = build builder > | > | where > | > | builder c n = foldr go n xs > | > | where > | > | go x r = if p x then x `c` r else n > | > | > | > | foo c n x = foldr c n . takeWhile (/= (1::Int)) $ [-9..10] > | > | > | > | There are some issues with the enumFrom definition that break things. > | > | If I use a fusible unfoldr that produces some numbers instead, that > | > | issue goes away. Part of that problem (but not all of it) is that the > | > | simplifier doesn't run to apply rules between specialization and full > | > | laziness, so there's no opportunity for the specialization of > | > | enumFromTo to Int to trigger the rewrite to a build form and fusion > | > | with foldr before full laziness tears things apart. The other problem > | > | is that inlining doesn't happen at all before full laziness, so > | things > | > | defined using foldr and/or build aren't actually exposed as such > | until > | > | afterwards. Therefore I decided to try adding a simplifier run with > | > | inlining between specialization and floating out: > | > | > | > | runWhen do_specialise CoreDoSpecialising, > | > | > | > | runWhen full_laziness $ CoreDoSimplify max_iter > | > | (base_mode { sm_phase = InitialPhase > | > | , sm_names = ["PostGentle"] > | > | , sm_rules = rules_on > | > | , sm_inline = True > | > | , sm_case_case = False }), > | > | > | > | runWhen full_laziness $ > | > | CoreDoFloatOutwards FloatOutSwitches { > | > | floatOutLambdas = Just 0, > | > | floatOutConstants = True, > | > | floatOutPartialApplications = False > | }, > | > | > | > | The weird thing is that for some reason this doesn't inline ($), even > | > | though it appears to be saturated. Using the modified thing with (my > | > | version of) unfoldr: > | > | > | > | foo c n x = (foldr c n . takeWhile (/= (1::Int))) $ unfoldr (potato > | 10) > | > | (-9) > | > | > | > | potato :: Int -> Int -> Maybe (Int, Int) > | > | potato n m | m <= n = Just (m, m) > | > | | otherwise = Nothing > | > | > | > | > | > | I get this out of the specializer: > | > | > | > | foo > | > | foo = > | > | \ @ t_a1Za @ c_a1Zb c_a1HT n_a1HU _ -> > | > | $ (. (foldr c_a1HT n_a1HU) > | > | (takeWhile > | > | (let { > | > | ds_s21z > | > | ds_s21z = I# 1 } in > | > | \ ds_d1Zw -> neInt ds_d1Zw ds_s21z))) > | > | (let { > | > | n_s21x > | > | n_s21x = I# 10 } in > | > | unfoldr > | > | (\ m_a1U7 -> > | > | case leInt m_a1U7 n_s21x of _ { > | > | False -> Nothing; > | > | True -> Just (m_a1U7, m_a1U7) > | > | }) > | > | ($fNumInt_$cnegate (I# 9))) > | > | > | > | > | > | and then I get this out of my extra simplifier run: > | > | > | > | foo > | > | foo = > | > | \ @ t_a1Za @ c_a1Zb c_a1HT n_a1HU _ -> > | > | $ (\ x_a20f -> > | > | foldr > | > | (\ x_a1HR r_a1HS -> > | > | case case x_a1HR of _ { I# x_a20R -> > | > | tagToEnum# > | > | (case x_a20R of _ { > | > | __DEFAULT -> 1; > | > | 1 -> 0 > | > | }) > | > | } > | > | of _ { > | > | False -> n_a1HU; > | > | True -> c_a1HT x_a1HR r_a1HS > | > | }) > | > | n_a1HU > | > | x_a20f) > | > | (let { > | > | b'_a1ZS > | > | b'_a1ZS = $fNumInt_$cnegate (I# 9) } in > | > | $ (build) > | > | (\ @ b1_a1ZU c_a1ZV n_a1ZW -> > | > | letrec { > | > | go_a1ZX > | > | go_a1ZX = > | > | \ b2_a1ZY -> > | > | case case case b2_a1ZY of _ { I# x_a218 -> > | > | tagToEnum# (<=# x_a218 10) > | > | } > | > | of _ { > | > | False -> Nothing; > | > | True -> Just (b2_a1ZY, b2_a1ZY) > | > | } > | > | of _ { > | > | Nothing -> n_a1ZW; > | > | Just ds_a203 -> > | > | case ds_a203 of _ { (a1_a207, new_b_a208) -> > | > | c_a1ZV a1_a207 (go_a1ZX new_b_a208) > | > | } > | > | }; } in > | > | go_a1ZX b'_a1ZS)) > | > | > | > | > | > | That is, neither the $ in the code nor the $ that was inserted when > | > | inlining unfoldr got inlined themselves, even though both appear to > | be > | > | saturated. As a result, foldr/build doesn't fire, and full laziness > | > | tears things apart. Later on, in simplifier phase 2, $ gets inlined. > | > | What's preventing this from happening in the PostGentle phase I > | added? > | > | > | > | David Feuer > | > | _______________________________________________ > | > | ghc-devs mailing list > | > | ghc-devs(a)haskell.org > | > | http://www.haskell.org/mailman/listinfo/ghc-devs > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > > > > >

2 1

Contributing To Haskell talk
by Joachim Breitner 28 Aug '14

28 Aug '14

Hi list, you might know that was I talked into^W^Wvolunteered to holding the “Contributing to GHC”¹ talk at HIW in 9 days. I’ll do it, but for some of the intended topics, I don’t feel like the best person to do it on my own. In particular, I was wondering if any of the active Phabricator proponents or users would be available to help me there, either during the preparation (which will happen at Göteborg; I’m currently distracted by the Debian Conference in Portland), or by performing a duet. Thanks, Joachim ¹ http://www.haskell.org/haskellwiki/HaskellImplementorsWorkshop/2014#Contrib… -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

1 0

Haddock build fails
by Simon Peyton Jones 28 Aug '14

28 Aug '14

Phab that I may have committed something that makes haddock fail to build (will teach me, again, to do a completely clean validate!) I'll look into this . Sorry Simon

1 1

nofib external dependencies
by Alexander Pakhomov 25 Aug '14

25 Aug '14

Hi all! I've noticed nofib depends on external packages, such as vector. So when vector is updated we have a benchmark result change even without compiler changes. I guess we need to use fixed version. When some package has major updates we do have to pick we should rename benchmark because it's not the same benchmark.

2 1

RE: Wired-in data-constructors with UNPACKed fields
by Simon Peyton Jones 25 Aug '14

25 Aug '14

I see three alternatives. 1. Flatten out the BigNat thing. You give good reasons why this would be bad. 2. Take care to build a DCR that really does match the one you get when you compile the source module that declares the data type. In principle, the representation does indeed depend on dynflags, so you need to know the flags with which the source module will be compiled. And that's reasonable: if we generate code for an unpacked constructor, GHC's wired-in knowledge must reflect that, and vice versa. But you can probably write the code in such a way as to be mostly independent (eg explicit UNPACK rather than rely on -funbox-strict-fields), or assume that some things won't happen (e.g. souce module will not be compiled with -fomit-interface-pragmas). See MkId.mkDataConRep. 3. Stop having Integer as a wired-in type. For the most part it doesn't need to be; you won't see any mentions of 'integerTy' or 'integerTyCon' scattered about the compiler. I believe that that the sole use is in CorePrep.cvtLitInteger, which wants to use the data constructor for small integers. What is odd here is that for non-small integers we are careful to look up mkInteger in the environment (precisely so that it is not wired in). Then we stash it in the CorePrepEnv, and pass it to cvtLitInteger. What I don't understand is why we don't do exactly the same thing for S#, the data constructor for small integers. (Add a new field to CorePrepEnv for the S# data constructor.) If we did that, then the Integer type and the data constructor, would become "known-key" things, rather than "wired-in" things; and the former are MUCH easier to handle. My recommendation would be to try (3) first. Ian Lynagh (cc'd) may be able to comment about why the inconsistency above arose in the first place, and why we can't simply fix it. Simon | -----Original Message----- | From: Herbert Valerio Riedel [mailto:hvriedel@gmail.com] | Sent: 18 August 2014 08:56 | To: Simon Peyton Jones | Subject: Re: Wired-in data-constructors with UNPACKed fields | | Hello Simon, | | On 2014-08-17 at 23:56:32 +0200, Simon Peyton Jones wrote: | > You'll see that 'pcDataCon' in TysWiredIn ultimately calls | > pcDataConWithFixity'. And that builds a data constructor with a | > NoDataConRep field, comment "Wired-in types are too simple to need | > wrappers". | > | > But your wired-in type is NOT too simply to need a wrapper! You'll | > need to build a suitable DCR record (see DataCon.lhs), which will be | > something of a nuisance for you, although you can doubtless re-use | > utility functions that are currently used to build a DCR record. | | Wouldn't I need to access to the current dynamic flags in order to be | able to construct the effective DCR record? If so, I'm not sure I can | access the dynflags while constructing a CAF (which I seem to need doing) | | > Alternatively, just put a ByteArray# as the argument of JP# and JN#. | > After all, you have Int# as the argument of SI#! | | Well, there's a big difference between the Int# use and the BigNat use: | | Int and Int# are isomorphic to each other. However, BigNat is a subset | of what can be represented in a ByteArray#. | | Also, BigNat is meant to be available as an abstract data type in its | own right for user to use it as building-block for other data-types | (Like e.g. a more efficient multi-constructor rational type in the style | of 'Integer' or also an optimized 'Either Word BigNat'-isomorphic | 'Natural' type I've got queued up for when integer-gmp2 is done). For | instance, there's a function for creating a BigNat out of a ByteArray# | which makes sure all internal invariants are satisfied. | | | However, should the task to wire-in BigNat turn out to be more pain than | bearable: Since we now have explicitly bidirectional pattern synonyms, I | have been considering to express the user-facing low-level interface to | the 'Integer' type via such pattern synonyms (and hide the "real" | 'data Integer = SI# Int# | Jp# ByteArray# | ..' type deeper, or maybe | not even export it at all). | | From a practical point, I'd like to get to a situation where code | requiring to access the "medium-level" Integer representation (like some | of Edward Kmett's packages, or some of the crypto-packages using | 'Integer's to perform RSA calculations) doesn't need to know it's using | integer-simple, integer-gmp2, or integer-xyz, as they'd all provide the | same abstracted API. | | | [...] | | > | data Integer = SI# Int# | > | | Jp# {-# UNPACK #-} !BigNat | > | | Jn# {-# UNPACK #-} !BigNat | > | | > | data BigNat = BN# ByteArray# | | Cheers, | hvr

3 3

Status updates
by Austin Seipp 25 Aug '14

25 Aug '14

Hello *, Here are some notes from what's happened this week: - I've rejiggered some of the wiki pages a bit more, including updating the BugTracker page[1], Phabricator/Harbormaster docs[2], -- The bugtracker page mostly saw some minor updates in relation to the updates from *last* week; notably the new 'upstream' status. -- I split the Phabricator page up a bit to be easier to read, so Harbormaster is its own page now (but see more below). - I spent a day or two working on a Windows buildbot for Phabricator. Good news: I think I have a reliable set of steps to get a windows SSH instance running. However, I have not yet gotten it to build GHC through msys2, so it's not working yet. - I spent time on Friday getting a fix for #7602 ready for real this time. I'll put a review on Phabricator soon (my other machine doesn't have `arc` credentials.) Hopefully OS X users can soon rejoice with a solid performance boost. - I fiddled with Applicative-Monad a tiny bit, but haven't made much progress still. Like last time, it would be really amazing if anyone would like to help me out and try the patch yourself (feel free to email/IRC, or see last weeks' email for more). Other things: - Thomas Miedema helped out Herbert by writing a Trac anti-spam plugin for us - Thank you so much Thomas!! Hopefully the spam will go away soon. I am not yet sure if Thomas's new plugin is installed yet - Herbert? Upcoming: - #7602 will go up for review. - I will land D165 today probably since it's ready and other refactorings can come later. D166 (faster copies) is not yet ready. - I haven't done this yet, but I'm going to try to turn on `--slow` ./validate mode in the next day or two for Phabricator. At first, I'm only going to configure this for *commits* first, and perhaps patches will follow once we have more build machines. That means Phabricator is going to start annoying you with consistent failures (I think `--slow` has a few right now), but putting on pressure is the best way to fix it, I think. I'll send another email about this shortly. - I will probably rejigger the Phabricator page again to be smaller. I've had some complaints it's getting a bit large (due to the images, mostly), so I'll probably move the hierarchy around a bit. - Sit down and do some thorough code review. We have about 3 major features sitting on Phabricator at the moment which are going to need extensive review before landing. I expect this will take a while. See: -- D169, source code notes: https://phabricator.haskell.org/D169 -- D168: Partial type sigs: https://phabricator.haskell.org/D168 -- D119: StaticValues extension: https://phabricator.haskell.org/D119 Please please please - feel free to review these patches! Even if they are not your area of expertise, doing so will A) help you learn more hopefully! and B) you can surely help still (pointing out typos, needed docs, lint violations, suggestions) etc. That would be really useful to help increase the 'shared ownership' we all have, I think. [1] https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/BugTracker [2] https://ghc.haskell.org/trac/ghc/wiki/Phabricator/Harbormaster -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0

Re: windows-x86-head (Windows/x86 HEAD (Gabor Pali)), build 2, Success
by Karel Gardas 25 Aug '14

25 Aug '14

Gabor, thanks a lot for your fantastic job on getting windows builder running. It's great to have that in the pool and not need to speculate if the change breaks windows build or not sometimes in the future when someone attempts to build that. Now it's one night turn over and this is great. Thanks a lot! Karel On 08/23/14 07:33 AM, Builder wrote: > windows-x86-head (Windows/x86 HEAD (Gabor Pali)), build 2 > > Build succeeded > Details: http://haskell.inf.elte.hu/builders/windows-x86-head/2.html > > git clone | Success > create mk/build.mk | Success > get subrepos | Success > repo versions | Success > touching clean-check files | Success > setting version date | Success > booting | Success > configuring | Success > creating check-remove-before | Success > compiling | Success > creating check-remove-after | Success > compiling testremove | Success > simulating clean | Success > checking clean | Success > making bindist | Success > making srcdist | Success > uploading bindist | Success > uploading srcdist | Success > uploading windows extra src tarball | Success > uploading tarball source | Success > testing bindist | Success > testing | Success > testsuite summary | Success > > Build succeeded > Details: http://haskell.inf.elte.hu/builders/windows-x86-head/2.html > > > > > _______________________________________________ > ghc-builds mailing list > ghc-builds(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-builds

2 1

Suggestion for GHC System User's Guide documentation change
by Howard B. Golden 25 Aug '14

25 Aug '14

I suggest changing the User's Guide extensions documentation to consistently use the LANGUAGE pragma form to specify extensions and code examples, rather than a combination of LANGUAGE pragmas and -XExtension flags. I find the combination of the two confusing. Also, the reader copying code examples which require a specific LANGUAGE to compile will be assisted by including the LANGUAGE pragma in the code examples. For example, in section 7.3, I would change: -------------------------------------------- 7.3. Syntactic extensions 7.3.1. Unicode syntax The language extension -XUnicodeSyntax enables Unicode characters to be used to stand for certain ASCII character sequences. -------------------------------------------- To: -------------------------------------------- 7.3. Syntactic extensions 7.3.1. Unicode syntax The language extension {-# LANGUAGE UnicodeSyntax #-} enables Unicode characters to be used to stand for certain ASCII character sequences. -------------------------------------------- Similarly, I would include the required LANGUAGE pragma(s) in _all_ code examples. For example, in section 7.3.7, I would change: -------------------------------------------- type Typ data TypView = Unit | Arrow Typ Typ view :: Typ -> TypView -- additional operations for constructing Typ's ... -------------------------------------------- To: -------------------------------------------- {-# LANGUAGE ViewPatterns #-} type Typ data TypView = Unit | Arrow Typ Typ view :: Typ -> TypView -- additional operations for constructing Typ's ... -------------------------------------------- I realize that LANGUAGE pragmas must be in file headers. While it is possible that users may be confused if they try to put pragmas in the body of a source file, I believe this will be outweighed by the benefit of making the examples clearer about the extensions necessary to use them. If this change is accepted, I volunteer to make the necessary documentation patches to implement it. Howard B. Golden Northridge, CA USA

3 4