- Haskell-prime - Haskell.org

Re: [Haskell] Status of Haskell'?
by Roman Cheplyaka 01 Dec '12

01 Dec '12

* Henning Thielemann <lemming(a)henning-thielemann.de> [2012-12-01 00:37:12+0100] > We should have multiple implementations before standardization. Alternative implementations already exist for lots of extenstions, see http://hackage.haskell.org/trac/haskell-prime/wiki/HaskellExtensions Roman

1 0

Re: backslashes within quotes
by Doug McIlroy 06 Oct '12

06 Oct '12

> "\xe\x1" is unambiguous. There are two things wrong with this solution: (1) It descends to another level of discourse--binary encoding of characters. (2) It does not actually eliminate the need for \&. Consider the string "\SOH1". It cannot be written "\x11", or even "\x011". Doug McIlroy

1 0

Re: backslashes within quotes
by Evan Laforge 05 Oct '12

05 Oct '12

On Fri, Oct 5, 2012 at 1:21 PM, Henrik Nilsson <Henrik.Nilsson(a)nottingham.ac.uk> wrote: > No, it would often (or even usually) not be that much more work, but it > is replacing a very simple and useful mechanism that has worked very > well for two decades with something more complicated, somewhat less > nice, breaking a not insignificant amount of code in the process, for > not much gain as far as I can see. Fair enough, works for me. On Fri, Oct 5, 2012 at 1:01 PM, brandon s allbery kf8nh <allbery.b(a)gmail.com> wrote: > There's a conflict between \SOA and \SO followed by A, which is resolved by > making the latter \SO\&A. Presumably you mean \SOH? "\xe\x1" is unambiguous. On Fri, Oct 5, 2012 at 1:34 PM, Edward Kmett <ekmett(a)gmail.com> wrote: > Implementing the string escapes falls to a small handful of us who write > compilers or tools for working with Haskell, but the proposal seems to be to > just randomly discard functionality that isn't particularly hard to > implement or all that exotic by comparison with other languages. Ok, good enough for me. As I mentioned, it does cause bugs, at least it did for me. Admittedly only one though.

1 0

backslashes within quotes
by Evan Laforge 05 Oct '12

05 Oct '12

The backslash string wrapping feature is a fairly obscure part of haskell syntax, and some tools don't handle it properly (e.g. the built in 'lex' function won't lex such strings properly). It's also not as useful as e.g. python's triple quotes, because you have to suffix and prefix every line with a backslash. As long as you are have to add suffixes and prefixes (i.e. straight cut and paste no longer works), you might as well write it out with (++). In other words, as long as you're applying ('\\':) . (++"\\") you might as well apply ("++ \""++) . (++"\""). And it seems to me that "string literal" ++ "another string" is an easy thing for a compiler to optimize, ghc-core says ghc unsurprisingly has no trouble with it. So it's probably not helpful for performance. IMO it's not very useful for it's intended purpose (embedding multiline strings) because of the \s everywhere. It doesn't seem very widely used, and it adds a little bit of a hassle to parsing. And 'lex' doesn't support it. Any interest in getting rid of it? I would actually be in favor of triple quotes (yeah, I know it can be done with quasi-quotes, but still...), but that's a different issue. Also, it's hardly a big deal, but do we really need \a, \b, \f, and \v? The one time I used one (it was \v) it was a typo and I would have preferred the parse error, instead I got weird output that I didn't notice for a long time. If I really want to, say, ring the terminal bell or do a vertical tab or perhaps send a telegraph, I would be using some library that handles terminal type stuff in a higher level way. Similarly, the \EM, \DC1, etc. codes are probably not pulling their weight. The '70s were 40 years ago! And there's that weird \& thing. Surely cursor control library authors have better ways to construct their magic codes.

4 4

Empty modules
by Reid Barton 20 Sep '12

20 Sep '12

Just a minor inconsistency in the Haskell 2010 report I happened to notice. The BNF in Section 5.1 disallows an empty module module X where {} while the following prose suggests that both the list of import declarations and the list of top-level declarations may be empty. GHC does accept such an empty module and I assume the intent of the Report is that an empty module should be allowed. The Report could be fixed by 1. adding an alternative "{ }" production for body or 2. replacing the bounds on n in impdecls and topdecls by "n >= 0" to match the prose. Then the empty module would match both the second and third alternatives for body but I do not think this is a concern. Regards, Reid Barton

2 1

import Module qualified as
by Christian Maeder 30 Aug '12

30 Aug '12

Hi, my import lists would look much nicer und could be sorted more easily if the keyword "qualified" could be placed before the "as" keyword instead of after "import". Therefore I suggest the alternative syntax: import Data.Map qualified as Map This should be fairly simple to implement, if more users would want it. Note, that this syntax does not work well without "as" since a list of names to be imported usually follows the module name. Also, usually qualified imports are used together with "as" to avoid the long module names. Apart from sorting it would also avoid quirks like _eleven_ spaces in: import qualified Data.Map as Map import Data.Map (Map) Cheers Christian

1 0

minor errors in Haskell 2010 report
by Ramana Kumar 24 Aug '12

24 Aug '12

I recently read http://www.haskell.org/onlinereport/haskell2010/ and noticed a few minor issues in Chapter 5. Is it easy to correct them on that web page for future readers? If not, at least this may be useful for future reports. Apologies if these were known already. Section 5.2, the first sentence of list item 5 says "The form “module M” names the set of all entities that are in scope with both an unqualified name “e” and a qualified name “M.e”." It is not clear that "in scope" here really means "in scope and exported by module M". Section 5.6.1 contains "These modules are not part of Haskell 98, and they cannot be imported separately." I suggest that the "98" be removed.

3 8

Proposal: Scoping rule change
by Lennart Augustsson 27 Jul '12

27 Jul '12

It's not often that one gets the chance to change something as fundamental as the scoping rules of a language. Nevertheless, I would like to propose a change to Haskell's scoping rules. The change is quite simple. As it is, top level entities in a module are in the same scope as all imported entities. I suggest that this is changed to that the entities from the module are in an inner scope and do not clash with imported identifiers. Why? Consider the following snippet module M where import I foo = True Assume this compiles. Now change the module I so it exports something called foo. After this change the module M no longer compiles since (under the current scoping rules) the imported foo clashes with the foo in M. Pros: Module compilation becomes more robust under library changes. Fewer imports with hiding are necessary. Cons: There's the chance that you happen to define a module identifier with the same name as something imported. This will typically lead to a type error, but there is a remote chance it could have the same type. Implementation status: The Mu compiler has used the scoping rule for several years now and it works very well in practice. -- Lennart

7 13

Re: TypeFamilies vs. FunctionalDependencies & type-level recursion
by Anthony Clayden 11 Jun '12

11 Jun '12

> > Sorry for the late reply. Thanks Oleg, I take it the Northern hemisphere is now on academic summer holidays. > > [snip] > > > Finally, I still think most of the "magic" in everything > > we've been talking about boils down to being able to > > have a type variable that can take on any type *except* > > a certain handful. This would allow us to avoid > > overlapping instances of both classes and type families, > would allow us to define TypeEq, etc. Moreover, it would > > be a more direct expression of what programmers intend, > > and so make code easier to read. Such a constraint > cannot be part of the context, because > > Alas, such `type variables' with inequality constraints > are quite complex, and the consequences of their > introduction are murky. Let me illustrate. First of all, > the constraint /~ (to be used as t1 /~ Int) doesn't help > to define TypeEq, etc. because constraints are not used > when selecting an instance. ... Yes indeed we can't use constraints when selecting an instance, several posters have pointed this out. I've suggested we call these inequality 'restraints' rather than 'constraints'. And a different syntax has been proposed, similar to pattern guards: type instance TypeEq a b | a /~ b = HTrue > Instances are selected only by > matching a type to the instance head. Instance selection > based on constraints is quite a change in the type checker > , and is unlikely to be implemented. I agree that selecting instances based on constraints would be abig change, but ... Selecting instances based on inequalities is already implemented in GHC and Hugs. (And has been successfully used for over a decade.) You've used it extensively yourself in the HList work, and much other type-level manipulation (such as IsFunction). Unfortunately, it's not called 'instance selection based on inequalities' (or some such), and its implementation got all mixed up with Functional Dependencies, which to my mind is an orthogonal part of the design. Instance selection based on inequalities is called 'Overlapping Instances'. The difficulty in adopting it into Haskell prime is that it isn't thoroughly specified, and you can currently only use it with FunDeps. To avoid confusion with FunDeps, let's imagine we could use overlapping instances with Type Families: type family HMember e l type instance HMember a HNil = HFalse type instance HMember a (HCons a l') = HTrue type instance HMember a (HCons b l') = HMember a l' Selecting that last instance implies a /~ b. (Otherwise the HTrue instance would be selected). Using inequality restraints, we'd write that last instance as: type instance HMember a (HCons b l') | a /~ b = HMember a l' And by putting an explicit inequality we are in fact avoiding the trouble with overlaps and all their implicit logic: The compiler can check that although the instance heads do overlap, the inequality disambiguates the instances. So type inference could only select one instance at most. I think this could be implemented under the new OutsideIn(X) type inference: Inference for the ordinary instances proceeds as usual. Inequalities give rise to implication terms(as used for GADTs), with the inequality in the antecedent: (a /~ b) implies (TypeEq a b ~ HFalse) As with GADTs, inference needs evidence that a /~ b before applying the consequent. There is no danger of clashing with other instances of TypeEq, because the instance (including inequality) doesn't overlap any of them. (I made some long posts to the Haskell-prime list last month, explaining in more detail, and responding to your TTypeable suggestion.) > > _______________________________________________ > Haskell-prime mailing list > Haskell-prime(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime

7 22

n+k
by S D Swierstra 05 Jun '12

05 Jun '12

In the index of the pdf version of the Haskell2010 report at http://www.haskell.org/definition/haskell2010.pdf there is still mentioning of n+k patterns: page 209 first column, where it says "see also n+k patterns`' (which does not exist) page 305, second column under patterns Doaitse

2 1