provide a simple revision history and comment support. Please
feel free to contribute some tweaks and fixes. I'll then see about
merging this into haskell-mode in some fashion.
It doesn't handle multiple line explicit imports as I have a personal
rule that any explicit import list with more than a few
about
merging this into haskell-mode in some fashion.
It doesn't handle multiple line explicit imports as I have a personal
rule that any explicit import list with more than a few symbols should
be changed to an as X import, as an addition to tibbe's style
guide.[1]
I haven't decided
Simon Peyton-Jones [EMAIL PROTECTED] writes:
I don't think this would be too hard to implement in GHC. Now I think
about it, it's rather attractive. I wonder what other people think?
Perhaps {-# SYNTAX #-} is a bit noisy -- but Haskell's philosophy is
to signal very clearly when something
Fergus Henderson quoting Simon P J:
... Sergey essentially wants to
replace the entire prelude, special syntax and all. There are lots
of small but important things under the heading of special syntax:
Explicit lists [a,b,c]
List comprehensions
Numeric constants
Hello all!
There has been a discussion going on about if the list
constructor operators (:, [], and type []) should be dealt
with in the same way as with other function and type names.
I think there are two separate issues here:
1. Introduction of special syntactic identifiers for:
Jerzy Karczmarczuk [EMAIL PROTECTED] writes:
I don't want to replace the entire Prelude. But I work with
non-standard (*) mathematical objects, and this will continue for
some time.
I'm probably missing a lot of obviousities, but if this is indeed the
most common desire, why is it so hard
On 20-May-2000, Simon Peyton-Jones [EMAIL PROTECTED] wrote:
Of course, that doesn't solve the problem! Sergey essentially wants to
replace the entire prelude, special syntax and all. There are lots
of small but important things under the heading of special syntax:
If I recall correctly,
On 22-May-2000, Koen Claessen [EMAIL PROTECTED] wrote:
I think there are two separate issues here:
...
2. Syntactic sugar which is translated away using prelude
functions.
...
Issue number 2 is completely different and unrelated. Note
that this also includes normal prelude functions
Sat, 20 May 2000 13:13:22 -0700, Simon Peyton-Jones [EMAIL PROTECTED] pisze:
Explicit lists [a,b,c]
List comprehensions
Numeric constants (1 means 'fromInteger 1')
do notation
Here is an idea for an extension to Haskell 98 to support this.
[...]
It has small
On 21-May-2000, Marcin 'Qrczak' Kowalczyk [EMAIL PROTECTED] wrote:
Sat, 20 May 2000 13:13:22 -0700, Simon Peyton-Jones [EMAIL PROTECTED] pisze:
Explicit lists [a,b,c]
List comprehensions
Numeric constants (1 means 'fromInteger 1')
do notation
Here is an idea for an
Sun, 21 May 2000 17:26:13 +1000, Fergus Henderson [EMAIL PROTECTED] pisze:
But being able to import and/or re-export such symbols is necessary
if you want to be able to implement an alternative prelude.
No: they can be simply always available, just as \ and let.
Standard Prelude has to be
On 21-May-2000, Marcin 'Qrczak' Kowalczyk [EMAIL PROTECTED] wrote:
Sun, 21 May 2000 17:26:13 +1000, Fergus Henderson [EMAIL PROTECTED] pisze:
But being able to import and/or re-export such symbols is necessary
if you want to be able to implement an alternative prelude.
No: they can be
Sun, 21 May 2000 17:26:13 +1000, Fergus Henderson [EMAIL PROTECTED] pisze:
On a related note, Hugs and ghc both allow the following module
module Bar(List(..)) where
type List = []
without complaint, but according to the Haskell report (5.2) the
syntax `typename(..)' should only be
On 20-May-2000, Simon Peyton-Jones [EMAIL PROTECTED] wrote:
Of course, that doesn't solve the problem! Sergey essentially wants to
replace the entire prelude, special syntax and all. There are lots
of small but important things under the heading of special syntax:
Explicit lists
Mon, 15 May 2000 17:23:29 -0700, Sigbjorn Finne [EMAIL PROTECTED] pisze:
Really, it terminates? My copy (ghc-4.05) blows the stack, which is
sort of what I'd expect here ( Eq.(==) is defined in terms of Eq.(/=),
and vice versa,
Ah, I see: in ghc-4.07 the default implementation of (==) always
The good news is that ghc (4.04) does not follow the Haskell 98
report -- it accepts the following code, apparently as an
extension to Haskell 98 (even without `-fglasgow-exts'):
module Example(Prelude.[](..)) where
import Prelude([](..))
Similarly, it also accepts
On 15-May-2000, S.D.Mechveliani [EMAIL PROTECTED] wrote:
I am again stuck. Who could help, please?
module T
where
import Prelude ( tail, (.) ) -- List(..) ?
At first glance, I didn't see what the problem was.
But having tried it myself, I see why you're having difficulty.
I am again stuck. Who could help, please?
module T
where
import Prelude ( tail, (.) ) -- List(..) ?
f = tail . tail
g (x:xs) = xs
T wants to import explicitly tail, (.), List data.
---
tail, (.) work, and (:) does not,
On Mon, 15 May 2000, S.D.Mechveliani wrote:
import Prelude ( tail, (.) ) -- List(..) ?
[](..) or []([],(:))
And also: ()(..) or ()(())
AFAIR the report says that : is a special syntax that always refers to the
Prelude thing, for consistency with the rest of the list syntax. But in
GHC
On 15-May-2000, Marcin 'Qrczak' Kowalczyk [EMAIL PROTECTED] wrote:
On Mon, 15 May 2000, S.D.Mechveliani wrote:
import Prelude ( tail, (.) ) -- List(..) ?
[](..) or []([],(:))
And also: ()(..) or ()(())
AFAIR the report says that : is a special syntax that always refers to the
the grammar for import and export lists use `tycon'
and `qtycon' (respectively) rather than `gtycon'.
Is there any particular reason for this, or is this
just a defect in the Haskell 98 report?
Would changing `qtycon' to `gtycon' in the
grammar production for `export' cause any problems?
Tue, 16 May 2000 00:37:04 +1000, Fergus Henderson [EMAIL PROTECTED] pisze:
import Prelude ()
nil :: [a]
nil = []
or
import Prelude ()
cons :: a - [a]
cons h t = h : t
ghc rejects them both,
But does not reject if "import Prelude ()" is changed to
[EMAIL PROTECTED] [EMAIL PROTECTED] writes:
GHC has strange behavior on perverse numeric instances. Given this:
newtype T = T Integer deriving (Show)
instance Eq T
instance Num T
main = putStrLn $ case T 2 of
4 - "4"
_ - "_"
it outputs 4, even though (==) and fromInteger
23 matches
Mail list logo
