The Haskell kernel

In the report on the Haskell programming language (http://www.haskell.org/onlinereport/),
the Haskell kernel is mentionen in several places. It says in section 1.2
that the Haskell kernel is a slightly sugared form of lambda calculus. Futhermore
most expression should be possible to translate to the Haskell kernel.

But where is this kernel defined (I cannot find it in the report) ?

Actually the case-expression(section 3.13) seems more fundamental than the
lambda-expression in Haskell. Several construct translate to the case-expression
instead of lambda-expression as the if-expression(section 3.6). It is also
shown howto translate the lambda-expression into the case-expression in
section 3.3. Am I missing something here ?

Grateful for any hint.

Mads

________________________________________
Få din egen webmail på http://mail.sol.dk - gratis og med dig overalt!

RE: The Haskell kernel

I'm afraid the "Haskell kernel" isn't formally defined.  The Report
describes how to translate complex constructs into simpler ones,
but neither specifies *exactly* what these simpler ones are, nor gives
their meaning in a formal way.

Simon

| -----Original Message-----
| From: ml_dk <at> sol.dk [mailto:ml_dk <at> sol.dk] 
| Sent: 01 May 2001 13:31
| To: Haskell mailinglist
| Subject: The Haskell kernel
| 
| 
| 
| In the report on the Haskell programming language 
| (http://www.haskell.org/onlinereport/),
| the Haskell kernel is mentionen in several places. It says in 
| section 1.2 that the Haskell kernel is a slightly sugared 
| form of lambda calculus. Futhermore most expression should be 
| possible to translate to the Haskell kernel.
| 
| But where is this kernel defined (I cannot find it in the report) ?
| 
| Actually the case-expression(section 3.13) seems more 
| fundamental than the lambda-expression in Haskell. Several 
| construct translate to the case-expression instead of 
| lambda-expression as the if-expression(section 3.6). It is 
| also shown howto translate the lambda-expression into the 
| case-expression in section 3.3. Am I missing something here ?

Interesting: "Lisp as a competitive advantage"

http://www.paulgraham.com/paulgraham/avg.html

I wonder how Haskell compares in this regard.
Any comment from Haskell startups? (eg Galois Connections)

Sengan

User defined Ix instances potentially unsafe

Sorry if this has been reported before.

I shouldn't be able to crash ghc or hugs without using any "unsafe"
features, right?  Well, here 'tis:

> module CrashArray where
> 
> import Array
> import Ix
> 
> newtype CrashIx = CrashIx Int deriving (Ord, Eq, Show)
> 
> instance Enum CrashIx where
>    toEnum   x = (CrashIx x)
>    fromEnum (CrashIx x) = x
> 
> instance Ix CrashIx where
>    inRange (_,_) _ = True
>    index (_,_) (CrashIx x) = x
>    range (x,y) = [x..y]
> 
> myArray = listArray (CrashIx 0, CrashIx 0) [0]
> crash = myArray ! (CrashIx maxBound)

In ghci-5.00, I get a segfault and hugs-feb-2000 says:
   INTERNAL ERROR: Error in graph

Now, admittedly my Ix instance is broken, but I don't think I should be
able to segfault the interpreter.

Re: Interesting: "Lisp as a competitive advantage"

Sengan <senganb <at> ia.nsc.com> wrote,

> http://www.paulgraham.com/paulgraham/avg.html
> 
> I wonder how Haskell compares in this regard.
> Any comment from Haskell startups? (eg Galois Connections)

I already see John Launchbury asking us not to teach Haskell
anymore 

Manuel

List of words

Re: List of words

Hello!

On Wed, May 02, 2001 at 01:31:54AM -0700, lynn yeong wrote:
> Hi, I'm fairly new to Haskell, and recently I came upon a question which asks to capitalise all words in a
given list. I haveno idea how to do it, can you help? Thanks!

[please wrap your lines!]

How about this:

import Char(toUpper)

capitalize :: String -> String
capitalize [] = []
capitalize (c:cs) = toUpper c : cs

capitalizeList :: [String] -> [String]
capitalizeList = map capitalize

Kind regards,

Hannah.

Re: List of words

At 2001-05-02 01:34, Hannah Schroeter wrote:

>How about this:
>
>import Char(toUpper)
>
>capitalize :: String -> String
>capitalize [] = []
>capitalize (c:cs) = toUpper c : cs
>
>capitalizeList :: [String] -> [String]
>capitalizeList = map capitalize

...or if you prefer...

capitalizeList :: [String] -> [String]
capitalizeList = map (map toUpper)

--

-- 
Ashley Yakeley, Seattle WA

Re: Implict parameters and monomorphism

	(B) Monomorphism restriction "wins"
	    Bindings that fall under the monomorphism restriction can't
		be generalised
	    Always generalise over implicit parameters *except* for bindings
		that fall under the monomorphism restriction

	    Consequences
		* Inlining isn't valid in general
		* No unexpected loss of sharing
		* Simple bindings like
			z = ?y + 1
		  accepted (get value of ?y from binding site)
	
	(C) Always generalise over implicit parameters
	    Bindings that fall under the monomorphism restriction can't
		be generalised, EXCEPT for implicit parameters
	    
	    Consequences
		* Inlining remains valid
		* Unexpected loss of sharing (from the extra generalisation)
		* Simple bindings like
			z = ?y + 1
		  accepted (get value of ?y from occurrence sites)

	Discussion
	~~~~~~~~~~
	None of these choices seems very satisfactory.  But at least we should
	decide which we want to do.

	It's really not clear what is the Right Thing To Do.  If you see

		z = (x::Int) + ?y

	would you expect the value of ?y to be got from the *occurrence sites*
	of 'z', or from the valuue of ?y at the *definition* of 'z'?  In the
	case of function definitions, the answer is clearly the former, but
	less so in the case of non-fucntion definitions.   On the other hand,
	if we say that we get the value of ?y from the definition site of 'z',
	then inlining 'z' might change the semantics of the program.

	Choice (C) really says "the monomorphism restriction doesn't apply
	to implicit parameters".  Which is fine, but remember that every 
	innocent binding 'x = ...' that mentions an implicit parameter in
	the RHS becomes a *function* of that parameter, called at each
	use of 'x'.  Now, the chances are that there are no intervening 'with'
	clauses that bind ?y, so a decent compiler should common up all 
	those function calls.  So I think I strongly favour (C).  Indeed,
	one could make a similar argument for abolishing the monomorphism
	restriction altogether.

I disagree.

I think it's important to have a simple model of how many times expressions
are evaluated. Function bodies are clearly evaluated many times, once for each
call, but non-function bindings should be evaluated at most once to respect
call-by-need semantics. Breaking the monomorphism restriction in ANY case
makes both space and time cost of evaluation unpredictable, and brittle when
program changes elsewhere introduce or remove an implicit parameter. It isn't
good enough to say `the chances are' that a program has, for example, linear
time and constant space complexity: the programmer should be able to convince
himself of such properties.

As far as what one would `expect', it's in the very nature of dynamic binding
that it makes the meaning of an expression depend on its context. I for one
would certainly not expect that inlining a definition bound to such an 
expression should preserve its meaning! Inlining changes the context, so
`of course' can change the meaning. So I strongly prefer (B)!

John Hughes

Re: List of words

I am relatively new to Haskell.

Somebody told me that it is a very good language, because all the
people on its mailing list are so nice that they solve all 
homeworks, even quite silly, of all students around, provided they
ask for a solution in Haskell.

Is that true, or a little exaggerated?

Jerzy Karczmarczuk