- Haskell-prime - Haskell.org

String literals
by Lennart Augustsson 14 Nov '06

14 Nov '06

I think it's time that string literals got overloaded just like numeric literals. There are several reasons for this. One reason is the new fast string libraries. They are great, but string literals don't work; you need to pack them first. Another reason is the increasing use of Haskell for DSELs. In a DSEL you might want string literals to have a different type than the ordinary String. I have not implemented anything yet, but I would like to see something along the lines of the following: class IsString s where fromString :: String -> s instance IsString String where fromString = id The instance declaration is not allowed in Haskell-98, but it can be rewritten as class IsChar c where -- Make this class local to it's defining module fromChar :: Char -> c instance IsChar Char where fromChar = id instance (IsChar c) => IsString [c] where fromString = map fromChar And, like with numeric literals, any string literal will then have an implicit fromString insert to make the right conversion. My guess is that the defaulting mechanism needs to be extended to default to the String type as well, or we'll get some ambiguous expressions. Any thoughts? -- Lennart

8 15

String literals
by Rohan Drape 13 Nov '06

13 Nov '06

On Mon Nov 13 12:27:08 EST 2006, Simon Peyton-Jones wrote: > In my experience I've seen more requests for overloaded *Boolean* > literals than strings. In a Fran context, for example. Has there been discussion of the related issue, described in a Pan paper as 'Unfortunately, the Bool type is wired into the signatures of operations like >= and ||.'? (I searched the trac but couldn't find it?) It seems common to have to write something like: class OrdE a where (>*) :: a -> a -> a etc. While for finite signals both have meaning, ie. [1,2,3] > [1,2,1] == True [1,2,3] >* [1,2,1] == [False,False,True] for infinite signals '>' is often a nonsense, and if these are the primary type it'd be nice to write '>' for '>*'. Regards, Rohan

1 1

Annotation system for Haskell
by Bulat Ziganshin 13 Nov '06

13 Nov '06

Both Java and C# provides annotations that can be used to pass some additional information about code to around-language tools and queried at program runtime via Reflection API: [AuthorAttribute ("Ben Albahari")] class A { [Localizable(true)] public String Text { get {return text; } ... } } in the last poll for Haskell', it was widely noted that some form of attribute (annotation) system for Haskell will be great, although there is no any design yet. i think that i've found rather good one: 1. Attributes must be available at run-time via some library that uses RTS-provided information, at compile-time for TemplateHaskell-like language extensions using appropriate APIs, and for 3rd-party tools like DrIFT using database generated by compiler during compilation process 2. Attributes are linked to _entities_, which includes packages, modules, values, types, classes and instances. Entity can be found by specifying its _path_, say "package Foo -> module M -> class Eq -> value (==)". Of course this path on practice may be written just as "Foo:M:Eq:(==)". Because almost any module imports class Eq from Prelude, we can find the very same entity by a number of various paths, including "Base:Data.List:Eq:(==)" and "stm:Control.Concurrent.STM:Eq:(==)". If module A imports module B qualified, then path may look as "Foo:A:B.f". Of course, we will also need some way to get "current" package/module name 3. It should be also possible to _enumerate_ all sub-entities of given entity or all attributes of entity. I think that we should provide both ability to enumerate all entities _available_ inside module and to enumerate all entities _defined_ in the module 4. Each entity has a list of named attributes. We should provide a way to define new attribute name together with its "sort". Using Haskell type to define this "sort" looks like a natural solution: [Declare Author :: String] [Declare Deriving :: [String]] [Author "Bulat"] data T = X | Y [^Deriving ["Eq","Ord"]] 5. Then, using a path to entity and attribute's name, one can easily get attribute value: getAttr "Foo:M:T" "Author". Simplest solution is just to return String representation of attribute value, leaving to programmer the job of using "read" to convert this String value into right type I don't consider this in deeper details, but some form of dynamic typing (Typeable/Data class) can also be used. Ideal solution will be to allow programmer to define his own datatypes of attributes which then may be used _both_ instead of [Declare] statements above and as result type for getAttr function, say: data MyAttrs = Author String | Deriving [String] deriving (Attribute) [Author "Bulat"] data T = X | Y [^Deriving ["Eq","Ord"]] use_reflection_api = case getAttr (CurrentPackage ++ ":" ++ CurrentModule ++ ":T") "Author" of Author str -> str In this scenario, standard (predefined) attributes may be just imported as part of Prelude, and user-defined attributes may be defined in current or imported module But while this way greatly simplifies and makes almost type-safe the most common case - using of well-known attributes, it should also be possible to keep 2 features: 1) ability to declare new attribute types inside a module and use these new attributes immediately inside the same module 2) ability to enumerate and get values of attributes of unknown types. imagine, for example, attribute browsing tool 6. Returning to compiler/3rd-party tools interaction, we can now say that attributes database for each module should be build during compilation of this module. It is something very like .hi file, one per each module compiled, but for external consumption. It looks natural to use XML format here, so the entity path will be translated into the path of appropriate xml file and xml path inside the file. Information in this file don't limited to the attributes provided by module writers, it can also contains any information compiler may provide (types of values, code metrics, options used when compiling module) and 3rd-party tools can also add their own information here it seems that also some indexing/xml merging tools should arise at some moment to speed up access to this database, especially to databases of installed packages -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

1 1

RE: Re: [Haskell-cafe] Fractional/negative fixity?
by Simon Marlow 09 Nov '06

09 Nov '06

Nicolas Frisby wrote: > Let's remember that if something is broke, it's only _right_ to _fix_ > it. I patiently waited for someone else to make that pun. > > Understanding the language won't be much harder, but understanding > fixity declarations will become a task. Consider: > > infixl -1.7521 -- what and why? > > As the operator space becomes more dense, negative and fractional > fixities are going to become more obfuscated. The negative and > fractional fixities will satisfy a number purposes well, but they will > also be abused and lead to confusion. > > This smells like a wart growing on a wart to me. All these are valid points. However, given that we can't completely redesign, implement and test a new fixity system in time for Haskell', it makes sense to make a simple change that unambiguously improves the current system, and is no more difficult to implement (in fact, I bet it adds zero lines of code to the compiler). Cheers, Simon > Nick > > On 11/7/06, David House <dmhouse(a)gmail.com> wrote: >> On 07/11/06, Jon Fairbairn <jon.fairbairn(a)cl.cam.ac.uk> wrote: >>> I must say though, that I don't like the reasoning that we >>> can put in fractional fixities because it's a small >>> change. The way to hell is through a series of small >>> steps. If using integers to express fixities is a bit of a >>> hack, switching to rational numbers is a hack on top of a >>> hack. >> >> Well, It's a _conceptually_ simple idea, one that doesn't make >> understanding the language much harder. >> >> Also, it provides an infinite space for fixities. I think the problem >> 'binds tighter than X but not as tight as Y', where X and Y are only >> fixity integer apart is somewhat common, and this would fix it. It >> would allow for extensibility into the future, where the operator >> space will only become more dense, and maintaining a complete order >> with only 10 integers to play will become more and more difficult. >> Allowing an infinite amount of operators to come between any two >> operators sounds like a solid design decision to me. >> >> -- >> -David House, dmhouse(a)gmail.com >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe(a)haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe

3 2

Re[4]: [Haskell-cafe] Fractional/negative fixity?
by Bulat Ziganshin 08 Nov '06

08 Nov '06

Hello Nicolas, Wednesday, November 8, 2006, 1:25:23 AM, you wrote: > prec ?? < $ > over-specification). You want ?? to bind more tightly than does $; > that's exactly what this approach would let you specify. and how then compiler will guess that is relational priority of this operator comparing to '$!' ? :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

3 2

lambda-match vs PMC
by Claus Reinke 07 Nov '06

07 Nov '06

It is encouraging that separate groups have come to similar approaches wrt to more modular pattern match facilities (though perhaps it isn't all that surprising, eg, my own musings on this topic started after one of the early functional logic programming high periods, in the early 1990s, and have since been shaped by the developments in monadic and type class programming in Haskell; PMC seems to have come from a rewriting background, shaped by monadic semantics and type theory; these would imply the same influences, moderated via different communities?). There are, however, some differences that might be worth further inspection. Referring to http://www.cas.mcmaster.ca/~kahl/PMC/ , and especially to the MPC 2006 paper, in no particular order, with no claim to completeness (and please read comments like "odd" as purely subjective, reflecting only my personal reactions as I'm trying to figure out the relation!-): - matchings are not first-class expressions in PMC the only syntactically correct way to mention a matching in an expression is inside a splice ( {| match |} ). this is fairly surprising given the aims of PMC, as one would expect operations on matchings, matchings as parameters and results of functions, etc. .. until one notices that not only the operations on matchings, but - *all* the interesting action in PMC is at the level of matchings, not at the level of expressions lambda-abstraction doesn't even exist at expression level, but is replaced by spliced matching; application exists, but is not needed, because (f e) = {| e |> {| f |} |} (unless I'm mistaken?) if one eliminated the oddity of having two applications, but only one abstraction, the category of expressions would be nearly empty, apart from constructor terms, and the separation of expressions and matchings seems needed only to support conversions between the two: {| _ |} :: Match -> Expression ^ _ ^ :: Expression -> Match which directly brings up the next oddity, in that there are no such types in PMC: - the difference between matchings and expressions is maintained in the typing contexts/labels, not in the types in spite of the monadic semantics, there are no monads in the type system, and instead of .. |- pattern |> match :: a -> m b (as Haskellers might expect to see), one has .. |M- pattern |> match :: a -> b I was looking into these details because I was trying to compare lambda-match and PMC, and while most of the differences seemed merely cosmetic at first, the one difference I couldn't account for was that PMC examples seemed to imply an implicit flattening of the monadic type structure, whereas I had to join nested lambda-matches explicitly (I would find the ability to join nested matchings quite useful on occasion, but I fail to see how this could be done implicitly/ automatically, unless by giving up the ability to express nested matches). if I now understand all these items correctly in combination, PMC is a flattened monadic framework, ie., one cannot even construct the equivalent of a ( <nested> :: m (m a))? or am I missing the obvious?-) cheers, claus ps. after reading the MPC 2006 paper, I have to support the referees' recommendation: as one of many who only occasionally dive into the most shallow parts of category theory, I don't find the monadic semantics in its current presentation helpful. A "running commentary" in computational lambda-calculus, as apparently suggested by the referees, would have made all the difference (I think, because that kind of presentation usually translates easily into Haskell;-). As it stands, I fear you are limiting your audience needlessly. -- <interactive>:1:0:-) Couldn't match `Categories' against `Haskell' Expected type: Haskell Inferred type: Categories In the first argument of `readPaper', namely `PMC_MPC2006' In the definition of `it' : it = readPaper PMC_MPC2006

2 3

Re: Fractional/negative fixity?
by Dan Weston 07 Nov '06

07 Nov '06

I started this e-mail thread on HaskellCafe instead of HaskellPrime because it was minimal, backwards-compatible, valid Haskell 98 (or very nearly so) and could go (now) into GHC if someone saw fit to put it in. > If you think C++ is not overly complicated, just what is a protected > abstract virtual base pure virtual private destructor, and when was > the last time you needed one? > -- Tom Cargil, C++ Journal The above was not a proposal for Haskell'. > Proposers of new [C++] features should be required to donate a kidney. > That would - Jim [Waldo] pointed out - make people think hard before > proposing, and even people without any sense would propose at most two > extensions. > -- Bjarne Stroustrup, creator of C++ But at the risk of losing a kidney... Here's where I think Haskell 98 got it wrong: "A fixity declaration may appear anywhere that a type signature appears and, like a type signature, declares a property of a particular operator." Like a type signature? A type signature has semantic value, fixity does not. In principle, neither does the name that a lambda abstraction is bound to in top-level definitions, but we are stuck with linkers that know about names. They don't know about fixity. Operator precedence is a purely syntactic device for people (like me) who hate parentheses. Its "scope" is essentially local to the attention span of a human being (i.e. a single module). A preprocessor can parethesize code to eliminate the need for fixity. I hate chasing other modules looking up operator fixity and would rather just specify it myself: What if we could remap fixity on import: -- (MyModule.???) fixity is 4, exported as its default... import MyModule((???)) -- But in this module I prefer 5... -- This fixity is *not* exported! infix 5 ??? Modules that import this module get the default fixity from the source. Summary: fixity at definition is exported, fixity on import is locally remapped but not reexported. > Better is the enemy of the good > -- Voltaire Simple, powerful, minimal. Any takers? Dan Dan Weston wrote: > Here's an idea that (I think) is useful and backwards compatible: > fractional and negative fixity. > > There have been 3 separate times where I've wanted an operator just > above 0 ($) but less than 1 (>>= or >>>), or else just below 0 (like a > superlow $$) > > infix 0.5 ??? > infix -1 $$ > > The only change would be internal to compiler, wouldn't it? Since fixity > is just syntactic sugar, there should be no semantic difficulties. > > Dan >

1 0

patch applied (haskell-prime-report): fix line-comment syntax to not consider ' --:' as a comment
by Simon Marlow 07 Nov '06

07 Nov '06

Tue Nov 7 08:22:46 PST 2006 Simon Marlow <simonmar(a)microsoft.com> * fix line-comment syntax to not consider '--:' as a comment See LineCommentSyntax on the wiki, ticket #42 M ./report/syntax-lexical.verb -1 +1

2 1

patch applied (haskell-prime-report): subsection needs to be interpreted by sh
by Simon Marlow 07 Nov '06

07 Nov '06

Tue Nov 7 08:13:22 PST 2006 Simon Marlow <simonmar(a)microsoft.com> * subsection needs to be interpreted by sh M ./report/Makefile -1 +1

1 0

patch applied (haskell-prime-report): update to compile with recent Haskell compilers
by Simon Marlow 07 Nov '06

07 Nov '06

Tue Nov 7 08:11:17 PST 2006 Simon Marlow <simonmar(a)microsoft.com> * update to compile with recent Haskell compilers M ./tools/tex.hs -5 +3

1 0