it's too hard to implement (and it's not always hard
- the YHC guys
managed it in a matter of days
Tom is the one who implemented it in Yhc, and details can be found
http://www.haskell.org/haskellwiki/Yhc/RTS/Concurrency
but some of the reasons that it was easier than in other compilers are:
Hi
- we've been told here that concurrency is just a library
No, its not. The interface to concurrency is just a library, but
internally certain things in the runtime have to change.
- FFI allows other Haskell' implementations to import that library
If all Haskell' prime implementations depend
Hi,
context-switches happen only on specific events, which every
thread will usually engage in, although it need not always do so:
1 only calls to yield
2 any calls to concurrency library api
3 any allocation
The Yhc concurrency switches every n instructions, and therefore even
an evil
Hi
What does YHC do about in-progress thunk evaluations when a context
switch happens? Does it use blackholing like GHC, or does it
portentially duplicate the work, or something else?
As far as I am aware, since it only switches on instruction
boundaries, it never has to worry about this. It
Hi
Any tool which assumes strings are delimited by a single front delimiter
and a single end delimiter, which they are in most reasonable languages,
will have trouble.
In current haskell any tool which assumes characters start and end
with a ' are also wrong, because you can have name' as a
Hi
In order to solve the trouble I propose enhancements
to teachers, compilers and standard libraries:
1. 'if' syntax should be teached as
if a
then b
else c
I love being able to ident if however I like:
if a then b else
c
Where b is a trivial case, and c is the hard
It seems better to change the language so it works like _everyone_
expects it does, rather than become syntax dictators. It's hard enough
persuading people to move from C, but when you tell someone that their
perfectly unambiguous sytnax is wrong, they aren't going to be
amused.
I don't
Actually if-then-else isn't used that often today. Most programmers
gave it up in favor of guards.
I question both these statements. Can you cite some evidence here?
I have 501 if statements in my current project. Yhc has 626. Hoogle
has 101. If's seem pretty well used to me!
Thanks
Neil
Hi
Is there a reason why we have to escape the character ' (apostrophe)
when used in a character literal? For example, we have to write '\''
instead of '''.
This is what Ada does. I think that's a reason enough to keep things
the way they are.
It does actually make syntax hilighting more
Hi
in spite of their similarity, all of these constructs handle some of the
monadic aspects differently. the translations of pattern guards not only
embed statements in guard, they also embed the right hand sides of
generators in return. translations of list comprehensions only lift
statements.
Hi
The argument that a trailing comma means the programmer forgot the
last item in a list / tuple is
inconsistent with the deliberately explicit permissiveness of a
trailing comma in the import / export lists.
In the import / export lists such a trailing comma does not mean
programmer forgot
Hi
I guess another important point is to make sure that when we pick a
design, then we have at least one (current) implementation that
supports it (ideally, all implementations would eventually). Could we
get a heads up from implementors about the the current status and
future plans in this
Hi
Put differently, I don't see a compelling use-case for the proposed
syntax extension. But I've seen many misused monads.
A compelling use-case:
http://darcs.haskell.org/yhc/src/libraries/core/Yhc/Core/Simplify.hs
Look at coreSimplifyExprUniqueExt
And from that file:
-- helpers,
Hi
This extension seems like a great idea - my only concern would be
about the order of computations. Clearly left-to-right makes sense,
but this may break some natural intuition in Haskell:
i think that undefined order will be a best one
Using undefined does not make for great reading in
Hi
hello thanks for my new subscription, do I need to pay a fee or is it free
to join ?
This is a mailing list. Its totally free, and for the purpose of
discussing future improvements to the Haskell standard. If you just
wait, you'll find interesting discussions flowing into your inbox. If
Hi
Re ! as an operator: This caused a number of complexities in the
parsing of stuff, including shift-reduce conflicts. Someone would need
to look into this, and determine that the rules are completely
unambiguous.
Backwards compatibility requires that it be implicitly imported from
Prelude
Hi Henrik,
In reality, string gaps are unusable in practice, because of GHC and
-cpp. We had some in Yhc at one point, and then breakage happened, so
we removed them.
To quote from the page:
* string gaps cause problems with CPP, which doesn't like the
backslash at the end of the line. (a
Hi
If you have two features battling each other, you probably need to
remove one of them. CPP isn't going to be removed, which kind of
forces the issue...
Well, for the record, I've used both CPP and string gaps
extensively. And all I've done is to be careful to run CPP
only
Hi
a!b = ...
Did I just define the function a or the function !?
I'm not saying they shouldn't be accepted, but the story should be a
little clearer about this as well!
For what it is worth, in discussions with Matt, we wondered if
eliminating infix function definition altogether was
Hi
How would you propose supporting multiple preludes at once?
Unhappy. The Haskell Prelude is more than just a standard library.
Things like $, ., otherwise, = etc would be keywords in any other
language. As such, you expect their meaning to be consistent.
If you let other people define
Hi
* remove the MR entirely
Finally!
* adopt Monomorphic Pattern Bindings (MPB)
There are 6 reasons on that page why we shouldn't adopt MPB - of those
number 5 I think is particularly compelling. There seems to be 1 main
reason to remove it, which is that it has a complex translation to
Hi
I think it is reasonable to look closely at the motivations for
wanting to retain the $ as is. Looking through this thread, I can find
only a single complaint raised (albeit an important one), namely
backwards compatibility. Yes, such a change would likely break quite a
few my
Hi
I think Henrik's criteria are pretty close to perfect.
As I have argued before on the committee list, I also think we should *not*
worry about backwards incompatible changes too much in cases where a simple
automatic translation from H98 to H' code is possible. Even for a large
project,
Hi Simon,
Those additional reasons given are much more compelling, and should
definately go on the wiki. I think the essential point is that it
makes reasoning about the code simpler - regardless of the effect on
implementation.
My main remaining reservation is that:
(x) /= x
[EMAIL PROTECTED]
Hi
So does the silence = approval rule apply here?
2 days is not enough time :-)
I disagree, its a breaking change from Haskell 98. It also means that
if you want to provide syntactic sugar for do notation, i.e. my Test
monad, you have to jump through more hoops.
Hi
1. Allow empty case, i.e. case some_variable of { } (GHC ticket [1]).
This adds consistency, it always causes a pattern-match error, and it is a
sensible way to look at all the cases of types with no constructors (recall
EmptyDataDecls will probably be in Haskell' [4]) -- especially for
Hi
Bringing up an old thread, but this issue just bit me in real life:
[0, 2.5 .. 3.75 ] = [0, 2.5, 5.0]
I was comparative testing some C++ and some Haskell, and its a shame
when its the Haskell that is clearly wrong! I don't think any end
decision was reached in this thread, but I think this
Hi Alson,
So why not {hello: 1, there: 2} ?
A comment from the peanut gallery:
I took circ's comment to be a suggestion that we adopt an _idiom_.
That you can non-idiomatically accomplish the same thing in Haskell by
defining some datatypes and functions doesn't seem to address the core
Hi
Would it be proper to create a counterproposal for this syntax?
ReversedLabelledFieldSyntax?
I would claim that, of the existing Haskell code,
StricterLabelledFieldSyntax only rejects unclear (bad) code, and
requiring it be changed (to be made clearer) is a good thing.
I haven't seen
I haven't seen anyone else claim to use the current more liberal
syntax for fields, but I know that I do rather extensively. I would
consider:
Just A {a = 1}
To be confusing, but if you simply omit the space:
Just A{a = 1}
I now find that perfectly clear and unambiguous.
I did
Hi
remove FixityResolution from the context-free grammar
http://hackage.haskell.org/trac/haskell-prime/wiki/FixityResolution
Please take a look and comment. This fixes a nasty bug in the Haskell
syntax - albeit one that doesn't cause problems in practice, but still. I
think the changes
There is nothing to stop an library author doing exactly this, and it
might even be useful for some people (personally I'm going to stick to
haskell-src-exts, because it's a brilliant library). However, I don't
think we should make it official or part of the standard. I've found
plenty of HSE/GHC
32 matches
Mail list logo
