RE: [Haskell] page renaming on the Haskell Wiki
Sounds good to me. I wonder whether the haskell home page http://haskell.org should say something like "This entire site is a Wiki, and is maintained by its users. To find out how to contribute, go here", where "here" gives guidance about logging in, and your page-naming guidelines? Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wolfgang | Jeltsch | Sent: 20 February 2006 23:51 | To: haskell@haskell.org | Subject: [Haskell] page renaming on the Haskell Wiki | | Hello, | | I just renamed several wiki pages. One reason for this renaming was the | inconsistent capitalization of page titles. The thread starting with | http://www.haskell.org//pipermail/haskell/2006-January/017485.html contains | some background of this renaming. | | I think that a consistent and sensible naming of pages of the Haskell Wiki is | very important. Since no further opinions were given concerning page naming | and late page renamings might be inconvenient for wiki users, I decided to do | this page renaming now, according to what was said in the above-mentioned | thread and to what I thought was sensible. | | I have put some further information about the renaming on the wiki itself | under http://haskell.org/haskellwiki/User:Wolfgang_Jeltsch/Page_renaming. | Maybe the rationale for page titles given there can server as a basis for a | kind of standard for Haskell Wiki page names? | | I'm open to comments. | | Best wishes, | Wolfgang | ___ | Haskell mailing list | Haskell@haskell.org | http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] PPDP'06 -- Call for Papers
[Apologies for multiple copies] Preliminary Call for Papers: PPDP 2006 Eighth ACM-SIGPLAN International Symposium on Principles and Practice of Declarative Programming Venice, Italy, 10-12 July, 2006 IMPORTANT DATES Submission 15 March 2006 Notification22 April 2006 WEB SITES: PPDP 2006: http://www.dsi.unive.it/ppdp2006/ PPDP: http://pauillac.inria.fr/~fages/PPDP/ SCOPE OF THE CONFERENCE: PPDP 2006 aims to provide a forum that brings together those in the declarative programming communities, including those working in the logic, constraint and functional programming paradigms, but also embracing a variety of other paradigms such as visual programming, executable specification languages, database languages, AI languages and knowledge representation languages used, for example, in the "semantic web". The goal is to stimulate research in the use of logical formalisms and methods for specifying, performing, and analyzing computations, and to stimulate cross-fertilization by including work from one community that could be of particular interest and relevance to the others. Topics of more specific interest are enhancements to such formalisms with mechanisms for mobility, modularity, concurrency, object-orientation, security, and static analysis. At the level of methodology, the use of logic-based principles in the design of tools for program development, analysis, and verification relative to all declarative paradigms is of interest. Papers related to the use of declarative paradigms and tools in industry and education are especially solicited. This list is not exhaustive: submissions related to new and interesting ideas relating broadly to declarative programming are encouraged. Prospective authors are encouraged to communicate with the Program Chair about the suitability of a specific topic. TOPICS (Not exhaustive): Logic, Constraint, and Functional Programming; Database, AI, and Knowledge Representation Languages; Visual Programming; Executable Specification Languages; Applications of Declarative Programming; Methodologies for Program Design and Development; Declarative Aspects of Object-Oriented Programming; Concurrent Extensions to Declarative Languages; Declarative Mobile Computing; Integration of Paradigms; Proof Theoretic and Semantic Foundations; Type and Module Systems; Program Analysis and Verification; Program Transformation; Abstract Machines and Compilation; Programming Environments EVALUATION OF SUBMISSIONS: Submitted papers will be judged on the basis of significance, relevance, correctness, originality, and clarity. They should include a clear identification of what has been accomplished and why it is significant. They must describe original, previously unpublished work that has not been simultaneously submitted for publication elsewhere. Authors who wish to provide additional material to the reviewers beyond the 12-page limit can do so in clearly marked appendices: reviewers are not required to read such appendices. Submissions that do not meet these guidelines may not be considered. PROCEEDINGS: Proceedings will be published by ACM Press. ACM formatting guidelines are available online, along with formatting templates or style files for LaTeX, Word Perfect, and Word: http://www.acm.org/sigs/pubs/proceed/template.html. Authors of accepted papers will be required to sign the ACM copyright form. RELATED EVENTS: PPDP 2006 will be co-located with the 33rd International Colloquium on Automata, Languages and Programming (ICALP 2006), which will take place 9-16 July 2006. See http://icalp06.dsi.unive.it for more information. CONFERENCE CHAIR: Annalisa Bossi, U. Ca' Foscari di Venezia web: http://www.dsi.unive.it/~bossi/, email: [EMAIL PROTECTED] PROGRAM CHAIR: Michael Maher, National ICT Australia web: http://www.cse.unsw.edu.au/~mmaher, email: [EMAIL PROTECTED] PROGRAM COMMITTEE: Nick Benton (Microsoft Research, UK) Annalisa Bossi (U. Ca' Foscari di Venezia, Italy) Manuel Chakravarty (U. NSW, Australia) Bart Demoen (K. U. Leuven, Belgium) Moreno Falaschi (U. Udine, Italy) Radha Jagadeesan (DePaul U., USA) Bharat Jayaraman (SUNY Buffalo, USA) Yukiyoshi Kameyama (U. Tsukuba, Japan) Andy King (U. Kent, UK) Francois Laburthe (Bouyges, France) David Sands (Chalmers U., Sweden) Christian Schulte (KTH, Sweden) Pascal Van Hentenryck (Brown U., USA) Roland Yap (NUS, Singapore) PREVIOUS PPDP CONFERENCES: Paris (1999), Montreal (2000), Firenze (2001), Pittsburgh (2002), Uppsala (2003), Verona (2004), Lisboa (2005). ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Fast unboxed references for the IO and ST monads
Hello oleg, Wednesday, February 08, 2006, 8:37:55 AM, you wrote: >> I suggest you follow the same scheme as the unboxed array types, and >> have IOURef/STURef types, parameterised over the element type. Of >> course, we should have instances for all of the primitive numeric types >> plus Ptr, ForeignPtr, StablePtr, Bool. opc> Perhaps it may be worth to introduce a class Unpackable as described opc> at the end of opc> http://www.haskell.org/pipermail/haskell-cafe/2004-July/006400.html opc> so we may define STUArray as an instance of MArray, and other similar opc> unpackable things easier? i just implemented this neat idea. this allowed to define all sorts of unboxed arrays and references in just 300 lines of code! for those who are not seen the discussion, it's a brief presentation of implemented facilities: 1. Types IOURef/STURef represent fast alternative to the IORef/STRef types. These "unboxed references" may be used only for simple datatypes, including Bool, Char, Int..Int64, Word..Word64, Float, Double, Ptr, FunPtr, StablePtr, but for these types they are guarantee maximum speed! The unboxed references completely replaces the "Fast Mutable Ints/Words/Bools" modules used before. To use unboxed references instead of boxed ones, you just need to replace IORef/STRef in type declarations to the IOURef/STURef and add the same "U" letter to the names of operations that use these references: main = do (i :: IORef Int) <- newIORef 1 readIORef i >>= print writeIORef i 2 will become: main = do (i :: IOURef Int) <- newIOURef 1 readIOURef i >>= print writeIOURef i 2 The library includes compatibility code that allows to use IOURef/STURef on other Haskell compilers. That allows to debug code that use the unboxed references with Hugs/NHC, and use for the final optimized compilation GHC/JHC. 2. Classes MRef and Var can be used to write monad-independent code that use mutable variables. Class MRef represents monad-independent boxed references, while class Var represents the unboxed ones. You can find examples of their usage in the Streams library. These classes uses functional dependencies, so they are available only in GHC/Hugs. 3. Module GHC.Unboxed also contains implementation of UnboxedArray, UnboxedSTArray and UnboxedIOArray type constructors, what is a full analogues of UArray, STUArray and IOUArray, only much easier to implement. These definitions follow the scheme proposed by Oleg: "instance (Unboxed e) => IArray UnboxedArray e" and so on. 4. You can define new unboxed types. For example, the code that defines "instance Unboxed Bool" can be reused without any modifications for any user-defined enumeration. -- Best regards, Bulatmailto:[EMAIL PROTECTED] Variables.hs Description: Binary data Unboxed.hs Description: Binary data ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Question for the haskell implementors: Arrays, unsafePerformIO, runST
John Meacham <[EMAIL PROTECTED]> wrote: > I generalized this primitive to > > drop__ :: a -> b -> b Also known in the Prelude as "const"... The difference is that you propose it be primitive, with the intention that a clever compiler should not be able to bypass it by inlining its definition and propagating the loss of the first argument outwards. Regards, Malcolm ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Long live Edison
Robert Dockins <[EMAIL PROTECTED]> wrote: > On Feb 20, 2006, at 5:19 PM, [EMAIL PROTECTED] wrote: > > > > Data.Set, Data.Map, Data.Hash and the various Array interfaces are > > all inconsistent in subtle ways, so whatever you do, do not take > > them as the ideal to which Edison should aspire. > > This is all true. The main advantage that the current Data.* APIs > have is that people use them ;-) And AFAIK the only reason people use them is because they are widely distributed, not because they are a perfect design. I certainly have reservations about the Data.* APIs, such as the left bias and so on, and personally preferred the older Data.FiniteMap API. Regards, Malcolm ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] page renaming on the Haskell Wiki
In making such changes, please bear in mind "Cool URIs Don't Change": http://www.w3.org/Provider/Style/URI This isn't to say "don't", but where possible, provide some redirection from the old name to the new name. To be effective, the web relies on stable links, so that references from elsewhere don't fade away. In the end, it is publishers own (presumed) goals in publishing to the Web that are compromised if URIs become inaccessible. #g -- Wolfgang Jeltsch wrote: > Hello, > > I just renamed several wiki pages. One reason for this renaming was the > inconsistent capitalization of page titles. The thread starting with > http://www.haskell.org//pipermail/haskell/2006-January/017485.html contains > some background of this renaming. > > I think that a consistent and sensible naming of pages of the Haskell Wiki is > very important. Since no further opinions were given concerning page naming > and late page renamings might be inconvenient for wiki users, I decided to do > this page renaming now, according to what was said in the above-mentioned > thread and to what I thought was sensible. > > I have put some further information about the renaming on the wiki itself > under http://haskell.org/haskellwiki/User:Wolfgang_Jeltsch/Page_renaming. > Maybe the rationale for page titles given there can server as a basis for a > kind of standard for Haskell Wiki page names? > > I'm open to comments. > > Best wishes, > Wolfgang > ___ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell > -- Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Question for the haskell implementors: Arrays, unsafePerformIO, runST
On Tue, Feb 21, 2006 at 10:15:59AM +, Malcolm Wallace wrote: > John Meacham <[EMAIL PROTECTED]> wrote: > > > I generalized this primitive to > > > > drop__ :: a -> b -> b > > Also known in the Prelude as "const"... well, 'flip const' but yes. > The difference is that you propose it be primitive, with the intention > that a clever compiler should not be able to bypass it by inlining its > definition and propagating the loss of the first argument outwards. sure, well whatever is required on a given compiler to ensure it has the above qualities, which might mean making it a primitive or have it have some compiler-specific pragmas attached. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] CFP Implementation of Functional Languages IFL 2006, Budapest, 4-6, Sep. 2006
FIRST ANNOUNCEMENT and CALL FOR PAPERS ** * 18th International Workshop on* * Implementation and Application of Functional Languages * * IFL 2006 * ** * September 4-6, 2006 * * Budapest, Hungary* * http://plc.inf.elte.hu/ifl2006 * ** * Hosted by the * *Department of Programming Languages and Compilers of* *the Faculty of Informatics at Eotvos Lorand University * ** - IMPORTANT DATES - * July 30th 2006 Registration deadline * Aug 4th 2006 Submission deadline for draft proceedings * Oct 24th 2006 Submission deadline for post-refereeing process * Dec 8th 2006 Notification of acceptance/rejection * Jan 31th 2007 Camera-ready papers Scope and Topics The IFL workshops form a tradition that has lasted for nearly two decades. The aim of these workshops is to bring together researchers actively engaged in the implementation and application of functional and function-based programming languages. They provide an open forum for researchers who wish to present and discuss new ideas and concepts, work in progress, preliminary results, etc. related primarily but not exclusively to the implementation and application of functional languages. Topics of interest include, but are not limited to: * language concepts * concurrent/parallel programming * type checking * concurrent/parallel program execution * compilation techniques * heap management * generic programming techniques * runtime profiling * (abstract) interpretation * performance measurements * automatic program generation * debugging and tracing * (abstract) machine architectures * verification * formal aspects * tools and programming techniques * array processing * demos of well working, useable tools and applications in functional languages Papers on applications demonstrating the suitability of novel ideas in any of the above areas and contributions on related theoretical work are also welcomed. The change of the workshop name adding the term "application", introduced in 2004, is to reflect the broader scope IFL has gained over recent years. Prospective authors are encouraged to submit papers to be published in the draft proceedings and to give presentations at the workshop. All contributions must be written in English, conform to the Springer-Verlag LNCS series format. Attendees at IFL'06 will have an opportunity to submit a revised version of their paper for post-workshop reviewing. Selected papers will be published by Springer Verlag in the well-known Lecture Notes in Computer Science (LNCS) Series, as has been a long-standing tradition for the IFL Workshops. Programme Committee Matthias Blume Toyota Technological Institute, Chicago, USA Zoran Budimac University of Novi Sad, Serbia Andrew Butterfield Trinity College Dublin, Ireland Ralf Hinze University of Bonn, Germany Zoltan Horvath Eotvos Lorand University, Budapest, Hungary (Chair) Tamas Kozsik Eotvos Lorand University, Budapest, Hungary Hans-Wolfgang LoidlLudwig-Maximilians-University Munich, Germany Rita LoogenPhilipps-University Marburg, Germany Frederic Loulergue University of Orleans, France Simon Marlow Microsoft Research, Cambridge, UK Marco Morazan Seton Hall University, New Jersey, USA Yolanda Ortega-Mallen University Complutense of Madrid, Spain Rinus Plasmeijer Radboud University Nijmegen, The Netherlands Jaroslav Poruban Technical University of Kosice, Slovakia Anna Soos Babes-Bolyai University, Cluj-Napoca, Romania Doaitse Swierstra Utrecht University, The Netherlands Peter Thiemann University of Freiburg, Germany German Vidal Technical University of Valencia, Spain Workshop Organization Zoltan Horvath, Viktoria Zsok Department of Programming Languages and Compilers Faculty of Informatics Eotvos Lorand University, Budapest, Hungary Further information Web-site: http://plc.inf.elte.hu/ifl2006/ E-mail: [EMAIL PROTECTED] ___ Haskell mailing list Haskell@haskell.org http://www.haskell.or
Re: [Haskell] Re: IO == ST RealWorld
On Feb 20, 2006, at 5:57 PM, Ben Rudiak-Gould wrote: John Meacham wrote: ST doesn't have exceptions which IO does. It would be no good to make ST pay for the cost of exception handling. GHC handles them behind the scenes (I think?) but in jhc they are explicit and IO is defined as follows: data World__ data IOResult a = FailIO World__ IOError | JustIO World__ a newtype IO a = IO (World__ -> IOResult a) Supposing you had data STResult s a where FailIO :: World__ IOWorld__ -> IOError -> STResult IOWorld__ a JustST :: World__ s -> a -> STResult s a could static analysis then eliminate the test for FailIO in ST code? Only in a very limited way. Nothing can be done with the following code: if checkOK then JustST ... else FailIO ... So we can "optimize away" the JustST from failure-free IO computations, but anything which might possibly fail is problematic. Sadly, IO computations which perform any actual IO must usually admit the possibility of failure, and you actually degrade performance in practice by wrapping things up in an extra constructor, at least compared to a mechanism where failure is propagated by invoking an alternate continuation. (You also have to carefully engineer the strictness of "bind" and of every IO construct in order to make sure that eliminating the constructor is actually a valid transformation and that things don't deadlock, but that's a simple matter of programming...) -Jan-Willem Maessen (who tried a similar experiment back in 1994 or so.) It would be pretty cool if the answer was yes, since it would mean that merging IO and ST would be an optimization instead of a pessimization (the test could also be omitted in IO code that uses only the ST subset). In jhc I suppose this would have to happen late in compilation, when you eliminate unused type parameters. Actually, won't the test for FailIO always be eliminated by the existing points-to analysis? -- Ben ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] page renaming on the Haskell Wiki
Am Dienstag, 21. Februar 2006 10:56 schrieb Graham Klyne: > In making such changes, please bear in mind "Cool URIs Don't Change": > > http://www.w3.org/Provider/Style/URI > > This isn't to say "don't", but where possible, provide some redirection > from the old name to the new name. > > To be effective, the web relies on stable links, so that references from > elsewhere don't fade away. In the end, it is publishers own (presumed) > goals in publishing to the Web that are compromised if URIs become > inaccessible. > > #g Hello again, well, there are certain points in the above-mentioned article which one should really think about. For example, I totally subscribe to the point of view that a URI shouldn't expose implementation details and should therefore not include a path component like "cgi-bin", for example. In a similar regard, we should probably think about removing the path component "haskellwiki" from our URIs since this path component "forces" our site to be a wiki. On the other hand, I think that the above W3C article is far too extreme. It tells you that stability is the most important thing concerning URIs. But I think that this is not true. In my opinion, another very, very important thing is that your URIs are reasonable and your URI-space is well structured. Otherwise you will confuse your users. How should a user know, for example, that one page uses sentence-style capitalization for its title and the other one doesn't. Or look at some URIs they use on the w3.org website: Annotea http://www.w3.org/2001/Annotea/ HTTP http://www.w3.org/Protocols/ Internationalization http://www.w3.org/International/ Patent Policy http://www.w3.org/2004/pp/ This inconsistency seems not very good to me. You cannot plan in advance what naming scheme will be appropriate in 50 years and maybe the one that will be appropriate then won't be appropriate now. I think that "good URIs somethimes have to change". Especially on a wiki where there is no webmaster allocating URIs so that you will often need to "fix things" later. Websites are changing, they are, in a sense, always dynamic. This holds especially for wikis. That said, I'm sure that changing of URIs is not something which should be taken too lightly. At least, one should always provide redirects from the old URI to the new. MediaWiki automatically inserts a respective redirect if you move a page. Alas, MediaWiki's redirects are not really (HTTP) redirects. Instead MediaWiki delivers a page under the redirect's URI which contains the content of the article the redirect points to, together with a note that a redirection took place. So the URI you see in your browser will be the "old" URI. Having said that redirects are important, let me state that, in my opinion, redirects shouldn't live forever. Normally, a redirect introduced by moving a page should be removed after a certain amount of time when nearly everybody had a chance to update his links. Managing a growing set of redirects is just not feasible. Keeping redirects forever also clutters the "All pages" page with lots of old page titles. Best wishes, Wolfgang ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] page renaming on the Haskell Wiki
Am Dienstag, 21. Februar 2006 11:17 schrieb Simon Peyton-Jones: > Sounds good to me. > > I wonder whether the haskell home page http://haskell.org should say > something like > > "This entire site is a Wiki, and is maintained by its users. To find > out how to contribute, go here", > > where "here" gives guidance about logging in, and your page-naming > guidelines? I have done something like this now. Have a look at the second paragraph of the main page. > Simon Best wishes, Wolfgang ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: Question for the haskell implementors: Arrays, unsafePerformIO, runST
John Meacham wrote: On Tue, Feb 21, 2006 at 10:15:59AM +, Malcolm Wallace wrote: John Meacham <[EMAIL PROTECTED]> wrote: I generalized this primitive to drop__ :: a -> b -> b Also known in the Prelude as "const"... well, 'flip const' but yes. The difference is that you propose it be primitive, with the intention that a clever compiler should not be able to bypass it by inlining its definition and propagating the loss of the first argument outwards. sure, well whatever is required on a given compiler to ensure it has the above qualities, which might mean making it a primitive or have it have some compiler-specific pragmas attached. Your drop__ reminds me of GHC's touch#, which is like drop__ in the IO monad. We use it to control lifetimes, eg. inside withForeignPtr. You could implement drop in terms of touch#: drop__ a b = case touch# a realworld# of s -> b I'm not sure about the other way around. Something like "touch# a s = drop__ (a,s) s" looks possible, but is wrong - the compiler can see the same s is returned. touch# compiles to no code at all in GHC, which is what you want, but it does keep its argument alive as far as the GC is concerned - that behaviour isn't necessary (is undesirable?) for drop__. Cheers, Simon ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: IO == ST RealWorld
On Mon, Feb 20, 2006 at 10:57:23PM +, Ben Rudiak-Gould wrote: > could static analysis then eliminate the test for FailIO in ST code? It > would be pretty cool if the answer was yes, since it would mean that > merging IO and ST would be an optimization instead of a pessimization (the > test could also be omitted in IO code that uses only the ST subset). In jhc > I suppose this would have to happen late in compilation, when you eliminate > unused type parameters. Hmm.. not sure, that is an interesting idea, I do do a form of 'early' type analysis to drop branches for types that are never used, but before the whole program is collected it is necessarily conservative so can't find everything. combining that analysis with GADTs might open up some new optimizations. > Actually, won't the test for FailIO always be eliminated by the existing > points-to analysis? Yeah, a lot of them are. but that doesn't happen til very late in the code generation so these FailIOs clutter up the intermediate jhc core code. I am experimenting with using longjmp(2) and setjmp(2) based exceptions in IO. though, I'd eventually like to add true c-- style continuations to grin which should obviate the need for setjmp and longjmp which currently cannot be optimized through all that well. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: Question for the haskell implementors: Arrays, unsafePerformIO, runST
On Tue, Feb 21, 2006 at 11:04:40PM +, Simon Marlow wrote: > Your drop__ reminds me of GHC's touch#, which is like drop__ in the IO > monad. We use it to control lifetimes, eg. inside withForeignPtr. You > could implement drop in terms of touch#: > >drop__ a b = case touch# a realworld# of s -> b Ah, cool. there isn't an optimization that can determine that b is passed through unchanged is there? some sort of core level points-to analysis for instance. > I'm not sure about the other way around. Something like "touch# a s = > drop__ (a,s) s" looks possible, but is wrong - the compiler can see the > same s is returned. Also, drop__ completly disapears when grin is first generated from jhc core and more grin-level optimizations are done that could loose the fact a should exist at least as long as s. some sort of grin-level primitive for touch# would be needed in jhc (or some sort of explicit region annotations? I have not thought enough about those). > touch# compiles to no code at all in GHC, which is what you want, but it > does keep its argument alive as far as the GC is concerned - that > behaviour isn't necessary (is undesirable?) for drop__. I would think undesirable. simply because there is no need and one of drop__s uses is to fine-tune memory management. though, I don't think it makes a big difference in the examples I gave. I think perhaps drop__ might be useful enough to standardize on, if not in haskell' then perhaps as a common convention between ghc and jhc because it solves a couple issues that have come up on the list before in a way that is more lightweight than hypothetical PRAGMAs. I am not attached to the name drop__ BTW, double underscores at the end of a name in jhc are equivalent in intent to # at the end in ghc, it just means "this might be special in some way" but if we were to have a common name, it should be something more descriptive. perhaps `dependingOn` ? > dependingOn :: a -> b -> a > dependingOn = flip drop__ > > f x = ... where > y = foo (z `dependingOn` x) John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] page renaming on the Haskell Wiki
On 2/21/06, Graham Klyne <[EMAIL PROTECTED]> wrote: > In making such changes, please bear in mind "Cool URIs Don't Change": > > http://www.w3.org/Provider/Style/URI > > This isn't to say "don't", but where possible, provide some redirection from > the > old name to the new name. > > To be effective, the web relies on stable links, so that references from > elsewhere don't fade away. In the end, it is publishers own (presumed) goals > in > publishing to the Web that are compromised if URIs become inaccessible. Although, while the wiki is still so new, it's unlikely that there are already links to it so there shouldn't be any harm in moving pages created before there was a clear naming policy established. Furthermore, I think that pages that were initially created by mistake or with misspellings (e.g., "Perforamnce") are fair game for deletion. Davor ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] page renaming on the Haskell Wiki
cubranic: > On 2/21/06, Graham Klyne <[EMAIL PROTECTED]> wrote: > > In making such changes, please bear in mind "Cool URIs Don't Change": > > > > http://www.w3.org/Provider/Style/URI > > > > This isn't to say "don't", but where possible, provide some redirection > > from the > > old name to the new name. > > > > To be effective, the web relies on stable links, so that references from > > elsewhere don't fade away. In the end, it is publishers own (presumed) > > goals in > > publishing to the Web that are compromised if URIs become inaccessible. > > Although, while the wiki is still so new, it's unlikely that there are > already links to it so there shouldn't be any harm in moving pages > created before there was a clear naming policy established. > Furthermore, I think that pages that were initially created by mistake > or with misspellings (e.g., "Perforamnce") are fair game for deletion. Though the renamings (which I agree with) did break some internal links. I'd be hesitant to do large renamings again. -- Don ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
