Re[2]: List syntax (was: Re: help from the community?)
Hello Brian, Saturday, February 3, 2007, 10:55:52 AM, you wrote: bracket_ (enter a) (exit a) (do b c)-- looks like LISP... this pattern is very typical in my programs and i use '$' before last parameter: postProcess_wrapper command $ \postProcess_processDir deleteFiles - do tempfile_wrapper arcname command deleteFiles pretestArchive $ \temp_arcname - do bracket (archiveCreateRW temp_arcname) (archiveClose) $ \archive - do ... ... for compressionOptions $ \option - case option of 'd':rest | Just md - parseDict rest - dict =: md -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Alleged problems with equational reasoning caused by views
Arie Peterson wrote: J. Garrett Morris wrote (to Bulat Ziganshin): Yes - you've reiterated Wadler's original design, with an automatic creation of a type class. Erwig and Peyton-Jones, _Pattern Guards and Transformational Patterns_ (http://research.microsoft.com/~simonpj/Papers/pat.htm) mentions problems with equational reasoning raised by this approach. I just read this paper, in particular the part about the problems with equational reasoning that come up once you introduce (a certain form of) views. The problems are not unsolvable - see the Pattern Matching Calculus http://www.cas.mcmaster.ca/~kahl/PMC/ for one way to re-introduce equational reasoning in pattern-matching. On another front, I am a big fan of the polar/cartesian 'view' of Complex numbers as being a fundamental test case for full views. In fact, that is quite restricted, one should instead be looking at the following views for R^2: bipolar, cardioid, cassinian, cartesian, elliptic, hyperbolic, invcassinian, invelliptic, logarithmic, logcosh, maxwell, parabolic, polar, rose, and tangent. In three dimensions, one then gets - bipolarcylindrical, bispherical, cardioidal, cardioidcylindrical, casscylindrical, confocalellip, confocalparab, conical, cylindrical, ellcylindrical, ellipsoidal, hypercylindrical, invcasscylindrical, invellcylindrical, invoblspheroidal, invprospheroidal, logcoshcylindrical, logcylindrical, maxwellcylindrical, oblatespheroidal, paraboloidal, paraboloidal2, paracylindrical, prolatespheroidal, rectangular, rosecylindrical, sixsphere, spherical, tangentcylindrical, tangentsphere, and toroidal. REFERENCES: Moon, P. and D.E.Spencer. Field Theory Handbook, 2nd Ed. Berlin: Springer-Verlag, 1971. Spiegel, Murray R. Mathematical Handbook of Formulas and Tables. New York: McGraw Hill Book Company, 1968. 126-130. Jacques ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: List syntax (was: Re: help from the community?)
On 2007 Feb 3, at 2:55 AM, Brian Hulley indited: Of course, but when I said error I meant error with respect to the intentions of the programmer not syntax error detected by the compiler. The problem with your proposal is that if optional trailing commas were allowed, if *I* wrote: (1,2,) by mistake, forgetting to add in the last element, the fact that the compiler would now treat the trailing comma as optional means it would now accept the code as being syntactically ok. If *you* wrote that same code, it *would* correspond to what you meant ie just (1,2), for me it would not because I'd have meant to write something like (1,2,3), so for me, instead of a nice simple syntax error I'd get a confusing type error possibly somewhere else in the code therefore my net productivity would be reduced. However a compiler option could be used to switch the optional trailing comma feature on and off and therefore suit everyone. So far as I can tell, this has not been a problem complained about in other languages that have this feature. I don't know Ruby well enough, but Python far too well, and it just doesn't seem to be a problem in practice. I was about to go through the syntax and construct a proposal that added an optional comma to all those places where commas are used as separates for the elements of groups (such as in deriving, which by the way, already has these other interesting variants: 'deriving ()', 'deriving A', 'deriving (A)' and 'deriving (A,B)'... But looking at the time table for Haskell' that is probably asking too much at this stage... I was going to suggest that a compiler option seems to be the worst of both worlds since it still leaves the existing inconsistencies in the syntax for your case. So again, considering the timing, perhaps the right thing to is submit compiler patches for GHC and Hugs... For a starting volley (names are hard, these are just placeholders): --98-trailing-commas --no-trailing-commas-anywhere --WARN-but-accept-trailing-commas --trailing-commas-anywhere At least hypothetically, I haven't looked at Hugs or GHC yet. :-) I think WARN would go a long way towards relieving the concern that someone might have that they are deliberately (maybe even subconsciously or habitually) using ,) as a way to force themselves to come back and add something later? (since the whole point of the (,,) syntax is that the number of commas is the same as that used when writing out the value in tuple notation) but we can't have a programmer choice when it comes to the constructor: the compiler writer must choose one way or the other. So I don't think there should be a choice in the sugar syntax either. Then if we choose to use (,,) to represent the pair constructor because of the popularity of trailing commas in the applied syntax, this would beg the question of what (,) would represent hence the spectre of introducing 1-tuples... I really don't see that making (,,) represent a pair constructor makes any sense. The whole compressed tuple constructor seems quite sensible in theory, however it is a slippery slope, and the Cons from: http:// hackage.haskell.org/trac/haskell-prime/wiki/TupleSections are rather compelling. Additionally, it doesn't have the correct inductive properties: Prelude (1,2) (1,2) Prelude (,) 1 2 (1,2) Prelude ((1,2),3) ((1,2),3) Prelude ((,),) 1 2 3 interactive:1:5: parse error on input `)' So I don't think there is much point with pretending that I can take an arbitrary tuple sugar and turn it into something functional. It is just _not the case_ that the comma in a list or tuple constructor is an operator. And *if* it were an operator, wouldn't it be a binary operator so that ( 1, 2, 3 ) would be equal to either ( (1, 2), 3 ) or ( 1, (2, 3) ) ??? No, it isn't, and wouldn't be else you couldn't utter nested tuples with sugar. ;-) Instead it is a special case of a flat tuple with a magical cascading ',' operators which looks sort of like an operator, but only when you don't focus on it very much, or only when you don't try to apply it as a general mechanism. Isn't a special case which strongly suggests a deeper regular mechanism that actually isn't there a kind of confusion/misleadingness that should be avoided? But this is probably way off topic for Haskell'... Also, I think in maths the convention is to use commas as separators when writing down coordinates etc. ??? I don't quite get the applicability here... Perhaps it is not applicable, but I thought a guiding principle of Haskell syntax was to try and stay as close to normal mathematical notation where possible, and I remember learning 2d coordinates in school as (x,y) not (x,y,). Again, you wouldn't have to use (1,2,) if you didn't want to. The medium has changed. We are writing programs with a ease not available in the preceding centuries of
Re: List syntax (was: Re: help from the community?)
Douglas Philips wrote: On 2007 Feb 3, at 2:55 AM, Brian Hulley indited: I know, I find the need to manually delete and insert commas extremely tedious as well. This is why I proposed: ... I like that. (I haven't done enough analysis on the layout part of the grammar to personally make sure it is ok.) The #( sugar ... Bulat Ziganshin wrote: Saturday, February 3, 2007, 10:55:52 AM, you wrote: bracket_ (enter a) (exit a) (do b c)-- looks like LISP... this pattern is very typical in my programs and i use '$' before last parameter I've written more details (and made some improvements to my original idea) at http://www.haskell.org/haskellwiki/Accessible_layout_proposal Brian. -- http://www.metamilk.com ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
self moderation (or, what is Haskell' about)
Folks, We all love to talk about fun and exciting new things, and I really don't like to change the subject, as it were, of a mailing list conversation unless it's very necessary. This list is unmoderated, and will stay unmoderated. Anyone can post whatever they want, and it's up to the community of the list to decide what's appropriate and what's off topic. If you see stuff that you think is off topic, please invite that discussion to move over to haskell-cafe or what-have-you. If you start a discussion about something core to Haskell', especially the definitely in topics, and the conversation wanders into strange and unknown territory, please, please re-focus your thread to get back to the important topics. Start a new thread if necessary with a summary of the discussion so far and the open questions. We've had a lot of people unsubscribing from the list in the last few days, for what it's worth. People get a mistaken impression about What Haskell' is about based on the discussions of the list, and sometimes it scares people :) So just be aware that the unmoderated list is _not_ a good way to get a sense of what's going on in Haskell'. Watch for announcements from the committee and requests for help from me and others for actually writing the report. Also, keep an eye on the status page of the wiki: http://hackage.haskell.org/trac/haskell-prime peace, isaac ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: List syntax (was: Re: help from the community?)
On 2/3/07, Brian Hulley [EMAIL PROTECTED] wrote: Of course, but when I said error I meant error with respect to the intentions of the programmer not syntax error detected by the compiler. The problem with your proposal is that if optional trailing commas were allowed, if *I* wrote: (1,2,) by mistake, forgetting to add in the last element, the fact that the compiler would now treat the trailing comma as optional means it would now accept the code as being syntactically ok. And invariably your code would fail to typecheck. That makes this a lot safer for tuples than for lists, for example. -- Taral [EMAIL PROTECTED] You can't prove anything. -- Gödel's Incompetence Theorem ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: rank-2 vs. arbitrary rank types
Hello, (I'll respond on this thread as it seems more appropriate) Simon PJ's says: * Rank-N is really no harder to implement than rank-2. The Practical type inference.. paper gives every line of code required. The design is certainly much cleaner and less ad-hoc than GHC's old rank-2 design, which I dumped with considerable relief. I am not too concerned about the difficulty of implementation, although it seems to me that implementing the rank-2 extension requires a much smaller change to an existing Haskell 98 type checker. My main worry about the rank-N design is that (at least for me) it requres a fairly good understanding of the type checking/inference _algorithm_ to understand why a program is accepted or rejected. Off the top of my head, here is an example (using GHC 6.4.2): g :: (forall a. Ord a = a - a) - Char g = \_ - 'a' -- OK g = g -- OK g = undefined -- not OK Simon PJ says: * I think it'd be a pity to have an arbitrary rank-2 restriction. Rank-2 allows you to abstract over a polymorphic function. Well, it's no too long before you startwanting to abstract over a rank-2 function, and there you are. I don't think that the rank-N system is any more expressive then the rank-2 one. The reason is that by placing a polymorphic value in a datatype we can decrese its rank. In this way we can reduce a program of any rank to just rank-2. So it seems that the issue is one of software engineering---perhaps defining all these extra types is a burden? In my experience, defining the datatypes actually makes the program easier to understand (of course, this is subjective) because I find it difficult to parse all the nested forall to the left of arrows, and see where the parens end (I susupect that this is related to Simon's next point). In any case, both systems require the programmer to communicate the schemes of polymorphic values to the type checker, but the rank-2 proposal uses construcotrs for this purpose, while the rank-N uses type signatures Simon PJ says: * The ability to put foralls *after* a function arrow is definitely useful, especially when type synonyms are involved. Thus type T = forall a. a-a f :: T - T We should consider this ability part of the rank-N proposal. The Practical type inference paper deal smoothly with such types. GHC's rank-2 design had an arbitrary and unsatisfactory forall-hoisting mechanism which I hated. There seem to be two issues here: 1) Allow 'forall's to the right of function arrows. This appears to be independent of the rank-2/N issue because these 'forall' do not increase the rank of a function, so it could work in either system (I have never really needed this though). 2) Allow type synonyms to name schemes, not just types. I can see that this would be quite useful if we program in the rank-N style as it avoids the (human) parsing difficulties that I mentioned while responing to the previous point. On the other hand, the following seems just as easy: newtype T = T (forall a. a - a) f (T x) = ... Simon PJ says: * For Haskell Prime we should not even consider option 3. I'm far from convinced that GHC is occupying a good point in the design space; the bug that Ashley points out (Trac #1123) is a good example. We just don't know enough about (type inference for) impredicativity. This is good to know because it narrows our choices! On the other hand, it is a bit unfortunate that we do not have a current implementation that implements the proposed rank-N extension. I have been using GHC 6.4.2 as an example of the non-boxy version of the rank-N proposal, is this reasonable? Simon PJ says: In short, Rank-N is a clear winner in my view. I am not convinced. It seems to me that the higher rank polymorphism extension is still under active research---after only 1 major version of existsince, GHC has already changed the way it implements it, and MLF seems to have some interesting ideas too. So I think that for the purposes of Haskell' the rank-2 extension is much more appropriate: it gives us all the extra expressive power that we need, at very little cost to both programmers and implementors (and perhaps a higher cost to Haskell semanticists, which we should not forget!). And now it is time for lunch! :) -Iavor ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: help from the community?
On Mon, Jan 29, 2007 at 10:08:59AM +0100, Andres Loeh wrote: I didn't fully understand this requirement. If Haskell-prime gets rank-2 or rank-n types, then do we need to restrict constructors in this way? Ok, this really boils down to the question of whether we do rank-2 or rank-n types. I'm biased, because I actually use rank-n types frequently, and feel somewhat limited by the rank-2 restrictions. I don't know how many people actually do, though. I can understand Iavor's points that rank-2 might be easier to explain, but at least GHC's rank-n extension has a very detailed paper explaining it, so I guess it's one of the better documented extensions. I would say there is not much point in doing just rank-2. Once you know how to do rank-n (and we do, thanks to SPJ's great paper) then it is just as easy to implement as rank-2. Perhaps even moreso since it is a rather elegant general change to the type inferencer rather than a special case. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
