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
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.
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
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
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.
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
___
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
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
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
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.
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.
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
31 matches
Mail list logo
