- Haskell-prime - Haskell.org

Over/underflow semantics for 'Int' et al.
by Herbert Valerio Riedel 29 Jan '14

29 Jan '14

Hello *, I'd like to point your attention to https://ghc.haskell.org/trac/ghc/ticket/8695 which brings up the issue what the results operations such as * `div minBound (-1)` * `quot minBound (-1)` * `abs minBound` shall result in for the standard H2010 fixed-width signed types such as `Int`, that is whether ⊥ (arithmetic overflow-exception) or `minBound` is the more appropriate result. Relevant sections from the Haskell 2010 report: (http://www.haskell.org/onlinereport/haskell2010/haskellch6.html#x13-1350006…) | 6.4. Numbers | | [...] The results of exceptional conditions (such as overflow or | underflow) on the fixed-precision numeric types are undefined; an | implementation may choose error (⊥, semantically), a truncated value, | or a special value such as infinity, indefinite, etc. ...which seems contradictory to... (http://www.haskell.org/onlinereport/haskell2010/haskellch18.html#x26-224000…) | * 18.1. Signed integer types | | This module provides signed integer types of unspecified width (Int) | and fixed widths (Int8, Int16, Int32 and Int64). All arithmetic is | performed modulo 2^n, where n is the number of bits in the type. | [...] Would a Haskell 2010 implementation which turns *every* integer over/underflow (even those for addition or multiplication of 'Int' values whose result would lie outside of [minBound..maxBound]) into a arithmetic exception be a valid H2010 implementation? -- hvr

1 0

Hiding top level declaration with tilde
by Ramin Honary 09 Jan '14

09 Jan '14

Hello, I did some Googling, and read a bit through the Haskell 2010 report, Chapter 5 "Modules," and searched through the Haskell-prime Trac tickets and can't really find anything on this. I don't know if it has ever been suggested before, or the reasoning for how export lists work the way they do. So as we all know, when there is no exports list in a module declaration, everything in the top level is exported by default. If you provide an exports list, everything is hidden except what you declare in the exports list. I think a good way to hide things without an exports list might be to simply prefix the type signature with a tilde character. For example: module M where ~type A = () ~newtype B = B () ~data C = MkB1 () | MkB2 () ~abc :: () abc = () increment :: Int -> Int increment = (+1) So in this example, the module M would only export the "increment" function, everything else would be hidden. Right now, this would produce a compile-time error like: Invalid type signature: ~abc :: () I propose making this kind of expression legal and effecting whether or not the symbol is exported. The only disadvantage I can think of is that tilde is generally reserved for making things more lazy, and using tilde in a way that has nothing to do with lazyness, it could make the language a bit more confusing. Otherwise I think it is very practical.

3 2

getWorkingDirectory/changeWorkingDirectory
by Benjamin Franksen 04 Dec '13

04 Dec '13

Module System.Posix.Directory of the unix package defines getWorkingDirectory :: IO FilePath changeWorkingDirectory :: FilePath -> IO () I believe the functionality is quite portable and not limited to unix-like systems. I know that e.g. Windows has chdir and getcwd. Module Filesystem of the system-fileio package has getWorkingDirectory :: IO FilePath setWorkingDirectory :: FilePath -> IO () I propose to add these functions to System.Environmant or maybe System.Directory. Rationale: (1) This is standard functionality that should at least be in the Haskell Platform, if not in the standard libraries. (2) I would like to avoid depending on an extra package just to have these two very basic functions available in a OS independent way. (3) "system-fileio".Filesystem does not seem to be the right place for this. The last point may be arguable, but the first two are plain common sense IMO. Cheers Ben -- "Make it so they have to reboot after every typo." ? Scott Adams

4 3

Lista de emails trabalho com mala direta mala direta como fazer
by Ed Soares 24 Nov '13

24 Nov '13

Lista de emails trabalho com mala direta mala direta como fazer lista de mail também lista de emails, cadastro email lista email: http://www.maladiretaemails.com Nós sabemos que list mail, é muito legal para a maioria das pessoas. endereco de email listas email e acima de tudo lista de emails, email de empresas o que e mailing, o objetivo de nosso website. se você busca emails de pessoas, email marketing e também email mailing: http://www.maladiretaemails.com é excelente listas de emails tais como lista email, endereco de email lista com emails. é fantástico emails de pessoas e, além disso lista email. envio de emails email cadastro, marketing email. atualmente lista de email compreendendo Enviar email, newsletter pode ser bastante bom. é realmente a função do nosso website: cadastro email, Enviar email, e bem como listas de emails. Oferecemos o melhor em lista de email listas de emails, envio de emails.

1 0

Anonymous records. A solution to the problems of record-system.
by Nikita Volkov 14 Oct '13

14 Oct '13

Anonymous records. A solution to the problems of record-system. The current record system is notorious for three major flaws: 1. It does not solve the namespacing problem. I.e., you cannot have two records sharing field names in a single module. E.g., the following won't compile: data A = A { field :: String }data B = B { field :: String } 2. It's partial. The following code will result in a runtime error: data A = A1 { field1 :: String } | A2 { field2 :: String } main = print $ field1 $ A2 "abc" 3. It does not allow you to use the same field name for different types across constructors: data A = A1 { field :: String } | A2 { field :: Int } This proposal approaches all the problems above and also a fourth one, which is unrelated to the current record system: it allows one to avoid declaration of intermediate types (see details below). Gentlemen, I want you to meet, <#anonymous-records>Anonymous Records When a record-syntax is used in Haskell it's almost always a single-constructor ADT. A question rises then: why use ADT when you don't need its main feature (i.e., the multiple constructors)? This main feature is actually the root of the second and the third problem of record-syntax from the list above. In such situations one doesn't actually need ADT, but something more like a tuple with ability to access its items by name. E.g.: f :: (a :: Int, b :: String) -> Stringf rec = rec.b ++ show rec.a application: f (a = 123, b = "abc") So now you think "Okay, but how about naming it?". Well, not a problem at all - use the existingtype-construct: type TheRecord = (a :: Int, b :: String) Now, about the avoidance of intermediate types: type Person = (name :: String, phone :: (country :: Int, area :: Int, number :: Int)) See? No need to declare separate types for inner values. But, of course, if you need, you still can: type Phone = (country :: Int, area :: Int, number :: Int)type Person = (name :: String, phone :: Phone) We can nicely access the deeply nested fields, e.g.: personCountryCode :: Person -> IntpersonCountryCode person = person.phone.country Okay. What about the type ambiguity? E.g., in the following the Person is actually the same type asCompany: type Person = (name :: String, phone :: Phone)type Company = (name :: String, phone :: Phone) Easily solvable with a help of newtype: newtype Person = Person (name :: String, phone :: Phone)newtype Company = Company (name :: String, phone :: Phone) What about ADTs? Again, easy: data Product = Tea (brand :: Company) | Milk (brand :: Company, fatness :: Float) Now, the beautiful fact: This solution does not conflict with any existing feature of Haskell! As the examples show, it easily fits into the language as an extension. It can peacefully coexist with the existing record system of ADTs. Hence a complete backwards compatibility with old codebase. There's also a potential for many other additional features. <#links>Links - Source of this proposal <https://gist.github.com/nikita-volkov/6977841> .

5 8

proposal for trailing comma and semicolon
by Garrett Mitchener 19 Aug '13

19 Aug '13

There's a weird idiom that I see all the time in Haskell code where coders put commas at the beginning of lines: data Thing = Thing { x :: Int ,y :: Int ,z :: Int ,foo :: String } ... items = [ "red" ,"blue" ,"green" ] and it's pretty clear that the reason for this is that it's easier to comment out the last item by prefixing -- items = [ "red" ,"blue" -- ,"green" ] instead of items = [ "red", "blue" -- , -- "green" ] The same sort of thing shows up with semicolons sometimes too let { x = 1 ;y = 2 ;z = 3 } in However, this punctuation-at-the-front just seems wrong. It ultimately comes from using , as a separator rather than a terminator in the syntax of sequences. But Python has this nifty quirk where you can leave a comma after the last item in a sequence, so that the following is OK in Python but not in Haskell: items = [ "red", "blue", -- "green" ] Part of why Python does this is to allow room in the syntax for tuples with a single item as in (1,) There might be problems doing this with Haskell tuples because of tuple sections like (,,,) building a 4-tuple from 4 arguments, and where (x,y,) is interpreted as a function that takes another item and produces a three-component tuple. Anyway, this is a "paper cut" in the language that has been bugging me for a while, and since there's now a call for suggestions for Haskell 2014, I thought I'd ask about it. -- Garrett Mitchener

12 13

Proposal: Non-recursive let
by oleg＠okmij.org 11 Jul '13

11 Jul '13

[reposting to Haskell-prime] Jon Fairbairn wrote: > It just changes forgetting to use different variable names because of > recursion (which is currently uniform throughout the language) to > forgetting to use non recursive let instead of let. Let me bring to the record the message I just wrote on Haskell-cafe http://www.haskell.org/pipermail/haskell-cafe/2013-July/109116.html and repeat the example: In OCaml, I can (and often do) write let (x,s) = foo 1 [] in let (y,s) = bar x s in let (z,s) = baz x y s in ... In Haskell I'll have to uniquely number the s's: let (x,s1) = foo 1 [] in let (y,s2) = bar x s1 in let (z,s3) = baz x y s2 in ... and re-number them if I insert a new statement. I once wrote about 50-100 lines of code with the fragment like the above and the only problem was my messing up the numbering (at one place I used s2 where I should've used s3). In the chain of lets, it becomes quite a chore to use different variable names -- especially as one edits the code and adds new let statements. I have also had problems with non-termination, unintended recursion. The problem is not caught statically and leads to looping, which may be quite difficult to debug. Andreas should tell his story. In my OCaml experience, I don't ever remember writing let rec by mistake. Occasionally I write let where let rec is meant, and the type checker very quickly points out a problem (an unbound identifier). No need to debug anything. Incidentally, time and again people ask on the Caml list why 'let' in OCaml is by default non-recursive. The common answer is that the practitioners find in their experience the non-recursive let to be a better default. Recursion should be intended and explicit -- more errors are caught that way. Let me finally disagree with the uniformity principle. It may be uniform to have equi-recursive types. OCaml has equi-recursive types; internally the type checker treats _all_ types as (potentially) equi-recursive. At one point OCaml allowed equi-recursive types in user programs as well. They were introduced for the sake of objects; so the designers felt uniformly warrants to offer them in all circumstances. The users vocally disagreed. Equi-recursive types mask many common type errors, making them much more difficult to find. As the result, OCaml developers broke the uniformity. Now, equi-recursive types may only appear in surface programs in very specific circumstances (where objects or their duals are involved). Basically, the programmer must really intend to use them. Here is an example from the natural language, English. Some verbs go from regular (uniform conjugation) to irregular: http://en.wiktionary.org/wiki/dive

3 3

Proposal: Non-recursive let
by Andreas Abel 10 Jul '13

10 Jul '13

Proposal: add a non-recursive let to the Haskell language. In let' p = e in e' do { ... let' p = e ... } the variables of pattern p are then *not* in scope in e. Reasons for adding a non-recursive let: 1. recursive-let is the source for many non-termination bugs. An instance of such a bug is in the state monad of mtl-2.1 (forgive me, Edward, for quoting this again): http://hackage.haskell.org/packages/archive/mtl/2.1/doc/html/src/Control-Mo… state :: (s -> (a, s)) -> m a state f = do s <- get let ~(a, s) = f s put s return a here, a non-recursive let was meant, the s bound by the let was supposed to be a new state, shadowing the old state. However, since let is recursive, this actually causes a loop. Another instance (cut-down) are let-guards like let Just x | x > 0 = e in x The "x > 0" is understood as an assertion here, documenting an invariant. However, Haskell reads this as let Just x = case () of { () | x > 0 -> e } in x leading to non-termination. A non-recursive version let' Just x | x > 0 = e in x could be interpreted as case e of { Just x | x > 0 -> x } instead, which is meaningful (in contrast to the current interpretation). 2. Connected to 1., a non-recursive let allows for painless shadowing. For instance, the hack do ... x <- return $ f x exploiting non-recursiveness of the <- binding, would be unnecessary, instead we could write do ... let' x = f x NB: In a do-Block, we could drop the keyword let' and simply write do ... x = f x for a non-monadic binding, in accordance to x <- mf x, See also http://www.haskell.org/pipermail/beginners/2009-February/001075.html http://stackoverflow.com/questions/8398607/declaration-order-in-let-binding… PS.: I can work out the details of grammar and semantics if this proposal finds followers. Cheers, Andreas -- Andreas Abel <>< Du bist der geliebte Mensch. Theoretical Computer Science, University of Munich Oettingenstr. 67, D-80538 Munich, GERMANY andreas.abel(a)ifi.lmu.de http://www2.tcs.ifi.lmu.de/~abel/

3 4

Re: In opposition of Functor as super-class of Monad
by Petr P 08 Jul '13

08 Jul '13

Hi, I was thinking lately about the well known problem that Monad is neither Functor nor Applicative. As I understand, it is caused by some historical issues. What I like about Haskell is that it allows to describe very nicely what different objects actually are - something that I find very important for programming. And this issue violates this principle. This has been discussed here more than year ago in http://www.haskell.org/pipermail/haskell-prime/2011-January/003312.html : On 1/4/11 11:24, oleg at okmij.org wrote: > I'd like to argue in opposition of making Functor a super-class of > Monad. I would argue that superclass constraints are not the right > tool for expressing mathematical relationship such that all monads are > functors and applicatives. > > Then argument is practical. It seems that making Functor a superclass > of Monad makes defining new monad instances more of a chore, leading > to code duplication. To me, code duplication is a sign that an > abstraction is missing or misused. > ... The main objections were that it would break existing code and that it would lead to code duplication. The former is serious, the second can be easily solved by standard Haskell, since one can define instance Applicative ... where pure = return (<*>) = ap instance Functor ... where fmap = liftM To address the first objection: AFAIK nobody mentioned the "Default superclass instances" proposal: http://hackage.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances To give an example how it would work: class Applicative f => Monad f where (>>=) :: f a -> (a -> f b) -> f b ... instance Applicative f where ff <*> fs = ff >>= \ f -> fs >>= \ s -> return (f s) ... This says that if somebody defines an instance of Monad it automatically becomes an instance of Applicative as defined in the nested "instance" block. So there is no need to define Applicative/Functor explicitly, making existing code work. Implementing this proposal would allow making Monad to extend Functor and Applicative without breaking existing code. Moreover, this would simplify other things, for example it would be possible to define an instance of Traversable and the instances for Functor and Foldable would be defined implicitly using fmapDefault and foldMapDefault. I'm sure there are many other cases where splitting type classes into a more fine-grained hierarchy would be beneficial, and the main reason against it is simply not to break compatibility with existing code. IMHO this would be worthwhile to consider for some future revision of Haskell. Best regards, Petr Pudlak

8 11

Interfaces - the Golden Path of Haskell?
by Wvv 08 Jul '13

08 Jul '13

This is fairly the same as http://hackage.haskell.org/trac/ghc/ticket/8021 but it's rewritten a little Interfaces Interface is a generalization of the class. Now class become just *instances* of interface For backward compatibility compiler should calculate interface by itself, but it should allow to write interfaces to everybody (more detail at "Maybe Problems"). /-- it is calculated by the Compiler or is written directly/ class interface Monoid (a :: k) where /-- like Typeable/ mempty :: * mappend :: * -> * -> * class Monoid a where ... class Monad m => Monoid m where ... class Arrow c => Monoid c where ... It is easy to use them with functions: foo :: (Monad m => Monoid m , Monad m ) => m a bar :: (Arrow c => Monoid c, Arrow c) => c b a These classes are open, you could lately add class MyClass c => Monoid c where ... We use like Typeable (a :: k) because: () => Monoid a :: * Monad m => Monoid m :: * -> * Arrow c => Monoid c :: * -> * -> * Backward compatibility If class have single constraint, you could write without it. If class have many constraints, you could write without it, if it is empty one. bar :: MonadPlus m => m a <<==>> bar :: () => Monad m => MonadPlus m => m a foo :: Monoid a => a <<==>> foo :: () => Monoid a => a baz :: Monad m => Monoid m => m a <<==>> baz :: () => Monad m => Monoid m => m a Better than superclasses we already have class Num a where ... But we wish to generalize it. It's easy now, we just add: class Additive a where addplus = ... class Multiplicative a where multprod = ... class (Additive a, Multiplicative a) => Num a where (+) = addplus (*) = multprod foo :: (Additive a, Multiplicative a) => Num a => a -> a -> a Maybe Problems 1) If we have already class class Foo a where data F :: ... type S :: ... data family G ... what interface do we have ? Possible reply - no data in the interface. 2) What is the interface of Typeable ? 2.1) What is the interface of class with unwritten interface? Possible reply - the same as class, so it is easy to Compiler. 3) Misfeature - to allow write interface manually Why? You can't change it later. So, it must be deprecated from the beginning. -- View this message in context: http://haskell.1045720.n5.nabble.com/Interfaces-the-Golden-Path-of-Haskell-… Sent from the Haskell - Haskell-prime mailing list archive at Nabble.com.

2 4