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 selectors
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
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
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't
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
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
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
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!
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
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 expression
containing the
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,
13 matches
Mail list logo
