- Glasgow-haskell-users

[ ghc-Feature Requests-1209056 ] functions without implementations
by SourceForge.net 26 May '05

26 May '05

Feature Requests item #1209056, was opened at 2005-05-26 12:53 Message generated for change (Settings changed) made by c_maeder You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1209056&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open >Priority: 2 Submitted By: C Maeder (c_maeder) Assigned to: Nobody/Anonymous (nobody) Summary: functions without implementations Initial Comment: Allow to declare a function by only supplying its type signature. This feature shall enhance rapid prototyping by fixing an interface but leaving some functions unimplemented. Currently this can be (only) simulated by supplying dummy implementations, like f :: ... f = undefined Since it is possible to supply dummy data types by "data T" (not followed by "="), allowing functions without implementations seems almost to be a logical consequence. Surely, the compiler should emit warnings for missing implementations. It would be nice if such function declarations via type signatures could be repeated at any position within a module. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1209056&group_…

1 0

[ ghc-Feature Requests-1209056 ] functions without implementations
by SourceForge.net 26 May '05

26 May '05

Feature Requests item #1209056, was opened at 2005-05-26 12:53 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1209056&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Priority: 5 Submitted By: C Maeder (c_maeder) Assigned to: Nobody/Anonymous (nobody) Summary: functions without implementations Initial Comment: Allow to declare a function by only supplying its type signature. This feature shall enhance rapid prototyping by fixing an interface but leaving some functions unimplemented. Currently this can be (only) simulated by supplying dummy implementations, like f :: ... f = undefined Since it is possible to supply dummy data types by "data T" (not followed by "="), allowing functions without implementations seems almost to be a logical consequence. Surely, the compiler should emit warnings for missing implementations. It would be nice if such function declarations via type signatures could be repeated at any position within a module. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1209056&group_…

1 0

Contexts differ in length
by Robert van Herk 24 May '05

24 May '05

Hi all, A while ago I sent an email to the glasgow haskell users maillinglist to explain how the "Contexts differ in length" feature (or bug :-)) restricted me in writing a haskell application. I was hoping for a reply, however I didn't receive one (yet). Therefore, I will explain the problem again: I am writing (for my master's thesis project) a webdevelopment framework in Haskell, with features somewhat comparable to Apple's WebObjects. Amongst others, session state and database interaction is transparent, etc. In my framework, functions that generate HTML are called WFComponents. These functions are monadic since they can generate IO (because they may do database interaction etc). Also, components can generate links to other components. However, since component a may generate a link to component b (so that when the user clicks that link component b will be evaluated) and component b may link to component a, there will occur errors when I try to do this, since the contexts of component a and b may not be the same. A minimal example of this will be something like: {-# OPTIONS -fglasgow-exts #-} module Main where import Data.IORef class MyReader r v | r -> v where myRead :: r -> IO v data R v = R (IORef v) instance MyReader (R v) v where myRead (R v) = do v <- readIORef v return v a :: IO () a = do r <- createReader b r b :: MyReader r Int => r -> IO () b r = do i <- myRead r if i > 10 then a else putStrLn (show i) createReader :: IO (R Int) createReader = do ref <- newIORef 0 return (R ref) A real example will be a bit more complicated, but this is basically what I need to do and currently am not able to. Of course, when needed, I can show you the real example. Somewhere in the history of this mailling list I read that people have had this program before, but only in toy programs. However, I am experincing this problem currently in something that is not a toy program. Therefore, my question is if it would be possible to lift this constraint on the language, and also, if the developers of GHC are currently planning to do this... Thanks, Robert

2 1

RE: runInteractiveProcess, confused
by Simon Marlow 24 May '05

24 May '05

On 18 May 2005 14:47, Frederik Eaton wrote: > When I run the following line in ghci: > > Prelude System.Process Control.Concurrent System.IO> do { (inp, out, > err, ph) <- runInteractiveProcess "cat" [] Nothing Nothing; forkIO > (do hPutStr inp "this\nis\na\ntest\n"; hClose inp); waitForProcess ph > } > > ... it doesn't terminate. I'm following the example in the > System.Process documentation. But I would think that since I close > 'inp', "cat" would terminate. Also, I don't see the expected output. This example won't work inside GHCi, because GHCi isn't compiled with -threaded: the -threaded option is required to get a version of waitForProcess that doesn't block other threads in a multithreaded program. The only reason GHCi isn't compiled with -threaded is because I'm being conservative; the threaded RTS introduces a lot more complexity and hasn't been shaken down as much as the single-threaded RTS. If you compile GHC up yourself you can fix it by adding "GhcStage2HcOpts += -threaded" to mk/build.mk before building. In a future release of GHC we'll do this by default. Cheers, Simon

1 0

Re: ghc bugs
by Robert van Herk 24 May '05

24 May '05

Serge D. Mechveliani wrote: >>Hi all, >> >>A while ago I sent an email to the glasgow haskell users maillinglist to >>explain how the "Contexts differ in length" feature (or bug :-)) >>restricted me in writing a haskell application. I was hoping for a >>reply, however I didn't receive one (yet). >> >>[..] >> >> > >In my experience, glasgow-haskell-bugs(a)haskell.org > >usually replies to bug reports (maybe, within a couple of weeks). > > I see, but this was "on of them bugs" that could be called "feature" :-). Actually, I think it is a overrestrictive constraint in the Haskell 98 language definition, which I am hoping that the Simons will lift :-). Robert

1 0

RE: GHC Win32 ffi functions as implemented for Pugs
by Simon Marlow 23 May '05

23 May '05

On 22 May 2005 23:32, Max Maischein (Corion) wrote: > The file is (live version) : > > http://svn.openfoundry.org/pugs/src/Pugs/Compat.hs > > The implemented wrappers that are functional and not just stubs are > (as of r3680) : > > For System.Environment: > setEnv :: String -> String -> Bool -> IO () > getEnv :: String -> IO (Maybe String) > unsetEnv :: String -> IO () System.Environment.getEnv should work on Win32. For the others, it would possibly make sense to include these in System.Environment, with implementations for both Unix & Win32. > For Posix.Process > getProcessTimes :: IO ProcessTimes > getProcessID :: IO Int Should probably be in System.Win32 somewhere. > The code itself is dual-licensed under the Artistic License and GPL > and thus should be compatible with whatever license GHC uses. Unfortunately we can't take code under that license into our existing packages - the rule is that each package has a single license, and currently all the packages distributed with GHC have a BSD3 license, with the exception of readline. You can start new packages, of course. > Hope you find my code useful, Contributions are always welcome, even if we can't use the code directly. You've pointed out things that the standard libraries lack. Thanks! Cheers, Simon

3 2

RE: cvs commit: fptools/ghc/compiler/hsSyn HsUtils.lhs fptools/ghc/compiler/typecheck TcRnDriver.lhs TcRnMonad.lhs TcUnify.lhs
by Simon Marlow 23 May '05

23 May '05

On 22 May 2005 14:17, Jim Apple wrote: > Simon Peyton Jones wrote: > >> - For command-line 'let' and 'x<-e' forms, if exactly one variable >> is bound, we print its value if it is Showable and not () >> prompt> let x = 4 4 >> prompt> x <- return 5 >> 5 > > prompt> let ones = [1:x] > > What am I to do if I want ones set, but not printed? I think you mean let ones = 1:ones but it's a good point. At the moment you can hack around it with let ones = 1:ones; x=x (for example). Simon: I think let bindings should be exempt from the new auto-show behaviour. The docs currently say that let doesn't evaluate its rhs: An important difference between the two types of binding is that the monadic bind (p <- e) is strict (it evaluates e), whereas with the let form, the expression isn't evaluated immediately: and the example that follows that paragraph is currently wrong (the let binding will yield an exception). Cheers, Simon

1 0

RE: error in your article? about meaning of safe/unsafe in "foreignimport"
by Simon Marlow 23 May '05

23 May '05

Yes, I think that sentence in the awkward squad paper is incorrect. The "unsafe" annotation on foreign import is not related to the purity of the function being called, it is the omission of 'IO' on the return type that indicates intended purity. Cheers, Simon On 19 May 2005 16:39, Bulat Ziganshin wrote: > Hello Peter, > > Sunday, May 15, 2005, 4:07:28 PM, you wrote: > >> http://research.microsoft.com/Users/simonpj/papers/marktoberdorf/ > > this article says that > > -------------------------------------------------- > some foreign procedures may cover have purely-functional semantics. > For example, > the C sin function really is a function: it has no side effects. In > this > case it is extremely tiresome to force it to be in the IO monad. So > the Haskell FFI > allows one to use the unsafe keyword, and omit the ``IO'' from the > return type, thus: > > foreign import ccall unsafe sin :: Float -> Float > > As in the case of unsafePerformIO (Section 2.6), ``unsafe'' indicates > that the programmer > takes on a proof obligation, in this case that foreign procedure is > genuinely functional. > -------------------------------------------------- > > > > while the FFI specification state that > > -------------------------------------------------- > Optionally, an import declaration can specify, after the calling > convention, the safety level that should be used when invoking an > external entity. A safe call is less efficient, but guarantees to > leave the Haskell system in a state that allows callbacks from the > external code. In contrast, an unsafe call, while carrying less > overhead, must not trigger a callback into the Haskell system. If it > does, the system behaviour is undefined. The default for an > invocation is to be safe. Note that a callback into the Haskell > system implies that a garbage collection might be triggered after an > external entity was called, but before this call returns. > Consequently, objects other than stable pointers (cf. Section 5.6) > may be moved or garbage collected by the storage manager. > -------------------------------------------------- > > > and one more question: is it possible to download sources of http > server mentioned in this article? i want to browse the code, it's no > matter how it compiles and works

1 0

GHC Win32 ffi functions as implemented for Pugs
by Max Maischein (Corion) 22 May '05

22 May '05

Hello all, I have been working on Pugs, the current Perl6 interpreter, and have been hacking on Win32 compatibility. For that, I've written some wrappers around native Win32 API calls using the very convenient FFI that GHC 6.4 provides! I wonder if you want to include the functions in GHC, as they are missing on Win32. Autrijus Tang pointed me to this list. The file is (live version) : http://svn.openfoundry.org/pugs/src/Pugs/Compat.hs The implemented wrappers that are functional and not just stubs are (as of r3680) : For System.Environment: setEnv :: String -> String -> Bool -> IO () getEnv :: String -> IO (Maybe String) unsetEnv :: String -> IO () For some other module: statFileSize :: FilePath -> IO Integer For Posix.Process getProcessTimes :: IO ProcessTimes getProcessID :: IO Int The code implementing them is inefficient and crude, partly because I speak Haskell with a quite perlish lisp, and partly because I used the first implementation that worked, so I like to hear about implementing them in better style, or, even better that you choose to accept them into GHC so I don't have to worry about them anymore. The code itself is dual-licensed under the Artistic License and GPL and thus should be compatible with whatever license GHC uses. Hope you find my code useful, -max PS: If this message went to the wrong list, please tell me so and also tell me where the message should go to! PPS: Please CC me on the replies as I won't stay subscribed long.

1 0

Re: cvs commit: fptools/ghc/compiler/hsSyn HsUtils.lhs fptools/ghc/compiler/typecheck TcRnDriver.lhs TcRnMonad.lhs TcUnify.lhs
by Jim Apple 22 May '05

22 May '05

Simon Peyton Jones wrote: > - For command-line 'let' and 'x<-e' forms, if exactly one variable > is bound, we print its value if it is Showable and not () > prompt> let x = 4 > 4 > prompt> x <- return 5 > 5 prompt> let ones = [1:x] What am I to do if I want ones set, but not printed? Jim

1 0