Brian Hulley wrote:
The use of a plain value to initialize the ref rather than a monadic
computation would ensure that there would be no problems with trying
to work out which order to initialize top level refs that are
dependent on values of refs in other modules since there could be no
Lennart Augustsson wrote:
And yes, somewhere there's some global mutable state in the OS.
I've never claimed that it should be totally forbidden. Various
circumstances forces it upon us. What I've been claiming is that
it should be avoided where possible. Which is almost always.
Thus there s
Brian Hulley wrote:
moduleOptions = ComposedOption "My module" [ModOption1, ModOption2]
moduleOptions = Option $ ComposedOption "My module" [ModOption1, ModOption2]
allOptions = ComposedOption "Name of program" [Module1.moduleOptions,
allOptions = Option $ C
John Meacham wrote:
On Thu, Apr 27, 2006 at 11:09:58AM +0100, Adrian Hey wrote:
What really frustrates me about all this is that AFAIK there are no
significant technical or theoretical reasons why we can't get
this safety (without resort to the unsafePerformIO hack). The
only serious obstacle se
Bulat Ziganshin wrote:
Hello Tomasz,
[snip]
ultimately, the main problem of all options-parsing stuff i ever seen,
is requirement to repeat option definition many times. if i have, say,
40 options, then i need to maintain 3 to 5 program fragments that deal
with each option. something like this:
Hi -
Given some large list of modules which need to be used qualified, I'd like
to be able to make a convenience module that I could use instead, and which
would export all these modules also qualified by an alias, ie:
module Top
( module qualified Top.First as First
, module quali
Brian Hulley wrote:
I've started work on a module to replace Control.Exception by
wrapping all the original Control.Exception functions in more general
monadic functions and using two type classes as follows:
class MonadIO m => MonadException m where
catch :: m a -> (Exception -
Simon Marlow wrote:
Brian Hulley wrote:
I've been looking at the docs for Haddock at
http://haskell.org/haddock/haddock-html-0.7/index.html but I can't
seem to find any option to recursively traverse a directory
generating hyperlinked docs for all modules anywhere in the
directory
Simon Marlow wrote:
Brian Hulley wrote:
Hi -
I have the following code:
[snip]
Is this just a bug in Haddock or am I misunderstanding something
about Haskell?
It's a bug / missing feature in Haddock. Haddock is basically pretty
dumb when it comes to understanding Haskell code; it
I've started work on a module to replace Control.Exception by wrapping all
the original Control.Exception functions in more general monadic functions
and using two type classes as follows:
class MonadIO m => MonadException m where
catch :: m a -> (Exception -> m a) -> m a
catchDyn :: Ty
Brian Hulley wrote:
instance MonadIOE m => StateT s m where ...
instance MonadIOE m => ReaderT r m where ...
instance MonadIOB m => ReaderT r m where ...
Ooops! ;-)
instance MonadIOE m => MonadIOE (StateT s m) where ...
instance MonadIOE m => MonadIOE (ReaderT r m) wher
[EMAIL PROTECTED] wrote:
Robert Dockins wrote:
One additional (very unfortunate) point is that higher-order IO monad
combinators will not work on your monad, eg, the ones in
Control.Exception.
Although that is true in general, for many useful and interesting
cases (including ReaderT, the state
Brian Hulley wrote:
Hi -
You could try something like:
import Foreign.Ptr
import Foreign.C.String
bmp <- withCAString "C:\1.bmp" $ bitmap (Size (100,100)) (Vertex2 0 0)
(Vertex2 0 0)
and if that doesn't work try withCString or withCWString. I'm
assuming that the Ptr a
Hi -
You could try something like:
import Foreign.Ptr
import Foreign.C.String
bmp <- withCAString "C:\1.bmp" $ bitmap (Size (100,100)) (Vertex2 0 0)
(Vertex2 0 0)
and if that doesn't work try withCString or withCWString. I'm assuming that
the Ptr a in the docs is supposed to be a pointer to
Hi -
I have the following code:
data MState = MState -- details omitted
type MonadStateMState = MonadState MState -- necessary for Haddock
newtype ManagerM a =
ManagerM (StateT MState IO a)
deriving (Monad, MonadIO, MonadStateMState)
which means that ManagerM is a
[EMAIL PROTECTED] wrote:
Robert Dockins wrote:
One additional (very unfortunate) point is that higher-order IO monad
combinators will not work on your monad, eg, the ones in
Control.Exception.
Although that is true in general, for many useful and interesting
cases (including ReaderT, the state
Hi -
I've been looking at the docs for Haddock at
http://haskell.org/haddock/haddock-html-0.7/index.html but I can't seem to
find any option to recursively traverse a directory generating hyperlinked
docs for all modules anywhere in the directory or any sub directory etc.
Is there a simple un
Brian Hulley wrote:
Robert Dockins wrote:
Sometimes I also think it would be nice if all the standard lib
functions with IO types would instead take arbitrary MonadIO types,
so you could avoid having to write down liftIO all the time
Thanks for the suggestion - it is certainly a lot
Robert Dockins wrote:
Are you compiling with -fglasgow-exts? You're relying on generalized
newtype deriving, which is a GHC extension.
http://www.haskell.org/ghc/docs/latest/html/users_guide/type-
extensions.html#newtype-deriving
If that's not it, what's the error you are getting?
'MonadStat
Robert Dockins wrote:
On Apr 21, 2006, at 10:34 AM, Brian Hulley wrote:
Robert Dockins wrote:
On Apr 21, 2006, at 9:56 AM, Brian Hulley wrote:
Hi -
I've run into the global mutable state problem described in http://
[snip]
There is only one GUI for the application and only one contr
Robert Dockins wrote:
On Apr 21, 2006, at 9:56 AM, Brian Hulley wrote:
Hi -
I've run into the global mutable state problem described in http://
www.haskell.org/hawiki/GlobalMutableState
Since the page was last edited in March last year, I'm wondering if
there have been any devel
Hi -
I've run into the global mutable state problem described in
http://www.haskell.org/hawiki/GlobalMutableState
Since the page was last edited in March last year, I'm wondering if there
have been any developments or further thoughts on how to safely create top
level IORefs since they are abso
On Wednesday 19th April 2006 21::55 Greg Fitzgerald wrote:
Brian,
> implementing the text buffer for an edit control
Just a few weeks ago I was thinking about a functional way to
implement an edit control. I ended up with the code below.
The function 'text' takes a stream of user input an
On Wednesday 19th April 2006 20:39 Udo Stenzel wrote:
[snip]
Even better, thanks to Ross Paterson you can get code at
http://www.soi.city.ac.uk/~ross/software/html/Data.Sequence.html or
simply get a recent version of GHC:
http://www.haskell.org/ghc/dist/current/docs/libraries/base/Data-Sequence.
Robert Dockins wrote:
On Apr 19, 2006, at 3:06 PM, Brian Hulley wrote:
Thanks. I might try this if I don't have any luck with finger trees
(from Udo's post), or if they seem too heavy for the simple thing
I'm planning to use them for (implementing the text buffer for an
edi
Cale Gibbard wrote:
I should perhaps point out that in the development GHC (iirc), there
is a library called Data.Sequence which uses 2-3 finger trees to get
rather nice efficient sequences. Operations on both ends (appending or
dropping) are constant time, while operations in the middle tend to
Sebastian Sylvan wrote:
On 4/19/06, Brian Hulley <[EMAIL PROTECTED]> wrote:
[snip]
Ideally I'd like functions like:
-- Insert new elements starting at the specified index, moving the
others up to make room
insert:: Array i e -> i -> [e] -> Array i e
-- Delete a range of el
Thanks. I might try this if I don't have any luck with finger trees (from
Udo's post), or if they seem too heavy for the simple thing I'm planning to
use them for (implementing the text buffer for an edit control which needs a
mutable array of lines where each line contains a mutable array of ch
On Wednesday 19th April 2006 18:09PM Udo Stenzel wrote:
Brian Hulley wrote:
In C++, STL provides a vector class which behaves as an array except you
can insert/delete elements from it.
Though you shouldn't. If you constantly insert and delete in the middle
of a std::vector, you&#
Hi -
In C++, STL provides a vector class which behaves as an array except you can
insert/delete elements from it. I'm wondering what is the best Haskell data
structure to use to simulate this, either mutable or immutable.
I've looked at the Array interface, but although there is the // operati
Brian Hulley wrote:
John Meacham wrote:
[snip]
1. one really does logically derive from the other, Eq and Ord are
like this, the rules of Eq says it must be an equivalance relation
and that Ord defines a total order over that equivalance relation.
this is a good thing, as it lets you write code
John Meacham wrote:
On Thu, Apr 06, 2006 at 10:52:52PM +0100, Brian Hulley wrote:
[snip]
The problem of allowing classes (in Haskell) to inherit is that you
end up with heirarchies which fix the design according to some
criteria which may later turn out to be invalid, whereas if there
were no
John Meacham wrote:
On Thu, Apr 06, 2006 at 09:31:24PM +0100, Brian Hulley wrote:
I've been wondering for a long time if there is a reason why Ord
should inherit from Eq and not vice versa, or whether in fact there
is any justification for making either Ord or Eq inherit from the
othe
Hi -
I've been wondering for a long time if there is a reason why Ord should
inherit from Eq and not vice versa, or whether in fact there is any
justification for making either Ord or Eq inherit from the other one.
For example, Ord and Eq could alternatively be defined as:
class Ord a where
(<
Robert Dockins wrote:
On Apr 1, 2006, at 3:23 PM, Brian Hulley wrote:
[snip]
" For particular types T1 and T2, if (f (x::T1))::T2 === g x for
all x in T1 then f :: T1->T2 and g ::T1->T2 can be freely
substituted since the context T1->T2 cannot tell them apart."
Having thoug
Claus Reinke wrote:
[snip]
... (try this for
one study of the many definitions [scanned paper - >3MB]:
http://www.dina.kvl.dk/~sestoft/papers/SondergaardSestoft1990.pdf ).
Thanks for the link,
Regards, Brian.
___
Haskell-Cafe mailing list
Haskell-Caf
Robert Dockins wrote:
[snip]
From an earlier post:
Now since f and g compute the same results for the same inputs,
anywhere in a program that you can use f you could just replace f
by g and the observable behaviour of the program would be
completely unaffected. This is what referential transpar
Robert Dockins wrote:
On Saturday 01 April 2006 11:53 am, Brian Hulley wrote:
Claus Reinke wrote:
the usual way to achieve this uses the overloading of Nums in
Haskell: when you write '1' or '1+2', the meaning of those
expressions depends on their types. in particular, th
Brian Hulley wrote:
(==) (Add xs) (Add ys) = and (map (\(x, y) -> x==y) (zip xs ys))
What on earth was I thinking!!! ;-) Should be:
(==) (Add xs) (Add ys) = xs == ys
(Doesn't affect the validity of my argument though...)
___
Hask
Claus Reinke wrote:
the usual way to achieve this uses the overloading of Nums in Haskell:
when you write '1' or '1+2', the meaning of those expressions depends
on their types. in particular, the example above uses 'T Double', not
just 'Double'.
However there is nothing in the functions themsel
Greg Buchholz wrote:
Hmm. It must be a little more complicated than that, right? Since
after all you can print out *some* functions. That's what section 5
of _Fun with Phantom Types_ is about. Here's a slightly different
example, using the AbsNum module from...
http://www.haskell.org/haw
Greg Buchholz wrote:
Neil Mitchell wrote:
Now lets define "super show" which takes a function, and prints its
code behind it, so:
superShow f = "not"
superShow g = "\x -> case ..."
now superShow f /= superShow g, so they are no longer referentially
transparent.
OK. I'm probably being rea
Hi -
In a discussion started on the GHC mailing list
http://www.haskell.org//pipermail/glasgow-haskell-users/2006-March/009923.html I
discovered an idea for typing imperative API functions that may be of
interest to other people, and which makes use of Haskell's type system to
achieve a level
Brian Hulley wrote:
Robin Green wrote:
On Wed, 29 Mar 2006 12:50:02 +0100
Jon Fairbairn <[EMAIL PROTECTED]> wrote:
[snip]
1) choosing the optimal reduction strategy is undecidable
2) we shouldn't (in general) attempt to do undecidable
things automatically
[snip]
[snip]
I sug
Robin Green wrote:
On Wed, 29 Mar 2006 12:50:02 +0100
Jon Fairbairn <[EMAIL PROTECTED]> wrote:
[snip]
1) choosing the optimal reduction strategy is undecidable
2) we shouldn't (in general) attempt to do undecidable
things automatically
[snip]
[snip]
I suggest that a Haskell program should b
Ben Rudiak-Gould wrote:
Brian Hulley wrote:
Is there a reason for using && instead of
[exists a. Resource a=>a]
?
Only that => looks like a function arrow, && looks like a tuple. I
stole this notation from an unpublished paper by SimonPJ et al on
adding existen
Ben Rudiak-Gould wrote:
Matthias Fischmann wrote:
now i want to create a list of a type similar to
[r1, r2, r3] :: (Resource a) => [a]
but with r1 being pizza, r2 being crude oil, and so on.
The type you actually want here is [exists a. (Resource a) && a], but
no Haskell implementation sup
Christian Maeder wrote:
Martin Percossi wrote:
matMul a b = do { let foo = 2*5; return a }
probably
{ let {foo = 2*5}; return a }
will work (untested)
your ";" indicates a further let-equation, but the possibility to use
";" without "{" and "}" is a bit pathologic (and haddock used to
re
Nils Anders Danielsson wrote:
On Tue, 07 Mar 2006, "Brian Hulley" <[EMAIL PROTECTED]> wrote:
(Moved from ghc-users.)
Brian Hulley wrote:
(time for a proper email client to be written in Haskell! ;-) )
I had the same thought yesterday, after an Emacs-Lisp session in which
Shannon -jj Behrens wrote:
I did think of using a monad, but being relatively new to Haskell, I
was confused about a few things. Let's start by looking at one of my
simpler functions:
-- Keep pushing tokens until we hit an identifier.
pushUntilIdentifier :: ParseContextTransformation
pushUntilI
Brian Hulley wrote:
translate :: (Monad m) => String -> m String
translate = do
createParseContext
readToFirstIdentifier
dealWithDeclarator
consolidateOutput
The type signature above doesn't m
Shannon -jj Behrens wrote:
I find "ctx |> currTok |> tokenType" to be more readable than
"tokenType $ currTok $ ctx" because you're not reading the code in
reverse. That's my primary complaint with "." and "$". That's
especially the case when I'm spreading the code over multiple lines:
-- Tran
Harry Chesley wrote:
But here's the thing that makes it hard (at least for me): two
programs are considered the same if they can be made to match by
rearranging the order of the input parameters. I.e., "f(a), g(b)" is
the same as "f(b), g(a)". Although parameters can be reordered, they
cannot be
Malcolm Wallace wrote:
Brian Hulley wrote:
However I think there is an error in the description of this in
section 2.7 of the Haskell98 report, which states:
"If the indentation of the non-brace lexeme immediately following a
where, let, do or of is less than or equal to the cu
Neil Mitchell wrote:
stackTop ctx =
let (x:xs) = stack ctx in x
stackTop ctx = head ctx
stackTop ParseContext{stack=x:_} = x
or:
stackTop ctx = head (stack ctx)
===stackTop ctx = head . stack $ ctx
===stackTop = head . stack
Regards, Brian.
_
Daniel Fischer wrote:
Am Freitag, 3. März 2006 19:21 schrieb Brian Hulley:
Brian Hulley wrote:
Brian Hulley wrote:
[snip]
AFAICT, the description in the report is correct, *except for the
'where' in module LayOut where*.
[snip]
So my guess is that layout-processing is applied o
Brian Hulley wrote:
Brian Hulley wrote:
One other thing I've been wanting to ask (not to change! :-)) for a
while is: how is the following acceptable according to the rules in
the Haskell98 report where "where" is one of the lexemes, which when
followed by a line more indented th
Brian Hulley wrote:
[snip]
So any solutions welcome :-)
Thank to everyone who replied to my queries about this whole layout issue.
One other thing I've been wanting to ask (not to change! :-)) for a while
is: how is the following acceptable according to the rules in the Haskell98
r
Benjamin Franksen wrote:
[snip]
I am used to hitting TAB key and get the correct number of spaces,
according to how I configured my editor (NEdit) for the current
language mode.
The only thing then is what happens when you type backspace or left arrow to
get back out to a previous indentation?
Ben Rudiak-Gould wrote:
Brian Hulley wrote:
Here is my proposed layout rule:
1) All layout keywords (where, of, let, do) must either be followed
by a single element of the corresponding block type, and explicit
block introduced by '{', or a layout block whose first line starts
on
Ben Rudiak-Gould wrote:
Brian Hulley wrote:
Whoever thought up the original Haskell layout rule assumed that
people would be happy using a single fixed width font, tabs set to 8
spaces, and didn't care about the brittleness of the code (in the
face of identifier renamings) it allowed o
David F. Place wrote:
On Feb 27, 2006, at 5:54 PM, Brian Hulley wrote:
there is a parse error (using ghc) at the line beginning with
result'. This binding doesn't line up with anything. Also the
second 'where' is dangerously close to the column started by the
'f'
David F.Place wrote:
[snip]
partList :: Ord k => [([k],v)]->[k]->[(k,[([k],v)])]
partList pairs alphabet = reverse . fst $ foldl' f ([],pairs) alphabet
where f (result,pairs) l = (result',rest)
where (part,rest) = span ((==l) . head . fst) pairs
result' = if null part
Matthias Fischmann wrote:
| -- fix rounding error:
| repair [i] = [upper]
| repair (h:t) = h : repair t
Just to point out that this only fixes the last element of the list, so
inputs like [1,2,10.8,10.8] would not be handled properly if you require the
same input values to map to
Neil Mitchell wrote:
Hi Pete,
a = (<)
b x = (x <)
c x y = (x < y)
I'm pretty sure this is the Monomorphism Restriction, its on the wiki
at: http://www.haskell.org/hawiki/MonomorphismRestriction
You can use ghc -fno-monomorphism-restriction to compile the above or
alternatively give a type
Brian Hulley wrote:
Another confusing thing is the use of the word "inheritance" in
tutorials/books about class declarations. Unlike object oriented
languages, where a class or interface gets all the methods of its
ancestor classes/interfaces in addition to some new methods declar
Hi -
In
http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/src-distribution/versions/HetCATS/docs/Programming-Guidelines.txt
one of the recommendations states:
"Don't put class constraints on a data type, constraints belong only to the
functions that manipulate the d
Cale Gibbard wrote:
On 09/02/06, Brian Hulley <[EMAIL PROTECTED]> wrote:
Brian Hulley wrote:
f :: forall m. (forall a. a->m a) -> c -> d -> (m c, m d)
Of course this type doesn't work on your original example, since (,)
is a type constructor with two parameters,
Brian Hulley wrote:
Brian Hulley wrote:
Brian Hulley wrote:
f :: (forall a m. a -> m a) -> c -> d -> (m c, m d)
The above is wrong - there is no way to quantify m properly. This
must be why intersection types need to be written with "&" after
all
Wh
Brian Hulley wrote:
Brian Hulley wrote:
f :: (forall a m. a -> m a) -> c -> d -> (m c, m d)
The above is wrong - there is no way to quantify m properly. This
must be why intersection types need to be written with "&" after
all
What am I saying! It&#x
Brian Hulley wrote:
f :: (forall a m. a -> m a) -> c -> d -> (m c, m d)
The above is wrong - there is no way to quantify m properly. This must be
why intersection types need to be written with "&" after all
__
Cale Gibbard wrote:
On 08/02/06, Brian Hulley <[EMAIL PROTECTED]> wrote:
Fred Hosch wrote:
Is type inferencing in Haskell essentially the same as in SML?
Thanks.
Well, that depends on what you mean by "essentially the same" ;-)
Both languages are based on the same Hin
Fred Hosch wrote:
Is type inferencing in Haskell essentially the same as in SML? Thanks.
Well, that depends on what you mean by "essentially the same" ;-)
Both languages are based on the same Hindley-Milner type inference
algorithm, so both suffer from the same problem that a function such as
Robert Dockins wrote:
[Moved to cafe; time to stop bothering the Haskell' committee...]
On Feb 8, 2006, at 1:19 PM, Malcolm Wallace wrote:
Robert Dockins <[EMAIL PROTECTED]> writes:
instance (Bin a,Bin b,Bin c,Bin d) => Bin (a,b,c,d)
See the problem? Sooner or later (probably sooner) I'll g
Ben Rudiak-Gould wrote:
Brian Hulley wrote:
One motivation seems to be that in the absence of whole program
optimization, the strictness annotations on a function's type can
allow the compiler to avoid creating thunks at the call site for
cross-module calls whereas using seq in the fun
Ben Rudiak-Gould wrote:
As Robert Dockins said, it's not implemented, and it isn't clear how
to implement it. At this point it's looking fairly likely that my PhD
thesis will be on this very topic, so stay tuned.
Isn't all this already implemented in Clean?
Regards, Brian.
___
Bulat Ziganshin wrote:
yes, i remember this SPJ's question :) "[!a]" means that list
elements are strict, it's the same as defining new list type with
strict elements and using it here. "![a]" means "strict list", it is
the same as defining list with "next" field strict:
data List1 a = Nil1 | L
Tomasz Zielonka wrote:
On Sun, Feb 05, 2006 at 04:36:44PM -, Brian Hulley wrote:
Just in case you are interested, in the "preprocessor" I'm writing,
I would write these examples as:
(.) #>
f x y
g x
h x
Chris Kuklewicz wrote:
Brian Hulley wrote:
Ben Rudiak-Gould wrote:
Paul Hudak wrote:
Minor point, perhaps, but I should mention that : is not special
syntax -- it is a perfectly valid infix constructor.
... but no more confusing than the fact that [f x | x <- xs] is
not the same as (
Ben Rudiak-Gould wrote:
Paul Hudak wrote:
Minor point, perhaps, but I should mention that : is not special
syntax -- it is a perfectly valid infix constructor.
>
... but no more confusing than the fact that [f x | x <- xs] is
not the same as (map f xs).
Can you explain why? On page 258 of P
Tomasz Zielonka wrote:
On Sun, Feb 05, 2006 at 05:18:55PM -, Brian Hulley wrote:
I must admit I'm a bit confused as to why the strictness annotations
in Haskell (and Clean) are only allowed in data declarations and not
function declarations
Clean does allow strictness annotatio
Tomasz Zielonka wrote:
On Sun, Feb 05, 2006 at 01:10:24PM -, Brian Hulley wrote:
2) Use "," instead of ";" in the block syntax so that all brace
blocks can be replaced by layout if desired (including record blocks)
Wouldn't it be better to use ; instead of , al
Bulat Ziganshin wrote:
Hello Brian,
Saturday, February 04, 2006, 4:50:44 AM, you wrote:
One question is how to get some kind of "do" notation that would
work well in a strict setting.
The existing "do" notation makes use of lazyness in so far as the
second arg of >> is only evaluated when nee
Brian Hulley wrote:
Brian Hulley wrote:
Robin Green wrote:
So simply make strictness the default and have laziness annotations
(for arguments), instead of making laziness the default and having
strictness annotations.
Where would you put these laziness annotations?
If you put them in the
Tomasz Zielonka wrote:
On Sun, Feb 05, 2006 at 01:14:42PM -, Brian Hulley wrote:
How about:
f x y
. g x
$ z
then you only need to add the line
. h x y
But then you have a problem when you when you want to add something
at the beginning ;-) With right-assoc $ adding
Tomasz Zielonka wrote:
The only problem I see right now is related to change locality. If I
have a chain like this:
f x y .
g x $
z
and I want to add some transformation between g and z I have to
change one line and insert another
f x y .
g x .
h x y $
z
With right-associ
Jon Fairbairn wrote:
Brian Hulley wrote:
Not exactly alone; I've felt it was wrong ever since we
argued about it for the first version of Haskell. ":" for
typing is closer to common mathematical notation.
But it's far too late to change it now.
- it's just sy
[EMAIL PROTECTED] wrote:
G'day all.
Quoting [EMAIL PROTECTED]:
This is the way that I normally express it. Partly because I find
function application FAR more natural than right-associative
application,
I meant to say that I find function COMPOSITION more natural than
right-associative appl
Jared Updike wrote:
[a,b,c ; tail] === a :: b :: c :: tail --
where ::
How is [a,b,c ; tail] simpler, clearer or less typing than
a:b:c:tail ? I think that the commas and semicolons are easy to
confuse.
It seems strange that you can write [a,b,c] with a nice list
Stefan Holdermans wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian wrote:
I think the mystery surrounding :: and : might have been that
originally people thought type annotations would hardly ever be
needed whereas list cons is often needed, but now that it is
regarded as good practi
Tomasz Zielonka wrote:
On Sat, Feb 04, 2006 at 07:15:47PM -, Brian Hulley wrote:
I think the mystery surrounding :: and : might have been that
originally people thought type annotations would hardly ever be
needed whereas list cons is often needed, but now that it is
regarded as good
Brian Hulley wrote:
Tomasz Zielonka wrote:
On Sat, Feb 04, 2006 at 02:52:20PM -, Brian Hulley wrote:
Hi -
In the Haskell98 report section 4.4.2 $ is specified as being right
associative. This means that f $ a0 a1 $ b0 b1 would parse as f (a0
a1 (b0 b1)) which seems rather strange to me
Tomasz Zielonka wrote:
On Sat, Feb 04, 2006 at 02:52:20PM -, Brian Hulley wrote:
Hi -
In the Haskell98 report section 4.4.2 $ is specified as being right
associative. This means that f $ a0 a1 $ b0 b1 would parse as f (a0
a1 (b0 b1)) which seems rather strange to me. Surely it would be
much
Hi -
In the Haskell98 report section 4.4.2 $ is specified as being right
associative. This means that f $ a0 a1 $ b0 b1 would parse as f (a0 a1 (b0
b1)) which seems rather strange to me. Surely it would be much more useful
if $ were defined as left associative so that it could be used to separa
Brian Hulley wrote:
Robin Green wrote:
So simply make strictness the default and have laziness annotations
(for arguments), instead of making laziness the default and having
strictness annotations.
Where would you put these laziness annotations?
If you put them in the function declaration eg
Brian Hulley wrote:
if' :: ~a -> ~b -> Bool
Oooops :-)
if' :: Bool -> ~a -> ~a -> a
Regards, Brian.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
John Meacham wrote:
On Fri, Feb 03, 2006 at 07:33:12PM -, Brian Hulley wrote:
One question is how to get some kind of "do" notation that would
work well in a strict setting.
The existing "do" notation makes use of lazyness in so far as the
second arg of >> is
Robin Green wrote:
On Fri, 3 Feb 2006 19:33:12 -
"Brian Hulley" <[EMAIL PROTECTED]> wrote:
I've been thinking along these lines too, because it has always
seemed to me that laziness is just a real nuisance because it hides a
lot of inefficiency under the carpet as we
Jan-Willem Maessen wrote:
I pointed out some problems with strict Haskell in a recent talk, but
I think it'd be worth underscoring them here in this forum.
Is the text of this talk or points raised in it available online anywhere?
There is one very difficult piece of syntax in a strict setti
Bulat Ziganshin wrote:
Hello Wolfgang,
Friday, February 03, 2006, 1:46:56 AM, you wrote:
i had one idea, what is somewhat corresponding to this 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 (laz
301 - 400 of 421 matches
Mail list logo
