Hello Lennart,
Friday, June 24, 2005, 9:16:22 PM, you wrote:
LA> There are, of course, type systems where my program works fine.
LA> O'Haskell is an example of a language with such a type system.
LA> In O'Haskell the Either type is defined like this:
i like O'Haskell because it's very close to t
"Ralf Lammel" <[EMAIL PROTECTED]> writes:
>> and a related paper by Jacques Garrigue,
>> where he proposes to solve it using OCaml's polymorphic variants.
>
> I am not sure.
> Is this referring to "Objective Label"? Which paper exactly?
I think it refers to
http://wwwfun.kurims.kyoto-u.ac.jp/%7E
> I recently implemented some new Haskell numeric types that, instead of
> performing calculations, can generate a rendering of the requested
> calculation or store units with it.
good old Haskell rule (with apologies to Daniel Düsentrieb, I think;):
"impossible things are delayed immediately, mir
I posted this on my blog at http://changelog.complete.org/node/339 but I
thought there may be some here that would find it of use.
I recently implemented some new Haskell numeric types that, instead of
performing calculations, can generate a rendering of the requested
calculation or store units wi
Jonathan Cast wrote:
No type theory (that I know of) goes beyond System F in accepting
anything like foo. So, given the current state of the art, foo is
unconditionally ill-typed. That could change if someone comes up with a
/consistent/ type theory that accepts foo, but foo is i
Jonathan Cast wrote:
Lennart Augustsson <[EMAIL PROTECTED]> wrote:
foo :: Either a b -> Either () b
foo (Left _) = Left ()
foo x@(Right _) = x
Since Haskell type checking doesn't use the information gained
by pattern matching to refine types we just have to accept that
some perfectly safe prog
> > Lennart Augustsson <[EMAIL PROTECTED]> wrote:
> Jonathan Cast wrote:
> >
> > Here is (approximately) the Core translation of foo above:
> >
> >
> >>foo :: forall a b. Either a b -> Either () b
> >>foo = /\ a b -> \ e -> case e of
> >> Left _ -> Left @() @b ()
> >> Right _ -> e
> >
> >
Christian Maeder <[EMAIL PROTECTED]> writes:
> > voidcast v@(VariantWithOne{}) = v { field1 = Void , field2 = Void }
>
> Setting field2 only assures type correctness, but the value of field2
> would be ignored at runtime.
Exactly what I was proposing.
> > I could write a single expression that
> Off-hand, I recall a paper by Martin Odersky and the Scala people
> discussing their approach to the Expression Problem,
So ...
http://icwww.epfl.ch/publications/documents/IC_TECH_REPORT_200433.pdf
... I guess
The key innovative idea there is composition of mixins while replacing
formal sup
Ralf Lammel wrote:
I would like to add a peer-reviewed clear reference
to the OOHaskell paper about the red herring that you mention.
I don't have such a reference. May I kindly ask you to offer
a few for selection?
Off-hand, I recall a paper by Martin Odersky and the Scala people
discussing
Malcolm Wallace wrote:
> Here is a strawman proposal, which does not fix the consecutive update
> problem, but which might address the original typing problem.
I think it does not really address the original typing problem.
It would allow you to write:
> voidcast v@(VariantWithTwo{}) = v { field
> > But note that "same functionality" is one thing,
> > having "separate compilation" and "program extensibility" too
> > is another one.
>
> As I said, and as is well-known, "extensibility" is a red herring in
> this context - you merely trade one dimension of extensibility for
> another one.
I
Ralf Lammel wrote:
only because it's C-like :) you just can't believe that Haskell
program can be 3-10 times smaller while keeping the same functionality
:)))
But note that "same functionality" is one thing,
having "separate compilation" and "program extensibility" too
is another one.
As I
Bulat wrote:
> if you require several operations, you can pack them in tuple or
> structure (really, tuple is a structure without field names)
How are we going to anticipate all possible bodies of a for-loop?
By comparison, when we build a normal Haskell list, does the
construction precisely mir
Hello Andrew,
Friday, June 24, 2005, 12:35:16 AM, you wrote:
AW> Assuming I have a list of shapes somewhere in my program. The list would
AW> be heterogeneous, or at least contain data constructed using various
AW> different type constructors. The list would also be changing all the
AW> time, f
Christian Maeder <[EMAIL PROTECTED]> writes:
> Even consecutive updates (that could be recognized by
> the desugarer) don't work:
>
> voidcast [EMAIL PROTECTED] = v { field1 = Void} {field2 = Void }
Yes, I find it interesting that consecutive updates are not equivalent
to a combined update. I b
Malcolm Wallace wrote:
> Ah, but the reason I want to use field update, rather than a new
> construction on the rhs, is that my type really has lots of other
> fields (not mentioned here), which are all of fixed definite types
> (not parametric). It is much nicer to be able to write
>
> v { f
Christian Maeder <[EMAIL PROTECTED]> writes:
> >>voidcast :: Fields a -> Fields Void
> >>voidcast v@(VariantWithTwo{}) = v { field1 = Void , field2 = Void }
> >>voidcast v@(VariantWithOne{}) = v { field1 = Void }
>
> I would not expect that updating only field1 can change the type of v.
> The rig
Ralf Lammel wrote:
Can you just tell how *you* would favor encoding the shapes example
that was posed by poster? (It might just be that your code would be
very close to Lennart's proposal?)
There is no universal answer. The shape example obviously is just a toy
example. As long as I have no i
Malcolm Wallace wrote:
> Whereas in the named field example, the rhs expression
> v {field1=Void}
> does indeed have the type
> Fields Void
> as declared in the signature. The expression explicitly converts all
> the relevant interior fields to Void. At least, that is how it could
> appea
Lennart Augustsson <[EMAIL PROTECTED]> writes:
> A somewhat similar problem exists even without fields:
>
> foo :: Either a b -> Either () b
> foo (Left _) = Left ()
> foo x@(Right _) = x
Your example is less surprising than mine with fields. The expression
x
on the rhs of the last clause h
Tomasz Zielonka wrote:
voidcast v@(VariantWithTwo{}) = v { field1 = Void , field2 = Void }
voidcast v@(VariantWithOne{}) = v { field1 = Void }
>>I would not expect that updating only field1 can change the type of v.
>
> But it can. Note that if you change the second field1 to field3 (both
I guess we just need to agree that we disagree.
Of course, you are right that I am just a newbie when it comes to
Haskell.
How did you know that I am actually a Cobol programmer?
Did you google?
http://www.google.com/search?biw=1003&hl=en&q=Ralf+Cobol
Seriously (?):
1.
I never intended to impo
Hello Ralf,
Thursday, June 23, 2005, 11:40:13 PM, you wrote:
RL> a) building (i) a list of data is fundamentally different
RL> from building (ii) a list of anticipated results of each datum.
RL> I would be surprised to hear that this counts as a valid technique.
RL> BTW, you can do the *same* in
24 matches
Mail list logo
