On Thu, Feb 02, 2006 at 01:05:57PM +, Ross Paterson wrote:
> Personally, I'm not sure about caseless underscore, concurrency, natural
> numbers and parallel list comprehensions.
There is one more reason to leave concurrency out of the standard.
Some experts (like Hans Boehm) argue, that concu
On 2/2/06, John Meacham <[EMAIL PROTECTED]> wrote:
> but it currently doesn't recognize any unicode characters as possible
> operators. which it should, but I am just not sure how to specify that
> yet until some sort of standard develops. Once there are more unicode
> compliant compilers out there
Ravi Nanavati wrote:
> Multi-parameter type classes, yes. Functional dependencies, no.
My experience is that even with very simple applications of MPTCs,
I often end up needing functional dependencies to make things work.
As a user, I'll echo this.
Me three, etc.
Might it be worth holdin
Just for larks, here is a side by side of the various compilers core for
the example on that page:
Haskell:
> module FibMain where
>
> main xs = pam daeh xs
>
> daeh (x:xs) = x
>
> pam f [] = []
> pam f (x:xs) = f x : pam f xs
Yhc:
> FibMain.pam v220 v221 =
> case v221 of
> Prelude.
> 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
__
oh, not that I don't see your points about it not being a pragma, I just
wanted to point to some previous work on the matter. All I know for sure
is {-# OPTIONS ... #-} is not a very good solution :)
John
--
John Meacham - ⑆repetae.net⑆john⑈
__
This sounds similar to the proposed LANGUAGE pragma which I believe is
already parsed by cabal and I'd like jhc (and the other compilers) to
parse it directly. Something I'd like to see come out of this comitee is
a process to get new extensions standardized independently of the
language. However,
john:
> On Thu, Feb 02, 2006 at 11:19:09AM +, Malcolm Wallace wrote:
> > There is a potential confusion here between the H-core language as used
> > in the Haskell'98 report, and ghc's current external-core language.
> > The former contains classes, and the latter does not. Ghc-core has
> > ty
On Thu, Feb 02, 2006 at 11:19:09AM +, Malcolm Wallace wrote:
> There is a potential confusion here between the H-core language as used
> in the Haskell'98 report, and ghc's current external-core language.
> The former contains classes, and the latter does not. Ghc-core has
> type-lambdas, but
On Thu, Feb 02, 2006 at 06:19:43PM -0600, Taral wrote:
> Got a unicode-compliant compiler?
sure do :)
but it currently doesn't recognize any unicode characters as possible
operators. which it should, but I am just not sure how to specify that
yet until some sort of standard develops. Once there a
On 2/2/06, Benjamin Franksen <[EMAIL PROTECTED]> wrote:
> This would open the possibility to allow unary (prefix) operators in
> general which I find rather more useful than sections.
Down that road lies APL.
--
Taral <[EMAIL PROTECTED]>
"Computer science is no more about computers than astronomy
On 2/2/06, Wolfgang Jeltsch <[EMAIL PROTECTED]> wrote:
> 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 allowe
One issue that pains me with Haskell 98 is that it does nothing about
one of its
original stated goals as a programming language.
I've always been very fond of pointing out that Haskell has been
designed as a
language for EXPERIMENTATION with language features, and therefore the
mind-bogglin
On Thu, Feb 02, 2006 at 11:26:04PM +, Thomas Davie wrote:
> 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.
Holy Moly, you came up with an exam
On Thursday 02 February 2006 23:25, Wolfgang Jeltsch wrote:
> 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.
>
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
Am Dienstag, 31. Januar 2006 15:16 schrieb Bulat Ziganshin:
> [...]
> 1) significantly simplifies declarations using typeclasses. i
> was seriously bitten by those huge declarations, and think that
> simplification in this area will lead to much wider use of type
> classes by the ordibary users (l
On 03/02/2006, at 10:03 AM, Ian Lynagh wrote:
On Fri, Feb 03, 2006 at 09:54:59AM +1100, Patryk Zadarnowski wrote:
Yes, it *would* mean that (-x) and (- 1) are sections while (-1)
isn't, and
yes, that would be slightly confusing (and a good compiler might
want to
issue a warning whenever it se
Am Dienstag, 31. Januar 2006 13:40 schrieb Marcin 'Qrczak' Kowalczyk:
> "Simon Marlow" <[EMAIL PROTECTED]> writes:
> > I've always liked the idea of saying 'class C' or 'type T' in
> > import/export lists.
>
> Type signatures too should be allowed in export lists.
Shouldn't we also allow fixity de
On Thu, Feb 02, 2006 at 03:09:35PM +, Henrik Nilsson wrote:
> Now, I'm not saying that FDs are that important, only that it seems
> to me they are. I'd be happy to be convinced of the opposite.
> But from the above, it at least seems that John M. too actually
> says that FDs are important?
Oh,
On Fri, Feb 03, 2006 at 09:54:59AM +1100, Patryk Zadarnowski wrote:
> On 03/02/2006, at 9:25 AM, Wolfgang Jeltsch wrote:
>
> >Am Mittwoch, 1. Februar 2006 01:32 schrieb Patryk Zadarnowski:
> >>[...]
> >
> >>The proposal would be to remove the unary "-" altogether, and,
> >>instead,
> >>extend th
On 03/02/2006, at 9:25 AM, Wolfgang Jeltsch wrote:
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
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 hsLineCommen
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 trans
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
co
On Thu, Feb 02, 2006 at 07:06:07PM +, Ben Rudiak-Gould wrote:
> Johannes Waldmann wrote:
> >(With that respect, braces in records and let and where are OK,
> >since order is irrelevant, but in do { .. } they are not,
> >but that's how we show our sympathy to C and Java, right.)
>
> You forge
On Thu, Feb 02, 2006 at 12:46:13PM -0800, Ashley Yakeley wrote:
> If Haskell Prime is going to have certain type extensions rolled in, can
> we make changes to the standard libraries that take advantage of these?
I would hope so. But then, just what are the standard libraries
anymore? The Haske
Josef Svenningsson:
> I'm in favour of changing the comment syntax.
>
> On 2/2/06, Manuel M T Chakravarty <[EMAIL PROTECTED]> wrote:
> I am against such a change. The change would break existing
> software
> (eg, Yampa) and secondly I don't buy the "main sources of
>
Hello Bulat,
Thursday, February 02, 2006, 3:48:45 PM, you wrote:
JW>> When I first learned functional dependencies
JW>> I remember I was really confused by their syntax.
JW>> First, it is hard to find it defined:
BZ> Hugs documentation contains excellent introduction into the fundeps.
namely ch
On Thu, 2 Feb 2006, Taral wrote:
> On 2/2/06, Philippa Cowderoy <[EMAIL PROTECTED]> wrote:
> > Not in the context of a predicative type system. Also, if we treat it
> > simply as an annotation (exists a . a), we end up throwing away the
> > additional information inferred.
>
> There's that word a
If Haskell Prime is going to have certain type extensions rolled in, can
we make changes to the standard libraries that take advantage of these?
--
Ashley Yakeley
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/list
On Thu, Feb 02, 2006 at 12:34:30PM -, Simon Marlow wrote:
> Still, you could argue that it doesn't actually tell you the cause of
> the problem: namely that i&j are being evaluated twice as often as you
> might expect by looking at the code.
Would not the "entries" count in the profile tip you
On 2/2/06, Philippa Cowderoy <[EMAIL PROTECTED]> wrote:
> Not in the context of a predicative type system. Also, if we treat it
> simply as an annotation (exists a . a), we end up throwing away the
> additional information inferred.
There's that word again. Can someone explain what "predicative" m
Johannes Waldmann wrote:
(With that respect, braces in records and let and where are OK,
since order is irrelevant, but in do { .. } they are not,
but that's how we show our sympathy to C and Java, right.)
You forget "let { f [] _ = 1 ; f _ [] = 2 } in f [] []".
-- Ben
_
Malcolm Wallace wrote:
The main conceptual difference is that H-core aims merely for simpler
expression of common syntactic constructs, whereas ghc-core aims
for low-level optimisability.
I think the fundamental difference is that the translation to GHC core is
type-directed, while the transla
On Thu, 2006-02-02 at 11:38 +0100, John Hughes wrote:
> For the last few days, my mail-box has been full of mail about the M-R,
> lazy pattern
> matching, n+k patterns, comment syntax--it's just like the good old
> days! And that
> worries me.
>
> Each of these topics is a snake pit--a tricky ar
I think this thread has outlived its usefulness. I ask the participants
to please take the time to summarize the pros & cons on the wiki, or in
this ticket if you don't have access to the wiki:
http://haskell.galois.com/cgi-bin/haskell-prime/trac.cgi/ticket/42
Most of the discussion lately has j
On Thu, 2 Feb 2006, Bulat Ziganshin wrote:
> Hello Philippa,
>
> Thursday, February 02, 2006, 3:38:15 AM, you wrote:
>
> >> btw, on the
> >> http://haskell.galois.com/trac/haskell-prime/wiki/PartialTypeSigs
> >> author mean using underscore for "(exists a . a)" types
> >>
>
> PC> No I don't,
> But isn't the whole point of Haskell' to standardise those features
> that are agreed to be necessary for writing real-world
> applications and libraries in a reasonable way?
Assuming for a little while that we'd actually want to incorporate FDs
in Haskell'. Could we even do it? Is there a docum
Hmm. Seems I missed sending this to haskell-prime.
Sorry.
/Henrik
--
Henrik Nilsson
School of Computer Science and Information Technology
The University of Nottingham
[EMAIL PROTECTED]
This message has been checked for viruses but the contents of an attachment
may still contain software viruses
Dear all,
John Mecham wrote:
> Yeah, I have been coming to the same conclusion myself. it pains me a
> lot. (monad transformers! I need thee!) but its not like fundeps will
> go away, they will just still be experimental so it isn't the end of
> the world.
But isn't the whole point of Haskell'
If this really is a big problem for beginners, it would not seem
totally infeasible to add some special code that helpfully suggests
that a space perhaps ought to be inserted?
Here is what Helium says:
Warning: Syntax colouring usually can not handle names containing --
Hint: If you wanted to
| We didn't dare include MPTCs in Haskell 98 because the number one goal
| on that occasion was to be conservative! But if we had taken that view
when
| Haskell was first designed, classes would never have seen the light of
| day at all. I think now is the time to bite this bullet.
I'm all for bit
From: Henrik Nilsson <[EMAIL PROTECTED]>
Subject: Re: MPTCs and functional dependencies
Simon PJ wrote:
> Multi-parameter type classes, yes. Functional dependencies, no.
My experience is that even with very simple applications of MPTCs,
I often end up needing functional dependencies to make
On Thu, Feb 02, 2006 at 11:36:34AM -, Simon Peyton-Jones wrote:
> I'm confident that it is premature to standardise functional
> dependencies at this stage, very useful though they are. If you doubt
> me, read the JFP journal submission that Martin Sulzmann and Peter
> Stuckey and I have been
On Thu, Feb 02, 2006 at 03:34:57PM +0300, Bulat Ziganshin wrote:
> JM> Also, the need for it is questionable if we were to allow polymorphic
> JM> components and newtype deriving. if your data acts differently then it
> JM> should be a different type with a newtype and derive all the properties
> J
Henrik Nilsson wrote:
Dear all,
Simon PJ wrote:
> Multi-parameter type classes, yes. Functional dependencies, no.
My experience is that even with very simple applications of MPTCs,
I often end up needing functional dependencies to make things work.
As a user, I'll echo this. It seems to me
> ... read the JFP journal submission that Martin Sulzmann and Peter
> Stuckey and I have been working on.
> http://research.microsoft.com/%7Esimonpj/papers/fd-chr
Has this list discussed using CHRs instead of fundeps?
Jim
___
Haskell-prime mail
Hello Philippa,
Thursday, February 02, 2006, 3:38:15 AM, you wrote:
>> btw, on the http://haskell.galois.com/trac/haskell-prime/wiki/PartialTypeSigs
>> author mean using underscore for "(exists a . a)" types
>>
PC> No I don't, for a number of technical reasons.
are you sure? this "_" means "an
Hello Johannes,
Thursday, February 02, 2006, 2:17:42 PM, you wrote:
JW> When I first learned functional dependencies
JW> I remember I was really confused by their syntax.
JW> First, it is hard to find it defined:
i should wrote this earlier, but nevertheless:
Hugs documentation contains excell
Hello John,
Thursday, February 02, 2006, 12:51:58 PM, you wrote:
JH> Let me make clear that what concerns me is not the impact of the M-R on
JH> space and time
JH> performance on average. What concerns me is the difficulty of debugging
JH> performance
JH> problems.
may be it's better in such ca
Hello John,
Thursday, February 02, 2006, 6:03:06 AM, you wrote:
>> Unfortunately, local instance declarations threaten the coherence
>> property of type classes and principle types. See for example,
>> ``Functional pearl: implicit configurations—or, type classes reflect the
>> values of types'',
Hello John,
Thursday, February 02, 2006, 4:24:06 AM, you wrote:
>> It can, but so far it's really ugly to apply transformations to entire
>> modules. A little syntactic sugar could be good there.
JM> module $hat.Foo(..) where
JM> ...
JM> could mean pass the entire module through the 'hat' funct
Hello Manuel,
Thursday, February 02, 2006, 3:40:26 AM, you wrote:
MMTC> I am against such a change. The change would break existing software
MMTC> (eg, Yampa) and secondly I don't buy the "main sources of
MMTC> confusion for beginners" argument. The confusion arises only when a
MMTC> single l
Dear all,
Simon PJ wrote:
> Multi-parameter type classes, yes. Functional dependencies, no.
My experience is that even with very simple applications of MPTCs,
I often end up needing functional dependencies to make things work.
Thus, if my hunch is right, and other people have a similar experi
On Thu, Feb 02, 2006 at 11:38:07AM +0100, John Hughes wrote:
> The problem with Haskell 98 is that it *lacks* features which
> have become absolutely essential to Haskell programmers today. Those
> features are what really *need* discussion and energy spent on them.
> [...]
> I'd like to see cleare
On 02 February 2006 09:52, John Hughes wrote:
> Summary: 2 programs failed to compile due to type errors (anna,
gg).
> One program did 19% more allocation, a few other programs
increased
> allocation very slightly (<2%).
>
> pic +0.28% +19.27% 0.
John Hughes <[EMAIL PROTECTED]> writes:
> Summary: 2 programs failed to compile due to type errors (anna, gg).
> One program did 19% more allocation, a few other programs increased
> allocation very slightly (<2%).
>
> pic +0.28% +19.27% 0.02
>
>
>
> Thanks, that w
I'm confident that it is premature to standardise functional
dependencies at this stage, very useful though they are. If you doubt
me, read the JFP journal submission that Martin Sulzmann and Peter
Stuckey and I have been working on.
http://research.microsoft.com/%7Esimonpj/papers/fd-chr
F
On Thu, Feb 02, 2006 at 11:38:07AM +0100, John Hughes wrote:
> The problem with Haskell 98 is that it *lacks* features which
> have become absolutely essential to Haskell programmers today. Those
> features are what really *need* discussion and energy spent on them.
>
> [...]
>
>Multi-paramet
John Meacham <[EMAIL PROTECTED]> writes:
> On Wed, Feb 01, 2006 at 02:51:08PM +, Philippa Cowderoy wrote:
> > specifying a dictionary-passing implementation of typeclasses -
>
> I am thinking we don't specify any particular translation scheme. just a
> sudset of the language that is consider
>Multi-parameter classes with functional dependencies
When I first learned functional dependencies
I remember I was really confused by their syntax.
First, it is hard to find it defined:
The GHC docs have barely three lines
http://www.haskell.org/ghc/docs/latest/html/users_guide/type-extensi
On Thu, 2006-02-02 at 11:38 +0100, John Hughes wrote:
> One such tool is wxHaskell--named by 19% of Haskell users in my survey,
> it's the de facto standard GUI toolkit. wxHaskell makes essential use of
> existential types in its interface, a strong reason for including them in
> Haskell'. It also
Manuel M T Chakravarty <[EMAIL PROTECTED]> writes:
> But we should probably ensure that, if the kind inference proposals
> don't make it, we revisit the possibility of having kind annotations.
> (Not sure what the best way is to ensure this in our process. Isaac?)
Wiki page and ticket added. (R
John Hughes wrote:
> The problem with Haskell 98 is that it *lacks* features which
> have become absolutely essential to Haskell programmers today. Those
> features are what really *need* discussion and energy spent on them.
Very well, but this looks like a discussion for implementors and
languag
For the last few days, my mail-box has been full of mail about the M-R,
lazy pattern
matching, n+k patterns, comment syntax--it's just like the good old
days! And that
worries me.
Each of these topics is a snake pit--a tricky area of language design,
with many
alternative possibilities and no
On 2/2/06, Henrik Nilsson <[EMAIL PROTECTED]> wrote:
Hi all,To corroborate Wadler's law further.:-) Josef wrote:
> Oh yes, it does happen that a single line comment begins with a > special symbol. It has happened to me on several occations when using > haddock annotation to my source code. It is a
Summary: 2 programs failed to compile due to type errors (anna, gg).
One program did 19% more allocation, a few other programs increased
allocation very slightly (<2%).
pic +0.28% +19.27% 0.02
Thanks, that was interesting. A follow-up question: pic has a spac
John Meacham wrote:
> module $hat.Foo(..) where ...
Before we invent more ad-hoc notation for annotations
(we already have deriving, {-# .. #-}, {-! .. -!} (DrIFT) )
can we replace all (or most) of this with a unified annotation syntax,
e. g. Java uses "@" notation which is basically allowed
at a
69 matches
Mail list logo
