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 a
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=1003hl=enq=Ralf+Cobol
Seriously (?):
1.
I never intended to
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 in
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 has type
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
appear to a
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
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 right thing is to
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 { field1
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, for
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
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
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 am not going to
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 { field1
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
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
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 updated
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 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
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,
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
20 matches
Mail list logo
