Re: new keyword: infixlr?
Am Freitag, den 10.09.2010, 23:18 +0200 schrieb S. Doaitse Swierstra: On 10 sep 2010, at 20:13, Ian Lynagh wrote: How would the compiler work out which parsing to prefer? Or would it assume that infixlr expressions are best balanced? Yes, that is the idea. To me, it seems weird that optimization should be done at the level of syntax. Note that optimization would only trigger if you write concrete applications of the infix operator, not if you construct them programmatically. Best wishes, Wolfgang ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: One more 'do' pattern
Am Samstag, 28. März 2009 10:52 schrieb Bulat Ziganshin: and i think that no functional GUI library support trees too The development version of Grapefruit already supports list views (and the derived concept of a set view) in a functional style. Tree views can be supported in a similar way. Best wishes, Wolfgang ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Suggestion: Syntactic sugar for Maps!
Am Donnerstag, 27. November 2008 22:14 schrieb Thomas Davie:
On 27 Nov 2008, at 19:59, circ ular wrote:
I suggest Haskell introduce some syntactic sugar for Maps.
Python uses {this: 2, is: 1, a: 1, Map: 1}
Clojure also use braces: {:k1 1 :k2 3} where whitespace is comma but
commas are also allowed.
I find the import Data.Map and then fromList [(hello,1), (there,
2)] or the other form that I forgot(because it is to long!) to be to
long...
So why not {hello: 1, there: 2} ?
In a similar vein, I suggest not only to not do this, but also for
Haskell' to remove syntactic sugar for lists (but keep it for strings)!
I have two (three if you agree with my opinions on other parts of the
language) reasons for this:
1) It's a special case, that doesn't gain anything much. [a,b,c,d] is
actually only one character shorter and not really any clearer than
a:b:c:d:[].
2) Removing it would clear up the ',' character for use in infix
constructors.
3) (requiring you to agree with my opinions about tuples) it would
allow for clearing up the tuple type to be replaced with pairs
instead. (,) could become a *real* infix data constructor for pairs.
This would make us able to recreate tuples simply based on a right
associative (,) constructor. I realise there is a slight issue with
strictness, and (,) introducing more bottoms in a tuple than current
tuples have, but I'm sure a strict version of the (,) constructor
could be created with the same semantics as the current tuple.
Just my 2p
Thanks
Tom Davie
I support this view.
Best wishes,
Wolfgang
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
Re: patch applied (haskell-prime-status): add Make $ left associative, like application
Am Montag, 28. April 2008 06:29 schrieben Sie: Wolfgang Jeltsch: Am Donnerstag, 24. April 2008 05:13 schrieb Manuel M T Chakravarty: […] Hence, anything that is *important* to change, we should change now. Although I can follow your arguments, I thought that the large and disruptive changes should be done for Haskell 2. Depends what you mean by Haskell 2. If it is an experimental language that shares some superficial similarities with Haskell, sure we may have Haskell 2. If you mean a serious successor of Haskell with the expectation that many/most Haskell users will eventually move to Haskell 2, then no. Haskell has been gaining a lot of momentum recently. That's good and bad, but surely makes it hard to change the trajectory. (This is, of course, just my personal opinion.) If they should really be done now, we should also fix a lot of other things. For example, the Num hierarchy, the Functor/Applicative/Monad hierarchy, the fact that there exist Alternative and MonadPlus although we have Monoid, the fact that we cannot have contexts like (forall a. Monoid (m a)) which is the source for the last problem, the fact that we don’t have class aliases, ugly names like fmap and mappend, etc. As Lennart and Ganesh have argued, the amount of breaking changes that we we will be able to fit in without causing serious problems is limited. Manuel Hello again (after a long time), the things I proposed above are mostly library changes which could mostly be made non-disruptive if we had class aliases. Would this make them acceptable for you? Best wishes, Wolfgang ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: patch applied (haskell-prime-status): BangPatterns: probably accept == undecided
Am Freitag, 18. April 2008 11:54 schrieb Sittampalam, Ganesh: Simon Peyton Jones wrote: Not allowing infix functions on the LHS would be a notable simplification. This would significantly weaken a useful property of Haskell, that definitions and uses often share the same concrete syntax. It's very natural to be able to define things that way and it would be a real shame to lose it (and I think it would break a lot of existing code). +1 (f . g) x = f (g x) is really nice. In any case, I've always thought this was weird: Just x == Just y = x == y It takes a little getting used to, but I don't find it that weird. +1 […] Best wishes, Wolfgang ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Haskell' - class aliases
Am Mittwoch, 23. April 2008 06:18 schrieb John Meacham: On Tue, Apr 22, 2008 at 08:33:53AM +0100, Simon Peyton-Jones wrote: Is this the most up-to-date description of the proposal? http://repetae.net/recent/out/classalias.html There were a few changes proposed in the discussion that followed my announcement that I wanted to make. The one I can remember now is getting rid of the 'alias' keyword since the equals sign unabiguously identifies it as an alias. I will dig through the archive to find the others.. I've just had another look, which threw up quite a few questions in my mind. I wonder what would be a good list to discuss it. Maybe this one is not bad, because it has people interested in Haskell innovation, regardless of whether it's a live Haskell' candidate? Sounds good to me. John By the way, what are your current thoughts about your supertyping proposal. At least, on http://repetae.net/recent/out/supertyping.html you say: This functionality becomes even more necessary when faced with binary-only libraries and standard language features which cannot be easily rewritten or overridden without great effort. This seems to be an advantage compared to the class alias library. On the other hand, it looks a bit weird to me that you can express a class relation in two different ways: A t = B t and B t = A t. Best wishes, Wolfgang ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: patch applied (haskell-prime-status): add Make $ left associative, like application
Am Mittwoch, 23. April 2008 01:20 schrieb Duncan Coutts: […] Surely there was a justification to having $ be the opposite associativity from application and not just a different precedence. Does anyone know what it was? Probably the fact that you can write f $ g $ h $ u $ v $ w $ x instead of f (g (h (u (v (w x) and thereby avoid building forests of parantheses. Duncan Best wishes, Wolfgang ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: patch applied (haskell-prime-status): add Make $ left associative, like application
Am Mittwoch, 23. April 2008 09:58 schrieb Bulat Ziganshin: […] my main point is that considering space-less operators as having larger priority is our natural habit. Really??? I‘ve never heard of people using spaceless operators for stating precedence before. And it contradicts nice typesetting. In my opinion, an operator needs space around it, otherwise it looks ugly. And I don’t want to have lhs2TeX-typeset source code where infix operators sometimes have the nice TeX spacing and sometimes are not surrounded by spaces at all. […] Best wishes, Wolfgang ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: patch applied (haskell-prime-status): add Make $ left associative, like application
Am Mittwoch, 23. April 2008 10:06 schrieb Cale Gibbard: […] I believe that migrating code will be quite a task regardless of the outcome here, but at least for the packages that are in Hackage, the system helpfully reports build failures, so we'll know where the breakages are, and roughly what's left to be done. Why not writing a tool which replaces all occurences of a $ b $ c $ d by a . b . c $ d? - Cale Best wishes, Wolfgang ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: patch applied (haskell-prime-status): add Make $ left associative, like application
Am Donnerstag, 24. April 2008 00:43 schrieb Ian Lynagh: […] Please see http://www.haskell.org/haskellwiki/Library_submissions f $$ x = f x Note that this clashes with Text.PrettyPrint I also doesn’t correspond to $!. We should introduce $$! then. […] Best wishes, Wolfgang ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: patch applied (haskell-prime-status): add Make $ left associative, like application
Am Donnerstag, 24. April 2008 09:30 schrieb Lennart Augustsson: Haskell has now reached the point where backwards compatibility is something that must be taken very seriously. Would you be opposed to a Haskell 2 which would break lots of things? […] Best wishes, Wolfgang ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Suggestion regarding (.) and map
Am Mittwoch, 23. April 2008 23:55 schrieb Cale Gibbard: […] Rename fmap to map This would be really great! There is no point in having a map just for lists and a general map for functors since the list map is the same as the list instance’s functor map. And identifiers with a single lowercase letter in front or after a lowercase word (fmap, foldr, etc.) are not nice, in my opinion. (like it was in Haskell 1.4), It really was this way in Haskell 1.4? Why was it changed? and define (.) as a synonym for it. I don’t think that this is reasonable. (.) corresponds to the little circle in math which is a composition. So (.) = () would be far better. Additionally, add the instance: instance Functor ((-) e) where map f g x = f (g x) (and hopefully the corresponding Monad instance as well) And hopefully the corresponding Applicative instance as well! Applicative functors are a very nice thing. (So a big “thank you” to Conor and Ross.) […] Best wishes, Wolfgang ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: patch applied (haskell-prime-status): proposal: remove string gaps
Am Donnerstag, 3. April 2008 20:24 schrieb Simon Marlow: Neil Mitchell wrote: […] Having two features which can't be used together in the same file seems ridiculous. It gets much worse if you decide ghc --make -cpp is the way you want to build your application, as we used to do for Yhc. I suggest that if string gaps don't get removed, then GHC should fix its -cpp flag. GHC is unlikely to fix its -cpp flag unfortunately, because the problem is with CPP, not GHC. The best we can do is document the problem, which we have done. Couldn’t you “fix” the -cpp flag by letting GHC use cpphs instead of C’s cpp? Cheers, Simon Best wishes, Wolfgang ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: patch applied (haskell-prime-status): add overloaded string literals
Am Dienstag, 1. April 2008 00:31 schrieb Simon Marlow: Mon Mar 31 15:31:44 PDT 2008 Simon Marlow [EMAIL PROTECTED] * add overloaded string literals M ./status.hs +2 Hello, although I like overloaded string literals very much, I see one problem with the current implementation of them in GHC. It’s the class name “IsString”. No other Haskell class name I know starts with “Is”; we don’t have “IsNum”, “IsMonad”, etc. Would it be possible to change the class name “IsString” to something different? Would it be possible to remove the type alias “String” and let “String” be the class name? Can I add this remark somewhere on the wiki? Best wishes, Wolfgang ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: deeqSeq proposal
Am Freitag, 7. April 2006 00:40 schrieb Andy Adams-Moran: Lennart Augustsson wrote: Andy Adams-Moran wrote: The only thing you can do with non-functions is put them in the sin bin: deepSeq :: a - IO () unsafeDeepSeq? I guess we don't want to expand the unsafe* vocabulary for Haskell' though ... What's wrong with deepSeeqIO :: a - IO () ? Then you can use unsafePerformIO if you want deepSeq :: a - b - b Yes, quite right! In the case of deepSeqIO, we do know precisely what the safety condition is (as opposed to generic uses of unsafePerformIO and its cousins), so maybe we want to call that out somehow. A And maybe we should switch from seq to seqIO :: a - IO ()? Best wishes, Wolfgang ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org//mailman/listinfo/haskell-prime
Re: seq as a class method
Am Freitag, 24. März 2006 14:40 schrieb John Hughes: [...] Thirdly, the laws one loses are nearly true anyway, and that's very often enough. See Fast and loose reasoning is morally correct, POPL 2006. We don't need to give up anything to make reasoning *as though* such laws held sound, in most cases. I will probably have a look at this paper. Nevertheless, I feel uncomfortable with the fact that something that isn't a monad claims to be a monad, etc. Maybe we should rename seq to unsafeSeq or something similar. John Best wishes, Wolfgang ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
seq as a class method
Hello, it seems that there is not yet a ticket about putting seq into a type class (again). In my opinion, having seq available for every type is a serious flaw. One problem is that the law f = \x - f x doesn't hold anymore since the equation is false for f = _|_. There was also a discussion on one of the mailing lists some time ago which revealed that the Monad instance for IO doesn't satisfy the monad laws because of the availability of seq for IO, I think. In addition, the automatic definition of seq for every type can make implementation details visible which were thought of as completely hidden. For example, it might make a difference whether one uses data or newtype for a one-alternative-one-field datatype, even if the data constructor is hidden. I therefore propose to declare a class like this: class Seq a where seq :: a - b - b (Perhaps the class name should be chosen better.) Generation of standard instances should be supported via deriving clauses or Template Haskell. For an algebraic datatype declared via data T a1 ... an = C1 t11 ... t1m1 | ... | Ck tk1 ... tkmk the implementation of seq should be something like this: seq (C1 _ ... _) = id seq _ = id What do others think? Best wishes, Wolfgang ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Strict tuples
Am Mittwoch, 22. März 2006 14:19 schrieb Bulat Ziganshin: Hello Wolfgang, you said WHAT you think but not said WHY? my motivation is to be able to use myriads of already implemented algorithms on new datatypes I think, I already tried to explain why I think the way I think in an earlier mail: Strictness has to refer to attributes (the things you apply a data constructor to). In you approach, strictness is connected to type arguments. This causes problems. For example, if you have data T a = C a a, what would T !a mean? Would both attributes be strict? But how would you force only one attribute to be strict then? By the way, would it be okay for you to answer below the quotation, not above it? And would it be possible to use just a sign, followed by a space for marking quotations. My MUA gets confused by things like “WJ ”. Thank you very much. [...] Best wishes, Wolfgang ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Ranges and the Enum class
Am Dienstag, 21. März 2006 02:47 schrieb Aaron Denney: [...] No, I use them. In my opinion, it makes much more sense to write succ n than n + 1. Agreed, for non-arithmetical types. I think, it's perfectly sensible for arithmetical types like Integer. If you mean “the next integer” then succ n is the most logical thing to write. If you write n + 1 instead, you invoke a more complex operation (addition) with a special constant as one of its parameters, and this obfuscates what you actually mean, in my opinion. Best wishes, Wolfgang ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Ranges and the Enum class
Am Dienstag, 21. März 2006 10:08 schrieb Malcolm Wallace: Wolfgang Jeltsch [EMAIL PROTECTED] writes: [...] Why do we need toEnum and fromEnum at all? As far as I know, they are merely there to help people implement things like enumFrom. They are often useful for writing serialisation routines, and they see occasional use for other kinds of safe type coercion as well (toEnum . fromEnum) Regards, Malcolm Maybe they should be in a separate class. Enum should be about enumerating, not “indexing”. Best wishes, Wolfgang ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Strict tuples
Am Dienstag, 21. März 2006 11:28 schrieb Bulat Ziganshin: [...] as i said, shebang patterns allow only to specify that IMPLEMENTATION of some function is strict. this helps only when this function are called directly. they can't help when function is passed as parameter or enclosed in data structure or a part of class. the same about datatypes - i can't declare what some algorithm works only with strict lists. i try to find extensions what will allow to specify strictness in every case where now we forced to use lazy computations the concrete syntax what i propose may be wrong Well, it's probably nice sometimes to have types which guarantee the strictness of certain components. For example, it might be good to have a list type where the strictness of the elements is guaranteed. But I'm sure that it's wrong to try to achieve this by annotating type arguments like in [!a]. I think, this approach is wrong, not just the syntax. Best wishes, Wolfgang ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Ranges and the Enum class
Am Freitag, 17. März 2006 18:49 schrieb Ross Paterson: [...] Also, toEnum and fromEnum would make more sense mapping from and to Integer. Why do we need toEnum and fromEnum at all? As far as I know, they are merely there to help people implement things like enumFrom. It's often not clear how toEnum and fromEnum should look like. How should they be implemented for Time.Day, for example? Should the days corresponds to the integers 0 to 6 or 1 to 7? It seems that succ and pred are unused. No, I use them. In my opinion, it makes much more sense to write succ n than n + 1. Best wishes, Wolfgang ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Strict tuples
Am Sonntag, 19. März 2006 15:53 schrieb Bulat Ziganshin: Hello Manuel, Sunday, March 19, 2006, 5:35:12 AM, you wrote: MMTC PS: IIRC Clean supports strict tuples. i've proposed to allow adding strict mark to any type constructors and type constructor parameters so that finally we can define any data structure that can be defined in strict languages. in particular: type StrictPair a b = !(,) a b type StrictElements a b = (,) !a !b type StrictBoth a b = !(,) !a !b type StrictFunction a b = !(-) !a !b strictMap :: StrictFunction a b - ![!a] - ![!b] where ![!a] is a strict list with strict elements Strictness has to refer to attributes (the things you apply a data constructor to). In you approach, strictness is connected to type arguments. This causes problems. For example, if you have data T a = C a a, what would T !a mean? Would both attributes be strict? But how would you force only one attribute to be strict then? These thinkings make me believe that assigning strictness flags to type arguments is just not sensible. Best wishes, Wolfgang ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
only explicit universal quantification
Hello, what about dropping implicit universal quantification of type variables from the language, meaning that every universal quantification has to be made explicit? One advantage of this would be that spelling mistakes in type variables would be detected by the compiler more often since every type variable would need to be “declared” by a forall (or exists). In addition one could think of different semantics for unbound type variables. Such a variable could refer to a quantification at a higher level which would solve the problem of sometimes not being able to give type declarations for let/where declarations. For example, in the following example, the type variable e in the where clause would refer to the same type as the type variable e in the type declaration of the function example: example :: forall e. Enum e = e - e example = helper where helper :: e - e helper = succ I know, these would be rather drastic changes but they seem sensible to me. What do others think? Best wishes, Wolfgang ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: If you really care, make sure it gets on the wiki (how to create a proposal)
Am Sonntag, 5. März 2006 02:59 schrieb isaac jones: [...] 2. If you don't have a wiki account, Log in with username guest and password haskell' to create and edit tickets. How do I get a account for the wiki? [...] Best wishes, Wolfgang ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
partial application syntax
Hello, there was some proposal for introducing a special syntax where f x _ z or f x ? z means \y - f x y z. Is there some information on the Haskell' trac site about this? Best wishes, Wolfgang ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Export lists in modules
Am Dienstag, 21. Februar 2006 21:59 schrieb Ketil Malde: Wolfgang Jeltsch [EMAIL PROTECTED] writes: On the other hand, sometimes it makes sense to have a mostly qualified import. For example, if you import Data.Set or Data.Map you might want only the type constructors to be imported unqualified and the rest to be imported qualified. Personally, I would greatly prefer to have libraries that do not clash with common Prelude functions. I would solve this problem by reducing the Prelude to just a core. List function could go, for example, (mostly) into Data.List. I find it quite annoying to always have to import these modules twice, and still have to qualify many uses. If you always have to qualify it, what's the advantage of Data.Set.empty over emptySet again? At least with 'emptySet' I know what to grep for. I would import Data.Set as Set. So I would use Set.empty instead of emptySet. The advantage is that Set.empty is more structured. You can easily distinguish the kind of operation (empty) and the type you are working with (Set). -k -w ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: New syntax
Am Dienstag, 21. Februar 2006 22:10 schrieb Ketil Malde: [...] Template Haskell breaks expressions with $, It's very bad that with TH enabled you cannot write sections of the form ($ x) anymore which are sometimes very handy. [...] (Perhaps it would be better to always require whitespace after symbolic infix operators?) Of course, this wouldn't help with the above-mentioned TH-related problem. [...] -k -w ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: ~ patterns
Am Mittwoch, 1. Februar 2006 01:32 schrieb Patryk Zadarnowski: [...] The proposal would be to remove the unary - altogether, and, instead, extend the lexical syntax of numeric constant to allow + and - prefix. Would this mean that (-x) is a section while (-1) isn't? That would be confusing. Apart from this, I would like to see the only unary operator of Haskell removed. [...] Best wishes, Wolfgang ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: strict Haskell dialect
Am Mittwoch, 1. Februar 2006 11:49 schrieb Bulat Ziganshin: [...] i had one idea, what is somewhat corresponding to his discussion: make a strict Haskell dialect. implement it by translating all expressions of form f x into f $! x and then going to the standard (lazy) haskell translator. the same for data fields - add to all field definitions ! in translation process. then add to this strict Haskell language ability to _explicitly_ specify lazy fields and lazy evaluation, for example using this ~ sign what it will give? ability to use Haskell as powerful strict language, what is especially interesting for real-world programmers. i have found myself permanently fighting against the lazyness once i starting to optimize my programs. for the newcomers, it just will reduce learning path - they don't need to know anything about lazyness Since laziness often allows you to solve problems so elegantly, I'm really scared of the idea of a Strict Haskell! :-( Is laziness really so unreal that real-world programmers have to see it as an enemy which they have to fight against? In fact, I was kind of shocked as I read in Simon Peyton Jones' presentation Wearing the hair shirt [1] that in his opinion Lazyness doesn't really matter. [...] Best wishes, Wolfgang [1] http://research.microsoft.com/Users/simonpj/papers/haskell-retrospective/ ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Comment Syntax
Am Montag, 30. Januar 2006 17:24 schrieb Taral: On 1/30/06, Thomas Davie [EMAIL PROTECTED] wrote: It gives you regexp and nothing more - this makes it a pain in the arse to input every possible character that is/isn't allowed. Steal it from places (vim): syn match hsLineComment ---*\([^-!#$%\*\+./=[EMAIL PROTECTED]|~].*\)\?$ What about Unicode? Best wishes, Wolfgang ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
