- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] wxHaskell: convenience functions
by Mark Carter 17 Sep '05

17 Sep '05

Re: [Haskell-cafe] wxHaskell: convenience functions Actually, I can see how my requirement of not wanting to pass in cbEdit might not be so good. From an FP point of view, that's just asking for trouble. A better solution would appear to be to put the cbEdit in as a parameter, and just face the fact that all callers will be required to pass an extra parameter. Mark Carter wrote: > > > I'm experimenting with wxHaskell, and I've got something like: > > main = run mainFrame > > mainFrame = do -- main application frame > ... > cbEdit <- checkBox p1 [text := "Edit Mode", on command ::= onCbEdit textlog] > ... > where > ... > > It would be useful to have some convenience function, let's say, isEditing, which works out whether cbEdit is checked, or not. That way, one could just pass this in as a parameter without requiring any extra code. The problem is, I can't see how it can be done. I've tried various things in the main section, and nothing worked. I tried putting the following defintion into the where clause: > > isEditing = do > checkedp <- get cbEdit checked > return checkedp > > but the compiler complained that cbEdit is not in scope. I /could/ pass in cbEdit as a parameter to isEditing, but I'd rather not. > > > > ___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___________________________________________________________ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com

1 0

Re: [Haskell-cafe] Haskell versus Lisp
by Jacques Carette 17 Sep '05

17 Sep '05

Glynn Clements wrote: >Every other language (including Haskell) tends to have the problem >that eventually you will encounter a situation where the language's >own worldview gets in the way. > >Or, to put it another way: if Haskell is so flexible, why do we need >Template Haskell? I can't imagine a "Template Lisp"; it would just be >Lisp. > > I was just about to say something very similar. So to add a new point: Why is there a partial evaluator for full Scheme (http://www.informatik.uni-freiburg.de/proglang/software/pgg/) but none for full Haskell (or full ML for that matter)? The problem is considerably harder - see the papers listed at http://partial-eval.org/scheme_pe.html. The issue there is definitely one of worldview. The Haskell type system (and the ML type system as well) have a wordview that is incompatible with very powerful code manipulations. That is why Template Haskell is *untyped*, and why MetaOCaml (www.metaocaml.org) puts serious restrictions on what can be done with code so as to prevent unsoundness. However, Gilmore's work on Intensional Type Theory (http://www.cs.ubc.ca/spider/gilmore/) looks very promising to me as a method to attack this worldview problem. Others have tried to use modal logic (mostly S4), but I personally don't believe that is the right way to go. Jacques PS: yes, I know about http://www.cs.chalmers.se/~rjmh/PECourse/Exercises/PE.html and http://www.informatik.uni-freiburg.de/proglang/research/software/mlope/.

1 0

Re: [Haskell-cafe] wxHaskell: getting a checkbox state
by Mark Carter 16 Sep '05

16 Sep '05

Arthur Baars wrote: > Hi, > > A "Checkbox" is instance of the class Checkable: > http://wxhaskell.sourceforge.net/doc/ > Graphics.UI.WX.Classes.html#t%3ACheckable > > This means you can "get" and "set" the "checked" property for > checkboxes. > for example: > c <- get cbEdit checked > set cbEdit [checked := not c ] > > The following code makes the checkbox print its state every time it > is checked or unchecked: > cbEdit <- checkBox f [text := "Edit Mode" ] > set cbEdit [ on command := do v <- get cbEdit checked > print v > ] AHA! Yes, very useful. The problem I was having before was that I was trying to create a separate function onCbEdit, thus: cbEdit <- checkBox p1 [text := "Edit Mode", on command := onCbEdit textlog ] This had the problem that onCbEdit basically needed to have its control passed in (i.e. cbEdit) as a parameter in order to inspect its state. So I wanted to do something like: cbEdit <- checkBox p1 [text := "Edit Mode", on command := onCbEdit textlog cbEdit ] Except you can't do that, because cbEdit isn't yet defined. But your suggestion gets 'round that. In the main loop, I now do: cbEdit <- checkBox p1 [text := "Edit Mode" ] set cbEdit [ on command := onCbEdit textlog cbEdit ] and in my where clause I do: onCbEdit textlog me = do checkedp <- get me checked appendText textlog "onCbEdit\n" appendText textlog (show checkedp) Of course, I'll ultimately want it to do something much more interesting than that - but I was just scratching my head wondering how on earth it could be done; until you came along. Hmm. interesting. I'm finding Haskell a bit head-scratching generally. The syntax is unfamiliar, and Monads, blimey. My understanding of them so far is that they form a barrier between the big, nastey, stateful world, and the clean functional world that I as a programmer occupy. Although I seem to be using a lot of do statements, which presumably means that I'm back in the world of imperative programming. I program in VBA for a living now, but I have a lot of familiarity with Python, and I've done a fair amount of C in my time. I know a bit about C++, but have never gotten involved much with the GUI side of it. A few days ago, I installed an old version of Visual C++, and generated an MFC boilerplate app. My impression is that this MFC/C++ stuff is a confused mess. Admittedly I know very little about MFC; but I'm fairly confident that if a good programmer sat down to design a GUI system from scratch, he would not end up with something like MFC. There seems to be too many "bits" to it, and you have to scatter your declarations over too many files, with scaffolding everywhere. My application also needs to create GUI elements on the fly - and the MFC approach to doing this is woefully painful. I'm currently hacking BouncingBalls.hs to be more to my liking (my balls don't bounce, for starters). The way it adds balls is straighforward. I find I need to hack code that already-exists because my understanding of the syntax and principles is very limited. I continue my Haskell experiments further ... > Arthur > > PS: there is a mailinglist for wxhaskell-related questions: > http://lists.sourceforge.net/lists/listinfo/wxhaskell-users Seems quite dormant, though. Only 4 postings last month. BTW, apologies Arthur Baars - I meant to email this response to the newsgroup, but ended up posting to him personally. ___________________________________________________________ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com

3 3

And another basic typing question -- empty list
by Adam Wyner 16 Sep '05

16 Sep '05

Hi, I have some questions about using the empty list in Hugs. In June 2001, this was raised as a bug in hugs (see Hugs-Bugs Archives). References therein to a bug list on S. Thompson's pages come up a dead end. I haven't found any follow up or solution to this discussed. I would particularly like to use an empty list in the Trex module of Hugs. Suppose I have two expressions: emptyListA = null emptyListB = [] emptyListA is apparently a function from empty lists to Bool. I would have thought that emptyListB would just be the empty list and output it as such. > :t emptyListA emptyListA :: [a] -> Bool > emptyListA [] True The problem is that there is no "show" function for emptyListB, which is just [] > emptyListB ERROR - Cannot find "show" function for: *** Expression : emptyListB *** Of type : [a] What I would like, simply is: >emptyListB [] More to my purpose, I would like to use the empty list as a value of a record in Trex. For instance, while the first example below gives a good result, the second example has no "show" function. Looking at the Trex module, it would seem that there is a show function for the empty list (?? but frankly, I have never touched this area of haskell, so I haven't given it much thought). Sample command line I/O. > (a = 'a', b = [2]) (a = 'a', b = [2]) > (a = 'a', b = []) ERROR - Cannot find "show" function for: *** Expression : (a = 'a', b = []) *** Of type : Rec (a :: Char, b :: [a]) Clearly, the problem is the empty list labelled b. What I want is the following sort of result: > (a = 'a', b = []) (a = 'a', b = []) Further along, what I want is to have values for the field labelled b to be lists which contain something. So, in one case, the value is [], while in another it is [2], say. Moreover, I want to define a type which has a label with values of type lists. That is, I want to have a record something like Rec (a :: Char, b :: List). However, List is not a basic data type. And in any case, the values of labels cannot show empty lists. I'm unsure whether Trex or any record type can handle this. Here are some examples. The following is OK. type TestList01 = Rec (a :: Char, b :: [Char]) testList01 :: TestList01 testList01 = (a = 'a', b = "b") Input and output are: > testList01 (a = 'a', b = "b") ComplexActions01> :t (a = 'a', b = "b") (a = 'a', b = "b") :: Rec (a :: Char, b :: [Char]) But the following type is uninterpretable: type TestList02 = Rec (a :: Char, b :: []) ERROR "ComplexActions01.lhs":196 - Illegal type "[]" in constructor application. Suggestions about how to treat empty lists? Thanks, Adam Wyner

2 1

Basic Haskell Types Question
by Adam Wyner 16 Sep '05

16 Sep '05

Hi, I have a basic question about how output types are reported. I'm using Hugs. Suppose I have the following, where the type String is predefined in the Prelude as [Char]. type PropList = [String] atomicProps1 :: PropList atomicProps1 = ["prop1"] And I have a function on expressions of type PropList which takes every string from the input list and prefixes the string "neg-" to it. negationAtomicProps :: PropList -> PropList negationAtomicProps inPropsList = [ "neg-" ++ inString | inString <- inPropsList] So, with the following, I get the right result: > negationAtomicProps atomicProps1 ["neg-prop1"] The types for the parts are right: > :t negationAtomicProps negationAtomicProps :: PropList -> PropList > :t atomicProps1 atomicProps1 :: PropList But, what I don't understand or like is that the type of the whole is given as [[Char]], not what I thought it would be, namely PropList. Nor is it [String]. > :t negationAtomicProps atomicProps1 negationAtomicProps atomicProps1 :: [[Char]] I really want to get the following sort of report for the type: negationAtomicProps atomicProps1 :: PropList The reason I want this is that in more complex cases, it will be easier to see what is going wrong (as the functions are developed) if I can see the types I want. Am I supposed to be using newtype or data declarations here? How would I do this? I looked around for information in the usual sources, but haven't found an answer. Thanks, Adam Wyner

2 1

Functional vs Imperative
by Dhaemon 16 Sep '05

16 Sep '05

Hello, I'm quite interested in haskell, but there is something I don't understand(intuitively). I've been crawling the web for an answer, but nothing talks to me... So I was hoping I could find some help here: "How is evaluating an expression different from performing action?" I'm puzzled... Doesn't it amount to the same thing? Maybe I have a wrong definition of "evaluating"(determine the value of an expression)? Examples would be appreciated. Also, just for kicks, may I had this: I read the code of some haskell-made programs and was astonished. Yes! It was clean and all, but there were "do"s everywhere... Why use a function language if you use it as an imperative one?(i.e. most of the apps in http://haskell.org/practice.html) Thanks in advance,

9 13

Binary parser combinators and pretty printing
by Einar Karttunen 16 Sep '05

16 Sep '05

Hello I am trying to figure out the best interface to binary parser and pretty printing combinators for network protocols. I am trying to find the most natural syntax to express these parsers in Haskell and would like opinions and new ideas. As an example I will use a protocol with the following packet structure: 0 message-id 4 sender-id 8 receiver-id 12 number of parameters 16 parameters. Each parameter is prefixed by 32bit length followed by the data. We will use the following Haskell datatype: data Packet = Packet Word32 Word32 Word32 [FastString] 1) Simple monadic interface getPacket = do mid <- getWord32BE sid <- getWord32BE rid <- getWord32BE nmsg<- getWord32BE vars<- replicateM (fromIntegral nmsg) (getWord32BE >>= getBytes) return $ Packet mid sid rid nmsg vars putPacket (Packet mid sid rid vars) = do mapM_ putWord32BE [mid, sid, rid, length vars] mapM_ (\fs -> putWord32BE (length fs) >> putBytes fs) vars This works but writing the code gets tedious and dull. 2) Using better combinators packet = w32be <> w32be <> w32be <> lengthPrefixList w32be (lengthPrefixList w32be bytes) getPacket = let (mid,sid,rid,vars) = getter packet in Packet mid sid rid vars putPacket (Packet mid sid rid vars) = setter packet mid sid rid vars Maybe even the tuple could be eliminated by using a little of TH. Has anyone used combinators like this before and how did it work? 3) Using TH entirely $(getAndPut 'Packet "w32 w32 w32 lengthPrefixList (w32 bytes)") Is this better than the combinators in 2)? Also what sort of syntax would be best for expressing nontrivial dependencies - e.g. a checksum calculated from other fields. 4) Using a syntax extension Erlang does this with the bit syntax (http://erlang.se/doc/doc-5.4.8/doc/programming_examples/bit_syntax.html) and it is very nifty for some purposes. getPacket = do << mid:32, sid:32, rid:32, len:32 rest:len/binary >> ... The list of lists gets nontrivial here too... - Einar Karttunen

4 5

RE: [Haskell] ANNOUNCE: ghc-src version 0.2.0
by Simon Marlow 16 Sep '05

16 Sep '05

On 30 August 2005 12:05, Arthur Baars wrote: > Daan is right, I wrote a parser for GHC using Doaitse Swierstra's > parsing combinator library > (http://www.cs.uu.nl/groups/ST/Software/UU_Parsing/index.html) > I needed a drop-in replacement for GHC's Happy parser, to make a > prototype for syntax macros. Syntax Macros allow a programmer to > extend a language with new syntax. Combinator based parsers parsers > can be dynamically extended, making them suitable for implementing > syntax macros. Unfortunately, I never had time to really finish the > syntax macro implementation. > > But I did finish the combinator based parser for GHC. I tested it by > having GHC( with combinator parser) compile itself and all the > libraries. This took about 10% longer than with the original GHC, so > in practice its speed is acceptable. With all due respect, a 10% increase in compile time isn't acceptable at all! And when you consider that parsing is less than 10% of compile time overall (probably much less), a 10% increase represents at least a factor of 2 in the parser. I'm not criticising the work at all - far from it, just the notion that we would consider adding 10% to GHC's compile times "acceptable". I've recently been struggling to shave a few percent off GHC's compile times, BTW :-) Cheers, Simon

2 1

Doing Windows Programming
by Brian McQueen 16 Sep '05

16 Sep '05

How can I use Haskell to do general Windows programming, like you would be able to do if you were using one of those Windows IDEs: *moving data between windows apps *gaining access to windows registry *in general, access to the available Windows APIs I'm sure folks must be writing Windows apps in Haskell somewhere. How do I get started? Brian McQueen

5 5

RE: Re[2]: [Haskell-cafe] Weak hashtable memoization code?
by Simon Marlow 15 Sep '05

15 Sep '05

On 15 September 2005 13:44, Bulat Ziganshin wrote: > Hello Simon, > > Tuesday, September 13, 2005, 7:42:52 PM, you wrote: > >> There's the memo table implementation in the util package: >> hslibs/util/Memo.lhs. Note that this is scheduled for demolition in >> GHC >> 6.6. > > why? It doesn't perform very well, there's a general lack of interest, and nobody interested in supporting it. The right thing to do is make it available as a Cabal package. Cheers, Simon

1 0