Re: ANNOUNCE: Bamse 1.0
Hi, On 8/17/07, Sigbjorn Finne [EMAIL PROTECTED] wrote: Galois is pleased to announce the first public release of Bamse, a Windows Installer creator framework written in Haskell. Using Bamse, you can easily create applications that let you build Windows Installer (MSIs) for your project's product deliverables. The tool was written quite a while ago (4-5 years) as an internal tool at Galois to help the automated building of shippable bundles for Windows platforms, but has also been used for GHC installers since version 5.0.x (and other Haskell-related tools, interpreters and packages.) Cool :-) I wish I had known this was coming - I've been working recently on MSI generator for pre-compiled Cabal-packages, but it uses Wix tools, instead of foreign bindings to MSI interfaces. The source code + support package is available from http://galois.com/~sof/bamse/ Remarks/notes: - the source code is covered by a BSD license. - questions, bug reports to [EMAIL PROTECTED] / [EMAIL PROTECTED] (*) - If someone would like to adopt and extend the code to make it even more useful, feel free to dive in and hack. (Integrate it into the building of Cabal source and binary dists, perhaps..?) - If there's genuine interest, the code could be made available via a repo ( (*) being the main reason not to right now.) Best regards, Esa ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Qualified identifiers opinion
Hi Isaac,
just to give you a reply at all, see below. I reply
glasgow-haskell-users@haskell.org since I'm not subscribed to
haskell-prime. And I don't want to subscribe, because I'm more
interested that Haskell becomes more stable (and standard). So here is
my opinion:
1. The lexer should recognize keywords.
2. I would not mind if Haskel98 rejected all keywords that are also
rejected by extensions, so that the lexer is extension independent.
(Starting with Haskell98, removing conflicting identifiers as soon as I
switch on valuable extensions does not make sense.)
3. I'm against qualified identifiers, with the unqualified part being a
keyword like Foo.where. (The choice of qualification should be left to
the user, usually one is not forced to used qualified names.)
4. However, Foo.where should always be rejected and not changed to
Foo.wher e! (Longest matching, aka maximal munch, must not consider
keywords!)
(see end of: http://www.haskell.org/onlinelibrary/lexemes.html#sect2.4)
I would not mind if a name F. is plainly rejected. It only makes
sense, when a data constructor is the first argument of the composition
operator (.)
Maybe . and $ as operators should require white spaces on both
sides, since $( also indicates template haskell.
Cheers Christian
Isaac Dupree wrote:
Especially after writing a partial lexer for Haskell, I opine that this
should be all legal:
module Foo where
--in case you didn't know, this is legal syntax:
Foo.f = undefined
Foo.mdo = undefined
Foo.where = undefined
x Foo.! y = undefined
x Foo... y = undefined --remember .. is reserved id, e.g. [2..5]
{-# LANGUAGE RecursiveDo, BangPatterns #-} module Bar where
import Foo
hello !x = mdo { y - Foo.mdo Foo... ({-Foo.-}f x y); return y }
{- Haskell 98 -} module Baz where
import Foo
goodbye x = x ! 12
(Foo.where) lexing as (Foo.wher e) or (Foo . where) does not make me
happy. (being a lexer error is a little less bad...) Especially not
when the set of keywords is flexible. I don't see any good reason to
forbid declaring keywords as identifiers/operators, since it is
completely unambiguous, removes an extension-dependence from the lexer
and simplifies it (at least the mental lexer); Also I hear that the
Haskell98 lexing is (Foo.wher e), which I'm sure no one relies on...
Well, that's my humble opinion on what should go into Haskell' on this
issue.
Isaac
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
where to take ghc-6.8(.1)
Yan Linah wrote about testing ghc-6.8(.1). Please, where to take its source from? If it is CVS, then, please, specify the command. Is it with profiling? - Serge Mechveliani [EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Qualified identifiers opinion
On Fri, Aug 17, 2007 at 12:53:11PM +0200, Christian Maeder wrote: Hi Isaac, just to give you a reply at all, see below. I reply glasgow-haskell-users@haskell.org since I'm not subscribed to haskell-prime. And I don't want to subscribe, because I'm more interested that Haskell becomes more stable (and standard). So here is my opinion: 1. The lexer should recognize keywords. 2. I would not mind if Haskel98 rejected all keywords that are also rejected by extensions, so that the lexer is extension independent. (Starting with Haskell98, removing conflicting identifiers as soon as I switch on valuable extensions does not make sense.) 3. I'm against qualified identifiers, with the unqualified part being a keyword like Foo.where. (The choice of qualification should be left to the user, usually one is not forced to used qualified names.) 4. However, Foo.where should always be rejected and not changed to Foo.wher e! (Longest matching, aka maximal munch, must not consider keywords!) (see end of: http://www.haskell.org/onlinelibrary/lexemes.html#sect2.4) I would not mind if a name F. is plainly rejected. It only makes sense, when a data constructor is the first argument of the composition operator (.) Maybe . and $ as operators should require white spaces on both sides, since $( also indicates template haskell. What's wrong with the status quo? Our current lexical rules *seem* complicated to newbies, but just like everything else in Haskell it carries a deep simplicity; having only one rule (maximal-munch) gives a certain elegance that the proposals all lack. I'd hate to see Haskell become complex all the way down just to fix a few corner cases; I see this pattern of simplicity degerating through well-intentioned attempts to fix things all over the language... Stefan signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Qualified identifiers opinion
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stefan O'Rear Sent: Friday, August 17, 2007 2:45 PM To: Christian Maeder Cc: Haskell Prime; GHC Users Mailing List; Isaac Dupree Subject: Re: Qualified identifiers opinion On Fri, Aug 17, 2007 at 12:53:11PM +0200, Christian Maeder wrote: Hi Isaac, just to give you a reply at all, see below. I reply glasgow-haskell-users@haskell.org since I'm not subscribed to haskell-prime. And I don't want to subscribe, because I'm more interested that Haskell becomes more stable (and standard). So here is my opinion: 1. The lexer should recognize keywords. 2. I would not mind if Haskel98 rejected all keywords that are also rejected by extensions, so that the lexer is extension independent. (Starting with Haskell98, removing conflicting identifiers as soon as I switch on valuable extensions does not make sense.) 3. I'm against qualified identifiers, with the unqualified part being a keyword like Foo.where. (The choice of qualification should be left to the user, usually one is not forced to used qualified names.) 4. However, Foo.where should always be rejected and not changed to Foo.wher e! (Longest matching, aka maximal munch, must not consider keywords!) (see end of: http://www.haskell.org/onlinelibrary/lexemes.html#sect2.4) I would not mind if a name F. is plainly rejected. It only makes sense, when a data constructor is the first argument of the composition operator (.) Maybe . and $ as operators should require white spaces on both sides, since $( also indicates template haskell. What's wrong with the status quo? Our current lexical rules *seem* complicated to newbies, but just like everything else in Haskell it carries a deep simplicity; having only one rule (maximal-munch) gives a certain elegance that the proposals all lack. I'd hate to see Haskell become complex all the way down just to fix a few corner cases; I see this pattern of simplicity degerating through well-intentioned attempts to fix things all over the language... Stefan I agree with Stefan, for the reasons he stated and for one additional reason: There would be a multitude of unintended behavior changes. Seth Kurtzberg Software Engineer Specializing in Security, Reliability, and the Hardware/Software Interface ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Qualified identifiers opinion
Christian Maeder wrote: Hi Isaac, just to give you a reply at all, see below. I reply glasgow-haskell-users@haskell.org since I'm not subscribed to haskell-prime. And I don't want to subscribe, because I'm more interested that Haskell becomes more stable (and standard). Then maybe you can join haskell-prime and provide the energy that rounds up all the little fixes and tries to actually produce the thing! Drastic changes are not intended to go in. Haskell' should bring more stability and standardness (as long as it doesn't diverge too much from Haskell98, which would decrease stability and standardness) So here is my opinion: 1. The lexer should recognize keywords. 2. I would not mind if Haskel98 rejected all keywords that are also rejected by extensions, so that the lexer is extension independent. (Starting with Haskell98, removing conflicting identifiers as soon as I switch on valuable extensions does not make sense.) Trouble is, extensions are just that: extensions, and more with their own keywords may be added in the future! unless we want an internet-standard-like x-keywordname - but that doesn't solve this problem: standardized new keyword names clogging up the general namespace, as long as they don't have a symbol (like Objective-C has @class, @whatever...). 3. I'm against qualified identifiers, with the unqualified part being a keyword like Foo.where. (The choice of qualification should be left to the user, usually one is not forced to used qualified names.) 4. However, Foo.where should always be rejected and not changed to Foo.wher e! (Longest matching, aka maximal munch, must not consider keywords!) (see end of: http://www.haskell.org/onlinelibrary/lexemes.html#sect2.4) I would not mind if a name F. is plainly rejected. It only makes sense, when a data constructor is the first argument of the composition operator (.) I wouldn't mind if that was banned either. That case needs to be considered for implementing my lexer. In fact, banning that and qualified keywords allows the lexer proper not to know keywords and nevertheless ban qualified keywords (a bit of a hack). But... while I wouldn't _recommend_ using qualified keywords, and compilers could give a warning even for haskell98 code that uses known extension-keyword-names at all, it seems best to me, to _allow_ them, in the interests of allowing code to remain fairly stable with the potential of extensions being developed (especially thinking of the BangPatterns that had an effect on existing definitions of (!) ). Maybe . and $ as operators should require white spaces on both sides, since $( also indicates template haskell. but it's so convenient as it is... plenty of code uses (.) without spaces, and I don't like the way template-haskell steals $( and $id (from the point of view of a person who has never tried to use template-haskell). I think haskell is more stable by allowing existing code e.g. (f = fix (\rec - rec ) --'rec' is arrow-sugar keyword than banning some bunch of new keyword names. And allowing interim interoperability with old code that exports those names, like the unfortunate (!) or (.) (I know, those aren't exactly ever keywords/syms) seems like a good idea when it removes complexity rather than adding it. I don't want Haskell98 to become a language that has difficulty interoperating with libraries and using-applications that use newer Haskells. from other comments: What's wrong with the status quo? Our current lexical rules *seem* complicated to newbies, but just like everything else in Haskell it carries a deep simplicity; having only one rule (maximal-munch) gives a certain elegance that the proposals all lack. I'd hate to see Haskell become complex all the way down just to fix a few corner cases; I see this pattern of simplicity degerating through well-intentioned attempts to fix things all over the language... I agree with Stefan, for the reasons he stated and for one additional reason: There would be a multitude of unintended behavior changes. Well, GHC doesn't implement aforementioned maximal-munch re: keywords. I don't think it's good (compositional?) design for the set of keywords to be part of the lexer rather than a pass after it, when keywords behave so similarly to other words, and also when there are non-keywords like as and qualified and sometimes forall (whose non-reserved status I support). lex -- keywords -- layout -- parse Besides, I don't think any of the above proposals will generate behavior changes in real code. Some cause more errors (adding more keywords; banning adjacent '.' or '$') and some allow a few more things that were errors before. f = Just.let x = x in id --a.k.a. f = Just would break in my proposal, but it also breaks according to Haskell98... Isaac ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org
