Re: PROPOSAL: Include record puns in Haskell 2011
On 24 Feb 2010, at 18:52, John Meacham wrote:
> On Wed, Feb 24, 2010 at 06:23:39PM +, Ian Lynagh wrote:
>> On Tue, Feb 23, 2010 at 07:07:30PM -0800, Iavor Diatchki wrote:
>> I have a feeling I'm in the minority, but I find record punning an ugly
>> feature.
>>
>> Given
>>data T = C { f :: Int }
>> we implicitly get
>>f :: T -> Int
>> which punning shadows with
>>f :: Int
>> whereas I generally avoid shadowing completely.
>
> I can see the thinking here, but I don't like for the language to try to
> enforce 'style' or make decisions based on it. I think it is more in the
> spirit of haskell to provide multiple mechanisms when it makes sense and
> let the users figure out what works for them stylistically.
The problem though, unless I'm misunderstanding, is that you *must* enforce one
or other convention here. Either you force everyone who's style is to never
shadow things to do so because of this language feature, or you remove the
language feature and trample on the other crowd.
For what it's worth, I'd side with Ian on this one.
Bob___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
Re: bug in language definition (strictness)
On 6 Aug 2009, at 17:34, Mathias Stearn wrote: On Thu, Aug 6, 2009 at 11:00 AM, Ross Paterson wrote: There is no stack overflow in the denotational semantics. There is currently no denotational semantics simulator with an infinite stack. Until there is, Haskell programs will have to be executed on lowly physical computers with all the limitations that is implied. Can we please make things work well on them? When writing a document that defines the denotation of values, no. Perhaps when considering operational semantics, but that's an entirely different matter. Bob ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: bug in language definition (strictness)
On 6 Aug 2009, at 14:37, Nils Anders Danielsson wrote: On 2009-08-06 11:08, Malcolm Wallace wrote: yet, because of the definition of $!, this applies the constructor to its arguments right-to-left instead of the intuitive left-to- right. I do not think that there is a bug: x `seq` y `seq` e has the same denotation as y `seq` x `seq` e. Not if one considers the "kind" of bottom one receives: undefined `seq` error "it exploded" `seq` e will print "Prelude.undefined" while error "it exploded" `seq` undefined `seq` e will print "Error: it exploded" Bob ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Re[8]: One more 'do' pattern
On 28 Mar 2009, at 10:52, Bulat Ziganshin wrote: Hello Thomas, Saturday, March 28, 2009, 12:41:50 PM, you wrote: and you have written GUI in FP style? with trees, d&d support and so on? I haven't, I'm working on a different part of the app √ Peter Verswyvelen has though. :) the problem is that no GUI library except for gtk2hs supports d&d. and i think that no functional GUI library support trees too it's why i asked - you work on functional part of project and FP features are enough for your work. and you think that everything that you personally don't use should be omitted from haskell To get back on topic though... Here's *why* I don't want these specific things I wouldn't use added to haskell: • The syntax gains very little over the nice consistent syntax we already have – all you do is move a symbol a little to the left. • For that small benefit we gain all these disadvantages • The language gets harder to parse • We gain more reserved words that we can't use in our programs • We gain more corner cases that can't be explained simply using the basic rules of how application works in Haskell • We gain a syntax that even more than previously indicates that things will be executed in order (which is a total lie) • We encourage people to write code unnecessarily in an imperative style Hope that helps clarify why I'm objecting to this. Bob___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Re[8]: One more 'do' pattern
On 28 Mar 2009, at 10:52, Bulat Ziganshin wrote: Hello Thomas, Saturday, March 28, 2009, 12:41:50 PM, you wrote: and you have written GUI in FP style? with trees, d&d support and so on? I haven't, I'm working on a different part of the app √ Peter Verswyvelen has though. :) the problem is that no GUI library except for gtk2hs supports d&d. and i think that no functional GUI library support trees too it's why i asked - you work on functional part of project and FP features are enough for your work. and you think that everything that you personally don't use should be omitted from haskell And we can't possibly have written our own GUI library as part of the project? As it happens, this library binds on to Gtk2Hs, but that's a trivially small amount of code, and even there very little uses do notation. Bob___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Re[6]: One more 'do' pattern
On 28 Mar 2009, at 10:38, Bulat Ziganshin wrote: Hello Thomas, Saturday, March 28, 2009, 12:34:05 PM, you wrote: I'm not sure why "industrial programming" means "programming not in a functional style". It certainly doesn't mean that where I work. what kind of problems you are solving? Large GUI applications doing lots of 3D rendering. and you have written GUI in FP style? with trees, d&d support and so on? I haven't, I'm working on a different part of the app – Peter Verswyvelen has though. Bob___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Re[4]: One more 'do' pattern
On 28 Mar 2009, at 10:24, Bulat Ziganshin wrote: Hello Thomas, Saturday, March 28, 2009, 12:15:37 PM, you wrote: I'm not sure why "industrial programming" means "programming not in a functional style". It certainly doesn't mean that where I work. what kind of problems you are solving? Large GUI applications doing lots of 3D rendering. Bob ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Re[2]: One more 'do' pattern
On 28 Mar 2009, at 10:13, Bulat Ziganshin wrote: Hello Thomas, Saturday, March 28, 2009, 12:05:02 PM, you wrote: In all honesty, I find the idea of adding yet more "imperative" looking stuff to do notation an appalling idea. We already get problems because people read do notation and think it means "execute this in sequence" (see threads about lazy IO not doing what's expected for example). well, people already have problems understanding haskell, not only 'do' statements As an aside, while these are merely syntactic sugars, I find the idea of attacking the problem with syntax to be somewhat silly as well. This simply adds a special syntax for another couple of cases that crop up occasionally. What do we do when we have another, and another, and another, do we keep just adding more and more syntax? i'm just making industrial programming, with lots of imperative code and 'do' syntax (compared to imperative languages) is somewhat limited. so, what i want to have is better syntax. i don't have any idea whether semantics can be somewhat improved to fix those shortages I'm not sure why "industrial programming" means "programming not in a functional style". It certainly doesn't mean that where I work. Bob ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: One more 'do' pattern
On 28 Mar 2009, at 09:54, Bulat Ziganshin wrote: Hello haskell-prime, as we know, the following code action x y >>= \v -> do can be shortened to following v <- action x y but there is one more very popular 'do' pattern, with a 'do' block passed as a parameter: for list $ \element -> do ... or bracket createDialog destroyDialog $ \dialog -> do ... what about adding one more 'do' sugar that will allow to move variable name to the left, such as for element in list do or with dialog in bracket createDialog destroyDialog do or just element <-- for list do dialog <-- bracket createDialog destroyDialog do ? In all honesty, I find the idea of adding yet more "imperative" looking stuff to do notation an appalling idea. We already get problems because people read do notation and think it means "execute this in sequence" (see threads about lazy IO not doing what's expected for example). As an aside, while these are merely syntactic sugars, I find the idea of attacking the problem with syntax to be somewhat silly as well. This simply adds a special syntax for another couple of cases that crop up occasionally. What do we do when we have another, and another, and another, do we keep just adding more and more syntax? Bob ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
[Proposal] Move most of Control.Monad to Control.Applicative
Hi, Most of Control.Monad doesn't actually rely on Monads, but instead Applicatives. Data.Traversable fixes this in a lot of cases, but it would be nice to have the 'standard' functions as general as possible. My quick reading of Control.Monad says these at least should fall victim to demotion to applicatives: mapA :: (Applicative f) => (a -> f b) -> [a] -> f [b] mapA_ :: (Applicative f) => (a -> f b) -> [a] -> f () sequence :: (Applicative f) => [f a] -> f [a] sequence_ :: (Applicative f) => [f a] -> f () filterA :: (Applicative f) => (a -> f Bool) -> [a] -> f [a] mapAndUnzipA :: (Applicative f) => (a -> f (b,c)) -> [a] -> f ([b], [c]) zipWithA :: (Applicative f) => (a -> b -> f c) -> [a] -> [b] -> f [c] zipWithA_ :: (Applicative f) => (a -> b -> f c) -> [a] -> [b] -> f () replicateA :: (Applicative f) => Int -> f a -> f [a] replicateA_ :: (Applicative f) => Int -> f a -> f () when :: (Applicative f) => Bool -> f () -> f () unless :: (Applicative f) => Bool -> f () -> f () I may have missed some. Bob ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Suggestion: Syntactic sugar for Maps!
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
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
Disjunctive tuples
Hi, I have a rather late suggestion for addition to Haskell. To appease those who I know think that Haskell is over-complicated already and should be having things removed, I'd like to suggest something that I think makes the language rather more consistent, and thus simplifies it despite adding things to it. My suggestion is for a disjunctive tuple syntax using the | symbol. We might right functions as such: fromEither :: Either a b -> (a | b) fromEither (Left x) = (x | ) fromEither (Right x) = ( | x) toEither :: (a | b) -> Either a b toEither (x | ) = Left x toEither ( | x) = Right x makeMoreComplexDisjunction :: Int -> Bool -> Int -> Float -> (Bool | Int | Float) makeMoreComplexDisjunction 1 x _ _ = (x | | ) makeMoreComplexDisjunction 2 _ x _ = ( | x | ) makeMoreComplexDisjunction 3 _ _ x = ( | | x) Using the '|' character gives a nice obvious syntax, and does not (I believe) conflict with anything in the Haskell 98 definition, as '|' is currently reserved for guards. Tom Davie ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Representing Tuple types as products
On 6 Feb 2006, at 13:58, Ben Rudiak-Gould wrote: Thomas Davie wrote: fst :: α × β → α even without Unicode we could allow fst :: a * b -> a like ML. But I'm not sure I like this. ((a,b),c) and (a,(b,c)) and (a,b,c) all feel distinct to me, but (a*b)*c, a*(b*c) and a*b*c feel the same. I could easily get used to it, but I doubt I'd use it as long as the old syntax remained available. Indeed, I think this only really becomes applicable when unicode is available, because we're all used to seeing tuples being written as cross products on the theoretical side of things. I'm just thinking that if we can get closer to the maths by using the greek letters, can we also get closer by using the same syntax? I suspect that I would use it, but only where I was doing something like directly implementing an abstract machine - i.e. when I want the Haskell to look as much like the theory as possible. Bob ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Representing Tuple types as products
Here's a random idea that popped into my head. There have been a few discussions about unicode support in Haskell'. One of the particular places this is useful would appear to be type signatures, I was considering that it would be particularly neat to be able to represent tuples as cross products if the user so desired. As such: fst :: α × β → α would be equivalent to: fst :: (α, β) → α Just random thought for the day, what do people think? Bob ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Unary operators [was: Re: ~ patterns]
On Feb 3, 2006, at 9:34 AM, Bulat Ziganshin wrote: Hello Benjamin, Friday, February 03, 2006, 2:29:47 AM, you wrote: (+ x) --->> (? + x) i like this idea! but i tink that it's too late for such incompatible change :( really, unary operators can be added to language without any troubles. we need only to prohibit using of the same symbol for unary and binary operators: unary 9 # #n = n-1 f = #1-1 we can even allow prefix and postfix operators as long as they all have different names The notable exception in this case, '-' (or anything starting with -), which breaks block comment syntax (see my earlier example). Bob ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: unary "-" operator
I don't know if this is something that's been argued before, but I
came across an interesting example of why the unary '-' is bad, while
searching for reasons that single line comments are bad. A section
involving the binary minus operator must always be bracketed, and as
such will always have a '(' infront of it. That means that this
example can never happen:
infixl 0 -->
(-->) x y = print x >> print y
f = do { -5 --> 5; return()}
Delete the space after the '{' and you have a problem. This can't
happen if you don't have a unary minus.
Bob
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime
Re: Comment Syntax
The fact that -- is a reserved word while {- is not just highlights
farther the inconsistency in the language.
Your position implies one of the following:
1) You think that "{{" ought to be a legal operator.
2) You think that "-" ought not to be a legal operator.
3) You think that custom operators are a bad idea. (Hey, Bjarne
Stroustrup agrees with you!)
Which is it? Personally, I disagree with all three, but then again, I
don't see any inconsistency here.
4) I think that comments should start consistently with either a) a
reserved word, or b) something involving a set character (or
characters) not allowed in operators. Maybe ever '{{' would be good
for a single line comment.
Bob
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime
Re: Comment Syntax
On Jan 30, 2006, at 7:53 PM, Henrik Nilsson wrote: Hi all, Neil Mitchell wrote: > Really? Using hoogle I can't find any operators that have -- as a > substring. For what's it worth, Yampa uses --> (along with >--). Similarly fwiw, Simon said something along the lines of Haskell98 -> Haskell' being an interesting refactoring for HaRe in the last meeting... But don't quote me on that, it was probably just a random musing. Bob ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Comment Syntax
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. Bob Oh, come on. It's a one time pain. How hard can it be? I agree, this is not a great argument, but the fact that the language is inconsistent, and that it confuses people easily, and can't come up with great error messages when it does go wrong, (my original arguments) really are good arguments for fixing this. Bob ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Comment Syntax
On 30 Jan 2006, at 14:49, [EMAIL PROTECTED] wrote: Quoting Thomas Davie <[EMAIL PROTECTED]>: On 30 Jan 2006, at 14:28, Neil Mitchell wrote: Another argument in favour of this is that most editors with syntax hilighting will show --> as a comment, which again increases the confusion factor. I would rather argue that since we have editors with syntax highlighting, this isn't a big problem. The editor will tell you (if the highlighting is implemented correctly) that --> does not start a comment. Rather than changing the language we should fix the highlighting modes for the editors in question. This is rather hard, unless your editor is actually a thinly disguised programming language. Certainly for my editor of choice (TextPad) this cannot be done easily - and isn't needed for most other languages. Ditto the SubEthaEdit syntax highlighting mode - I guess most people have got used to editors being thinly disguised operating systems these days (not looking at emacs or vim here). Are you telling me that your text editor doesn't even give you a regexp for defining comments? If it doesn't, I'd say your editor needs to upgrade to some good 1960s text editor technology. 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. Bob ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Comment Syntax
On 30 Jan 2006, at 14:28, Neil Mitchell wrote: Another argument in favour of this is that most editors with syntax hilighting will show --> as a comment, which again increases the confusion factor. I would rather argue that since we have editors with syntax highlighting, this isn't a big problem. The editor will tell you (if the highlighting is implemented correctly) that --> does not start a comment. Rather than changing the language we should fix the highlighting modes for the editors in question. This is rather hard, unless your editor is actually a thinly disguised programming language. Certainly for my editor of choice (TextPad) this cannot be done easily - and isn't needed for most other languages. Ditto the SubEthaEdit syntax highlighting mode - I guess most people have got used to editors being thinly disguised operating systems these days (not looking at emacs or vim here). Bob ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: Comment Syntax
On 30 Jan 2006, at 14:01, Antti-Juhani Kaijanaho wrote:
Thomas Davie wrote:
Except that there is a good reason (pos two) why the language is
wrong
- it's inconsistant with the other comment syntax, and it's
confusing
to newbies.
I tend to think of "--" as a reserved word in the same sense as "case"
is a reserved word. Hence, -- starts a comment, --> doesn't. The
opening
brace ({) is not a symbol character, so {- is in the same category as
the semicolon, special symbol, not a reserved word.
I was actually delighted to learn that it works like this.
For newbies, just tell them that "-- " is the comment starter. It
works
well enough, and newbies get a lot of other half-truths, so it's
nothing
earth-shattering :)
True but they're bound to get it wrong at least once (I know I did,
and damn were the errors confusing). Also, how do you propose that
-- is put on a slide and differentiated from --?
The fact that -- is a reserved word while {- is not just highlights
farther the inconsistency in the language.
Bob
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime
Re: Comment Syntax
On 30 Jan 2006, at 13:51, Ulf Norell wrote: On Jan 30, 2006, at 1:30 PM, Neil Mitchell wrote: Another argument in favour of this is that most editors with syntax hilighting will show --> as a comment, which again increases the confusion factor. I would rather argue that since we have editors with syntax highlighting, this isn't a big problem. The editor will tell you (if the highlighting is implemented correctly) that --> does not start a comment. Rather than changing the language we should fix the highlighting modes for the editors in question. Except that there is a good reason (pos two) why the language is wrong - it's inconsistant with the other comment syntax, and it's confusing to newbies. Bob ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Comment Syntax
I would like to suggest a different change to single line comment
syntax to do two things. First, address an inconsistency with multi
line comments, and secondly remove one of the main sources of
confusion for beginners.
My proposal is to make any text beginning '--' a comment (rather than
requiring a space after the two dashes. I appreciate that the
argument against this is that various operators that look like this
are useful (e.g. -->). However I think that any benefit gained by
operators like this is lost in confusion.
In order to back up my suggestion, I'd like to point out, that this
is indeed already how it is done for block comments. i.e. we do not
expect {-> to be an operator, we expect it to be the beginning of a
comment.
Secondly, from my limited experience helping to teach Haskell, the
comment syntax is a primary source of confusion for beginners.
Beginners inevitably forget (or don't know) to add the space, and
will receive confusing errors about undefined symbols, or type
mismatches. This is made yet more confusing by the fact that the
compiler appears to be pointing at an error in a comment.
Thanks
Tom Davie
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime
