Re: [Haskell-cafe] Re: Packages and modules
Package names should never appear in source files IMHO. if a package name is in the source file, then you might as well make it part of the module name. packages exist for 'meta-organization' of code. A way to deal with mapping code _outside_ of the language itself, putting packages inside the code will force the creation of yet another level, meta-packages, or something. packages should not be a language issue, they are an environment one. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Windows Haskell GUI
On Thu, 06 Jul 2006 07:56:49 +0900, Neil Mitchell <[EMAIL PROTECTED]> wrote: I want to develop a GUI using Haskell on Windows. As far as I can tell the options for a reasonably high level GUI toolkit are: * wxHaskell * Gtk2Hs Unfortunately I cannot find released packages for GHC 6.4.2 for either of them - Gtk supports only 6.4.1 and wx supports only 6.4.0. I'm already proviedding my modified version of wxHaskell released packages for GHC 6.4.2 on my project's page. Because, it seems that developping wxHaskell is stopped, and I'm not wxHaskell's developper now. http://www.haskell.org/pipermail/haskell/2006-June/018043.html https://sourceforge.net/project/showfiles.php?group_id=168626 -- shelarcy http://page.freett.com/shelarcy/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Windows Haskell GUI
On 7/5/06, Duncan Coutts <[EMAIL PROTECTED]> wrote: On Wed, 2006-07-05 at 16:06 -0700, Jason Dagit wrote: > I can't help with gtk2hs as I haven't tried it yet, but I hear the dev > community is much more alive and very helpful. My main concerns with > gtk2hs were 1) I need a native look 'n feel This is a common misconception. Gtk+ uses the windows native theming dlls so look pretty good. See some of our screen shots: http://www.haskell.org/gtk2hs/gallery/HRay If you do find any places where it doesn't match the native theme then please report them in the Gtk+ bugzilla. What about file dialogs? Perhaps it's just GIMP but I thought it was all gtk programs that used the really out-of-place file dialogs on windows (I think gaim uses the same ones). I looked at some of your screenshots. Looks better overall than I remembered. > 2) ease of distribution with my application. Is there something specific we could improve here? I haven't tried this myself; I was going by word of mouth. The testimonial appears here: http://article.gmane.org/gmane.comp.lang.haskell.cafe/13378 Note that if you're building a standalone app then you can just bundle all the Gtk+ .dll files in your apps install directory and it'll work fine. So there's no need to have users install Gtk+ separately, you can include all the stuff into one installer. Ah, that's good to know. I may not be using haskell on my project after all :( but I'll keep this in mind for future oppurtunities. Thanks, Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Windows Haskell GUI
On Wed, 2006-07-05 at 16:06 -0700, Jason Dagit wrote: > I can't help with gtk2hs as I haven't tried it yet, but I hear the dev > community is much more alive and very helpful. My main concerns with > gtk2hs were 1) I need a native look 'n feel This is a common misconception. Gtk+ uses the windows native theming dlls so look pretty good. See some of our screen shots: http://www.haskell.org/gtk2hs/gallery/HRay If you do find any places where it doesn't match the native theme then please report them in the Gtk+ bugzilla. > 2) ease of distribution with my application. Is there something specific we could improve here? Note that if you're building a standalone app then you can just bundle all the Gtk+ .dll files in your apps install directory and it'll work fine. So there's no need to have users install Gtk+ separately, you can include all the stuff into one installer. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Windows Haskell GUI
On Wed, 2006-07-05 at 23:56 +0100, Neil Mitchell wrote: > Hi, > > I want to develop a GUI using Haskell on Windows. As far as I can tell > the options for a reasonably high level GUI toolkit are: > > * wxHaskell > * Gtk2Hs > > Unfortunately I cannot find released packages for GHC 6.4.2 for either > of them - Gtk supports only 6.4.1 and wx supports only 6.4.0. > > Does anyone have builds of either of these that work with 6.4.2? Bowing to public pressure I've done a Windows build of Gtk2Hs-0.9.10 with GHC 6.4.2. It's available here: http://haskell.org/~duncan/gtk2hs/gtk2hs-0.9.10.exe It needs GHC 6.4.2 and Gtk+ 2.8.x, for more detailed install instructions see: http://haskell.org/gtk2hs/archives/2005/06/24/installing-on-windows/ Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] New Benchmark Under Review: Magic Squares
Am Mittwoch, 5. Juli 2006 21:28 schrieben Sie:
> Hi Daniel,
>
> In the paragraph below it looks like you improved the performance of
> 5x5 from one and one half hours to one second. Is that a typo or
> should I be very, very impressed. :-)
>
> Cheers, David
Err, neither, really. Apparently, I haven't expressed myself immaculately
clearly, so let me try again.
Josh Goldfoot's original code produced a 5x5 magic square on the benchmarking
computer in 8063.01s, on my computer, I hit ctrl-C after about 4 1/2 hours.
My first version produced a 5x5 square in a little over 4 seconds (or was it a
little over 5s, I'm not sure), and a 6x6 square in 86.5s, but since I used
better bounds for the possible moves - e.g., if we regard a 5x5 square with
two entries, 1 at (1,1) and 2 at (1,2), JG's code would give [3 .. 25] as the
list of possible moves for (1,3), whereas I took into account that the sum of
(1,4) and (1,5) is at most 24 + 25 = 49 (and at least 3+4, but that doesn't
help here), thus finding that (1,3) must be at leat 65 - (1+2) - 49 = 13 and
[13 .. 25] as the list of possible moves. So I avoided a lot of dead ends,
but produced a different magic square.
This code I have pushed down to 1s for the 5x5 square and 5.4s for the 6x6
square (simply by replacing "intersect [a .. b]" with "takeWhile (<= b) :
dropWhile (< a)").
I have then tuned Josh Goldfoot's code (throwing out the List <-> Set
conversions, keeping a list of unused numbers and not much else), so that it
produced a 5x5 square in 1 1/2 hours on my computer, giving the same list of
possible moves as the original and hence the same magic square.
That's not bad, but not really awe-inspiring.
However, I've also combined the algorithms, using my better bounds, thus
avoiding many dead ends, but calculating the priorities as if I used the
original bounds, so exploring the branches in the same order and producing
the same square as the original.
This took about 12 minutes for a 5x5 square and impressed me - I expected it
to be significantly slower than the fast code, but a factor of 720 was much
more than I dreamed of.
Cheers,
Daniel
>
> On Jul 4, 2006, at 6:48 AM, Daniel Fischer wrote:
> > Hi,
> > I have now tuned Josh Goldfoot's code without changing the order in
> > which the
> > magic squares are produced, for a 5x5 magic square, my machine took
> > about 1
> > 1/2 hours and used 2Mb memory (considering that the original code
> > did not
> > finish within 4 1/2 hours here, that should push time on the
> > benchmarking
> > machine under 3000s and put us in the lead, I hope).
> > However, with the improved bounds for the possibilities, I can now
> > get a 5x5
> > square in 1s, a 6x6 square in 5.5s (replacing intersect by takeWhile &
> > dropWhile), so it's still sl.
> >
> > Brent, can I informally submit the code thus, or what formalities
> > would I have
> > to perform to submit my code?
> >
> > --
> > -
> > {- The Computer Language Shootout
> >http://shootout.alioth.debian.org/
> >
> >benchmark implementation
> >contributed by Josh Goldfoot
> >modified by Daniel Fischer to improve performance -}
> >
> > {- An implementation using Data.Graph would be much faster. This
> > implementation
> > is designed to demonstrate the benchmark algorithm. -}
> >
> > import Data.Array
> > import Data.List
> > import System (getArgs)
> >
> > main = do
> > n <- getArgs >>= return . read . head
> > let mn = (n * (1 + n * n)) `div` 2 -- the magic number
> > initialNode = makeSquare n mn (listArray ((1,1),(n,n))
> > (repeat 0), [1
> > .. n^2])
> > allSquares = bestFirst (successorNodes n mn) (initialNode:[])
> > putStrLn $ printMatrix n $ grid $ head allSquares
> > where
> > printMatrix n grid = unlines [ (rowlist grid n y) | y <-
> > [1..n]]
> > where
> > rowlist grid n y = unwords [show $ grid ! (x,y) | x
> > <- [1..n]]
> >
> > data Square = Square { grid :: Array (Int,Int) Int,
> >ffm :: ([Int], Int, Int),
> >unused :: [Int],
> >priority :: !Int }
> >
> > {- bestFirst: Given a queue with one initial node and a function,
> > successors,
> > that takes a node and returns a list of nodes that are created
> > by making
> > all possible moves in a single cell, implements the Best-First
> > algorithm,
> > and returns a list of all nodes that end up with priority
> > zero. In this
> > implementation we only ever use the first node.
> > -}
> > bestFirst _ [] = []
> > bestFirst successors (frontnode:priorityq)
> >
> > | priority frontnode == 0 = frontnode:bestFirst successors
> >
> > priorityq
> >
> > | otherwise = bestFirst successors $ foldr (insertBy
> >
> > compSquare) priorityq
> > (successors frontnode)
> > where
> > {- The priority queue is sorted first by
Re: [Haskell-cafe] Re: Trading with Haskell
On Jul 5, 2006, at 11:56 PM, Ashley Yakeley wrote: Trading financial instruments? You might be interested in the SPJ/ Eber/Seward paper "Composing contracts": http://research.microsoft.com/~simonpj/Papers/financial-contracts/ contracts-icfp.htm Yes, that paper and an hour or so on the phone with SPJ inspired me to take up Haskell when I was Erlang-ing in Sweden. Thank you Simon :D. and also Lexifi, though it appears to be written in OCaml: http://homepages.inf.ed.ac.uk/wadler/realworld/lexifi.html I would love to see sample contract code from that project. Joel -- http://wagerlabs.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Windows Haskell GUI
I was able to build wxHaskell for ghc 6.5 that ships with VisualHaskell and I'd say it's worth the little bit of extra work. I followed the build instructions on the wxHaskell website plus a few modifications that you can find in this thread: http://article.gmane.org/gmane.comp.lang.haskell.cafe/13383 I like wxWidgets a lot although I am finding that wxGrid controls are a bit klunky compared to some of the other wx controls I've used. I can't help with gtk2hs as I haven't tried it yet, but I hear the dev community is much more alive and very helpful. My main concerns with gtk2hs were 1) I need a native look 'n feel 2) ease of distribution with my application. HTH, Jason On 7/5/06, Neil Mitchell <[EMAIL PROTECTED]> wrote: Hi, I want to develop a GUI using Haskell on Windows. As far as I can tell the options for a reasonably high level GUI toolkit are: * wxHaskell * Gtk2Hs Unfortunately I cannot find released packages for GHC 6.4.2 for either of them - Gtk supports only 6.4.1 and wx supports only 6.4.0. Does anyone have builds of either of these that work with 6.4.2? Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Windows Haskell GUI
Hi, I want to develop a GUI using Haskell on Windows. As far as I can tell the options for a reasonably high level GUI toolkit are: * wxHaskell * Gtk2Hs Unfortunately I cannot find released packages for GHC 6.4.2 for either of them - Gtk supports only 6.4.1 and wx supports only 6.4.0. Does anyone have builds of either of these that work with 6.4.2? Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Trading with Haskell
Joel Reymont wrote: Is there anyone trading with Haskell or interested in doing it? Trading financial instruments? You might be interested in the SPJ/Eber/Seward paper "Composing contracts": http://research.microsoft.com/~simonpj/Papers/financial-contracts/contracts-icfp.htm and also Lexifi, though it appears to be written in OCaml: http://homepages.inf.ed.ac.uk/wadler/realworld/lexifi.html -- Ashley Yakeley ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: New Benchmark Under Review: Magic Squares
Am Mittwoch, 5. Juli 2006 15:50 schrieb Simon Marlow: > Malcolm Wallace wrote: > > Daniel Fischer <[EMAIL PROTECTED]> wrote: > >>Cool, though the problem of exploding runtime remains, it's only > >>pushed a little further. Now I get a 5x5 magig square in 1 s, a 6x6 > >>in 5.4 s, but 7x7 segfaulted after about 2 1/2 hours - out of memory, > > > > I note that your solution uses Arrays. I have recently discovered that > > the standard array implementations in GHC introduce non-linear > > performance profiles (wrt to the size of the array). None of the > > ordinary variations of arrays seemed to make any significant difference, > > but replacing Array with the new ByteString from fps brought my > > application's performance back down to the expected linear complexity. > > > > Here are some figures, timings all in seconds: > > > > dataset size (Mb) Array ByteString > > -- - -- > > marschnerlobb0.0690.670.57 > > silicium 0.1131.371.09 > > neghip 0.26 2.682.18 > > hydrogenAtom 2.1031.617.6 > > lobster 5.46 137 49.3 > > engine 8.39 286 83.2 > > statueLeg 10.8420 95.8 > > BostonTeapot11.8488 107 > > skull 16.7924 152 > > Mutable, boxed arrays in GHC have a linear GC overhead in GHC > unfortunately. This is partially fixed in GHC 6.6. > > You can work around it by using either immutable or unboxed arrays, or > both (if you already are, then something else is amiss, and I'd be > interested in taking a look). However, I doubt that IOUArray would beat > ByteString. The code uses UArray (Int,Int) Int, but I'm not convinced that using ByteString would make so much of a difference, it might reduce memory consumption (even significantly), but I think, the problem is the algorithm. bestFirst produces a long list of partially filled squares (for a 7x7 square, the queue's length rises quickly to over 100,000; 5x5 gives a ~500 long queue and 6x6 a ~4,150 queue) and it continually inserts new ones (though not far down the list), so the sheer amount of data the algorithm produces will forbid all dreams of linear complexity. I don't know the algorithm's complexity, it's better than O( (n^2)! ), but from my measurements I gained the impression it's worse than O( n! ), so even with optimal data representation and no overhead, I expect memory consumption rather sooner than later. If anybody produces a 10x10 magic square with this algorithm (and whatever representation of the grid), I'll be very impressed (even 8x8 will be impressive, but 10x10 is beyond what I deem possible). > > Cheers, > Simon Cheers, Daniel -- "In My Egotistical Opinion, most people's C programs should be indented six feet downward and covered with dirt." -- Blair P. Houghton ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Darcs-synchronisation tool
Hello,I typically back up my darcs repositories on different computers. However I do always use the same structure for the different "forests" of darcs repositories. Lately my laptop charger has died which has led me to constantly use a usbstick to move these repositories. Therefore I have started working on a little tool that will automatically sychronise similarly laid out darcs-forests. At the moment it's very bare-to-the-bones. IT will only darcs pull from the repositories in one forest to the other. I later plan to add options to automatically darcs init when necessary (another thing which I've personally missed from time to time). So, if you find yourself in a similar situation, or you have thoughts, concerns, comments regarding it, feedback is welcome!The source can be found at http://www.notvincenz.com/wiki/uploads/Personal/ApplyDarcs.hs and requires Neil Mitchell's http://www.cs.york.ac.uk/fp/darcs/filepath/System/FilePath.hs renamed as plain FilePath.hs. Cheers,Christophe (vincenz) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Packages and modules
Simon Peyton-Jones wrote: So instead of just taking this simple solution, the wiki proposal is instead destroying the beauty of the per-package namespace idea by incorporating into it the existing shared namespaces with their attendant problems, instead of just letting the existing messy system die a natural death through the syntactic isolation I proposed. Brian, I think your proposal may be clearer to you than to everyone else. It's always hard to reconstruct a detailed proposal by reading long email threads. Suggestion: if you feel strongly about this, why not start a Wiki page (you can link to it from the current one) to describe the design you propose, at a comparable level of detail? Incidentally, compatibility with Cabal is a significant goal. Hi Simon - Actually re-reading my post I realised I may have sounded a bit negative about the hard work you'd done to collate the various responses to form the wiki proposal - my apologies. I've followed your suggestion and made a separate page at http://hackage.haskell.org/trac/ghc/wiki/GhcPackagesAlternativeProposal (linked from the bottom of the existing page)which will hopefully make my ideas a lot clearer. I've also changed my proposed syntax so that it is 100% backwards compatible (no new keywords) with the existing module system and language (and existing package naming rules). Regards, Brian. -- Logic empowers us and Love gives us purpose. Yet still phantoms restless for eras long past, congealed in the present in unthought forms, strive mightily unseen to destroy us. http://www.metamilk.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell as embedded DSL
Joel Reymont skrev: On Jul 5, 2006, at 3:07 PM, Niklas Broberg wrote: Lava: http://www.cs.chalmers.se/~koen/Lava/ Excellent example, thank you Niklas! Are you using QuickCheck for verification? I assume you're asking if Lava (rather than Niklas) uses QuickCheck. In Lava, you write properties in a style similar to QuickCheck props., but the actual verification is done by external tools. You still get the nice benefit of having description and verification within the same language. About teaching Lava (and probably other Haskell DSLs) to non Haskellers, I think that higher-order functions (and the type errors you get when using them incorrectly) is what causes most confusion among our students. A minority of them also finds it hard to use recursion instead of loops. Luckily, they don't have to use monads... I've been talking to a person at Intel who has been trying to teach their hardware designers to use a functional language (somewhat like Lava). This turned out to be much harder than expected, since the designers were so used to the imperative style. I'm not sure what the current status is, but they really have to make a trade-off between the time it takes to "convert" the designers and the quality (correctness/maintainability/performance/coding time/etc.) of the resulting code. It is important to show that functional programming has an advantage on the latter aspect (if that is the case). / Emil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Cyclic Type-synonyms
Addendum:
(18:19:50) vincenz: anyways the haskell-cafe post is orthogonal to this safety issue
(18:20:46) vincenz:
it's about the inability to use a generic annotation data-type with any
generic indirect composite ADT without introducing a third data
constructor if one wants recursion
(18:21:33) vincenz: data Foo a = A a; date Note a n = Note { data :: a, info :: n} ;type RecNoteFoo = Note (Foo RecNoteFoo) Int
(18:25:53) audreyt: vincenz: that is a good summary.
(18:26:17) audreyt: sugar selectors, smart constructors, SYB, etc.
(18:26:24) audreyt: but the core problem seems like a real limitation
On 7/5/06, Christophe Poucet <[EMAIL PROTECTED]> wrote:
Hello,
I use the Indirect Composite pattern a lot, and this means that
typically, especially with recursive types (such as an AST), you end up
with a lot of data-constructors. I understand that it is not
possible to have pure cyclic types (because haskell requires
iso-recursive and not equi-recursive types). However I wonder why
certain cases can not be allowed.
For instance, assume the following somewhat simplified AST:
data Exp e =
ELet String e e -- let x = a in b
| ECond e e e -- If then else construct
Now if I wanted to decorate this structure, I would use something like:
data AnnotExp a = AE {
unAE :: Exp (AnnotExp a),
note :: a
}
However, and this
example might be slightly too trivial to motivate it, however it does
exemplify what can be done, one might not want to annotate at all and
just have a recursive data AST. At this point, one either uses
AnnotExp () or creates a new data type. It would be nice if
instead one could use cyclic type-declarations, with the knowledge that
we're going through a data-constructor and hence the type iso-recursive
and not equi-recursive:
type AST = Exp AST -- This is iso-recursive as it goes through the data constructors ELet and ECond
Sadly this is not
possible with the current GHC (I'm using 6..4.2). Is this
possible with 6.6? Is there any reason why this is not
possible. Feedback regarding this is welcome. A more
motivating example can be seen below.
Cheers,
Christophe
-
data Exp var ident func exp stm =
ELit
Lit
-- ^ Literals
| EVar ident -- ^ Identifiers
| EData Const [exp] -- ^ Data Constructors
| ECall func -- ^ Function Calls
| ELet var stm stm -- ^ Scoping
| ECond exp stm stm -- ^ Conditional
| ELoop exp stm -- ^ Looping
deriving (Eq, Show)
data AExp exp annot = AExp {
unAExp :: exp,
aexpNote :: annot,
aexpLoc :: Location
}
type UnCorExp var annot =
Exp
var
-- ^ Let-binders
var
-- ^ Named identifiers
(Ident, [AExp UnCorExp var annot]) -- ^ Function calls
(AExp UnCorExp var
annot)
-- ^ Expressions
(AExp UnCorExp var
annot)
-- ^ Statements
-- Flattened AST: function parameters can only be variables, similar for while- and if- conditions
type UnSimExp var annot
Exp
var
-- ^ Let-binders
var
-- ^ Named identifiers
(Ident,
[var])
-- ^ Function calls
(var)
-- ^ Expressions
(AExp UnSimExp var
annot)
-- ^ Statements
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Trading with Haskell
On 04/07/06, Joel Reymont <[EMAIL PROTECTED]> wrote: Is there anyone trading with Haskell or interested in doing it? Assuming you mean professional development and not Pokemon-style card swapping, you might want to check out the 'Commercial Users' section of the HCAR [1]. [1]: http://www.haskell.org/communities/06-2006/html/report.html#sect7.1 -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Cyclic Type-synonyms
Hello,
I use the Indirect Composite pattern a lot, and this means that
typically, especially with recursive types (such as an AST), you end up
with a lot of data-constructors. I understand that it is not
possible to have pure cyclic types (because haskell requires
iso-recursive and not equi-recursive types). However I wonder why
certain cases can not be allowed.
For instance, assume the following somewhat simplified AST:
data Exp e =
ELet String e e -- let x = a in b
| ECond e e e -- If then else construct
Now if I wanted to decorate this structure, I would use something like:
data AnnotExp a = AE {
unAE :: Exp (AnnotExp a),
note :: a
}
However, and this
example might be slightly too trivial to motivate it, however it does
exemplify what can be done, one might not want to annotate at all and
just have a recursive data AST. At this point, one either uses
AnnotExp () or creates a new data type. It would be nice if
instead one could use cyclic type-declarations, with the knowledge that
we're going through a data-constructor and hence the type iso-recursive
and not equi-recursive:
type AST = Exp AST -- This is iso-recursive as it goes through the data constructors ELet and ECond
Sadly this is not
possible with the current GHC (I'm using 6..4.2). Is this
possible with 6.6? Is there any reason why this is not
possible. Feedback regarding this is welcome. A more
motivating example can be seen below.
Cheers,
Christophe
-
data Exp var ident func exp stm =
ELit
Lit
-- ^ Literals
| EVar ident -- ^ Identifiers
| EData Const [exp] -- ^ Data Constructors
| ECall func -- ^ Function Calls
| ELet var stm stm -- ^ Scoping
| ECond exp stm stm -- ^ Conditional
| ELoop exp stm -- ^ Looping
deriving (Eq, Show)
data AExp exp annot = AExp {
unAExp :: exp,
aexpNote :: annot,
aexpLoc :: Location
}
type UnCorExp var annot =
Exp
var
-- ^ Let-binders
var
-- ^ Named identifiers
(Ident, [AExp UnCorExp var annot]) -- ^ Function calls
(AExp UnCorExp var
annot)
-- ^ Expressions
(AExp UnCorExp var
annot)
-- ^ Statements
-- Flattened AST: function parameters can only be variables, similar for while- and if- conditions
type UnSimExp var annot
Exp
var
-- ^ Let-binders
var
-- ^ Named identifiers
(Ident,
[var])
-- ^ Function calls
(var)
-- ^ Expressions
(AExp UnSimExp var
annot)
-- ^ Statements
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] forall and a parse error
On 03/07/06, Neil Mitchell <[EMAIL PROTECTED]> wrote: [1,2] /= [(1,2)] Ah, I figured we were talking at the type level. -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell as embedded DSL
On Jul 5, 2006, at 3:07 PM, Niklas Broberg wrote: Lava: http://www.cs.chalmers.se/~koen/Lava/ Excellent example, thank you Niklas! Are you using QuickCheck for verification? Thanks, Joel -- http://wagerlabs.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: New Benchmark Under Review: Magic Squares
Hello Simon, Wednesday, July 5, 2006, 5:50:58 PM, you wrote: > Mutable, boxed arrays in GHC have a linear GC overhead in GHC > unfortunately. This is partially fixed in GHC 6.6. > You can work around it by using either immutable or unboxed arrays, or immutable boxed array can still have large overhead because they are created via mutable ones -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell as embedded DSL
On 7/5/06, Joel Reymont <[EMAIL PROTECTED]> wrote: Do you have examples of using Haskell as a DSL in an environment NOT targeted at people who know it already? Lava: http://www.cs.chalmers.se/~koen/Lava/ "Lava is a hardware description language based upon the functional programming language Haskell. Its main aim is to show that modern programming language features such as type inference, polymorphism, higher-order functions, type classes, and laziness are very useful even in hardware description." The target audience is primarily hardware designers, not haskellers. /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] RE: Packages and modules
| So instead of just taking this simple solution, the wiki proposal is instead | destroying the beauty of the per-package namespace idea by incorporating | into it the existing shared namespaces with their attendant problems, | instead of just letting the existing messy system die a natural death | through the syntactic isolation I proposed. Brian, I think your proposal may be clearer to you than to everyone else. It's always hard to reconstruct a detailed proposal by reading long email threads. Suggestion: if you feel strongly about this, why not start a Wiki page (you can link to it from the current one) to describe the design you propose, at a comparable level of detail? Incidentally, compatibility with Cabal is a significant goal. Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: New Benchmark Under Review: Magic Squares
Malcolm Wallace wrote: Daniel Fischer <[EMAIL PROTECTED]> wrote: Cool, though the problem of exploding runtime remains, it's only pushed a little further. Now I get a 5x5 magig square in 1 s, a 6x6 in 5.4 s, but 7x7 segfaulted after about 2 1/2 hours - out of memory, I note that your solution uses Arrays. I have recently discovered that the standard array implementations in GHC introduce non-linear performance profiles (wrt to the size of the array). None of the ordinary variations of arrays seemed to make any significant difference, but replacing Array with the new ByteString from fps brought my application's performance back down to the expected linear complexity. Here are some figures, timings all in seconds: dataset size (Mb) Array ByteString -- - -- marschnerlobb0.0690.670.57 silicium 0.1131.371.09 neghip 0.26 2.682.18 hydrogenAtom 2.1031.617.6 lobster 5.46 137 49.3 engine 8.39 286 83.2 statueLeg 10.8420 95.8 BostonTeapot11.8488 107 skull 16.7924 152 Mutable, boxed arrays in GHC have a linear GC overhead in GHC unfortunately. This is partially fixed in GHC 6.6. You can work around it by using either immutable or unboxed arrays, or both (if you already are, then something else is amiss, and I'd be interested in taking a look). However, I doubt that IOUArray would beat ByteString. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Packages and modules
Simon Peyton-Jones wrote: In response to Brian and Ian's helpful comments, I've added a bunch more stuff to our proposal about packages. If I have missed anything, let me know. http://hackage.haskell.org/trac/ghc/wiki/GhcPackages If you or anyone else thinks the choices made there are poor ones, continue to say so. It's a helpful process. I think the proposed system is too complicated. I'd have thought there were some simple aims: 1) Backwards compatibility so existing code doesn't break 2) Allow people to use per-package module namespaces in new code 3) Allow package names to be URLs (Marc Weber's idea http://www.haskell.org//pipermail/haskell-cafe/2006-June/016378.html ) And the following possible solutions: 1) The current "import" syntax would refer to shared namespace imports (exactly as at present) 2) A new keyword, "use", would indicate use of per-package namespaces 3) Putting the package name in quotes allows more complex package names including URLs and packages located in a specific folder etc in future, and also makes it clear that the package name is an OS filename (albeit conforming to a special form) not a Haskell id, and also allows the "use" syntax to be very concise since a quoted name cannot be confused with a modid. So instead of just taking this simple solution, the wiki proposal is instead destroying the beauty of the per-package namespace idea by incorporating into it the existing shared namespaces with their attendant problems, instead of just letting the existing messy system die a natural death through the syntactic isolation I proposed. In three years' time, how easy will it be to explain Haskell's module system to a new programmer? Regards, Brian. -- Logic empowers us and Love gives us purpose. Yet still phantoms restless for eras long past, congealed in the present in unthought forms, strive mightily unseen to destroy us. http://www.metamilk.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Clever generic ByteString hack?
Hello Donald, Wednesday, July 5, 2006, 3:38:44 PM, you wrote: >> > In MissingH, I have a bunch of little functions that operate on lists. >> > Some, like uniq (which eliminates duplicate elements in a list), operate >> > on (Eq a => [a]) lists. Others, like strip (which eliminates whitespace >> > at the start and end), operate on Strings only. > Spencer Janssen is actually working on such a class (String) to deal > with this, initially to support [a] and Word8 and Unicode bytestrings, > as part of his Summer of Code project. it will be better to implement ListLike class that supports any type of elements -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Packages and modules
Niklas Broberg wrote: So here are some options: 1. the proposal as it is now, keeping exposed/hidden state in the package database, don't support "available" 2. Add support for "available". Cons: yet more complexity! 3. Drop the notion of exposed/hidden, all packages are "available". (except for base?). Cons: lots more typing, very non-backwards-compatible, still have to list dependencies in .cabal files. anyone have any more suggestions? Is there any way to simplify? I rather feel this design is getting a little unwieldy. Maybe a dumb question, but why not support only exposed and available? Why have hidden modules that cannot be used, even when the programmer explicitly asks for them? The main reason for wanting hidden is so that we can be sure that the build-depends field of a Cabal package is exhaustive; we currently do this by making all packages not listed in build-depends hidden. Outside of Cabal, I don't see a reason for wanting hidden. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Clever generic ByteString hack?
On Wed, Jul 05, 2006 at 12:25:53PM +0100, Duncan Coutts wrote: > > different types of input? I'd rather avoid having 3 versions, that are > > exactly the same except for imports. > > People sometimes talk about doing a type class to cover string like > modules. Yes, that makes sense to me. I was sorta hoping to avoid having to say something like: instance StringLike B.ByteString where vlength = B.length vcons = B.cons ... with about 50 of these lines ... > What functions are you thinking of btw? We may want to include them in > the ByteString modules anyway (possibly directly rather than in terms of > other functions, to take advantage of tricks with the representation). Most everything here: http://quux.org/devel/missingh/html/MissingH-Str.html The appropriate bits from: http://quux.org/devel/missingh/html/MissingH-List.html And perhaps even: http://quux.org/devel/missingh/html/MissingH-Str-CSV.html Also, it would be nice to see direct regexp support in ByteString. It seems ugly to have to convert to a String just to pass it back to C. But even if you did implement all of that, I think there is still utility in having a generic typeclass that can take any of the three string-like types that we have in Haskell these days. Otherwise, you are going to see library fracturization -- some code works with Strings, some with ByteStrings, some with lazy ByteStrings, and woe to the programmer that has to integrate all this mess. (OCaml has this problem in a big way with its lists vs. Streams and built-in handicapped IO vs. Posix IO) -- John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Clever generic ByteString hack?
On Wed, Jul 05, 2006 at 09:38:44PM +1000, Donald Bruce Stewart wrote: > > What functions are you thinking of btw? We may want to include them in > > the ByteString modules anyway (possibly directly rather than in terms of > > other functions, to take advantage of tricks with the representation). > > Spencer Janssen is actually working on such a class (String) to deal > with this, initially to support [a] and Word8 and Unicode bytestrings, > as part of his Summer of Code project. That's nice, but that sounds different. I'm specifically wanting support for the ByteString and lazy ByteString types. Also, it sounds like he would have to re-implement some of the functions you already have in ByteString. > Note also that we have the Foldable and Monoid classes, which support parts of > a String interface. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Strictness in do block
On 2006-07-05, Duncan Coutts <[EMAIL PROTECTED]> wrote: >> What I have done in the past is to take the length of the string, and >> test the length in some way - although I guess you could call seq on >> the length. > > evaluate is for just that purpose. > > evaluate (length input) > > > from the docs: > > http://haskell.org/ghc/docs/latest/html/libraries/base/Control-Exception.html#v%3Aevaluate That looks like what I need, but why is it in Control.Exception instead of System.IO? If it were in System.IO, I would have found it. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] New Benchmark Under Review: Magic Squares
Hello Malcolm, Wednesday, July 5, 2006, 4:30:43 PM, you wrote: > I note that your solution uses Arrays. I have recently discovered that > the standard array implementations in GHC introduce non-linear > performance profiles (wrt to the size of the array). None of the > ordinary variations of arrays seemed to make any significant difference, > but replacing Array with the new ByteString from fps brought my > application's performance back down to the expected linear complexity. are you give a chance to UArray? boxed arrays in ghc 6.4 may sufficiently increase GC times -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Packages and modules
So here are some options: 1. the proposal as it is now, keeping exposed/hidden state in the package database, don't support "available" 2. Add support for "available". Cons: yet more complexity! 3. Drop the notion of exposed/hidden, all packages are "available". (except for base?). Cons: lots more typing, very non-backwards-compatible, still have to list dependencies in .cabal files. anyone have any more suggestions? Is there any way to simplify? I rather feel this design is getting a little unwieldy. Maybe a dumb question, but why not support only exposed and available? Why have hidden modules that cannot be used, even when the programmer explicitly asks for them? /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Clever generic ByteString hack?
Hello Duncan, Wednesday, July 5, 2006, 3:25:53 PM, you wrote: > People sometimes talk about doing a type class to cover string like > modules. class ListLike ce e | ce->e where head :: ce -> e instance ListLike [a] a instance ListLike (Sequence a) a instance ListLike ByteString Char instance ListLike (ArraySlice a) a (ByteString is really array slice specialized for "StorableArray Char") > What functions are you thinking of btw? We may want to include them in > the ByteString modules anyway (possibly directly rather than in terms of > other functions, to take advantage of tricks with the representation). we anyway need class to allow implementing, say, FilePath module working with strings of any type -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Strictness in do block
Hello John, Wednesday, July 5, 2006, 3:04:22 PM, you wrote: > What I want to know is the generic way to force an entire String (or > other list, perhaps from hGetContents) to be evaluated (read into RAM, I > guess) so the underlying file can be closed and do it right now. eval [] = [] eval (x:xs) = eval xs do str <- getContents return $! eval str is my usual hack. there is also `deepSeq` if you need to fully evaluate more complex structure. btw, this 'eval' don't evaluate list elements - it should be not a problem for evaluation result of 'getContents' -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] New Benchmark Under Review: Magic Squares
Daniel Fischer <[EMAIL PROTECTED]> wrote: > Cool, though the problem of exploding runtime remains, it's only > pushed a little further. Now I get a 5x5 magig square in 1 s, a 6x6 > in 5.4 s, but 7x7 segfaulted after about 2 1/2 hours - out of memory, I note that your solution uses Arrays. I have recently discovered that the standard array implementations in GHC introduce non-linear performance profiles (wrt to the size of the array). None of the ordinary variations of arrays seemed to make any significant difference, but replacing Array with the new ByteString from fps brought my application's performance back down to the expected linear complexity. Here are some figures, timings all in seconds: dataset size (Mb) Array ByteString -- - -- marschnerlobb0.0690.670.57 silicium 0.1131.371.09 neghip 0.26 2.682.18 hydrogenAtom 2.1031.617.6 lobster 5.46 137 49.3 engine 8.39 286 83.2 statueLeg 10.8420 95.8 BostonTeapot11.8488 107 skull 16.7924 152 Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Clever generic ByteString hack?
duncan.coutts: > On Wed, 2006-07-05 at 05:58 -0500, John Goerzen wrote: > > Hi, > > > > In MissingH, I have a bunch of little functions that operate on lists. > > Some, like uniq (which eliminates duplicate elements in a list), operate > > on (Eq a => [a]) lists. Others, like strip (which eliminates whitespace > > at the start and end), operate on Strings only. > > > > Most functions of both types would be useful on ByteStrings and lazy > > ByteStrings. Most of these functions are written in terms of Data.List > > functions or list primitives that have equivolents in Data.ByteString. > > > > So, my question is: is there a clever hack available to me so that I > > could have 1 version of each function, and have it work on all three > > different types of input? I'd rather avoid having 3 versions, that are > > exactly the same except for imports. > > People sometimes talk about doing a type class to cover string like > modules. > > What functions are you thinking of btw? We may want to include them in > the ByteString modules anyway (possibly directly rather than in terms of > other functions, to take advantage of tricks with the representation). Spencer Janssen is actually working on such a class (String) to deal with this, initially to support [a] and Word8 and Unicode bytestrings, as part of his Summer of Code project. Note also that we have the Foldable and Monoid classes, which support parts of a String interface. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Packages and modules
Ketil Malde wrote: What is the "current package"? The package that you're currently compiling. This now must be known at compile time. My impression was that "from" would only be needed when there was ambiguity. (And if I wanted to type myself to death, I'd be using Java :-) If you *have* to specify package, this makes things a lot less flexible (e.g., moving a module from one package to another will break code) Our current plan is a relatively small delta from the current scheme: as you say, "from" is only required when there is an ambiguity. This assumes we keep the current idea of exposed/hidden packages. Having a default set of exposed packages is terribly convenient when just firing up GHCi, for example. In fact, we can imagine three states that a package could be in: - exposed: the package's modules populate the global module namespace, explicit "from" imports may be used to resolve ambiguity - hidden: the package cannot be used at all - available: the package can be used only by an explicit "from" import (this is rather like a qualified import at the package level, and might be useful if you want to use a package with module names that overlap with local modules). Currently, packages have a default state of either exposed or hidden. Cabal ignores the default state, and requires you to say explicitly which packages you want to be exposed. We don't have the "available" state, at the moment. So here are some options: 1. the proposal as it is now, keeping exposed/hidden state in the package database, don't support "available" 2. Add support for "available". Cons: yet more complexity! 3. Drop the notion of exposed/hidden, all packages are "available". (except for base?). Cons: lots more typing, very non-backwards-compatible, still have to list dependencies in .cabal files. anyone have any more suggestions? Is there any way to simplify? I rather feel this design is getting a little unwieldy. I resist the temptation to discuss syntax too early... Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Packages and modules
Ian Lynagh wrote: I think I missed where the plan to use quotes came from. What's the purpose? Package names already have a well-defined syntax with no spaces or other confusing characters in them, so why do we need the quotes? Or is it just so we can have packages with the same name as keywords? I think it's non-trivial to embed the syntax of package names into the Haskell grammar. The version part will sometimes lex as a floating point literal, for example. Ugh. Strings are much easier. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Clever generic ByteString hack?
On Wed, 2006-07-05 at 05:58 -0500, John Goerzen wrote: > Hi, > > In MissingH, I have a bunch of little functions that operate on lists. > Some, like uniq (which eliminates duplicate elements in a list), operate > on (Eq a => [a]) lists. Others, like strip (which eliminates whitespace > at the start and end), operate on Strings only. > > Most functions of both types would be useful on ByteStrings and lazy > ByteStrings. Most of these functions are written in terms of Data.List > functions or list primitives that have equivolents in Data.ByteString. > > So, my question is: is there a clever hack available to me so that I > could have 1 version of each function, and have it work on all three > different types of input? I'd rather avoid having 3 versions, that are > exactly the same except for imports. People sometimes talk about doing a type class to cover string like modules. What functions are you thinking of btw? We may want to include them in the ByteString modules anyway (possibly directly rather than in terms of other functions, to take advantage of tricks with the representation). Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Strictness in do block
I can always stumble upon things that work, but I'm never sure if I've got 'em right. So, what is the idiomatic way to do this? I think something like > evaluate (rnf myString) Evaluate is an action that forces the value to be evaluated. rnf (from Control.Parallel.Strategies) is 'reduce to normal form', i.e. deepSeq. Twan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Strictness in do block
On Wed, 2006-07-05 at 12:08 +0100, Neil Mitchell wrote: > Hi, > > > What I want to know is the generic way to force an entire String (or > > other list, perhaps from hGetContents) to be evaluated (read into RAM, I > > guess) so the underlying file can be closed and do it right now. > What I have done in the past is to take the length of the string, and > test the length in some way - although I guess you could call seq on > the length. evaluate is for just that purpose. evaluate (length input) from the docs: http://haskell.org/ghc/docs/latest/html/libraries/base/Control-Exception.html#v%3Aevaluate evaluate :: a -> IO a Forces its argument to be evaluated, and returns the result in the IO monad. It can be used to order evaluation with respect to other IO operations; its semantics are given by evaluate undefined `seq` return () ==> return () catch (evaluate undefined) (\e -> return ()) ==> return () NOTE: (evaluate a) is not the same as (a `seq` return a). Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Strictness in do block
Hi, What I want to know is the generic way to force an entire String (or other list, perhaps from hGetContents) to be evaluated (read into RAM, I guess) so the underlying file can be closed and do it right now. What I have done in the past is to take the length of the string, and test the length in some way - although I guess you could call seq on the length. Of course, the length tests technically doesn't evaluate the character positions (just the spine of the list), but it always works in practice. Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Strictness in do block
Hi, One thing that seems to keep biting me is strictness in do blocks. What I want to know is the generic way to force an entire String (or other list, perhaps from hGetContents) to be evaluated (read into RAM, I guess) so the underlying file can be closed and do it right now. One quick hack that works is hPutStrLn on it, right where I want it to be evaluated. But ugly and not always appropriate. Passing it to some other IO-based functions also works, but again, that doesn't "feel" right. I can always stumble upon things that work, but I'm never sure if I've got 'em right. So, what is the idiomatic way to do this? Most of the documents I see out there on this topic are for usage outside the I/O monad, and I'm not seeing how they apply here. Thanks, -- John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Clever generic ByteString hack?
Hi, In MissingH, I have a bunch of little functions that operate on lists. Some, like uniq (which eliminates duplicate elements in a list), operate on (Eq a => [a]) lists. Others, like strip (which eliminates whitespace at the start and end), operate on Strings only. Most functions of both types would be useful on ByteStrings and lazy ByteStrings. Most of these functions are written in terms of Data.List functions or list primitives that have equivolents in Data.ByteString. So, my question is: is there a clever hack available to me so that I could have 1 version of each function, and have it work on all three different types of input? I'd rather avoid having 3 versions, that are exactly the same except for imports. Thanks, -- John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [haskell] ANNOUNCE: HNOP 0.1
On Sat, 2006-07-01 at 16:36 +0100, Ian Lynagh wrote:
> [resending as the original seems to have been silently eaten;
> attachements are at http://urchin.earth.li/~ian/splitting/ ]
>
> On Fri, Jun 30, 2006 at 03:45:57PM -0700, mvanier wrote:
> >
> > I'm at a loss here. Somehow, the SplitObjs option doesn't seem to be doing
> > the job. Any suggestions would be appreciated.
>
> It looks like gcc 4.1 is floating all the
>
> __asm__("\n__stg_split_marker:");
>
> results to the top of the file, so the splitter sees only a number of
> empty sections followed by one large one.
http://hackage.haskell.org/trac/ghc/ticket/809
this is now fixed by ghc passing -fno-unit-at-a-time to gcc
> Amd64 doesn't seem to be afflicted.
because it was already using -fno-unit-at-a-time
Duncan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell as embedded DSL
Folks, Do you have examples of using Haskell as a DSL in an environment NOT targeted at people who know it already? I'm thinking of using Haskell to build my Mac trading app but I'm very concerned about dumping Haskell on the trading systems developers. It seems that using, say, Ruby as the trading systems DSL would give me a leg up since it's simple and syntax and generally warm and fuzzy. What do you think? Thanks, Joel P.S. Yes, I'm a big fan of "Composing Financial Contracts" -- http://wagerlabs.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [haskell] ANNOUNCE: HNOP 0.1
On Fri, Jun 30, 2006 at 03:45:57PM -0700, mvanier wrote:
>
> I'm at a loss here. Somehow, the SplitObjs option doesn't seem to be doing
> the job. Any suggestions would be appreciated.
It looks like gcc 4.1 is floating all the
__asm__("\n__stg_split_marker:");
results to the top of the file, so the splitter sees only a number of
empty sections followed by one large one. Results of
echo 'module Foo where' > Foo.hs
for i in `seq 1 10`; do echo "foo$i = 'c'" >> Foo.hs; done
mkdir Foo_split
ghc -O -split-objs -c Foo.hs -v -keep-tmp-files
are attached, using
$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,java,fortran,objc,obj-c++,ada,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.1-1.4.2.0/jre --enable-mpfr
--with-tune=i686 --enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.1.2 20060613 (prerelease) (Debian 4.1.1-5)
Amd64 doesn't seem to be afflicted.
Thanks
Ian
[EMAIL PROTECTED]:~/debug$ ghc -O -split-objs -c Foo.hs -v -keep-tmp-files
Glasgow Haskell Compiler, Version 6.4.2, for Haskell 98, compiled by GHC
version 6.4.2
Using package config file: /usr/lib/ghc-6.4.2/package.conf
Hsc static flags: -static -fglobalise-toplev-names
*** Checking old interface for Foo:
*** Parser:
*** Renamer/typechecker:
*** Desugar:
Result size = 50
*** Simplify:
Result size = 30
Result size = 30
*** Specialise:
Result size = 30
*** Float out (not lambdas, not constants):
Result size = 30
*** Float inwards:
Result size = 30
*** Simplify:
Result size = 30
*** Simplify:
Result size = 30
*** Simplify:
Result size = 30
*** Demand analysis:
Result size = 30
*** Worker Wrapper binds:
Result size = 30
*** GlomBinds:
*** Simplify:
Result size = 30
*** Float out (not lambdas, constants):
Result size = 30
*** Common sub-expression:
Result size = 21
*** Float inwards:
Result size = 21
*** Simplify:
Result size = 21
*** Tidy Core:
Result size = 21
*** CorePrep:
Result size = 21
*** Stg2Stg:
*** CodeGen:
*** CodeOutput:
*** C Compiler
gcc -x c /tmp/ghc26801.hc -o /tmp/ghc26801.raw_s -DDONT_WANT_WIN32_DLL_SUPPORT
-fno-defer-pop -fomit-frame-pointer -fno-builtin -DSTOLEN_X86_REGS=4
-ffloat-store -fno-strict-aliasing -v -S -Wimplicit -O
-D__GLASGOW_HASKELL__=604 -DUSE_SPLIT_MARKERS -I . -I /usr/lib/ghc-6.4.2/include
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,java,fortran,objc,obj-c++,ada,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.1-1.4.2.0/jre --enable-mpfr
--with-tune=i686 --enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.1.2 20060613 (prerelease) (Debian 4.1.1-5)
/usr/lib/gcc/i486-linux-gnu/4.1.2/cc1 -quiet -v -I . -I
/usr/lib/ghc-6.4.2/include -DDONT_WANT_WIN32_DLL_SUPPORT -DSTOLEN_X86_REGS=4
-D__GLASGOW_HASKELL__=604 -DUSE_SPLIT_MARKERS /tmp/ghc26801.hc -quiet -dumpbase
ghc26801.hc -mtune=i686 -auxbase-strip /tmp/ghc26801.raw_s -O -Wimplicit
-version -fno-defer-pop -fomit-frame-pointer -fno-builtin -ffloat-store
-fno-strict-aliasing -o /tmp/ghc26801.raw_s
ignoring nonexistent directory "/usr/local/include/i486-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../i486-linux-gnu/include"
ignoring nonexistent directory "/usr/include/i486-linux-gnu"
#include "..." search starts here:
#include <...> search starts here:
.
/usr/lib/ghc-6.4.2/include
/usr/local/include
/usr/lib/gcc/i486-linux-gnu/4.1.2/include
/usr/include
End of search list.
GNU C version 4.1.2 20060613 (prerelease) (Debian 4.1.1-5) (i486-linux-gnu)
compiled by GNU C version 4.1.2 20060613 (prerelease) (Debian 4.1.1-5).
GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=129565
Compiler executable checksum: 3efbb0b5b3119ec825babd3e1cecb910
*** Mangler
/usr/lib/ghc-6.4.2/ghc-asm /tmp/ghc26801.raw_s /tmp/ghc26801.split_s 4
*** Splitter
/usr/lib/ghc-6.4.2/ghc-split /tmp/ghc26801.split_s /tmp/ghc26801.split
/tmp/ghc26801.split
*** Assembler
gcc -c -o Foo_split/Foo__1.o /tmp/ghc26801.split__1.s
/* GHC_PACKAGES base-1.0 rts-1.0
*/
#include "Stg.h"
#include "HsBase.h"
__STG_SPLIT_MARKER
EI_(GHCziBase_Czh_static_info);
StgWord Foo_foo10_closure[] = {
(W_)&GHCziBase_Czh_static_info, 0x63U
};
__STG_SPLIT_MARKER
EI_(Foo_foo9_info);
StgWord Foo_foo9_closure
[Haskell-cafe] RE: Packages and modules
In response to Brian and Ian's helpful comments, I've added a bunch more stuff to our proposal about packages. If I have missed anything, let me know. http://hackage.haskell.org/trac/ghc/wiki/GhcPackages If you or anyone else thinks the choices made there are poor ones, continue to say so. It's a helpful process. One particular point: | 2b) Exporting the contents of an external module qualified | |module Foo | ( qualified module P | ) where While this might be a good idea, it's an orthogonal one, and the proposal doesn't tackle it. One thing at a time! Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Packages and modules
"Brian Hulley" <[EMAIL PROTECTED]> writes: > because if the suggested syntax is used, import directives come in two > flavours: ones that use "from" to import from a different package and > ones that don't use "from" and therefore must refer to the current > package. What is the "current package"? My impression was that "from" would only be needed when there was ambiguity. (And if I wanted to type myself to death, I'd be using Java :-) If you *have* to specify package, this makes things a lot less flexible (e.g., moving a module from one package to another will break code) Would 'base' be the current package in most cases? That would encourage cramming even more stuff into base¹, and I suspect the overloaded 'base' is half the reason we're discussing all this extra syntactical baggage. (E.g. experimenting with a newer version of Don's FPS, I basically need to replace 'base'. With the features being discussed, I could get by rewriting the import statements in all my fps-using code, which would be an improvement. It'd be much safer and better to have a compiler option, of course, but I guess that will only work for complete packages.) Anyway (and like you say) I think the workaround using qualification or hiding is more than sufficient, I consider recycling names from imported modules for local variables questionable as best, and would rather it wasn't encouraged. > 3) Syntax: > I liked Ian Lynagh's suggestion of using "from" to start either a > single import directive or a block of import directives > http://www.haskell.org//pipermail/haskell-cafe/2006-June/016338.html > eg (modified to use quotes): >from "base" >import Predude hiding(length) >import Control.Exception >import qualified Data.List as List Would this make 'from' a reserved word? I think this is only useful if you require the module to be declared, and thus not worth an extra keyword (and code breakage) if non-ambigous modules can still be imported. Anyway, I'd just like to say that I'm really happy about the way GHC and Cabal currently works - 'ghc --make' takes care of package imports, and Cabal is simple enough that most of my code gets Cabalized these days. -k ¹ What *is* the advantage of stuffing everything and the kitchen sink into base, btw? -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Packages and modules
On Wed, Jul 05, 2006 at 01:03:01AM +0100, Brian Hulley wrote:
> Simon Peyton-Jones wrote:
> >Concerning other mail on this subject, which has been v useful, I've
> >revised the Wiki page (substantially) to take it into account.
> >http://hackage.haskell.org/trac/ghc/wiki/GhcPackages
> >
> >Further input (either by email or by adding material to the Wiki)
> >would be welcome. (No guarantee Simon M agrees with what I've
> >written... I'm at home this afternoon :-)
>
> I think the following is a non-question:
>
> An open question: if A.B.C is in the package being compiled,
> and in an exposed package, and you say import A.B.C,
> do you get an error ("ambiguous import"), or does the current
> package override.
>
> because if the suggested syntax is used, import directives come in two
> flavours: ones that use "from" to import from a different package and ones
> that don't use "from" and therefore must refer to the current package.
FWIW this isn't what I actually intended when I was talking about using
"from". I was imagining it would work similar to how "foo" unqualified
can refer to either an imported variable or a variable in the current
package, but we can still qualify "Foo.foo" should we wish to be
explicit. So you can "import" from any package, including the current
one, but qualify "from package import" should you wish to be explicit.
> (modified to use quotes):
>
>from "base"
I think I missed where the plan to use quotes came from. What's the
purpose? Package names already have a well-defined syntax with no spaces
or other confusing characters in them, so why do we need the quotes? Or
is it just so we can have packages with the same name as keywords? (if
so I think personally I'd prefer a slightly more context-sensitive
grammar, not entirely unlike the as/qualified/hiding semi-keywords in
import statements).
>import Predude hiding(length)
>import Control.Exception
>import qualified Data.List as List
>
> since otherwise it would soon become a bit of a pain to have to type 'from
> "base"' everywhere (esp if the package name was some long URL). It would
> also make it easier to quickly change to a different package without having
> to modify multiple import directives, which might be especially useful in
> the context of using a debug or release version of a package by putting C
> pre-processor directives around the "from" part.
>
> There is a minor open question about the exact indentation rule for the
> above syntax since "base" is not a keyword and it would seem strange to
> desugar it into from {"base"; import ... } so it looks like it would need a
> special layout rule that would give a desugaring into from "base" {import
> ...}
It would only be slightly different to the current rules (it would be if
the second lexeme after "from" was not '{', rather than the first),
although now you mention it this would be an alternative possibility:
from "base" import
Prelude hiding (length)
Control.Exception
qualified Data.List as List
where "import" behaves much like "of" as far as the layout rule is
concerned.
Thanks
Ian
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
