[ ghc-Bugs-811427 ] ghci messes up xterm's tty settings
Bugs item #811427, was opened at 2003-09-23 22:14 Message generated for change (Comment added) made by simonmar You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=811427group_id=8032 Category: None Group: None Status: Closed Resolution: Duplicate Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: ghci messes up xterm's tty settings Initial Comment: $ uname -a SunOS syrma.ccs.neu.edu 5.9 Generic_112233-07 sun4u sparc SUNW,Sun-Blade-100 $ echo $TERM xterm $ stty -a speed 9600 baud; rows = 76; columns = 80; ypixels = 992; xpixels = 499; csdata ? eucw 1:0:0:0, scrw 1:0:0:0 intr = ^c; quit = ^\; erase = ^?; kill = ^u; eof = ^d; eol = undef; eol2 = undef; swtch = undef; start = ^q; stop = ^s; susp = ^z; dsusp = ^y; rprnt = ^r; flush = ^o; werase = ^w; lnext = ^v; parenb -parodd cs8 -cstopb hupcl cread -clocal -loblk -crtscts -crtsxoff -parext -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl -iuclc ixon -ixany -ixoff -imaxbel isig icanon -xcase echo echoe echok -echonl -noflsh -tostop echoctl -echoprt echoke -defecho -flusho -pendin iexten opost -olcuc onlcr -ocrnl -onocr -onlret -ofill -ofdel $ ghci ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.0.1, for Haskell 98. / /_\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package base ... linking ... done. Prelude :quit Leaving GHCi. $ stty -a speed 9600 baud; rows = 76; columns = 80; ypixels = 992; xpixels = 499; csdata ? eucw 1:0:0:0, scrw 1:0:0:0 min = 1; time = 0; intr = ^c; quit = ^\; erase = ^?; kill = ^u; eof = ^a; eol = undef; eol2 = undef; swtch = undef; start = ^q; stop = ^s; susp = ^z; dsusp = ^y; rprnt = ^r; flush = ^o; werase = ^w; lnext = ^v; parenb -parodd cs8 -cstopb hupcl cread -clocal -loblk -crtscts -crtsxoff -parext -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl -iuclc ixon -ixany -ixoff -imaxbel isig -icanon -xcase echo echoe echok -echonl -noflsh -tostop echoctl -echoprt echoke -defecho -flusho -pendin iexten opost -olcuc onlcr -ocrnl -onocr -onlret -ofill -ofdel $ Note how using ghci changes the tty's value for eof and icanon... Changing eof in particular is annoying since suddenly the time-honored ^d keyboard shortcut stops working for any subsequent program I try to use in that xterm unless I manually reset the tty's eof setting. Philippe ([EMAIL PROTECTED]) -- Comment By: Simon Marlow (simonmar) Date: 2003-09-24 10:35 Message: Logged In: YES user_id=48280 Closed as a dup of #764685. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=811427group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-764685 ] GHCi breaks the terminal
Bugs item #764685, was opened at 2003-07-02 15:52
Message generated for change (Comment added) made by simonmar
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=764685group_id=8032
Category: None
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Hampus Ram (hampusr)
Assigned to: Simon Marlow (simonmar)
Summary: GHCi breaks the terminal
Initial Comment:
After running ghci the terminal does not work exactly
as it should: Running su does no longer work for some
unknown reason (su stops after reading the first
character of the password). This happens with ghc 5.04
as well as 6.0 and current CVS-version, both in xterm
and console. This only seem to be a problem with my
Linux/Debian installation, I cannot reproduce the
problem on Solaris.
Also some minor spelling :) According to the CVS
users-guide the reverse of -frules-off is the very same
-frules-off.
--
Comment By: Simon Marlow (simonmar)
Date: 2003-09-24 10:36
Message:
Logged In: YES
user_id=48280
Fixed, thanks. It turns out that it is nothing to do with
readline, but indeed GHC's IO library should really be
restoring the terminal settings if it changes them.
Note that #811427 is another report of the same bug.
--
Comment By: Hampus Ram (hampusr)
Date: 2003-07-28 10:20
Message:
Logged In: YES
user_id=159064
I performs a ioctl at the end, strace says:
ioctl(1, SNDCTL_TMR_TIMEBASE, {B38400 opost isig icanon echo
...}) = 0
when running with input from /dev/null. This is all ok.
However when running in the terminal it says:
ioctl(1, SNDCTL_TMR_TIMEBASE, {B38400 opost isig -icanon
echo ...}) = 0
Not so good. Dpkg reports that I'm using readline 4.3-5. I'm
running bash (2.05b-7) as my primary shell but I just tried
tcsh and there it all works well!
--
Comment By: Simon Marlow (simonmar)
Date: 2003-07-28 09:20
Message:
Logged In: YES
user_id=48280
Readline is supposed to reset the terminal. Could you try
strace ghci /dev/null
and see if it attempts to reset the terminal at the end? My
trace has an ioctl(1, ...) near the end.
What version of readline? Is it different from your Debian-
running friends? What shell are you using? (some shells
save/restore the terminal settings between running
commands).
--
Comment By: Hampus Ram (hampusr)
Date: 2003-07-27 21:27
Message:
Logged In: YES
user_id=159064
The (only) difference is that instead of icanon (before)
ghci leaves the terminal with -icanon (su no longer works
using line buffering, I think).
I've had this problem before with an older installation of
Debian too but no one else of my Debian-running friends seem
to have this problem.
Well, it's a minor problem but annoying.
--
Comment By: Simon Marlow (simonmar)
Date: 2003-07-22 11:27
Message:
Logged In: YES
user_id=48280
I can't reproduce this on our boxes here. It could be a
readline problem.
Could you try 'stty -a' before and after running GHCi, and
post the results?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=764685group_id=8032
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
a few moments?
Title: Untitled Document DON'T LOSE ANY MORE MONEY ON YOUR EXISTING HOME LOAN!hi please check out the following siteonly the banks know about this, but it will save you a fortuneare you prepared for lower mortgage repayments? Open 24 hours a day, 7 days a week. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Milyonlara ulasin..
Title: maillist Web Sayfalarnz, rnlerinizi yada duyurularnz milyonlarca insana tantma frsat... CD1 CD2 CD3 Trk Liste Yabanci Liste Uzakdogu Liste 120 meslek grubu sehir vb (grub) ulke ve sehir (meslek gruplu) ticaret ve ithlat,ihracatcilar 8 milyon E-Mail+ Gerekli Programlar 450 milyon E-Mail + Gerekli Programlar 18 milyon E-Mail+ Gerekli Programlar 8 milyon Turk'e web sitenizi veya rnz yada duyurunuzu ulastirma imkani sunuyoruz. 450 milyon Dunya capindaki internet kullanicilarina web sitenizi veya rnz yada duyurunuzu ulastirma imkani sunuyoruz. 18 milyon in Tayvan Japonyadaki ticaret, ithalat ve ihracatcilarina ulasabilme imkani sunuyoruz. Sadece 49 Milyon! Sadece 89Milyon Sadece 79Milyon SIKCA SORULAN SORULAR S1 - Bu cdlerden herhangi birini nasil alacagim? C1- ncelikle alttaki formu eksiksiz doldurup, size gnderecegimiz deme bilgilerini takip ederek cdlerden birini yada bir kaini satin alabilirsiniz. (not: demeler banka havalesiyle yada istanbul iinde elden yapilmaktadir.) S2 - Cd ler elimize ka gnde geecek? C2- demeyi yaptiginiz tarihten itibaren 1 is gn iinde elinizede olacaktir. Yurtii kargo ile alismaktayiz. S3- Ben fazla internetten anlamiyorum bu cdler bilgi gerektirirmi? C3- Programlarin kullanimi olduka basittir. S4- Bu islem yasalmi? C4- Bizdeki mail adresleri insanlarin kendi istekleriyle vermis oldugu maillerdir. Bu nedenle hersey yasaldir. Burada olmayan soru ve cevaplar iin bize mail yoluyla ulasabilirsiniz. [EMAIL PROTECTED] Siparis Vermek Iin Ltfen Asagidaki Formu Eksiksiz Doldurun Ltfen Bilgilerinizi Yaziniz Isim Soyad * Sirket ismi Mail Adresiniz * Adres * Adres devami Sehir * Semt ile Posta Kodu * lke * Telefon Ek Bilgi Almak istediginiz cd yada cdleri sein CD1 (Trk Maillist) 49 Milyon CD2 (Dnya Maillist) 89 Milyon CD3 (Uzakdogu Maillist) 79 Milyon Not: * yazan yerlerin doldurulmasi gereklidir. Not: Hotmail kullan?c?lar? sipari? ver tu?una basman?za ra?men ekrana bi?ey gelmiyorsa sipari? iin bize mail at?n Not: bu tr maillerden almak istemiyorsaniz ltfen [EMAIL PROTECTED] adresine remove baslikli bir mail gonderin. Esenlikler. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
BUSINESS PARTNER
Dear Sir, I am Aken Malakin Udah, Director of logistics for the government of Liberia under former President Charles Taylor,I was in charge of the proceeds from the diamond mines scattered around the countryside, but since the current president has accepted to go into exile I decided to leave the country immediately before it is too late. I have in my possession the sum of fifteen million United States Dollars (US$15M), Which I am Willing to invest under your care probably in your company or another you may recommend. I am currently in hiding in Ghana since my recent escape from Liberia. I will unfold the procedure for the realization if you indicate your interest to collaborate and you will get 20% of the total sum as commission. Should this proposal not interest you, please disregard it without prejudice .However, if you are interested in this proposal, please contact me using the above email. Please do treat this as a confidential issue as any leakage to the present goverment will be dangerous to me and my family . please treat this with utmost urgency that it requires. Best regards Aken Malakin Udah ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
From enumerators to cursors: turning the left fold inside out
There are two basic approaches of accessing a collection, be it a file, a database, or a generating function. One approach relies on enumerators (aka folds); the other is based on lazy lists (aka cursors, streams). Given a stream, we can always construct the corresponding enumerator. It's perhaps less appreciated that given a left fold enumerator, we can always construct the corresponding stream [1]: we can mechanically invert an enumerator inside out. It has been argued [2] that the enumerator approach is superior, especially from the point of view of managing scarce resources such as database connections. When we design the interface to a collection, it seems a good idea to choose enumerator as a primitive. We can always obtain a stream if we really need it. The mechanical inversion procedure presented in [2] had a catch: it relies on shift/reset (or call/cc plus a mutable cell, which is the same thing). How can we do such an inversion in Haskell? Well, we can introduce a right fold enumerator, which is more amenable to such transformation. Or we can use a continuation monad and emulate shift/reset. The present article demonstrates a third approach: a half-baked, non-recursive left-fold. We argue that such a left fold is the best interface for a collection. Indeed, given the half-baked left-fold we can: - instantiate it into the ordinary left fold - instantiate in into a stream If we turn two enumerators into streams, we can *safely* interleave these streams. The rest of the article demonstrates the inversion procedure. We use a file as a sample collection, a collection of characters. Haskell provides a stream interface to that collection: hGetChar. We implement a left fold enumerator. We then show how to turn that enumerator back to a stream: how to implement a function mygetchar only in terms of the left fold enumerator. The approach is general and uses no monadic heavy lifting. The following code is Haskell98. No unsafe operations are used. import IO The desired left-fold enumerator over a file: hfold_left:: FileName - Title - Iteratee seed - seed -- the initial seed - IO seed type FileName = String type Title = String -- just an identifying string for debug printing type Iteratee seed = seed - Char - Either seed seed The function (seed - Char - Either seed seed) is an iteratee: it takes the current seed and the current character and returns a new seed. To be more precise, if it returns Right seed', the iteration continues with seed' as the new seed. If the iteratee returns Left seed'', the enumerator immediately stops further iterations, frees all the resources, and returns seed'' as the final result. So our left fold enumerator supports premature termination of iterations, a quite useful feature. As me mentioned above, we actually need a half-baked, non-recursive enumerator hfold_left' make_hfold_left' filename title = do h - openFile filename ReadMode let hfold_left' self iteratee seed = do mc - try $ hGetChar h case mc of Left exc - hClose h return seed Right c - do putStrLn $ reading from ++ title ++ . Got ++ (show c) case iteratee seed c of Left seed - hClose h return seed Right seed - self iteratee seed return hfold_left' We can easily obtain the desired hfold_left as an instantiation of hfold_left': hfold_left filename title iteratee seed = do hfold_left' - make_hfold_left' filename title let g = hfold_left' g hfold_left' g iteratee seed We should note that the Handle is an internal resource and is never leaked. The statement putStrLn $ reading from ++ title ... is for debugging. We want to be sure that we don't read from a stream too much. This will be important for interleaving. Let us create a test file tf = /tmp/a make_test_file fname = do h - openFile fname WriteMode mapM_ ((hPutStr h) . show) [0..9] putStrLn $ Wrote ++ fname hClose h and test our left fold enumerator test_read fname n = do (count,acc) - hfold_left fname handle reader (0,[]) putStrLn $ Have read: ++ (show acc) where reader (count,acc) c = let count' = count + 1 acc' = c:acc in (if count' = n then Left else Right) (count',acc') The first test checks the premature termination. We read only five characters, and then terminate the iteration and dispose of its resources, including the (invisible) handle. *Main test_read tf 5 reading from handle. Got '0' reading from handle. Got '1' reading from handle. Got '2' reading from handle. Got '3' reading from handle. Got '4' Have read: 43210 The following tests the exhaustive iteration. *Main test_read tf 20 reading from handle. Got '0' reading from handle. Got '1' reading from handle. Got '2' reading from handle. Got '3' reading from handle. Got '4' reading from handle. Got '5'
Re: pretty newby
Thanks. i understand that a2ps is rather for printing. What I had in mind what to pp my own programs, to clean the source layout, rather. The process i used in other context is to hack , without really taking care of the layout ( say getting distracted by) , and once i got a resonalble level of stability, i cleaned the program, using a pp; ideally in haskell, this would add the typing for me, also. ( still havent made my religion if that's cool to have the typing on top of the definition, or not, but at least for doc generation purpose, that's good.) feedback on that ? so the two gain i was expecting were : - cleaning the layout, after i removed all the debugging code - generating the type but i understood from Per from that the parser would not take care of the comments. ( not take care, or remove , btw ?). alos, Im surprised that this bland issue has not already been solved (PP lib paper looks dated 96). no offence intended, but aas im newbie, i wonder what am i missing ? what is different in the process of creation so that this need did not arised already? i should admint i'm puzzled, given the facilities at hand... Alle 16:05, martedì 23 settembre 2003, Luc Taesch ha scritto: are there any facility to pretty print an haskell program ? If what you need is an external program and not a library, have a look at GNU a2ps. Vincenzo ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Haskell front ends, was pretty newby
Hi all, I'm not sure I'll answer the question properly, but I think it raises an interesting issue, regarding the state of Haskell front ends. What I had in mind what to pp my own programs, to clean the source layout, rather. so the two gain i was expecting were : - cleaning the layout, after i removed all the debugging code - generating the type alos, Im surprised that this bland issue has not already been solved (PP lib paper looks dated 96). no offence intended, but aas im newbie, i wonder what am i missing ? what is different in the process of creation so that this need did not arised already? i should admint i'm puzzled, given the facilities at hand... Is this what you are after? A tool to read in Haskell source, and then print it out (to file or screen) in a pretty printed manner. It should retain comments from the source. And possibly add type annotations. Such a tool would be very nice indeed. Though I do not think such a thing exists at the moment. Why not? Good question. One thing that Haskell is really lacking (IMO) is a common front end. Something that can lex, parse, type check ... do all the things that a compiler or interpreter would do before it starts to generate code. Such a thing would be great for many people. It would help define the language. It would help implementors and researchers. It would probably even serve as a good source of example Haskell code for those looking to study the language. And, importantly, it would enable Haskell specific editors, refactorers, pretty printers and so on. Some work has been done towards this, including the hsparser library and supporting material that comes with GHC these days. I have been a very happy client of that parser for a long time now (sorry about the pun). At the recent Haskell workshop I saw a presentation about the nice tools that the Programatica group are working on. This seems to include most of the front end of a Haskell system. http://www.cse.ogi.edu/PacSoft/projects/programatica/ It appears that binary forms of their programs are available: http://www.cse.ogi.edu/~hallgren/Programatica/download/ Alas, I could not find a source distribution and I'm not sure if one exists. One problem I see is that it is hard to justify the large amount of work that is required to implement such a thing when it might not be regarded as research worthy. Though, in the long run I think the research community is being held back because we must continually re-implement the front end of Haskell, and often we only get part way through it before we run out of steam (see Hatchet for example, I'm a guilty party...). We owe it to ourselves to implement a front end. Though I fully appreciate the difficulty of the task, and I'm not putting my hand up to do it at the moment (grumble, thesis writing, grumble). Perhaps there are some keen Haskell hackers out there who are itching for a nice project? And by the way, I don't want to sound like I'm complaining too much, because, as I said, I've been using the hsparser and pretty printer extensively, and I failed to finish Hatchet. Cheers, Bernie. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: From enumerators to cursors: turning the left fold inside out
Hi Oleg, Just thought I'd mention that this is, in fact, my preferred method of iterating over a file. It alleviates the pain associated with lazy file IO, and simultaneously provides a useful abstraction. I actually have 3*2 functions that I use which look like: type Iteratee iter seed = seed - iter - Either seed seed hFoldChars :: FilePath - Iteratee Char seed - seed - IO seed hFoldLines :: FilePath - Iteratee String seed - seed - IO seed hFoldWords :: FilePath - Iteratee [String] seed - seed - IO seed type IterateeM iter seed = seed - iter - IO (Either seed seed) hFoldCharsM :: FilePath - IterateeM Char seed - seed - IO seed hFoldLinesM :: FilePath - IterateeM String seed - seed - IO seed hFoldWordsM :: FilePath - IterateeM [String] seed - seed - IO seed Which perform as expected (hFoldWords(M) can be written in terms of hFoldLinesM, but I find I use it sufficiently frequently to warrent having it stand out). Also, of course, the only ones actually implemented are the (M) variants; the non-M variants just throw a return into the Iteratee. - Hal hfold_left:: FileName - Title - Iteratee seed - seed -- the initial seed - IO seed type FileName = String type Title = String -- just an identifying string for debug printing type Iteratee seed = seed - Char - Either seed seed -- Hal Daume III | [EMAIL PROTECTED] Arrest this man, he talks in maths. | www.isi.edu/~hdaume ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: pretty newby
On Wed, 24 Sep 2003, Luc Taesch wrote: alos, Im surprised that this bland issue has not already been solved (PP lib paper looks dated 96). no offence intended, but aas im newbie, i wonder what am i missing ? what is different in the process of creation so that this need did not arised already? i should admint i'm puzzled, given the facilities at hand... As the author of the 96 paper (wasn't it 95?), let me defend it a bit, or at least explain what it offers, and what it does not. The problem I was solving in that was paper was how to pretty-print *data-structures* from inside a program. That includes abstract syntax trees in compilers -- in fact, that's maybe the most important application. The library is used in GHC, for example, to pretty-print programs at various stages, after varying degrees of transformation. You the user can see what the compiler has produced after each phase, and you see it laid out in a readable format. Pretty-printing data-structures is quite different from pretty-printing *programs* -- we should have two different words for it, really! When you pretty-print a program, you just want to change the layout in an existing text, and comments etc. ought to be preserved and appear in sensible places afterwards. When we pretty-print programs, there is an input (the program as you wrote it) to take into account. When you pretty-print a data-structure, you're just trying to output something produced by a program... there is no input it was produced from which the pretty-printed output ought to resemble. So, if you want to see what GHC has produced after phase X, then the pretty-printing library is appropriate. Of course, if there were comments in the program you wrote, then you ought to realise the compiler discarded them early, and you should not expect them to appear in the result of various transformations/optimisations. But if you want to standardise the layout of a program you wrote, then this is no good. The pretty-printing library is not sufficient to do this by itself... it solves a different problem. It is possible to BUILD a program pretty-printer using the library (although this is not the only possible approach), but it requires combining the library with a parser which loses no information, in particular including comments at the appropriate places in abstract syntax trees, so that they are a part of the data structure being pretty-printed. The problem is that parsers in compilers don't keep track of comments... instead they discard them at the first opportunity (during lexing). Thus such a parser, combined with a pretty-printer, cannot solve the *program pretty-printing* problem. What's needed is a parser that can parse comments, and tie them to the *right place* in the abstract syntax tree. Figuring out what a comment is really commenting is probably extremely hard... But without an AST with attached comments in the right places, my pretty-printing library, and Simon PJ's extension, are useless. That said, maybe it is surprising that no good Haskell pretty-printer has appeared yet, especially given the importance of layout in the language. Why not write one? I dare say there would be many users, and no doubt you could publish a paper at the Haskell Workshop... John Hughes ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: pretty newby
On woensdag, sep 24, 2003, at 17:46 Europe/Amsterdam, John Hughes wrote: What's needed is a parser that can parse comments, and tie them to the *right place* in the abstract syntax tree. Figuring out what a comment is really commenting is probably extremely hard... The commenting conventions of Haddock serve this purpose pretty well. And Haddock's parser must hold onto the comments to do its job. Maybe that's a good place to start on a Haskell pretty-printer. Regards, Frank ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Beautifying Haskell programs (was: Re: pretty newby )
John Huges wrote: On Wed, 24 Sep 2003, Luc Taesch wrote: alos, Im surprised that this bland issue has not already been solved (PP lib paper looks dated 96). no offence intended, but aas im newbie, i [..] As the author of the 96 paper (wasn't it 95?), let me defend it a bit, or at least explain what it offers, and what it does not. I think the reason it looks dated is that it pretty much solved the problem it was addressing. For pretty-printing data structures, the solution given in that paper does a rather good job, is configurable in the ways you might want to configure it, and is fairly easy to use and understand. No one has needed to invent a new way of doing it since. Regarding beautifying Haskell programs: as John says, it's not straightforward. But I think the reason that there isn't such a thing is that most people don't need it. We mostly use editors that allow us to get the indentation right, automatically, as we type the source in, and we take care to preserve it as we edit, because it makes the code easier to understand. (note that there *are* tools for producing beautified documentation: Haddock lists exports, type definitions, type signatures, and argument and function documentation in HTML format, but it doesn't deal with actual code). And your other point, Luc, about generating type signatures automatically, shows up something about your approach to debugging code. You should always put the type signatures in as you go - preferably, before you write the function! This is not just good design practice and good documentation, it helps you debug the function. With type signatures, the compiler can see what you intended to write, and verify that what you did write matches it. Without type signatures, all it can see is that two things don't match - it has no idea what you meant to type. Try it: try putting in type signatures, and see how much better the compiler's error messages become. Hope this helps.. --KW 8-) ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: pretty newby
John Hughes [EMAIL PROTECTED] writes: The problem is that parsers in compilers don't keep track of comments. Instead they discard them at the first opportunity (during lexing). ... What's needed is a parser that can parse comments, and tie them to the *right place* in the abstract syntax tree. Fortunately, there *is* one Haskell parser already which preserves comments in the source code and links them properly to the surrounding program structure, namely Haddock, the automatic-documentation generator. I expect Haddock would be a good place to start if one wanted to develop a program re-formatter. (Furthermore, if one were to add a type inference engine that could fill-in missing type signatures in a program, that would be highly useful for both Haddock and the hypothetical re-formatter.) Regards, Malcolm ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Beautifying Haskell programs
hello, i also like pretty for simple pretty priniting tasks, but i think it is a bit low level. for example, the cominators could be parameterised by a monad, so that one can have different printing styles, and also deal nicely with precedences. one can build that functionality on top of the library pretty and this was done for the pretty printing component of the programatica project mentioned in one of the other posts. bye iavor Keith Wansbrough wrote: John Huges wrote: On Wed, 24 Sep 2003, Luc Taesch wrote: alos, Im surprised that this bland issue has not already been solved (PP lib paper looks dated 96). no offence intended, but aas im newbie, i [..] As the author of the 96 paper (wasn't it 95?), let me defend it a bit, or at least explain what it offers, and what it does not. I think the reason it looks dated is that it pretty much solved the problem it was addressing. For pretty-printing data structures, the solution given in that paper does a rather good job, is configurable in the ways you might want to configure it, and is fairly easy to use and understand. No one has needed to invent a new way of doing it since. Regarding beautifying Haskell programs: as John says, it's not straightforward. But I think the reason that there isn't such a thing is that most people don't need it. We mostly use editors that allow us to get the indentation right, automatically, as we type the source in, and we take care to preserve it as we edit, because it makes the code easier to understand. (note that there *are* tools for producing beautified documentation: Haddock lists exports, type definitions, type signatures, and argument and function documentation in HTML format, but it doesn't deal with actual code). And your other point, Luc, about generating type signatures automatically, shows up something about your approach to debugging code. You should always put the type signatures in as you go - preferably, before you write the function! This is not just good design practice and good documentation, it helps you debug the function. With type signatures, the compiler can see what you intended to write, and verify that what you did write matches it. Without type signatures, all it can see is that two things don't match - it has no idea what you meant to type. Try it: try putting in type signatures, and see how much better the compiler's error messages become. Hope this helps.. --KW 8-) ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell -- == | Iavor S. Diatchki, Ph.D. student | | Department of Computer Science and Engineering | | School of OGI at OHSU | | http://www.cse.ogi.edu/~diatchki | == ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Beautifying Haskell programs (was: Re: pretty newby )
Am Mittwoch, 24. September 2003, 18:01 schrieb Keith Wansbrough: [...] And your other point, Luc, about generating type signatures automatically, shows up something about your approach to debugging code. You should always put the type signatures in as you go - preferably, before you write the function! This is not just good design practice and good documentation, it helps you debug the function. With type signatures, the compiler can see what you intended to write, and verify that what you did write matches it. Without type signatures, all it can see is that two things don't match - it has no idea what you meant to type. Try it: try putting in type signatures, and see how much better the compiler's error messages become. Let me add that there are situations where you don't want the most general type (which is yielded by type inference) as the type of a specific variable (which can be a function, of course). One reason might be that the most general type doesn't fit your idea about what the variable (function) shall describe. You could, for example, describe mappings from keys to values as lists of key value pairs. An empty mapping would be implemented as []. The type of this would be infered as [a] but what you want is [(a,b)]. Another reason for giving a type signature with a restricted type is that you want to enforce certain constraints by the type system. A good example is Peter Thiemanns handling of HTML documents in his WASH/CGI software. Note also that the asTypeOf function from the prelude is essentially the const function; the only difference is the type. It's the restricted type of asTypeOf that lets this function fulfill its purpose. Hope this helps.. --KW 8-) Wolfgang ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
learning to love laziness
Consider the following Haskell function: asPair x = (fst x, snd x) This function has type forall a b. (a, b) - (a, b) and is almost equivalent to the identity function, except it can be used to make programs terminate that might otherwise fall into a black hole. My students are extremely mystified by such functions---and I can hardly blame them! Is there a good place to read about programming with lazy evaluation that will cover such functions and when to use them? Norman ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Library Infrastructure Proposal Home Page
Followups to [EMAIL PROTECTED] please. Greetings, After many rounds of email and discussion, some wiki work, and discussion at the HIM, I've finally put together a proposal for the Library Infrastructure Project. I've inserted the introduction below. The draft proposal itself is available in a variety of formats. I've also started a web page for the project under the haskell.org site: http://www.haskell.org/libraryInfrastructure/ Please let me know if there's anything that needs to be added, if anything is confusing, etc. Comments and questions are welcome by email or on the [EMAIL PROTECTED] mailing list. peace, isaac ps. I expect to be moving a lot of stuff off of the wiki page since it is duplicated here. Library Infrastructure Project Proposal The Library Infrastructure Project is an effort to provide a framework for developers to more effectively contribute their software to the Haskell community. The Haskell Implementations[1] come included with a good set of standard libraries, but this set is constantly growing and is maintained centrally. This model does not scale up well, and as Haskell grows in acceptance, the quality and quantity of available libraries is becoming a major issue. There are a wide variety of Haskell Implementations (both compilers and interpreters), each of which target a variety of hardware architectures and operating systems. There are also a number of different groups and individuals providing libraries, and these libraries depend upon each other and they depend upon external systems such as Java or GTK. It can be very difficult for an end user to manage these dependencies and build all the necessary software at the correct version numbers on their platform: there is currently no generic build system to abstract away differences between Haskell Implementations and operating systems [2]. The Library Infrastructure Project seeks to provide some relief to this situation by building tools to assist developers, end users, and operating system distributers. This is a draft proposal. If you have comments, please email Isaac Jones. The latest version of this document should be available in a variety of formats from the Library Infrastructure Project home page. _ Table of Contents 1. High-Level Overview 2. Issues Facing Developers 2.1. Issues Facing Packagers 2.2. Why We Should Solve This 3. A Solution for Haskell in Haskell 3.1. The Module Design 3.2. But Why Should We Use Haskell? 3.3. Setup.lhs Command-Line Interface 3.4. An Example Setup.lhs Script 4. Distribution Module 4.1. Distribution.Build 4.2. Distribution.Install 4.3. Distribution.Package 4.3.1. PackageConfig Data Structure 4.4. haskell-config Command-line interface 4.5. haskell-pkg? 4.6. Distribution.Config 5. Use Cases 6. Means of Distribution and Layered Tools 7. Development Plan A. Related Systems A.1. Debian A.2. Python Distutils A.3. CPAN and Boost A.4. FreeBSD's Ports System A.5. The XEmacs Packaging System A.6. Make-Based Systems A.7. hmake 1. High-Level Overview On a high level, we say that we want the system to help the user to install packages (whether they be libraries or applications) and their dependencies. To accomplish this, we propose a system similar to Python's Distutils (Section A.2) where each Haskell tool is distributed with a script (Section 3.4) which has a standard command-line interface. This script will provide a familiar user interface (Section 3.3) for compiling, installing, and removing packages and their dependencies. For instance, to install the HUnit package, the user might download the source code from the web site, change into the HUnit directory, and type ./Setup.lhs install default, which would build and install the HUnit package for the default compiler. Similarly, he might type ./Setup.lhs install nhc to install the package for NHC. Other tasks might be necessary to make the package known to the system, such as registering it with the Haskell Implementation of interest (Section 4.3). Such tasks would also be performed by this Setup program. FULL TEXT AT: http://www.haskell.org/libraryInfrastructure/proposal/index.html ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: learning to love laziness
On Wed, 24 Sep 2003, Norman Ramsey wrote: Consider the following Haskell function: asPair x = (fst x, snd x) This function has type forall a b. (a, b) - (a, b) and is almost equivalent to the identity function, except it can be used to make programs terminate that might otherwise fall into a black hole. What is an example program that asPair rescues from nontermination? Nathan ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: lexer puzzle
Marcin 'Qrczak' Kowalczyk wrote: A... should be split into A.. and . I found a compromise: let's make it a lexing error! :-) At least that agrees with what some Haskell compilers implement. No current Haskell compiler/interpreter agrees with what the report seems to say, that is that A... should be lexed as the two tokens A.. and ., and similarly, A.where should be lexed as A.wher followed by e. It seems that the source of the problem is the use of the (nonstandard) difference operator r1r2 in the specification of the lexical syntax in the Haskell report [1]. It was presumably fairly innocent and easy to understand originally, but I guess that nobody understood its consequences when qualified names were introduced. Anyway, this should teach us not to use homemade pseudo formal notation when defining a new language, but to stick to well-established, well-understood, tool-supported formalisms... For the Programatica Haskell front-end, I have now switched to a regular expression compiler that has direct support for the difference operator, so hopefully, our implementation agrees with what the report specifies. (This is not necessarily a good thing, though, since it makes our front-end different from all other Haskell implementations :-) For what it is worth, I tested A..., A.where and A.-- in the main Haskell implementations and in the Programatica Haskell front-end. The input was two modules A and B: 1 module A where 2 3 wher = id 4 e = id 1 module B where 2 import A 3 4 x = (A.where) 5 y = x Here is the result: GHC: B.hs:4: parse error on input `where' HBC: B.hs, line 4, Bad qualified name on input:eof Hugs: ERROR B.hs:4 - Undefined qualified variable A.where NHC98: Identifier A.where used at 4:6 is not defined. PFE: ok If line 4 in module B is replaced with x = (A...): GHC: B.hs:4: Variable not in scope: `A...' HBC: B.hs, line 4, Bad qualified name on input:eof Hugs: ERROR B.hs:4 - Undefined qualified variable A... NHC98: Identifier A... used at 4:6 is not defined. PFE: B.hs:4,13, before ): syntax error (A.. is lexed as A.. .) If line 4 in module B is replaced with x = (A.--) GHC: B.hs:4: Variable not in scope: `A.--' HBC: B.hs, line 5, syntax error on input:= (treats -- as the start of a comment) Hugs: ERROR B.hs:4 - Undefined qualified variable A.-- NHC98: Identifier A.-- used at 4:6 is not defined. PFE: B.hs:5,1, before : syntax error (A.-- is lexed as A.- -) I used the following versions GHC 6.0.1 HBC 0..5b Hugs 98 November 2002 NHC98 1.16 PFE 030912 -- Thomas H [1] http://www.haskell.org/onlinereport/syntax-iso.html ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: learning to love laziness
hello, Richard Nathan Linger wrote: On Wed, 24 Sep 2003, Norman Ramsey wrote: Consider the following Haskell function: asPair x = (fst x, snd x) This function has type forall a b. (a, b) - (a, b) and is almost equivalent to the identity function, except it can be used to make programs terminate that might otherwise fall into a black hole. What is an example program that asPair rescues from nontermination? 'undefined' is a program that does not terminate. 'asPair undefined' is a program that terminates immediately (with a pair containing two nonterminating components). unfortunatelu in haskell you can tell the difference between those two: test (x,y) = True test undefind = undefined test (asPair undefined) = True it may be nice to have tuples unlifted in haskell (and in general datatypes with a single constructor). this could be introduced in the language by either changing the semantics of 'data' (prolly not too nice) or by generalizing 'newtype' (and perhaps renaming it to 'record') to handle more than one type. the semantics of such thing could be just like now except that pattern matching on them is always lazy (i.e.patterns have an implicit ~). then one could not tell the difference between `undefined' and (undefined,undefined). well i guess unless one used seq, but seq is also not very nice. bye iavor -- == | Iavor S. Diatchki, Ph.D. student | | Department of Computer Science and Engineering | | School of OGI at OHSU | | http://www.cse.ogi.edu/~diatchki | == ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: Database interface - would like advice on oracle library bind ing
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] I'd like to remark first that many real databases let us avoid opening many cursors at once. It seems to be more efficient to do as much as possible within the engine ... I agree (and Tom Pledger makes the same comment). It's rare that I want to have more than one cursor open at once. When I've seen other developers do it, they're often doing something that would be better accomplished as a join. And that last time I remember doing it, it was a nested loops situation (which, on reflection, probably could have been done as a join... oh well). OTOH, I have seen interleaved fetches used to simulate a join where the specific DBMS product struggled to perform the join efficiently itself. In this case the developer is making up for a deficiency in the DBMS, and I don't want to exclude the option from the interface (if you agree with what you read on http://www.dbdebunk.com , then most DBMS products are deficient in a number of ways). Still, opening several cursors may be unavoidable. The left fold approach may still help -- we _can_ mechanically invert a left fold combinator (to be precise, a half-baked version of it) into a lazy list. Please see a separate message how to invert the left fold Found it. I'll have a look... I believe the extract functions can be constructed automatically -- similar to the way Quickcheck constructs test cases. I believe that instead of I though this might be possible, but I had no idea how to do it. I'll have a look at the Quickcheck source to see how it's done, unless you can suggest a better example. buffers. It's hard for me to write the corresponding code because I don't have Oracle handy (besides, I like Informix better). Is it possible to come up with a stub that uses flat files? We are only interested in fetching rows. It doesn't matter if these rows come from a file or from a database. That would make prototyping the interface quite easier. I wasn't interested so much in prototyping the interface, as trying to write an implementation that supported the interface(s) discussed previously. I intended to provide the left-fold interface, and was wondering if that was all that was needed (for selects). Still, this would be a good exercise for me, at least so I can figure out how to generate extraction functions. From: Tom Pledger [mailto:[EMAIL PROTECTED] Here's one approach: find the OCI equivalent of JDBC's ResultSetMetaData, and use it to drive the allocation and freeing of buffers. I've considered this, and I think it's the next route I'll take (the OCI supports it). At the least it'll give me the ability to perform arbitrary queries (at present I have to know the types of the result set columns and construct the extraction function manually). I've also considered stuffing more information into the Cursor type (which I've introduced), and using this in a modal fashion to decide what to do at each point. Here's another: ... Make getInt (and friends) behave differently depending on the mode of the cursor they're passed: either allocate a buffer and return _|_, decode and return the current column of the current row, or free a buffer and return _|_. Not wanting to sound too dumb, but how do you return _|_ ? Thanks, Alistair. * The information in this email and in any attachments is confidential and intended solely for the attention and use of the named addressee(s). This information may be subject to legal professional or other privilege or may otherwise be protected by work product immunity or other legal rules. It must not be disclosed to any person without our authority. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are not authorised to and must not disclose, copy, distribute, or retain this message or any part of it. * ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Database interface - would like advice on oracle library bind ing
Here's another: ...
Make getInt (and friends) behave differently depending on the mode
of the cursor they're passed: either allocate a buffer and return
_|_, decode and return the current column of the current row, or
free a buffer and return _|_.
Not wanting to sound too dumb, but how do you return _|_ ?
Return
undefined
or better,
error Erroneously demanded bottom result of buffer allocation phase
Note that
undefined :: a
undefined = undefined
error :: String - a
{- defined internally -}
HTH.
--KW 8-)
--
Keith Wansbrough [EMAIL PROTECTED]
http://www.cl.cam.ac.uk/users/kw217/
University of Cambridge Computer Laboratory.
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Modeling multiple inheritance
I'm trying to build a nicer interface over the one generated by jvm-bridge. I'm using fancy type classes to remove the need to mangle method names. I would like methods to be automatcially inherited, following an inheritance hierarcy defined with another set of type classes. My basic classes look like this class HasFooMethod cls args result | cls args - result where foo :: cls - args - result If I have classes A and B with foo methods like foo_JA_Jint :: ClassA - Jint - Bool foo_JB_Jboolean :: ClassB - Bool - Jint then I can make instances instance HasFooMethod ClassA Jint Bool instance HasFooMethod ClassB Bool Jint Now I can just use foo everywhere. I would like to avoid declaring an instance for every class though. In java methods are inherited from a superclass, and I would like to inherit methods automatically as well. In the bindings jvm-bridge generates a method is invoked with a function mangled after the highest ancestor that defined that particular overloading, so the implementation of HasFooMethod at a particular overloading is the same for any descendant. So I defined a class to model the inheritance relationships class SubType super sub | sub - super where upCast :: sub - super Now I can define a default instance of HasFooMethod: instance (HasFooMethod super args result, SubClass super sub) = HasFooMethod sub args result where foo sub args = foo (upCast sub) args This will propagate foo methods down the inheritance hierarcy. If a new class C is derived from A, I just need to say instance SubClass ClassA ClassC and ClassC gets a foo method. (In the actually code I piggy-back on a transitive subclass relation jvm-bridge defines that already includes an upcast method, so upCast has a default that should always be acceptable). The problem comes when interfaces are added to the mix. Interfaces are treated just like classes by jvm-bridge, and even though no implementation is inherited from instances in Java, the method accessors generated by jvm-bridge should be inherited. One problem is that the subclass relationship needs the functional dependency so that the default instance of HasFooMethod will respects the functional dependencies of HasFooMethod, so I can't declare subclass instances for multiple inheritance. On the other hand, if I don't use the functional dependency on HasFooMethod I end up needing to annotate most of the return values in a program. I run into similar problems trying to use numeric literals as arguments, because they are also overloaded. Does anyone know of clever solutions that would model multiple inheritance while preserving the functional dependencies (unsafe compiler flags are fine too), or ways to reduce the pain of overloading resolution without the functional dependency? One alternative is generating seperate HasFooMethod instances for every class in the system. The problem is that this would require alterating the bit of jvm-bridge that uses JNI to find information on classes, which currently only reports newly defined methods. JNI is black magic to me. Thanks Brandon ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Modeling multiple inheritance
On Thu, 25 Sep 2003 [EMAIL PROTECTED] wrote: On 25/09/2003, at 7:22 AM, Brandon Michael Moore wrote: I'm trying to build a nicer interface over the one generated by jvm-bridge. I'm using fancy type classes to remove the need to mangle method names. I would like methods to be automatcially inherited, following an inheritance hierarcy defined with another set of type classes. ... Hi Brandon, it looks like the way that you're modelling inheritance and OO-style overloading is basically the same way that I did in my thesis: http://www.algorithm.com.au/mocha The actual implementation of the thesis will be up in CVS in ~24 hours, I'm just waiting from an email back from the people I'm getting it hosted with. If you want a quick run-down on how I did the OO-style overloading without delving into the paper, let me know and I'll post a quick summary. I've only skimmed your email, but I think that the problem you're having with interfaces is solved with the way I'm modelling OO overloading and class inheritance. Thanks. I think I could use the summary. I already found and skimmed your thesis, and I don't think it gives me exactly what I want. All you do in chapter 3 is represent a multiple inheritance hierarcy. I want default instances that will propagate method definitions along the hierarcy. I'm not sure that's possible though. I want something like this: data Object data ClassA data ClassB data ClassC class SubClass super sub ??? instance SubClass Object ClassA instance SubClass Object ClassB instance SubClass ClassA ClassC instance SubClass ClassB ClassC class HasFooMethod cls args result ?? foo :: cls - args - result instance SubClass super sub, HasFooMethod super args result ,??? = HasFooMethod sub args result where foo obj args = foo (upCast obj) args instance HasFooMethod Object int int where foo = id (now all four classes have a foo method) Brandon ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
