If you say {-# INLINE f #-} on a fn defn for f, it'll get inlined at
all its call sites, which is sort of what you want. Just saying
'evaluate this CAF to WHNF' might only inline the outer combinator.
Generally, some precise way of controlling what gets evaluated
at compile time, a bit less
Hi Haskellers,
personally, I'd prefer to use a kind of labeled fields notation at the
point where the function is called, like:
addBase{?base=7} 5
In recursive calls, this notation would then be optional, of course.
If a function should be called multiple times with the same
value of the
Ch. A. Herrmann proposed:
| addBase{?base=7} 5
I like this! It is the least polluting syntax of all.
/Koen.
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
This bug is already fixed in 5.02.2, which is available now.
Simon
| -Original Message-
| From: Ashley Yakeley [mailto:[EMAIL PROTECTED]]
| Sent: 04 February 2002 02:23
| To: Haskell List
| Subject: Implicit Parameter Bug?
|
|
| What's wrong with this?
|
| f :: ((?param :: a) =
Ashley Yakeley [EMAIL PROTECTED] wrote,
At 2002-02-03 15:34, Manuel M. T. Chakravarty wrote:
The main disadvantage of this solution is that, in
Haskell, some keywords (`let', `case', `where', and `do')
trigger the layout rule and now `dynamic' or `nonrec'
would have to trigger the
Hi all,
Now we are talking about implicit parameters, let us take up
the following problem with them on the Haskell mailing list
too.
Suppose I have the following function definition:
app :: (?ys :: [a]) = [a] - [a]
app xs =
case ?ys of
[] - xs
(y:ys') - y : (app xs
| p :: Maybe ((?param :: a) = a)
| p = return g;
Neither GHC nor Hugs allow a polymorphic type variable
(the argument of Maybe) to be instantiated to a polymorphic
type. Systems which do are called 'impredicative' (or is it the
other way around?). Going impredicative has big negative
Suppose I have the following function definition:
app :: (?ys :: [a]) = [a] - [a]
app xs =
case ?ys of
[] - xs
(y:ys') - y : (app xs with ?ys = ys')
This function appends its argument to its implicit argument,
Title: RE: Implicit Parameters
I'm obviously missing something here.
I dont understand what monomorphism has to do with
the given example as the implicit parameter would be
the same type [a] for some type a in each case.
If we made the parameter explicit then
removing the type
| I propose replacing the above with the following. It does
| mean that CRLF creates 2 newlines, but I don't believe
| this should be a problem.
|
| whitechar- newline | vertab | formfeed | space | tab | uniWhite
| newline - return | linefeed
| return - a carriage return
|
On Mon, Feb 04, 2002 at 03:15:40AM -0800, Simon Peyton-Jones wrote:
| I propose replacing the above with the following. It does
| mean that CRLF creates 2 newlines, but I don't believe
| this should be a problem.
|
| whitechar- newline | vertab | formfeed | space | tab | uniWhite
|
[Resent with permission of author -=chak]
I'm beginning to find implicit parameters *extremely* useful, so I think it's
important to get this right. I have some code that will have to change, but not
as much as I will have in a couple of years...!
I find adding a keyword to implicit parameter
Summer School and Workshop on Generic Programming
St Anne's College, Oxford, UK
26th to 30th August 2002
In conjunction with
Summer School and Workshop on Advanced Functional Programming
This school is a successor to the Summer School and Workshop on
The haskell.org server was replaced on Sat with a new machine.
Although care was taken to migrate all the files it looks like
we missed some. The good news is the old server is still available
and most likely has the missing archives.
I'll work on restoring the missing ones today.
On Monday 04 February 2002 01:58 am, Koen Claessen wrote:
Hi all,
Now we are talking about implicit parameters, let us take up
the following problem with them on the Haskell mailing list
too.
[implicit parameters are not propogated down recursive definitions without
a type signature]
On Monday 04 February 2002 02:25 am, John Hughes wrote:
Not so fast! Proposing a solution means this is regarded as a problem!
But what is to say that the first behaviour is right in any general
sense?
The important thing is that the language semantics is clear, and this is a
semantic
For those of you interested, Mondrian and Haskell for .NET are
available for the release version of Microsoft's .NET platform - see
http://www.mondrian-script.org.
Mondrian is a simple functional language designed to inter-work with
OO languages, and integrates well into .NET and with other
At 2002-02-04 01:45, Koen Claessen wrote:
| addBase{?base=7} 5
I like this! It is the least polluting syntax of all.
Hmm... you have braces without following a keyword. I think in all other
cases, braces follow a keyword (where, let, do, of).
--
Ashley Yakeley, Seattle WA
Our switch to a new server for haskell.org is complete. We are making
a few changes in the way this machine is administered - instead of
handing out the root password we are now using sudo instead. Anyone
who used needs root access and is not a sudoer can contact me and I'll
fix things.
Some
On Mon, Feb 04, 2002 at 01:33:54PM -0800, Ashley Yakeley wrote:
At 2002-02-04 01:45, Koen Claessen wrote:
| addBase{?base=7} 5
I like this! It is the least polluting syntax of all.
Hmm... you have braces without following a keyword. I think in all other
cases, braces follow a keyword
Hi all,
How about the following syntax:
(addBase 5 | ?base = 10)
This is quite unlike from other binding constructs in Haskell,
so maybe something more similar to list comprehension
would be better:
(addBase 5 | ?base - 10)
Cheers,
Sebastien
21 matches
Mail list logo
