- Haskell-prime - Haskell.org

Re: Proposal: Define UTF-8 to be the encoding of Haskell source files
by Doug McIlroy 07 Apr '11

07 Apr '11

This suggestion supposes that every system names files in the same way modulo choice of "directory separator": > To find a source file corresponding to a module name used in an import > declaration, the following mapping from module name to OS file name is > used. The '.' character is mapped to the OS's directory separator > string while all other characters map to themselves. The ".hs" or > ".lhs" extension is added. Where both ".hs" and ".lhs" files exist for > the same module, the ".lhs" one should be used. This supposition is unwarranted. We have all seen relative naming systems that run both ways: a.b.c versus c(b(a)). And Haskellites would simplify the latter to c$b$a. Secondary storage may be organized by files, segments, objects, etc. Combinations of these notions have been created in order to cater for legacy languages that depend on particular models. It is a step too far to try to predict how Haskell modules will be adopted into every possible naming environment. Doug McIlroy

2 1

Proposal: add ghc -fwarn-non-ascii warning flag
by Christian Maeder 07 Apr '11

07 Apr '11

similar in spirit to the -fwarn-tabs warning. C. P.S. In the mean time you may use http://projects.haskell.org/style-scanner/ (Caveat, it crashes on latin1 files when compiled with ghc-6.12 or greater.)

1 0

Re: Proposal: Define UTF-8 to be the encoding of Haskell source files
by Jason Reich 07 Apr '11

07 Apr '11

Tillmann Rendel wrote: > How would that affect the non-code parts of literate Haskell (*.lhs) > files? In particular, would it place any burden on third-party tools > processing these files? lhs2TeX already has limited support for UTF-8 for the rendering of Literate Agda files. Jason

2 1

Thoughts on unsafeLocalState
by Dan Knapp 19 Feb '11

19 Feb '11

Hi, First off, this is my first time posting to this list. I hope my post is appropriate! I noticed in going through the API docs that we now have unsafeLocalState in Foreign.Marshal, which currently is defined as equivalent to unsafePerformIO, but with a note that it "is likely to be replaced". I did look through the archives of this list, but found no discussion of it. The description of it in the API docs is simply: Sometimes an external entity is a pure function, except that it passes arguments and/or results via pointers. The function unsafeLocalState permits the packaging of such entities as pure functions. The only IO operations allowed in the IO action passed to unsafeLocalState are (a) local allocation (alloca, allocaBytes and derived operations such as withArray and withCString), and (b) pointer operations (Foreign.Storable and Foreign.Ptr) on the pointers to local storage, and (c) foreign functions whose only observable effect is to read and/or write the locally allocated memory. Passing an IO operation that does not obey these rules results in undefined behaviour. It is expected that this operation will be replaced in a future revision of Haskell I found a more complete explanation at the bottom of: http://hackage.haskell.org/trac/haskell-prime/wiki/ForeignFunctionInterface (Scroll to "Considerations for the future".) The notion seems to be that we would create a new monad that only allows specific actions to be taken. This is great as far as it goes. I very much support the idea, and would switch my code to use it if it were developed. However, I think the restrictions as given in the text I quoted above are too tight. Ideally we want something that would be suitable for libraries such as ByteString, which I believe wraps the allocation of data on the foreign heap in pure functions. This would not be allowed by unsafeLocalState in the form given, because the only pointer operations allowed by clause (b) are those on memory that is allocated in temporary fashion as by clause (a). I'm not sure quite how to word this, but I think perhaps broadening clause (a) to also allow allocation of ForeignPtrs, effectively changing the restriction from "anything you allocate must be freed by the time you return" to "anything you allocate must be known to the garbage collector". I have a practical use for this; I am working on a binding to libffi, pursuant to developing a better ObjC/Cocoa binding. To use libffi, it is necessary to build complicated structs. So I have the definition type ComplicatedStruct = ForeignPtr (), and a function, currently wrapped in unsafePerformIO, which constructs a new complicated struct given a description of what it should contain. This is, in my understanding, a "safe" usage of unsafePerformIO, but really it would be nice to use something safer. So I don't know that I have an action item, I just wanted to make sure that if and when future development on this happens, it takes this concern into account. Um, thanks for reading? -- Dan Knapp "An infallible method of conciliating a tiger is to allow oneself to be devoured." (Konrad Adenauer)

1 0

specify call-by-need
by Scott Turner 18 Feb '11

18 Feb '11

In practice, Haskell a call-by-need language. Still, software developers are not on firm ground when they run into trouble with evaluation order, because the language definition leaves this open. Is this an underspecification that should be fixed? 1. Haskell programmers learn the pitfalls of sharing as soon as they cut their teeth on 'fib', 2. Virtually all significant-sized Haskell programs rely on lazy evaluation and have never been tested with another evaluation strategy, 3. Questions come up on Haskell-Café, infrequently but regularly, regarding whether a compiler optimization has altered sharing of values within a program, causing it to fail, 4. The rationale for the monomorphism restriction assumes lazy evaluation, 5. It is the effect on asymptotic behavior that matters, 6. Portable Haskell code should not have to allow for the variety of non-strict evaluation strategies, as the Haskell Report currently implies. I suggest specifying call-by-need evaluation, allowing for the places where type classes prevent this. If necessary, make it clear that local optimizations not affecting asymptotic behavior are permitted. This would not eliminate struggles with evaluation order. The intent would be to clarify expectations. -- Scott Turner

3 3

Reform of the Monad, and Disruptive Change
by John Smith 05 Feb '11

05 Feb '11

There has been a fair amount of discussion, both on this list and libraries, regarding the Monad class hierarchy. The many on the libraries list expressed support for the patch at http://hackage.haskell.org/trac/ghc/ticket/4834, conditional on it being part of the next Haskell report. However, Haskell' prefers patches to have been implemented before proposing here. What is the best way out of this deadlock?

7 7

Re: Reform of the Monad, and Disruptive Change
by Howard B. Golden 04 Feb '11

04 Feb '11

John Smith <voldermort(a)hotmail.com> asked: > What is the best way out of this deadlock? My suggestions: * If possible, make the change optional. As an example, create a second (third, etc.) Prelude with the new features without abandoning the current Prelude. Let the user choose the Prelude he/she wants via a pragma or compiler option. Then developers can vote with their feet (fingers?). If the new Prelude is buggy, it will be easy to try something else. You might call this "intellectual free enterprise." * Do everything possible to create adapters to make upgrading existing code to the new Prelude. Thus, if a new Prelude is adopted widely, existing code will be easy to incorporate with minimal source changes. * Avoid disruptive changes by letting the user decide. Once there is a clear consensus based on significant usage, then the new Prelude can be blessed by some committee (if desired). However, don't abandon the previous Prelude as an option, ever. Textbooks might teach only the newer Prelude, but old code would still work. * Recognize that the Haskell user base at this time shouldn't be constrained by mandated changes, but should be encouraged to experiment and evolve the libraries. Cheers, Howard

1 0

Local definitions in the class instances
by Boris Lykah 02 Feb '11

02 Feb '11

I think it would be convenient to allow adding variables and functions, which are not members of the class, to a class instance so that they are visible only in the instance scope. It will help if the same functions are used by several class functions. Example: When implementing Num class for my datatype, I found that I routinely do unwrapping in each operator definition. I extracted it into functions, but as they are used only in instance definition, I want to put them there and restrict them to that scope. It would be neater than leaving them in the global scope or copypasting into each operator. > newtype Wrapped = Wrapped Integer deriving (Show, Eq) > instance Num Wrapped where > (+) = lift2 (+) > (-) = lift2 (-) > (*) = lift2 (*) > abs = lift abs > signum = lift signum > fromInteger = Wrapped > lift2 f (Wrapped a) (Wrapped b) = Wrapped (f a b) > lift f (Wrapped a) = Wrapped (f a) The extension implementation should be very simple. -- Regards, Boris

8 9

RelaxedLayout language extensions should be default for Haskell
by Axel Simon 21 Jan '11

21 Jan '11

Hi, following the discussion on the ghc mailing list, I propose that the new "RelaxedLayout" extension that is proposed for ghc 7.1 should be incorporated into the language standard. The motivation is that ghc <7.1 have silently implemented the "RelaxedLayout" by default and that removing this feature will break many programs without any gain except that ghc complies to the standard. Hence, it would be better that the standard is adjusted, as this would imply no changes to current ghc compilers nor user programs. As I'm not familiar with the technical details, I can only give an idea about what "RelaxedLayout" does. Haskell 2010 would parse foo = do some computation trace "hello" $ do other computation such that "other computation" belongs to the first "do", i.e. foo = do { some computation ; trace "hello" $ do ; other computation } which leads to a parse error since the second "do" not followed by any instructions. The relaxed layout extension opens a new block after a "do" if the next line commences on in the same column as the current block. Thus, it would parse the example above as: foo = do { some computation ; trace "hello" $ do { other computation } } Observations: - the proposal has been implemented in ghc for years - it does not break any existing programs (as far as I can see) - incorporating this proposal into the standard involves no implementation effort for the ghc compiler nor any program that compiles with ghc Cheers, Axel

1 1

Re: [Haskell] Announce: ~Haskell 2011
by Malcolm Wallace 20 Jan '11

20 Jan '11

>> (a) we wish to accept the NoDatatypeContexts proposal >> http://hackage.haskell.org/trac/haskell-prime/wiki/NoDatatypeContexts > > The Trac-Wiki says: "What removing the datatype contexts from a source > file will do is make some previously illegal programs legal." What > is an > example? As on the wiki, data Eq a => Foo a = Constr a getVal :: Foo a -> a getVal (Constr x) = x would previously have been rejected. Once the compiler forces the user to remove the Eq a => context on the datatype, the rest of the program will be accepted. Regards, Malcolm

1 0