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 Patersonr...@soi.city.ac.uk 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: 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
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: 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: 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
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: 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
