15:04:03 <donri> stepcut: what again was the problem with http-types such that IIRC you didn't want to use it for hyperdrive?
15:18:43 <donri> mm_freak_: i see you're using Map and Set in cascading, but order is significant in css...
15:21:48 <mm_freak_> donri: i'm using Map and Set only where it's not significant
15:22:08 <mm_freak_> for everything else i'm using [] as pointed out in the haddocks =)
15:22:27 <donri> mm_freak_: well i don't think there are any cases where it isn't significant :)
15:22:39 <donri> mm_freak_: for example you use it for imports, but that matters for the same reasons as why properties matter
15:27:41 <mm_freak_> ah, the reason is that i'm assuming that there are no inter-dependencies between stylesheets in different files
15:27:53 <mm_freak_> but anyway, i recommend using clay instead
15:28:06 <mm_freak_> i wrote cascading because i wasn't aware of clay =)
15:28:07 <donri> mm_freak_: you gave up on cascading? :(
15:28:27 <donri> mm_freak_: anyway say you import a reset or normalize, you totally need those to come first
16:07:33 <mm_freak_> yeah, i gave up on cascading…  also i'm not doing much web dev right now =)
16:08:28 <mm_freak_> but it wasn't completely in vain…  i learned much more about CSS than i thought there was to learn during the development
16:19:01 <levi> I did my recent homepage's stylesheet in Clay.
16:19:54 <levi> It worked out pretty well, although it could use more active users and a bit of refinement at a couple of points.
16:19:57 <uniquenick> I hadn't look at either before, is the motivation to be like a LESS/SASS?
16:20:45 <levi> It's kind of like that, although it's a combinator library rather than a translator.
16:22:28 <mm_freak_> well, cascading is supposed to produce small stylesheets and integrate well with any framework
16:22:47 <mm_freak_> that's why it's polymorphic in the monad it uses
16:23:27 <levi> Clay really just uses its monad to get do syntax for aggregation. It's really just a monoid.
16:24:01 <mm_freak_> cascading does the same, but it doesn't define a monad
16:24:09 <mm_freak_> it uses MonadReader and MonadWriter
16:24:12 <mm_freak_> together with Monoid
16:24:50 <levi> I don't believe Clay even has a Reader.
16:27:36 <levi> Yeah, its monad is a newtype of Writer [Rule] a
16:28:21 <levi> That's actually something I'd like to change about it.
16:29:32 <mm_freak_> levi: are you the author of clay?
16:29:36 <levi> Nope.
16:29:53 <uniquenick> what do you mean when you say integrating with frameworks?  isn't css pretty not integrated anyways?
16:30:44 <mm_freak_> uniquenick: when you use cascading together with happstack, you can access all your happstack functionality right within a stylesheet
16:30:54 <mm_freak_> it already has a MonadRoute instance
16:31:07 <mm_freak_> and you could add all the others as part of a cascading-happstack package
16:31:52 <stepcut> donri: http-types is still a candidate for usage
16:31:55 <uniquenick> do you have an example of what you might use that for?
16:35:15 <levi> I ran into issues with Clay while trying to separate out parameterized stylesheet generation into a library. You can't, really.
16:35:41 <levi> I guess you could have a module with a fixed set of parameters that you export into all your other sheets.
16:37:11 <mm_freak_> well, perhaps then cascading has a use case after all =)
16:37:42 <donri> uniquenick: the MonadRoute is useful for referring to assets safely
16:37:49 <levi> But dynamically-scoped parameters via monad would be really handy for some things, like convenient syntax for nested grid glasses.
16:38:56 <levi> Clay is also a bit weak in its handling of sizes. They're Num instances, but most of the Num methods are just error calls.
16:39:24 <mm_freak_> cascading uses prisms for its sizes
16:39:39 <mm_freak_> and is even type-safe regarding where you can use what kind of size
16:40:01 <levi> As the tin for Clay says, it really doesn't do anything fancy.
16:40:09 <levi> As far as language features goes.
16:40:52 <levi> Clay does restrict which size types work in which contexts, but it's currently *too* restrictive in a few places and I had to manually loosen it up a bit.
16:40:57 <donri> mm_freak_: including whether you can use negative values?
16:41:15 <donri> i found that hard to do when i was working on my type safe css lib
16:41:25 <mm_freak_> no, i don't think so
16:41:39 <levi> But once you put a number into one of Clay's size types, there's no further numeric processing you can do with it.
16:41:56 <donri> and you can't really use the Word types or a Nat type because it still allows decimals :p
16:42:31 <levi> I started a separate size type implementation, but it's currently awkward and otherwise bad.
16:42:47 <donri> levi: one thing i wanted to do was Num instances that understood css, so you could say things like Em 2 + Px 3 and it would figure out what that meant
16:43:08 <donri> maybe not with Em though because that depends on the font size
16:43:43 <levi> donri: Yeah, I wanted to do that too, but Num doesn't even support that without some 'from<type>' calls all over the place.
16:43:55 <donri> levi: ?
16:46:07 <donri> instance Num where Inch a + Cm b = Cm (b + 2.54)
16:46:10 <bergmark> but aren't all the size types pretty awkward to combine?
16:46:13 <donri> it's not hard
16:46:33 <donri> uh, Cm (b + 2.54 * a) :)
16:46:54 <levi> Oh, I didn't think of creating Num instances for pairs of types.
16:47:04 <levi> Didn't know you could do that.
16:47:08 <donri> bergmark: css differentiates between "absolute length units" and "relative units"
16:47:22 <donri> bergmark: we probably couldn't do the relative ones easily
16:47:49 <donri> levi: data Length = Cm Double | Inch Double
16:47:51 <donri> etc
16:48:07 <bergmark> and why would you want to add inches and cms :) or why use them at all
16:48:25 <donri> bergmark: in deed. mostly because "cool".
16:49:22 <donri> another option would be to say newtype Length = Length Double and instead of Inch you have inch a = Length (a * 2.54)
16:49:35 <levi> The relative ones are actually inter-convertable with the fixed ones if you can look up the sizes you've given for the ones they're relative to. At least if you assume a default stylesheet for the base settings.
16:49:42 <donri> but one of my goals for that type safe css lib was to keep the css structure and give you rich types to pattern match on
16:50:23 <donri> levi: yeah that assumes having the full stylesheet (and computing selector equivalences and inheritance)
16:50:26 <levi> A lot of techniques for generating different kinds of flexible grid systems use fixed-to-relative conversions in their math.
16:51:09 <levi> It would at least be handy to have conversion functions where you explicitly give the value they're relative to.
16:53:33 <levi> All of the fixed units also have standard conversions to/from inch/cm values as well.
16:53:42 <levi> A CSS Point is 1/72nd of an Inch.
16:53:55 <levi> And a CSS Pixel is 3/4 of a Point.
16:54:00 <donri> yes, those are part of the "absolute" units
16:54:04 <levi> A Pica is 12 Points.
16:55:30 <levi> And I also found it interesting that the CSS spec considers percentage sizes as a separate kind from the fixed and relative sizes.
16:56:49 <levi> I think the rationale is that what the percentages are relative to varies depending on the element, while the relative ones all behave the same regardless of the element they're styling.
16:58:42 <levi> Anyway, after learning about how all that works, creating a nice basic style is actually fairly straightforward.  Lining things up no longer seems like black magic.
20:32:10 <donri> i'm playing with generating types for css by parsing the spec. it's fun to end up with constructors like ListStyleTypeDecimalLeadingZero
20:32:23 <donri> via TH
20:37:27 <levi> Heh, nice.
20:37:46 <levi> Which CSS spec are you parsing, though? There are like 20 of them now. :P
20:38:27 <donri> css2
20:38:39 <donri> but since i'm generating things it shouldn't be much work to port to css3 modules
20:40:02 <donri> man i wish constructors were type scoped :/
20:40:15 <levi> Yeah.
20:40:27 <donri> i'd rather have Inherit :: Clear than Clear'Inherit (i added a ' to separate)
20:41:06 <donri> and TH doesn't really help for generating *modules*
20:41:11 <bergmark> ' in the middle of names always baffle me
20:41:30 <donri> bergmark: _ ?
20:41:36 <bergmark> Couldn'tFindImport ModuleName
20:41:41 <levi> Maybe TH is not the right approach. I mean, you only really need to do this once for a library.
20:42:23 <mm_freak_> how can you parse the CSS specs?  they are almost completely english
20:42:29 <donri> levi: possibly. could maybe generate HSE nodes and write them out pretty printed
20:42:42 <donri> mm_freak_: http://www.w3.org/TR/CSS2/propidx.html
20:42:56 <donri> just playing with properties
20:43:01 <mm_freak_> ah
20:43:48 <donri> properties and values are the hard part for type safe API anyway, since they vary a lot between each other
20:44:48 <donri> levi: i'm just gonna generate type classes for every keyword :P
20:46:02 <mm_freak_> donri: that's why i used type classes of prisms
20:46:19 <donri> ya, i did in my previous attempt as well
20:46:22 <donri> but that was all hand written
20:46:33 <donri> which got really insane when trying to keep it all type safe
20:47:02 <donri> (ie. i'm going for "valid css by construction" at least as much as possible)
20:47:28 <donri> (because masochism)
20:48:01 <mm_freak_> not sure what the point of that would be
20:48:11 <donri> me either! :)
20:48:39 <mm_freak_> can i use mozilla extensions?
20:49:48 <donri> mm_freak_: in my previous package i included constructors like "UnsafeProperty Text Text"
20:50:22 <mm_freak_> how do i add a property with the common vendor prefixes?
20:51:14 <mm_freak_> for CSS you normally have a choice between correctness and flexibility
20:51:29 <mm_freak_> it was one of the lessons i learned from writing 'cascading'
20:52:13 <donri> forM_ prefixes $ \prefix -> unsafeProperty (prefix <> propName) propVal
20:53:48 <donri> another idea would be to include a DSL for untyped but syntactical CSS, under the assumption that vendor properties still use the same CSS syntax
20:54:31 <donri> (ie. provide something like "cascading" as a fallback/backdoor)
20:56:43 <donri> anyway the point is mostly 1) to see if i can and how far i can take it :), 2) writing correct CSS is hard, 3) complete and fully typed DSL makes it all work well with your existing tools (type checking on the fly, autocompletions, hoogle etc)
20:58:07 <donri> i should probably use agda or idris for this though xD (not that they provide code generation support that i know of...)
20:58:39 <donri> but if it ends up anywhere near usable and complete, i do want it in haskell anyway
21:19:11 <donri> haha TH allows you to include - in a non-infix name
21:21:33 <donri> actually it allows : even
21:21:52 <donri> bergmark: how do you like Display:Inline ;)
21:21:59 <donri> you can't refer to it without TH :D
21:24:04 <bergmark> you are travelling down a dark road friend!
21:27:01 <levi> Clay has a nice "string" -: "string" as the ultimate escape hatch.
21:29:11 <levi> donri: What kind of code generation support would you be looking for in Agda/Idris?
21:29:44 <donri> levi: something that doesn't involve string programming :)
21:39:58 <levi> Well, CSS files are big strings.
22:05:15 <donri> levi: i mean for generating agda/idris. and yes that's why i'm making a typed api for css ;)
22:23:11 <levi> Well, I don't think there's a 'Template Idris' but it is implemented in Haskell, so I imagine it would be possible to generate Idris code from some AST defined in its source.
22:26:28 <levi> Yeah, src/Idris/AbsSyntaxTree.hs has got both the tree types *and* their pretty-printers! What a deal. :)
22:27:46 <donri> :)
22:27:56 <donri> but i still want a haskell dsl in the end
22:30:38 <donri> bedtime
22:31:04 <levi> Maybe you can do the type-checking in idris and generate a Haskell AST to prettyprint with it. Run it as a HSX-like preprocessor. ;)
22:31:38 <levi> G'night.
23:22:59 <mm_freak_> apropos idris…  i wonder if it has a nice interpreter interface
23:23:25 <mm_freak_> hmm, no =/