Yes, things are clearer and I rather like the idea. The only
thorny issue is that the update function for field 'wibble'
is formed from but not equal to the field name itself.
In short, the magic thing would be in the 'deriving' clause:
If the data type declares fields with names x_1, ..., x_n
an
Hi!
> So in summary, here is my proposal:
>
> No specific "extensible records" system.
>
> Define record update to be a function just like record selection is.
>
> Allow these functions to be in type classes.
I do not understand the second and third point: As I understand your
idea, record sel
Wait a minute!
As far as I have understood, "threaded" refers (in this context) to a
style of writing (byte code) interpreters. A threaded interpreter does
not have a dispatch loop which reads the next byte code and then
invokes the correct handler (typically by using the byte code as an index
i
Hi!
The listlessness stuff is a precursor to deforrestation, so it
replaces lists by (fewer lists and) scalars. I do not think there
are any arrays involved.
The most important property for being able to convert a list to
an array is that there should never be two cons cells with the same
tail
Hi!
On the performance (or not) of high level code: I'm working on a
compiler with a strong emphasis on generating good code for
programs written in a fairly generic style. This work is very
far from being completed, but some of the highlights of the
compiler are:
- Aggressive removal of highe
Hi!
For whatever that is worth, my semantics agrees with Simon's point here,
ie in the example code
module M( C(op1) ) where-- NB: op2 not exported
class C a where
op1 :: a->a
op2 :: a->a
module N where
import M
Hi!
In fact, we might want to be slightly more general. Why don't go for
a general base conversion, much like Malcolms idea but without converting
every digit to a Char. Say something like
toBase :: (Integral a) => a -> a -> [a]
toBase base n
| n < 0 = error "Numeric.toBase: can'
Hi!
The binding form := must absolutely have a completely monomorphic type.
A while back I posted the result that the MR kills principal types in
Haskell. The problem with the MR is exactly that it introduces types
which may be polymorphic but not overloaded. So if we want to regain
principal typ
Hi!
George Russel proposed a search for things which should be deprecated.
I have a very distinct unfondness for contexts in algebraic data type
declarations. They make absolutely no difference except move type
errors to a different part of a program (or rather, they add type
errors). In that se
Hello again,
Wolfgang wrote
> The Haskell report seems to be inconsistent here (once again). In the
> beginning of section 5.3 it says
>
> Imported names serve as top level declarations: they scope over the entire
> body of the module but may be shadowed by local NON-TOP-LEVEL bindings.
>
Hi all!
I have been thinking about the scoping issues for imported names. Of
course, this musing is ispired by the formal static semantics I have
been working on, but it is also prompted by the revised Haskell report.
Section 5.5.2 relates to name clashes and has an interesting example
towards t
Hi!
Jon Fairbairn wrote:
> I agree too, but being able to omit method definitions is
> sometimes useful -- would it be possible to make calls to
> those methods a /static/ error? I suspect this would be hard
> to do.
Yes, quite tricky. The problem is that the class constraints (in an
inference
Oops!
I said THIH has problems with type synonyms. That is completely wrong.
I meant type SIGNATURES and nothing else. Sorry for the confusion.
/kff
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Hello again!
John Hughes suggested that Haskell should have two forms of binding,
one with call-by-name (does not preserve sharing) semantics and
polymorphism and overloading and monomorphic with call-by-need
(preserves sharing).
The question is; would this restore principal types in general?
Hi!
Marcin wrote:
> Juan Carlos Arévalo Baeza wrote:
>> Karl-Filip wrote:
>>>- a -> Bool (without quantification and with "IsNil a" among the
>>> predicates).
>>
>>This is something I didn't understand either. Which predicates?
>
>I think "isNil a" goes to the context of the whole expressio
Hi all!
I've been spending some time the last year writing up a formalization
of the Haskell type system (actually, most of the static semantics).
In doing so, I've come across an oddity. It seems that Haskell does not
have the principal type property, ie there are Haskell expressions
which, in
>
> Karl-Filip Faxen <[EMAIL PROTECTED]> writes:
>
> > There is a hidden cost to trapping Int overflow ...
> > operations on Ints become unsafe i.e. may raise exceptions
> > This is a problem both for a global
> > instruction scheduler
There is a hidden cost to trapping Int overflow, beyond the extra
instruction per operation mentioned by Paul Hudak. This is that
operations on Ints become unsafe i.e. may raise exceptions (well
that was the whole idea...). This is a problem both for a global
instruction scheduler (e.g. a trace s
18 matches
Mail list logo
