Re: Graphical User Interface Libraries

Juan Ignacio Garcia Garcia <jigg <at> ugr.es> wrote,

> Does anybody know a GUI library which goes OK with ghc-5?
> I have been looking for one, but it seems that they only
> can be used with old versions of ghc or with hugs. 

The CVS version of Gtk+HS

  http://www.cse.unsw.edu.au/~chak/haskell/gtk/

works since quite a while with GHC 5.00.  (I hope that I get
around to put up pre-build packages soonish.)

Manuel

How do you stop functions being inlined?

Well, I think we all know the answer to this one, namely 
   {-# NOINLINE [name] #-}
This is, after all, what GHC does, and what several of the
files in ghc/fptools do.

Only slight problem is that according to the Haskell 98
report, including Simon Peyton Jones' revised draft, you
should use:
   {-# notInline [name] #-}
Most of the time in fptools/hslibs (which I have from
GHC), NOINLINE is used, but in one case notInline is used.

Of course one of the delights of pragmas is that the
"pragma should be ignored if an implementation is not prepared to 
handle it.".  So if you guess wrong, you may never know, until
you get a mysterious bug from GHC inlining a call to create
a global variable via unsafePerformIO.  Aren't pragmas wonderful?

Would someone tell me which we are supposed to use?  Or should I
use both "NOINLINE" and "notInline", just to be on the safe side?

RE: How do you stop functions being inlined?

{-# NOINLINE name #-}

| -----Original Message-----
| From: George Russell [mailto:ger <at> tzi.de] 
| Sent: Wednesday, August 01, 2001 3:46 PM
| To: haskell <at> haskell.org
| Subject: How do you stop functions being inlined?
| 
| 
| Well, I think we all know the answer to this one, namely 
|    {-# NOINLINE [name] #-}
| This is, after all, what GHC does, and what several of the 
| files in ghc/fptools do.
| 
| Only slight problem is that according to the Haskell 98
| report, including Simon Peyton Jones' revised draft, you
| should use:
|    {-# notInline [name] #-}
| Most of the time in fptools/hslibs (which I have from
| GHC), NOINLINE is used, but in one case notInline is used.
| 
| Of course one of the delights of pragmas is that the
| "pragma should be ignored if an implementation is not prepared to 
| handle it.".  So if you guess wrong, you may never know, 
| until you get a mysterious bug from GHC inlining a call to 
| create a global variable via unsafePerformIO.  Aren't pragmas 
| wonderful?
| 
| Would someone tell me which we are supposed to use?  Or 
| should I use both "NOINLINE" and "notInline", just to be on 

RE: How do you stop functions being inlined?

In fact, GHC understands both NOINLINE and NOTINLINE with any
capitalisation.  We just tend to use NOINLINE because I think GHC had it
before notInline was mentioned in the report.

Cheers,
	Simon

> -----Original Message-----
> From: Julian Seward (Intl Vendor) [mailto:v-julsew <at> microsoft.com] 
> Sent: Thursday, August 02, 2001 10:31 AM
> To: George Russell; haskell <at> haskell.org
> Subject: RE: How do you stop functions being inlined?
> 
> 
> 
> {-# NOINLINE name #-}
> 
> | -----Original Message-----
> | From: George Russell [mailto:ger <at> tzi.de] 
> | Sent: Wednesday, August 01, 2001 3:46 PM
> | To: haskell <at> haskell.org
> | Subject: How do you stop functions being inlined?
> | 
> | 
> | Well, I think we all know the answer to this one, namely 
> |    {-# NOINLINE [name] #-}
> | This is, after all, what GHC does, and what several of the 
> | files in ghc/fptools do.
> | 
> | Only slight problem is that according to the Haskell 98

Re: lexical description problem in language report?

On Tue, Jul 24, 2001 at 10:50:16AM -0700, Thomas Hallgren wrote:
> Although qualified names are listed in section 2.4,and in appendix B, 
> the two first productions of the grammar are:
> 
>   program ->  {lexeme | whitespace }
>   lexeme  ->  varid | conid | varsym | consym | literal | special | 
> reservedop | reservedid
> 
> There is no reference to qualified names here. I thought the purpose of 
> these productions were to say that a Haskell program is correct on the 
> lexical level iff there is a derivation of it in the lexical grammar, 
> starting from the nonterminal "program".

Similarly, in 4 and 4.4.2, we have

	gendecl -> fixity [digit] ops

but digit isn't in the list of lexemes in 2.2 and B.2, nor is it
reasonable for it to be there.  I suggest

	gendecl -> fixity [integer] ops

with the value of the integer constrained to be between 0 and 9 inclusive.
Incidentally, this is what GHC, Hugs and NHC do, in that they accept

	infix 0x0003 !$%

as equivalent to

	infix 3 !$%

Re: How do you stop functions being inlined?

Simon Marlow wrote:
> 
> In fact, GHC understands both NOINLINE and NOTINLINE with any
> capitalisation.  We just tend to use NOINLINE because I think GHC had it
> before notInline was mentioned in the report.
[snip]
So why does the GHC documentation only document NOINLINE?  Is this
a secret Microsoft plot to get to use non-standard features and stop us
switching later to Turbo Haskell?  

I think in the light of the current situation, it would be better if the Haskell
standard for pragmas were changed to specify:
(1) NOTINLINE is a synonym for NOINLINE.
(2) Case in the first word of a pragma is ignored (which everyone seems to
    be assuming but isn't specified anywhere).
(3) Perhaps also SPECIALISE as a synonym for SPECIALIZE, like GHC.
It does seem to me particularly important that we should standardise pragmas
as much as possible, given that pragmas not recognised get ignored.

Re: Haskell-JNI Bridge

At 2001-07-05 02:23, I wrote:

>In this apparent absence I'm writing my own Haskell-JNI bridge.

This now has a home at <http://sourceforge.net/projects/jvm-bridge/>, and 
I'm licensing it under LGPL.

--

-- 
Ashley Yakeley, Seattle WA

CFP: ICLP ws SAVE 2001

===============================================================================
               We apologize for multiple copies of this message
===============================================================================

                        ICLP 2001 workshop SAVE 2001

        Specification, Analysis and Validation for Emerging Technologies

                           in Computational Logic

              http://www.disi.unige.it/person/DelzannoG/save.html

	  Dec 1, 2001 , Coral Beach Hotel and Resort, Paphos, Cyprus

                     Submission Deadline: August 25, 2001

The huge increase in interconnectivity we have witnessed in the last decade has boosted the development of
systems which are often large-scale, distributed, time-critical,  and possibly acting in an unreliable
or malicious
environment. Furthermore, software and hardware components are often mobile, and have to interact with a
potentially arbitrary number of other entities. 

These systems require solid formal techniques for their verification and analysis. In this respect, computational
logic plays an increasingly important role, both providing formal methods for proving system's
correctness and
tools - e.g. using techniques like constraint programming and theorem proving - for verifying their
properties. 

In addition, computational logic is gaining importance as tool for the specification of (part) of these
systems. For

RE: More feedback on Haskell 98 modules from the Programatica Team

Folks

The folk at OGI have continued the current trend of discovering 
unspecified corners of Haskell 98.  That means taking some decisions,
and, as ever, I don't want to do that without giving you all a chance to
demur.   Nevertheless, I doubt this'll be controversial, because it's
all dark-corner stuff.

| 1) Sec 5.3.1:  In an "import A(x, ...)", the report tells us 
| that x must be one of the names exported from A.  There is no 
| indication whether a similar rule applies to declarations 
| like "import A hiding (x, ...)" if x is not exported from A.  

I propose that hiding something that isn't exported should be 
considered an error.  It's not actually harmful but it is misleading.

| 2) The semantics of "module M" style entries in export lists seems to
| be underspecified.   Here are some programs to illustrate:
| 
|    Program 1:  module A(module B, ...) where
|    ~~~~~~~~~~   ... code that doesn't import B ...
| 
|    Is this valid?  We thought that it should probably be invalid,
|    but could also see an interpretation in which it was valid, but
|    with nothing exported for the "module B" part.

By the same token, I think this should be an error.

|    Program 2:  module A(module B, ...) where
|    ~~~~~~~~~~   import qualified B

micro-rant