#apache #archlinux #asterisk #centos #debian #gentoo #haskell #kde #kubuntu #lisp #math #mysql #perl #python #ruby-lang #rubyonrails #suse #ubuntu #vim #wikipedia 0 1 2 3 4 5 6 7 8 9
Top Prev 3208 3209 3210 3211 3212 3213 3214 3215 3216 3217 3218 3219 3220 3221 3222 3223 3224 3225 3226 Next
#haskell
<Cale> er
<Cale> S :: (Summa a) => a -> Summa
<dmhouse> nmessenger: yep, but other languages don't have such advanced type systems.
<nmessenger> dmhouse: :D
<Cale> But the usefulness of that depends on what you want to do with those values
<dmhouse> Cale: wouldn't it be great to see some sugar that essentially defined an existential box for every class we define?
<Cale> What are the types of the methods of Summa?
<Cale> dmhouse: sorta :)
<nmessenger> if I remember correctly Summa is Monoid, Int1 is (0,+) and Int2 is (1,*)
<paolino> mmhh. Cale this is not the real code :)
<Cale> For one, sometimes it's impossible, and secondly, you want it to be explicit, because it's an irreversible operation that throws away information. Other than that, it would be nice. :)
<paolino> You know the real code !
<Cale> (I mean the application of the existential constructor had better be explicit)
<Cale> paolino: what was the URL to your code again, and which class is this?
<Cale> Doing this with something like Monoid won't work.
<Cale> If Summa is anything like Monoid.
<Cale> You really just want a union type.
<paolino> catenova.org/~paolino/hancl/Net/Net.hs
<Cale> okay, which class, I don't see Summa :)
<paolino> classes to be parsed are Collect, Refine, Tag, Schedulig
<Cale> Scheduler won't work.
<Cale> Well, it sort of will, but probably not the way you want it to.
<Cale> The others would be okay having existential instances.
<paolino> what is wrong with Scheduling
<Cale> mediate has to take values of type h
<Cale> (well [h])
<Cale> and so when you go to write the existential instance, you'll be getting a list of existential boxes of things which could be any instance of Scheduler
<Cale> and there's no downcasting.
<paolino> also Tag is wrong then
<Cale> tag would be okay
<Cale> because you can unbox the thing, and apply its tag function
<Cale> since you know it's in the Tag class
<Cale> But there's only one of it :)
<Cale> It's when you have to combine things that it becomes an issue.
<Cale> Like, suppose I had some class Add a where (+) :: a -> a -> a
<nmessenger> @get-oleg
<lambdabot> Unknown command, try @list
<Cale> then I go to make an existential type for the class:
<Cale> data Addable = forall a. (Add a) => Addable a
<Cale> that's all fine
<Cale> only once I apply the Addable tag to a value, it becomes useless.
<Cale> I'd like to write:
<Cale> instance Add Addable where
<Cale> (Addable x) + (Addable y) = Addable (x + y)
<Cale> but I could only do that if I knew that x and y had the *same* type
<Cale> and I don't know that
<Cale> all I know is that they're individually some types which are instances of Addable
<Cale> I could write something like:
<paolino> I refactor Scheduling
<Cale> double (Addable x) = Addable (x + x)
Previous Page Next Page