November 2006 - Haskell-prime

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 08 Nov '06

08 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 08 Nov '06

08 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

patch applied (haskell-prime-report): make it work with recent GHCs
by Simon Marlow 07 Nov '06

07 Nov '06

Tue Nov 7 08:10:45 PST 2006 Simon Marlow <simonmar(a)microsoft.com> * make it work with recent GHCs M ./tools/Makefile -3 +2

1 0

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

07 Nov '06

Hello Henning, Monday, November 6, 2006, 1:27:54 PM, you wrote: >> print msg `on` mode==debug >> >> but failed because my code frequently contains '$' and there is no way >> to define operation with a lower precedence > This could be solved by the solutions proposed in this thread: > > http://www.haskell.org/pipermail/haskell-cafe/2006-October/018923.html it's too complex for my purposes. -1 priority is enough -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

3 2

Importing and Exporting Instance Declarations
by Bas van Dijk 04 Nov '06

04 Nov '06

Hello, Can anybody explain or point me to previous discussions about why it isn't allowed to import and export instance declarations? See: section 5.4 of http://haskell.org/onlinereport/modules.html I don't want to propose this for Haskell' (yet) because I think there has to be some very good reasons why this seemingly very obvious feature is missing. regards, Bas van Dijk

2 1

Re: Proposal for stand-alone deriving declarations?
by John Hughes 03 Nov '06

03 Nov '06

What I implemented in GHC is an extension of the proposal below. The proposal just mentions: deriving Class for Type In GHC I also added a form for newtype deriving of multi-parameter type classes: deriving (Class t1 ... tn) for Type I think that it's close to what we ended up with when talking about it at the Hackathon. My intuition about this syntax is that except for the "for Type" part, it looks the same as a normal deriving clause. The "for" part is just there to connect it to a data/newtype declaration. This lets it pretty much use the normal code for deriving declarations. Stand-alone deriving declarations are currently a little bit weaker than normal deriving clauses, since the current implementation does not let you reference the type arguments of a newtype in the arguments of an MPTC. See my response to Bulat on cvs-ghc(a)haskell.org for more details. /Björn > > > A suggestion re syntax: With the newtype-deriving extension, the instances named in a deriving clause are not just class names, but partial applications of class names to all but the last argument. Why all but the last one? Because the last one is the type being defined. Once deriving clauses are separated from type definitions, then there is no type being defined any more--hence the need for "for Type" in your syntax, and the introduction of another keyword. But why single out one class parameter, once deriving clauses are separated from type definitions? Why not simply write the FULL application of the class in the deriving list? Thus: deriving (Eq Foo, Ord Foo) instead of deriving (Eq, Ord) for Foo I find the former syntax clearer and more readable, actually. John

10 20