Lennart wrote:
OOHaskell is ingenious, but it's a terrible way to use Haskell.
It's very unidiomatic Haskell, and it makes you do things in the
same old OO way.
It's probably obvious but let me say that ...
OOHaskell is more of a proof of concept and a sandbox for OO language design.
It is
Misha,
This feels like you would compose dictionary types in heterogeneous lists and
then have a type-driven lookup from the dictionary list; this would be very
similar to the lookup operation for TICs in the HList lib, only that the
driving type is of kind *-* and that the traversing
Did I say TICs?
Assuming that you want to tuple up many constraints, I should have said TIPs
of course.
The SYB3 code distribution actually exercises some related chaining of
contexts; cf. PairCtx.
However, what's missing is the obliviousness dimension for irrelevant
constraints.
So you may
[Foundations of AOP and AO languages have benefitted from the functional
programming community for a while now. Haskellers, please have a look. Thanks!
Ralf]
Call For Papers
FOAL: Foundations of Aspect-Oriented Languages 2007
A one day workshop affiliated
[Added a subject. Please accept my apologies! Foundations of AOP and AO
languages have benefitted from the functional programming community for a while
now. Haskellers, please have a look. Thanks! Ralf]
Call For Papers
FOAL: Foundations of Aspect-Oriented
Arthur,
constrFields eventually returns some mangled strings from the abstract syntax
tree; see ghc-fptools/ghc/compiler/basicTypes/DataCon.lhs; and that abstract
syntax promises to be order-preserving.
It says (not surprisingly):
dcFields :: [FieldLabel],
-- Field
I start wondering, how OO languages solve the same problem.
Conceptually, what is needed is a mapping of the head of the input to a type.
This is indeed a recurring problem in OO languages; think of object
serialization or XML/Object mapping. One common way of accomplishing the
mapping is to
Hi Mark,
Cc Haskell-café,
It seems the OGI links for THIH have gone dead.
Is there any preferred download location for THIH these days?
I couldnt spot anything.
Thanks,
Ralf
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
Read a sentence like this If your programming language requires you to
use functors, you're not getting all the benefits of a modern
programming environment. See if you can get some of your money back.
If this is not a very subtle pun (regarding Java functors vs. Haskell
functors), which
Dear Haskellers,
The following paper may still benefit from your comment.
The final version is only due per 10 August 2006.
Thanks,
Ralf Laemmel
--
http://homepages.cwi.nl/~ralf/gpce06/
Title: Software Extension and
be so ...
Is there some well-argued example where someone would explain why this
could be at all useful?
Thanks,
Ralf
-Original Message-
From: Simon Peyton-Jones
Sent: Tuesday, July 25, 2006 5:45 AM
To: Ralf Lammel; glasgow-haskell-bugs@haskell.org
Subject: RE: incoherent instance
Bulat,
Dmitri is not necessarily mixing [...] class and its (default)
instance.
Bulat, one could suspect a reasonable use of default class methods:
http://www.haskell.org/onlinereport/decls.html#overloading
Indeed, Dmitri's declarations make sense as default class methods.
... except for Jared's
The following pain is sort of ghc (6.4.2) specific.
(The same behavior is achievable with hugs -98 +O which is Ok in so far
that +O (as opposed to +o) is not strongly supposed to be coherent.)
Note the following GHC options preceding the code.
They do not contain -fallow-incoherent-instances.
Bulat wrote:
it seems that Haskell continues to be a source of new technologies for
other languages. i will wait for GADT for C# :)
No need to wait:
http://doitest.acm.org/10.1145/1094811.1094814
We show that existing object-oriented programming languages such as
Java and C# can express GADT
to call 'toConstr' on any type.
[Ralf Lammel]
I get your overall question but let me ask about one detail. When you say an
interface, what does this mean in the Haskell sense (where normally a
type-class is like an OO interface *anyhow*)?
Is there a fear that this would lead to sloppy programming
Hi David,
Readers on this list will not be surprised to hear me saying that, of
course, type classes perfectly make sense for your scenario. You may
have a look at some posts on extensible interpreters:
- http://compilers.iecc.com/comparch/article/04-12-111
-
Bas,
There is a really easy (and intended) way to make this work.
See Sec. 6.4 SYB1 paper (TLDI 2003).
- You compose things as follows:
simplify = id `extT` simplifyRhs `extT` simplifyExp `extT` ...
- You apply everything right away to simplify.
There is no need to use a class in your case.
RULE'06, 7th International Workshop on Rule-Based Programming, 11th August,
2006, Seattle, USA, A Satellite Event of RTA
http://www.dcs.kcl.ac.uk/events/RULE06/
IMPORTANT DATES
- 14th May, 2006 Deadline for electronic submission of papers
- 15th
Hi Frederik,
[resending; as it bounced because of size.]
That’s a tricky one.
Let’s first recall that this one is still fine:
*Main :t cast True :: (Typeable a, Typeable b) = Maybe (a,b)
cast True :: (Typeable a, Typeable b) = Maybe (a,b) :: (Typeable b,
Hi Ralf,
I'm looking for a function like extT but with more general type:
(t a - s a) - (t b - s b) - (t a - s a)
Is there such a thing in the generics library?
Hi Frederik,
Not sure how you are exactly going to use such an operation ...
But here is its implementation anyhow.
Thanks
==
Call for Papers
RULE 2006
7th International Workshop on Rule-Based Programming
http://www.dcs.kcl.ac.uk/events/RULE06/
Two new papers available:
Book review
The Haskell Road to Logic, Maths and Programming by Kees Doets and Jan van
Eijck
To appear in JoLLI journal; 13 pages.
http://www.cs.vu.nl/~ralf/JoLLI06
Executive summary: The Haskell road is an excellent book worth
considering as course material and reading
... for the same reason as this one doesn't get through:
import Control.Monad.ST
import Data.Array.ST
main = print $ runST $
do return ()
... but this one does:
import Control.Monad.ST
import Data.Array.ST
main = print $ runST (
do return ())
it's all about rank-2 types;
Simon PJ,
Is that Ok?
Should I?
Ralf
-Original Message-
From: [EMAIL PROTECTED]
[mailto:glasgow-haskell-
[EMAIL PROTECTED] On Behalf Of Frederik Eaton
Sent: Thursday, December 29, 2005 11:39 AM
To: glasgow-haskell-bugs@haskell.org
Subject: missing Data instances
These don't
Dear Frank,
HList is definitely tested with 6.4. See transcript below. My guess
would be that you are perhaps not running with options as stated in the
Makefile. Anyway, if your problems persist, I am happy to take this
offline.
Merry Christmas,
Ralf
[EMAIL PROTECTED] ~/projects/HList/src
$
FOAL: Foundations of Aspect-Oriented Languages
--- CALL FOR PAPERS ---
Submission deadline: 25 January 2006
A one day workshop affiliated with AOSD 2006 in Bonn, Germany, on March 21,
2006.
Themes and Goals
FOAL is a forum for research in foundations of aspect-oriented programming
languages.
Good questions.
You can't have a polymorphic typecase like `extQ` (show :: Show a = a
- String ) because that's not really a *type*case. It is too
polymorphic.
You can have a polymorphic typecase like `extQ` ( lshow :: [ a ] -
String ) because that's covered by the SYB2 paper; you need ext1Q
I certainly agree with Keean. It's just that the given example is a bit
misleading. As Bulat observed, the example is about a heterogeneous
list, as opposed to a record. But there are of course tons of record
examples to be found, if you follow the HList link.
Ralf
P.S.: The HList paper also has
Hi Greg,
Since hfoldr is right-associative, I prefer to reorder your list of
functions as follows:
test = HCons (length::String - Int) (HCons ((+1)::(Int-Int)) (HCons
((*2)::(Int-Int)) HNil))
Note that I also annotated length with its specific type.
(If you really wanted to leave things more
In a type system like MLF, your original code may type check.
Let's do an experiment.
We replace the IO monad by the Id(entity) monad.
We actually replace the Id newtype also to become true type-level
identity.
So we get:
--
-- This is like your 2nd say unchecked... sample
--
fooBar :: [v] -
Yeah, I was also thinking of impredicative types and that they would
make this problem go away. First of all, we may need to wait a while for
such types to become available in Haskell, but Daan has good stuff at
avail.
Also, for clarity, let me just point out that this is really about an
Hi,
'isBoxed (Carton func)' fails because there is no way whatsoever that any
expression context will disambiguate the x y type variables of func's type.
That is, the type of `isBoxed (Box func)` does not expose x (and y -- the
latter being irrelevant because of the fundep); so there is no way
Just for the record,
Cobol has a long history of specifying local rounding options.
More recently, the options for rounding are elaborated in the context of
adding standard arithmetic.
http://www.cobolportal.com/j4/files/05-0152.doc
Ralf
-Original Message-
From: [EMAIL PROTECTED]
Define a type A such that for any type B you can define
up :: B - A
down :: A - Maybe B
such that
down . up = Just
You can do this quite easily in Java or C++, mutatis mutandis. You
can't
do this in Haskell, I don't think. You can't actually do this in
O'Haskell
I would rather argue that:
- Template Haskell approx. *compile-time* reflection
- Scrap your boilerplate II (ICFP 2004) approx. *run-time* reflection
- Generic Haskell is effectively a Haskell generator
Ralf
P.S.: Another way to get *compile-time* reflection in Haskell is of course
type-level
: Sunday, September 18, 2005 7:50 PM
To: Ralf Lammel
Cc: haskell-cafe@haskell.org
Subject: Re: [Haskell-cafe] generics question, logical variables
Hi Ralf,
I'm revisiting this project and just have another question. The story
seems to be that GHC cannot derive Typeable1, or Typeable when
An extended technical report has been released at:
TR software: http://homepages.cwi.nl/~ralf/OOHaskell/
TR: http://arxiv.org/abs/cs.PL/0509027
Haskell's overlooked object system
10 September 2005, 79 pages
by O. Kiselyov (FNMOC, Monterey, CA, USA)
and R. Laemmel (Microsoft Corp., WA, USA)
Yoann,
Thanks for your comments.
Yoann wrote: I dont think XML is a good idea
for files that are managed/edited by humans.
I think the users prefer simpler files with a custom
syntax, and the user is the king.
I dont mind, but when you say user do you mean application
Hi Yoel,
This looks like fun.
Just some general comments:
- One should try to *also* provide a simple solution. Here I would pick
a solution that doesn't need a lot of explanation (of Haskell and the
solution) and a lot of defense to score with it.
- As a second step, one should identify a
Frederik,
[I am trying to drag this voluminous thread to cafe.]
Jeremy Gibbons mentioned Martin Erwig and Deling Ren's paper on
monadification. Very useful, indeed -- also with regard to the question
you seem to ponder about; also see here for an early take on
monadification, if you like
Frederik,
Thanks for the challenge.
I didn't get some of the bits about your application scenario though.
(What did you mean by the type Pred? Why a list in the result of solve?
How did you model typed logical variables? With GADTs, phantoms? ...
Perhaps send more code, if you want to discuss
this feature request
because we will still confuse beginners, but that's just my feeling.
Ralf
-Original Message-
From: Stefan Holdermans [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 16, 2005 11:48 PM
To: Ralf Lammel
Cc: haskell-cafe@haskell.org; Benjamin Franksen
Subject: Re: [Haskell-cafe
Technically this is trivial it seems. I think that some people consider this
proposal a problem because typos (misspelled type parameters) immediately lead
to the accidental exploration of a more advanced type-system feature and
correspondingly more involved error messages. Of course, the type
3:32 AM
To: Simon Marlow; 'Frank Huch'; 'glasgow-haskell-bugs@haskell.org'
Cc: Ralf Lammel
Subject: RE: Deriving Typeable instances
Yes, you could I suppose. But then there'd be a different peculiar
change
in behaviour at arity 7. I'm not sure that'd be an advantage.
Simon
Stefan,
the problem can be spotted in the following erased version of your
program.
data Identity a
instance Monad Identity
class (Monad m) = IsItem m i where
processItem :: i - m ()
class (Monad m) = IsProcessor p m | m - p where
process :: (IsItem m i) = i - m ()
newtype Item m = Item
ShallowEq?
Ralf Lammel wrote:
As Bulat points out, the GHC primitive dataToTag#
indeed nicely solves the problem. Ben, just for
completeness' sake; with SYB, you get such reflective
information too (and others):
shallowEq :: Data a = a - a - Bool
shallowEq x y = toConstr x == toConstr y
As Bulat points out, the GHC primitive dataToTag#
indeed nicely solves the problem. Ben, just for
completeness' sake; with SYB, you get such reflective
information too (and others):
shallowEq :: Data a = a - a - Bool
shallowEq x y = toConstr x == toConstr y
(dataToTag# returns Int, while
If we were on an OOP mailing
list, I could ask for days how to simulate pattern matching and
algebraic types---and get a nonsensical runaround involving the
visitor
pattern and huge swaths of unreadable code.
In such a case, I would be happy if someone told me that there is work
like this:
this, but your code avoids it.
Anyway the solution is trivial: ex. quantification, you didn't propose
that.
Cheers,
Ralf (back to Cobol)
-Original Message-
From: Bulat Ziganshin [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 23, 2005 11:37 PM
To: Ralf Lammel
Cc: Pal-Kristian Engstad; haskell
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
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
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
Bulat,
Bulat wrote:
just create list of draw functions itself:
[drawCircle (10,10) 5, drawSquare (20,20) 10]
No! the exercise is about lists of shapes
not lists of results of drawing shapes.
This is clearly a major difference.
Bulat wrote:
for more complex tasks - declare interface as a
Andrew,
you are circumventing the hard problem!
(Even though I am sure you just forgot to mention it.)
That is, the question is about drawing a *list* of shapes.
As correctly observed by Rathman ages back, one naturally
ends up with existential quantification when simulating
dynamic binding.
Andreas Rossberg:
Andreas R. wrote:
dynamic binding is just the OOO way of saying
calling a first-class function).
Let me presume that dynamic binding
was meant here in the sense of late binding, in the sense of
subtyping polymorphism. At least, the given shapes example
strongly suggested
Lennart,
from a textbook perspective I agree
that this solution should be mentioned to make it easy
for non-Haskellers to get into the subject.
However (as you of course know, but I just don't understand
why you don't dare to mention the limitations a) and b) ...)
a)
Your constructor-based
Thomas Sutton wrote:
Main :t (Impl (Prop p) (Poss (Prop p)))-- p - p
Impl (Prop p) (Poss (Prop p)) :: PC
So the type says that this is a formula in the predicate calculus?
(Even though you combine two formulae of modal logics.)
Are you happy with that? Just wondering?
Also, are you
Andreas Rossberg said:
[Followups to Haskell Cafe]
as far as I read it, dynamic or late binding is orthogonal to
subtyping, or typing in general. It is just that most typed OO
languages
lump these concepts together.
Absolutely agreed.
Often a simple first-class function, or a record
,
functional way
Thanks,
Ralf (returning to his VB problem)
-Original Message-
From: Bulat Ziganshin [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 23, 2005 4:55 AM
To: Ralf Lammel
Cc: Andrew Ward; Pal-Kristian Engstad; haskell-cafe@haskell.org
Subject: Re[4]: [Haskell] Dynamic binding
At the risk of being excluded from this list
(because of an unmoral number of plugs about OOHaskell),
here we go: http://homepages.cwi.nl/~ralf/OOHaskell/
You might start with the appendices of the paper and also read Section 2
which finally implements the Shapes example with ease. The C++
On 6/6/05, Gracjan Polak [EMAIL PROTECTED] wrote:
If you stick to single inheritance there is other way to simulate OO in
Haskell. Look for phantom types. Whole wxHaskell (for example) is
based on this concept.
I heard about them indeed but barely found clear explanations of it.
Any
There are tons of good research questions readily waiting.
Such as:
- What would we want to explore in OOish Haskell so that we, once more,
can provide interesting input for mainstream language development? More
specifically: what sorts of type inference would make a difference in
Java 1.5+, C#
Hi Gracjan,
http://homepages.cwi.nl/~ralf/OOHaskell/src/PoorMens2/
(again *not* using OOHaskell)
From the quick skim of code:
.?. -- apply function to upcast object
.!. -- apply modification function to upcast object and substitute
returned value (new object), basically update
Hi Cedric,
http://homepages.cwi.nl/~ralf/OOHaskell/src/PoorMens/
Good compromise between complexity, typing and usefulness.
[unfortunately also limited,
which is the reason that we came up with the monadic version:
PoorMens2.]
I noticed that both Rectangle and Circle need to redefine the
Cédric Paternotte wrote:
...
5. With this :
http://www.cs.utexas.edu/ftp/pub/techreports/tr01-60/tr01-60.pdf
Gracjan Polak wrote:
I've been thinking about slight generalization of this lately. Here are
my semi-backed thoughts as of now.
I should have mentioned
-Original Message-
From: Cédric Paternotte [mailto:[EMAIL PROTECTED]
Sent: Monday, June 06, 2005 3:36 PM
To: Ralf Lammel
Cc: haskell-cafe@haskell.org; Gracjan Polak
Subject: Re: [Haskell-cafe] [Newbie] Quest for inheritance
Hi Ralf,
I should have mentioned
http://homepages.cwi.nl
Re: your enumeration. Let me add one more bullet.
In cases where inheritance is about abstract base classes
and concrete subclasses ((add interface polymorphism likewise))
you can use a (for unknown reasons) unappreciated pattern for
extensible datatypes in Haskell:
I think this is an old bug,
or at least I have seen it months back.
The overlapping instances directive does not make it to the top-level.
See attached sample with the offending session.
Thanks for fixing.
Ralf
Test.hs
Description: Test.hs
___
-
From: Keean Schupke [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 02, 2005 9:20 AM
To: Simon Peyton-Jones
Cc: Ralf Lammel; glasgow-haskell-users@haskell.org
Subject: Re: GHC 6.4 release candidates available
In the past having:
{-# OPTIONS -fallow-overlapping-instances
That's a very good point.
Me too, I would often wish to see some principled
code details when entering documentation. For instance
what is the point of _explaining_ that inc aliases
add 1, why not just show that equation! I agree that
gmap?? are a bit of this kind. It is so much easier to
explain
Please find attached the call for participation for the Summer School on
Generative and Transformational Techniques in Software Engineering
4 - 8 July, 2005, Braga, Portugal
http://www.di.uminho.pt/GTTSE2005
Registration is open.
There are 17 confirmed tutorials and other presentations.
--
Ralf
71 matches
Mail list logo
