FranTk: how to justify a widget collection?
I run FranTk with hugs. I want a `nabove' collection of widgets, each of them justified to the left; but the `above' combinator seems to center its arguments, regardless of their options (anchor, justify). Related question: I can set configuration options :: [ Conf w ] for each "explicit" widget (buttons, etc.) but is there a way to configure the (unnamed) composed widgets for instance the result of (a `beside` b)? Any hints appreciated, -- -- Johannes Waldmann http://www.informatik.uni-leipzig.de/~joe/ -- -- [EMAIL PROTECTED] -- phone/fax (+49) 341 9732 204/252 -- === Drittes Leipziger Jongliertreffen 6. - 8. Oktober === === http://www.informatik.uni-leipzig.de/~joe/juggling/dreilei/ ===
Re: lazy file reading in H98
Tue, 05 Sep 2000 12:10:14 +1100, Manuel M. T. Chakravarty [EMAIL PROTECTED] pisze:
H98 doesn't really specify what happens in this situation.
I think, there are two ways to solve that:
Similar problem is in the case of hClose on a semi-closed handle.
For example in GHC it means that whatever was not evaluated yet,
will be lost.
When one hCloses a semi-closed handle, he might mean one of two things:
- He is not interested in this file nor its contents any more.
- He wants to process what was read by hGetContents but have this file
physically closed, as if hGetContents was strict.
There is no perfect way to automatically distinguish between these
cases. When the handle hidden in the free variables of the contents
string is finally garbage collected, the RTS may be certain that the
first action was needed and the file may be forgotten, but when it's
still alive, we _probably_ should read the rest into memory and then
close it.
There is a chance that it was not garbage collected yet but it's dead,
and reading a whole 10 megs of file when the user losed its interest
after first bytes is unnecessary. So this is not a sufficient rule.
I don't see how to do this without extending the interface.
In the case that solution (1) is chosen, I think, we should also
have something like `strictReadFile' (and `hStrictGetContents')
which reads the whole file before proceeding to the next IO action.
It's not enough too: it forces strict reading from the beginning,
where what could be really needed is to process almost the whole file
sequentially and finally ensure that anything more is read too.
It is sufficient - but perhaps not the nicest interface - to have
an operation on a semi-closed handle which ensures that everything
previously told to be read lazily is actually read now, which of course
causes closing the file afterwards. hClose would be left as is in GHC,
to be able to lose interest on the file without the danger of reading
the whole. It means that instead of readFile, hGetContents should be
used in cases this operation is needed.
Could hFlush be reused for this? :-) Probably no, it's a different
thing.
Alternatively, hClose could do that, but there should be a variant
of hClose that means losing interest.
Since it does not give best possible behavior in case of writeFile
after reading on Unix, perhaps it should be combined with your rule
(2).
Otherwise, in situations like in the mentioned assignment, you have
to resort to reading the file character by character, which seems
very awkward.
Actually you could apply
foldr (\_ x - x) (return ())
or even
foldr seq (return ())
to its lazy contents. But it seems too bad for an official method.
--
__(" Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTÊPCZA
QRCZAK
An Interview with Brian Kernighan
With some small mention of FP (ML in particular): http://www.cs.cmu.edu/~mihaib/kernighan-interview/index.html
Re: FranTk: how to justify a widget collection?
Hi Regarding the nabove question, if you use "packAnchor W" then it should align the widgets to the left. If this doesn't work then there is a bug. Let me know and I'll fix it. As far as giving configuration options to composite widgets. FranTk will eventually allow this, but does not do so at the moment. I've got it partially implemented in the updated version which will eventually be released. Unfortunately life continues to get in the road of that event :-) Meurig - Original Message - From: "Johannes Waldmann" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, September 05, 2000 8:06 AM Subject: FranTk: how to justify a widget collection? I run FranTk with hugs. I want a `nabove' collection of widgets, each of them justified to the left; but the `above' combinator seems to center its arguments, regardless of their options (anchor, justify). Related question: I can set configuration options :: [ Conf w ] for each "explicit" widget (buttons, etc.) but is there a way to configure the (unnamed) composed widgets for instance the result of (a `beside` b)? Any hints appreciated, -- -- Johannes Waldmann http://www.informatik.uni-leipzig.de/~joe/ -- -- [EMAIL PROTECTED] -- phone/fax (+49) 341 9732 204/252 -- === Drittes Leipziger Jongliertreffen 6. - 8. Oktober === === http://www.informatik.uni-leipzig.de/~joe/juggling/dreilei/ ===
Some questions about Monads
Hi all, I'm new to Haskell, and I've found its approach to imperative programming (monad) quite interesting; but there are some problems with this, partly already mentioned by Philip Wadler in his paper "How to Declare an Imperative": using his words, there no way to move smoothly from no monad (no interaction), to one monad (a single form of interaction), to many monad (several independent forms of interaction). I'm looking for a way to solve these problems: I've a couple of idea, but I now need a collection of Monad for testing them; so far, I've found only this types of Monads: - IO - ST - Maybe (modeling exception) - List (modeling nondeterminism) The only combined monad I've seen is the Parse monad (a combination of ST and List). The questions are: - Are there other interesting Monads or Combined Monads to consider? - In Haskell is there some way to combine IO and ST? In example, suppose I want to define a function that take a reference, update it and then print the updated value: f :: STRef s Int - ?? () f r = do x - readSTRef r putStrLn (show x) - By chance, is someone already working on this? Thanks, -- Diego Dainese P.S. Sorry for my bad English
Re: Some questions about Monads
- Are there other interesting Monads or Combined Monads to consider? see Mark P. Jones and Luc Duponcheel: Composing Monads Research Report YALEU/DCS/RR-1004, Yale University, New Haven, Connecticut, USA, December 1993. http://www.cse.ogi.edu/~mpj/pubs/composing.html -- -- Johannes Waldmann http://www.informatik.uni-leipzig.de/~joe/ -- -- [EMAIL PROTECTED] -- phone/fax (+49) 341 9732 204/252 -- === Drittes Leipziger Jongliertreffen 6. - 8. Oktober === === http://www.informatik.uni-leipzig.de/~joe/juggling/dreilei/ ===
Re: Some questions about Monads
Hi Diego,
"Diego" == Diego Dainese [EMAIL PROTECTED] writes:
Diego - In Haskell is there some way to combine IO and ST?
there is a so-called IOS-Monad combining IO and State, appended below.
Thanks to John O'Donnell who told me about it and gave it to me a few weeks ago.
Cheers
Christoph
--
IOS: Input/Output with state
module IOS where
newtype IOS s a = IOS (s - IO (a, s))
unIOS :: IOS s a - (s - IO (a, s))
unIOS (IOS m) = m
liftIOS :: IO a - IOS s a
liftIOS m = IOS (\s - m = \a - return (a,s))
runIOS :: IOS s a - s - IO (a, s)
getIOS :: IOS s s
setIOS :: s - IOS s ()
modIOS :: (s - s) - IOS s s
runIOS= unIOS
modIOS f = IOS (\s - return (s, f s))
setIOS s' = IOS (\s - return ((),s'))
getIOS= IOS (\s - return (s,s))
thenIOS m k= IOS (\s - unIOS m s = \(a,s') - unIOS (k a) s')
then_IOS m k= IOS (\s - unIOS m s = \(_,s') - unIOS k s')
retIOS a = IOS (\s - return (a,s))
instance Monad (IOS s) where
(=) = thenIOS
() = then_IOS
return = retIOS
---
-- Basic operations for data parallel monad
rundp :: IOS s a - s - IO ()
rundp prog initst =
do runIOS prog initst
return ()
dp_putStr :: String - IOS s ()
dp_putStr xs = liftIOS (putStr xs)
dp_getChar :: IOS s Char
dp_getChar = liftIOS getChar
dp_showState :: Show s = String - IOS s ()
dp_showState cs =
do dp_putStr cs
x - getIOS
dp_putStr (show x)
dp_putStr "\n"
return ()
dp_showStatenew :: (s - IO ()) - IOS s ()
dp_showStatenew f =
do x - getIOS
liftIOS (f x)
dp_putStr "\n"
return ()
repeatLoop f =
do q - f
if q then repeatLoop f
else return ()
---
-- Data parallel monadic operations with list state
dpl_map :: (a-a) - IOS [a] [a]
dpl_map f = modIOS (map f)
dpl_foldl :: (a-b) - (b-b-b) - b - IOS [a] b
dpl_foldl f g a =
do xs - getIOS
return (foldl g a (map f xs))
---
-- Examples of monadic data parallel programs
-- Basic I/O with dp operations in the IOS monad
dp_echoChar :: IOS [Int] ()
dp_echoChar =
do dp_putStr "This is dp_echoChar, type in a character for me!\n"
c - dp_getChar
dp_putStr ("\nyou typed in the character ---" ++ [c] ++ "---\n")
dp_showState "this is the initial state:\n "
dp_putStr "bye\n"
return ()
run_echoChar = rundp dp_echoChar [1..10]
Monadic data parallel maps, folds and scans with list state
dp_alg :: IOS [Int] ()
dp_alg =
do dp_putStr "\nThis is dp_alg\n"
dp_showState "initial state:\n "
dpl_map (*10)
dp_showState "after mapping (*10):\n "
x - dpl_foldl id (+) 0
dp_putStr ("dplfold id (+) == " ++ show x ++ "\n")
dpl_map (+x)
dp_showState "after mapping (+x):\n "
dp_putStr "bye\n\n"
return ()
run_dp_alg = rundp dp_alg [1..10]
---
-- The pure Data Parallel monad (without I/O)
data DP s a = DP (s - (a,s))
instance Monad (DP s) where
(f = g) =
DP (\s - case unwrapDP f s of
(a,s') - unwrapDP (g a) s')
return a = DP (\s - (a,s))
unwrapDP :: DP s a - (s -(a,s))
unwrapDP (DP f) = f
===
END of mail
Re: Some questions about Monads
05 Sep 2000 12:05:29 +0200, Diego Dainese [EMAIL PROTECTED] pisze:
- In Haskell is there some way to combine IO and ST?
In GHC and Hugs there are IORef, IOArray, readIORef etc. which
give ST's functionality in IO. There is also stToIO and even
unsafeIOtoST. In newer GHCs there is a MArray module which provides
mutable array operations overloaded on both STarrays in ST and IOArrays
in IO.
--
__(" Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTÊPCZA
QRCZAK
Postdoc and PhD Student Position Announcement
EPFL Lausanne Programming Methods Group Prof. Martin Odersky For the Project "Practical Implementations of Functional Nets", funded in part by the Swiss National Science Foundation, we are looking for * Postdoctoral researcher (1 or 2 year term), * PhD student (fully funded). The project explores novel implementation techniques for programming languages which lie in the intersection of the functional, object-oriented, and concurrent language families. The positions offer exciting opportunities for research in a young but rapidly growing group. Postdoctoral applicants should have a strong background in at least two of the following areas: - programming language design and implementation, - functional programming, - object-oriented programming, - concurrent and distributed systems. The ideal candidate will have a lively interest in both system building and theory. She or he will enjoy the opportunity to work collaboratively with other researchers and PhD students at the programming methods group at EPFL. The appointment is for one year with a possible renewal. PhD student applicants should have strong research interests in one or more of the areas given above and should like to work on the boundary betwen theory and practice. They should have obtained a degree equivalent to a Swiss EPFL diploma (usually this is a master's degree, although a B.Sc. with honors might also be considered). The duration of PhD studies at EPFL is typically 4 years. Both positions are open from Fall 2000, with a starting date in Spring or Fall 2001 also being possible. Compensation is competetive: CHF 70K+ for the post-doc position, and CHF 50K+ for the PhD student position (1 CHF ~~ 0.6 U.S$). Informal inquiries about the positions may be addressed to [EMAIL PROTECTED] Formal applications should be sent by e-mail to the following address: Madame Yvette Dubuis [EMAIL PROTECTED] Tel. +41 21 693 5202 Fax +41 21 693 6660 To be guaranteed full consideration, applications should be received by October 15th, 2000. Applications should consist of a curriculum vitae, a publication list, and the names of three personal references (two for PhD students). Please ask your references to send their letters directly to [EMAIL PROTECTED], there is no need for a request from us. EPFL Lausanne is one of two federal universities in Switzerland. It has one of the most nationally diverse research, teaching and learning communities in Europe. Lausanne is situated in very attractive surroundings in the French-speaking part of Switzerland, on the bord of Lake Geneva, in close proximity to the Alps. [apologies if you receive this on multiple lists --MO]
Programming in Latin
Monash University School of Computer Science and Software Engineering 2000 Clayton campus Seminar Series -- Seminar: Programming in Latin (and Why You Really Might Want To) Speaker: Dr Damian Conway ([EMAIL PROTECTED]), School of Computer Science and Software Engineering, Monash University Date: MONDAY, 11 September 2000 Time: 2:00 pm Venue: Room 135, Computer Science Building (26), Clayton Campus Video Wall at Caulfield Campus Seminar Abstract: English has a comparatively weak lexical structure. Much of the grammatical load of a sentence is carried by positional cues. A statement such as: "The boy gave the dog the food." only makes sense because of the convention that the subject precedes the verb, which precedes the indirect object, which precedes the direct object. Changing the order -- "The food gave the boy the dog." -- changes the meaning. Most programming languages use similar positional grammatical cues. The instruction: maximum = next; is very different in meaning from: next = maximum; Generally speaking, older languages have richer lexical structures (such as inflection for noun number and case) and so rely less on word order. For example, in Latin the sentences "Puer dedit cani escam." and "Escam dedit puer cani." both mean "The boy gave the dog the food." Indeed, the more usual word order would be "Reverse Polish", with the verb coming last: "Puer cani escam dedit." This flexibility is possible because Latin uses inflection to denote lexical roles. There is no reason that programming languages could not also make use of inflection, rather than position, to denote lexical roles. This talk will describe an alternative syntactic binding for the Perl programming language. This binding uses inflections based on classical Latin grammar, rather than positional constraints. No prior knowledge of Latin will be assumed, but by the end of the talk the following program will make perfect sense: pre maximum inquementum tum biguttam tum stadium egresso scribe. vestibulo perlegementum da meo maximo . maximum tum novumversum egresso scribe. da duo tum maximum conscribementa meis listis. dum damentum nexto listis decapitamentum fac sic lista sic hoc tum nextum recidementum cis vannementa listis da. next tum biguttam tum nextum tum novumversum scribe egresso. cis /pre About The Speaker: Dr Damian Conway is a Senior Lecture in the School of Computer Science and Software Engineering at Monash University. His research interests include: language design, the teaching of programming, object orientation, software engineering, natural language generation, synthetic language generation, morphing, human-computer interaction, geometric modelling, the psychophysics of perception, nanoscale simulation, and parsing. School Contact: Damian Conway ([EMAIL PROTECTED] ) - - A complete list of forthcoming Monash (Clayton) Computer Science and Software Engineering seminars is available from: http://www.csse.monash.edu.au/cgi-bin/seminar?forthcoming Clayton campus parking information is available from: http://www.csse.monash.edu.au/cgi-bin/seminar?parking - - Andrew P. Paplinski (seminar coordinator) ([EMAIL PROTECTED]) - - Updated: 05 Sep 2000
student compiler in Haskell
I'm hoping to write the compiler for my graduate compilers course in Haskell, using Hugs on Windows NT. I find several choices for scanner and parser generators at http://www.haskell.org/libraries/. I would love to hear opinions about the overall suitability (usability, robustness, compliance with Haskell 98, etc.) of these tools (and any others that you consider useful) for such a project. Thanks in advance. Dean Herington Department of Computer Science University of North Carolina at Chapel Hill [EMAIL PROTECTED]
