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 p
> 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.
>>>
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
>> 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 unambig
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'
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 addre
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 is
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
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.
http://neilmitchell.blogsp
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
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
> proje
Hi
> How many research papers have you seen which use chained ($)
> applications? I can't recall a single one.
You should read my papers! :-)
http://www-users.cs.york.ac.uk/~ndm/downloads/paper-uniform_boilerplate_and_list_processing-30_sep_2007.pdf
- section 4.1, being just the first one I pi
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 mo
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
> 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 ot
Hi
> I'm hoping someone will supply some. There seemed to be strong opinion on
> #haskell that this change should be made, but it might just have been a very
> vocal minority.
I think the feeling was that it encourages a slightly different style
of programming, instead of:
f $ g $ h x
People
Hi Chris,
> > * add ""Make $ left associative, like application"
>
> Is there a justification for this somewhere? I know it would break
> nearly every single piece of Haskell code I've ever written. As such,
> I'm biased toward thinking it's an extremely bad idea.
>From the patch:
+ ,Iss
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 altoget
Hi
> In the list of features "required for Haskell in practice", bang patterns are
> way up there.
But their syntax has issues:
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
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
>
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 mi
roblem now. It makes sense to come to
some consensus which Haskell' will follow, then fix whichever set of
compilers is determined to be wrong.
Opinions
--
The basic differing of opinions is should Show print the minimal ASCII
representation (Neil Mitchell, Simon Marlow) or somethin
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
> > Prelu
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
y
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 readin
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
> Ian, a member of the "Out with DMR, defaulting, unary negation and n+k
> patterns" club
Ian: what's DMR?
That's what I asked on IRC - answer: Dreaded Monomorphism Restriction.
And as it happens, I am a member of the same club as Ian.
Thanks
Neil
___
Hi,
From Section 10 of the Haskell report, regarding automatic derivation:
to derive Bounded for a type: "the type must be either an enumeration
(all constructors must be nullary) or have only one constructor."
This seems a very artificial restriction - since it allows you to be
in any one of
Hi Twan,
> In the interest of removing things from the standard, I found this in
> the Haskell 98 report (section 4.4.3.2):
Great idea to remove things, but keep your hands off extended pattern
guards! I've got at least 3 instances of that in the module that is
currently open on my screen. I'v
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 are
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 forgo
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
statemen
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 com
On 10/26/06, Bulat Ziganshin <[EMAIL PROTECTED]> wrote:
> are c.f. should work for polymorhic values? afaiu, it's just the
> problem that leads to the famous monomorhism restriction. w/o type
> specifier your expressions will got monomorhic types
These are small enough to be inlined, and are almo
Hi
Are these numbers high, or low? I have no idea unless you specify a
reference point. Compared to guards, say? Or case?
Let's just say that 2000 occursances of a syntactic construct between
3 projects probably means that it's not going to be depreciated ever
(thankfully!)
Neil
_
> 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
> 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
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 one
Hi
reverse @ ensure { reverse (reverse xs) == xs }
Question, does "reverse [1..]" meet, or not meet this invariant? What
is the type signature for reverse? What about "reverse [(+),(-)]" ? Is
anything going to be said about the semantics of the invariants? Or
are we just reserving a little pie
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 fu
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.
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 "ev
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 depen
> 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,
>1) it is impossible to explain the precise workings of the rule to
> a class of first years undergraduates
Then don't explain it to them. At York in the 3rd year Haskell course
it is never explained in detail, I think it might be briefly mentioned
in passing that some kind of indentation
> [an innocent question
I know this was me, and various things I do would be a LOT easier if
this standard interface did exist, but I don't think its possible.
To compare GHC, Hugs and Yhc - they have very little in common. Hugs
is written in C, the other two in Haskell, so for a start there is no
> habit of alway saying the full haskell core, ghc core, or jhc core (is
> there an nhc core?) but sometimes get sloppy.
Yhc ~= nhc, and Yhc has a Core:
http://www.haskell.org/haskellwiki/Yhc/API/Core
http://yhc06.blogspot.com/2005/12/yhc-core.html
Thanks
Neil
__
> Second, a warning about "loss of sharing" may befuddle beginners (who
> are usually not taught to write type signatures at the start).
Are standards documents the place for prescribing which warnings
should be raised, and under what circumstances?
If someone is using GHC, and has specified -O2
> Yes, I buy those arguments. But it's also rather convenient to be
> able to use -- in operators.
Really? Using hoogle I can't find any operators that have -- as a substring.
And some text editors can't handle regular expressions for syntax
definitions, in the same way that some editors don't p
> > 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
>
Another argument in favour of this is that most editors with syntax
hilighting will show --> as a comment, which again increases the
confusion factor.
Thanks
Neil
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listin
51 matches
Mail list logo
