Re: [Haskell-cafe] Re: Interest in helping w/ Haskell standard
David Roundy [EMAIL PROTECTED] writes: Bah, simple libraries. They don't have to be part of the Standard Prelude. I completely agree. I'd rather decrease the number of libraries defined in the language itself and decouple library standardization from the definition of the language standard. Libraries can much more easily be developed and improved. I'd vote for moving map, null and lookup from Prelude to an explicit List import (like insert already is). They tend to be used by collections (Data.Set, Map etc), which complicates imports or requires unnecessary qualification. Alternatively, as (List.)map and null are very common, use different names for other collections (fmap? isEmpty?). As a general rule, I think libraries shouldn't overload names imported implicitly from the Prelude. (I know it is fashionable to qualify everything this week, but I prefer to be able to use unqualified names occasionally as well). -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Interest in helping w/ Haskell standard
On 15/10/05, Ketil Malde [EMAIL PROTECTED] wrote: David Roundy [EMAIL PROTECTED] writes: Bah, simple libraries. They don't have to be part of the Standard Prelude. I completely agree. I'd rather decrease the number of libraries defined in the language itself and decouple library standardization from the definition of the language standard. Libraries can much more easily be developed and improved. I'd vote for moving map, null and lookup from Prelude to an explicit List import (like insert already is). They tend to be used by collections (Data.Set, Map etc), which complicates imports or requires unnecessary qualification. Alternatively, as (List.)map and null are very common, use different names for other collections (fmap? isEmpty?). As a general rule, I think libraries shouldn't overload names imported implicitly from the Prelude. (I know it is fashionable to qualify everything this week, but I prefer to be able to use unqualified names occasionally as well). -k -- If I haven't seen further, it is by standing in the footprints of giants Or fix the Set is not an instance of Functor problem and then rename fmap to map. :) John Hughes' proposal works, though I don't know if I'd like all the wft's cluttering up my class contexts. I've been thinking of some other ways to solve the problem by extending the kind system (as the problem is that the kind of the type parameter to Set should not really be *, but a subkind thereof consisting of the types satisfying Ord). It looks like this approach should work, but I either need to do more reading or more talking to people knowledgeable about type theory, and the existing implementations in order to completely formalise it. I agree somewhat about the qualified names, but I think in a lot of cases, when things are called the same thing, it is because they are doing the same thing, and so there should be a typeclass for them. - Cale ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Interest in helping w/ Haskell standard
Ketil Malde [EMAIL PROTECTED] writes: David Roundy [EMAIL PROTECTED] writes: Bah, simple libraries. They don't have to be part of the Standard Prelude. I completely agree. I'd rather decrease the number of libraries defined in the language itself and decouple library standardization from the definition of the language standard. Libraries can much more easily be developed and improved. I'd vote for moving map, null and lookup from Prelude to an explicit List import (like insert already is). I hope we decide to reduce the size of the Prelude to the minimum possible. Most of what is currently in there can be more conveniently dumped into libraries. Then we could have one or more standard aggregations of useful libraries, e.g. BeginnersPrelude which has no classes, IntermediatePrelude, and AdvancedPrelude. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Interest in helping w/ Haskell standard
Hello Stephane, Thursday, October 13, 2005, 11:24:30 AM, you wrote: SB As someone who is not an academic researcher and not a student in CS, SB I would like to express a personal opinion; we don't need a new SB standard. To me, Haskell needs more libraries, more users (which means SB more debugging and more documentations), more implementations, of SB course more real applications (darcs did a lot of the success of SB Haskell), so we can read their code, push sysadmins to install SB Haskell, etc. i put just the same opinion 1-2 months ago :))) but i got answer that current Haskell standard are too restrictive and ALL real programs use extensions. we need to standartize these de facto used extensions in order to simplify constructing of libraries and teaching language in universities/courses. we must explicitly declare the language really used in 2005, which is far away from the language used in 1998 -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Re: Interest in helping w/ Haskell standard
Em Qui, 2005-10-13 às 09:47 +0100, Bayley, Alistair escreveu: - * Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. * Is this kind of notice legal in the context of Haskell-Cafe? -- Abraços, marcot mailto:[EMAIL PROTECTED] jabber:[EMAIL PROTECTED] UIN:50599075 MSN:[EMAIL PROTECTED] Telefone:33346720 Celular:91844179 Endereço:Rua Paula Cândido 257/201 Gutierrez 30430-260 Belo Horizonte-MG Brasil signature.asc Description: This is a digitally signed message part smime.p7s Description: S/MIME cryptographic signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Re: Interest in helping w/ Haskell standard
From: Marco Tulio Gontijo e Silva [mailto:[EMAIL PROTECTED] Em Qui, 2005-10-13 às 09:47 +0100, Bayley, Alistair escreveu: * Confidentiality Note: The information contained in this message blah blah blah Is this kind of notice legal in the context of Haskell-Cafe? Sorry, but it's not under my control. My employer's email system is configured to append this to every message, and I suspect that it's not worth the hassle to try to get it removed. Alistair. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Interest in helping w/ Haskell standard
Am Donnerstag, 13. Oktober 2005 13:39 schrieb Stephane Bortzmeyer:
[...]
Regexps and XML are, IMHO, also must haves.
By the way, it should be possible to handle regular expressions in an
Haskell-like way. I always couldn't understand why one has to write regular
expressions as strings which have to be interpreted at runtime. I would
prefer something like this:
identifierRegExp = alpha +++ iterate (alpha ||| digit ||| underscore)
alpha = ('A' `to` 'Z') ||| ('a' `to` 'z')
digit = '0' `to` '9'
underscore = only '_'
What do others think?
Best wishes,
Wolfgang
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Interest in helping w/ Haskell standard
On Fri, 14 Oct 2005, Stephane Bortzmeyer wrote: On Fri, Oct 14, 2005 at 04:20:24PM +0200, Wolfgang Jeltsch [EMAIL PROTECTED] wrote a message of 23 lines which said: By the way, it should be possible to handle regular expressions in an Haskell-like way. If you like so, but as one more possibility, not as the only way. I'm not sure I see the need to do that specifically given the existance of libraries like Parsec? -- [EMAIL PROTECTED] There is no magic bullet. There are, however, plenty of bullets that magically home in on feet when not used in exactly the right circumstances. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Interest in helping w/ Haskell standard
Regexps and XML are, IMHO, also must haves. By the way, it should be possible to handle regular expressions in an Haskell-like way. Harp? :-) http://www.cs.chalmers.se/~d00nibro/harp /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Interest in helping w/ Haskell standard
On Fri, Oct 14, 2005 at 07:15:11PM +, Aaron Denney wrote: On 2005-10-13, Stephane Bortzmeyer [EMAIL PROTECTED] wrote: On Thu, Oct 13, 2005 at 11:29:57AM +, Robin Green [EMAIL PROTECTED] wrote a message of 22 lines which said: ... and, in the case of the Standard Prelude section, or equivalent, a specification of well-understood functions that the spec authors agree should be provided in all implementations. ... (It is, however, one of the must haves for Haskell to be considered for use in production systems.) Regexps and XML are, IMHO, also must haves. Bah, simple libraries. They don't have to be part of the Standard Prelude. I completely agree. I'd rather decrease the number of libraries defined in the language itself and decouple library standardization from the definition of the language standard. Libraries can much more easily be developed and improved. -- David Roundy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Interest in helping w/ Haskell standard
On Fri, Oct 14, 2005 at 03:34:33PM +0100, Jon Fairbairn wrote: On 2005-10-14 at 16:25+0200 Stephane Bortzmeyer wrote: On Fri, Oct 14, 2005 at 04:20:24PM +0200, Wolfgang Jeltsch [EMAIL PROTECTED] wrote a message of 23 lines which said: By the way, it should be possible to handle regular expressions in an Haskell-like way. If you like so, but as one more possibility, not as the only way. I always couldn't understand why one has to write regular expressions as strings Because the language used inside these strings is standard, multi-language, widely used and documented? 10,000 lemmings can't be wrong? Using strings for regexps is a disaster. Not even the syntax of such regexps is checked at compile time. (This was part of the point of my April 1st joke by the way). The language would certainly benefit from the inclusion of regexps the way Wolfgang suggested, but if we really need the short-form syntax (I'm not convinced; it seems pretty much a write only notation), then do it by having special syntax as a shorthand for the proper Haskell. Since Unicode is increasingly adopted, we could just use «regexp» and specify some rules to convert the regexp into Haskell, as ... is meant to stand for '.':'.':'.':[]. my perl-like regexps for haskell package adds (=~) that works very similarly to the perl operator, but is much more flexible since we have so many types to work with rather than just scalar or list context. in any case it uses a typeclass for regexs and what sort of thing they work on. so you could do foo =~ .*foo$ let regex = mkRegex .*foo$ -- so the building of the regex will be shared foo =~ regex o foo =~ (my fancy regex domain specific language) I should cabalize it... John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Interest in helping w/ Haskell standard
As someone who is not an academic researcher and not a student in CS, I would like to express a personal opinion; we don't need a new standard. Maybe you just don't realise how much we do need a new standard! standard. To me, Haskell needs more libraries, more users (which means more debugging and more documentations), Without a standard that everyone uses, debuggers and implementations are useless. course more real applications (darcs did a lot of the success of Haskell) Darcs is NOT written in Haskell, its written in ghc. (ditto Pugs, ditto Yi ...) If people want to standardize things, their time could be, IMHO, best spent by standardizing libraries (I just recently discovered that Text.Regex is not standard and my programs do not run under hugs). Heirarchical libraries, i.e. the whole concept of putting a dot between Text and Regex are NOT in the Haskell standard. This type of thing is the thing that needs standardising. Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Re: Interest in helping w/ Haskell standard
From: Stephane Bortzmeyer [mailto:[EMAIL PROTECTED] As someone who is not an academic researcher and not a student in CS, I would like to express a personal opinion; we don't need a new standard. To me, Haskell needs more libraries, more users (which means more debugging and more documentations), more implementations, of course more real applications (darcs did a lot of the success of Haskell), so we can read their code, push sysadmins to install Haskell, etc. A significant number of Haskell libraries, both user-contributed and compiler-bundled (in the standard library hierarchy), are not written in Haskell98, and rely on a number of (typically well supported) language extensions like multi-parameter type classes + functional dependencies, existential types, hierarchical modules, etc. Some libraries target a specific compiler (often GHC). It should be clear that standardising the popular extensions would make a greater number of compiler-bundled and user-contributed libraries standards compliant, which has the obvious benefit that they can be used with any standardised compiler/interpreter i.e. they become more portable. Alistair. - * Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. * ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Interest in helping w/ Haskell standard
Well, what we already have is a lot of language extensions with varying degrees of support across implementations. GHC is somewhat of a standard in and of itself, and one thing that standardisation efforts bring is a record of what exactly GHC is doing, thus allowing for more and better implementations. Also, Haskell is only as good as it is now because it has been changing, and many options and smart ideas have been explored at each step. I'd personally like to see Haskell grow in all directions - both in practicality and in language features/abstraction. Not every change has to break everything, but sometimes breaking things is worth it if the language comes out better. In basically every case, implementations will almost certainly be able to provide backwards compatibility modes for incompatible changes, at least until things are largely switched over. There are a variety of unsatisfying things about the H98 standard which should be dealt with if Haskell is to be the best language it can be. Dealing with them is a good idea in my opinion (though in many cases it might be better to do this with Haskell 2, depending on what people think). There are some potential extensions I've been discussing lately with Stefan Ljungstrand, one of which is for fixing the issue that, for example Set cannot be made an instance of Functor or Monad, which may turn into concrete proposals sometime soon. Other proposals, like John Meacham's recent class aliasing proposal would be useful in cleaning up the class hierarchy in the Prelude, and making it feel less like all the good infix identifiers are stolen. Also, many people have complained, myself included, about Functor not being a superclass of Monad, and join not being included as a class method of Monad (with default instances going between join and bind). Future proposals aside, the language that people are programming in today is not Haskell 98. Multiparameter typeclasses and functional dependencies are common. I use newtype deriving fairly often (together with monad transformers), and that's not standard. Class methods are not allowed to have types which are typeclass restricted in H98, which, regardless of how often it's actually used, is kind of silly not to allow. Arbitrary rank polymorphism isn't in Haskell 98, which means that things like Control.Monad.ST aren't possible. GADTs are new, but they're a great idea and already in use in major projects such as Pugs. Concurrent and Parallel Haskell aren't standard. I'm sure I've missed things too. Standardising these extensions which people use will help document them in one place rather than a variety of papers, and will help existing code be more portable. If done right, there's no reason that Haskell has to lose users over further standardisation, and cleaning up of previous standards. Transitions can be made smoother by providing backwards compatibility in the implementations for at least a limited amount of time, with warnings to note deprecated usage of the language. New standards shouldn't serve as forks of the language, but as continuations of it. - Cale Gibbard On 13/10/05, Stephane Bortzmeyer [EMAIL PROTECTED] wrote: On Wed, Oct 12, 2005 at 03:39:34PM -0700, Isaac Jones [EMAIL PROTECTED] wrote a message of 30 lines which said: One of the main topics was the perceived need of a new standard, As someone who is not an academic researcher and not a student in CS, I would like to express a personal opinion; we don't need a new standard. To me, Haskell needs more libraries, more users (which means more debugging and more documentations), more implementations, of course more real applications (darcs did a lot of the success of Haskell), so we can read their code, push sysadmins to install Haskell, etc. Most functional programming languages have been killed by the CS effect: the fact that most users are more interested in exploring new areas of computer science than in producing code. Lisp and ML were killed by the explosion of many different and incompatible versions. I am not interested in Haskell++ or OOHaskell or anything like that. If people want to standardize things, their time could be, IMHO, best spent by standardizing libraries (I just recently discovered that Text.Regex is not standard and my programs do not run under hugs). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
