Camelia, the Perl 6 bug

IRC log for #november-wiki, 2009-03-10

| Channels | #november-wiki index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:44 PerlJam joined #november-wiki
01:25 viklund joined #november-wiki
03:31 Tene_ joined #november-wiki
03:33 wayland76 joined #november-wiki
07:34 wayland76 joined #november-wiki
08:45 masak joined #november-wiki
09:45 p6eval joined #november-wiki
10:24 wayland76 joined #november-wiki
10:37 ihrd joined #november-wiki
11:01 masak ihrd: oh hai
11:01 ihrd masak: HAI
11:05 masak ihrd: have you thought of what you'll be using as a database backend for the MVC stuff in Web.pm?
11:06 masak for the model part, I mean.
11:07 ihrd files on the start, sqlite or mysql on the end (I hope)
11:08 ruoso porting DBIx::Class to Perl 6 would be a good subject to another grant
11:08 masak ihrd: there is a Perl 6 script in the Parrot repo that does sqlite.
11:13 masak https://svn.parrot.org/parrot/t​runk/examples/nci/mysqltest.p6
11:13 masak seems it was mysql though, and not sqlite.
11:15 wayland76 I'm going to backend my stuff onto XML
11:15 wayland76 But I may not be using all the layers of Web :)
11:16 wayland76 s/XML/Tree/ :)
11:16 ruoso masak, but I insist that you leave the model part to the end
11:16 masak ruoso: ok.
11:16 ruoso as well as the view part
11:16 masak lunch &
11:16 wayland76 ...and maybe the controller too?  :)
11:20 ruoso wayland76, in fact... the most important part is the dispatch, for starts, so... the controller can be delayed as well ;)
11:23 wayland76 Where do I read about dispatch?
11:24 wayland76 Does it mean "which (sub)pages are loaded when"?
11:24 ihrd masak: yes, I saw this link
11:33 rkendall joined #november-wiki
11:38 ruoso wayland76, http://github.com/masak/web/blob​/master/doc/web-framework-roles
11:38 zarah ruoso's link is also http://tinyurl.com/cn3bhg
11:40 wayland76 components, that's the word I was after :)
11:40 wayland76 thanks ruoso
14:45 ihrd left #november-wiki
15:11 p6eval joined #november-wiki
15:14 masak http://www.hanselman.com/blog/TheWeeklySour​ceCode20AWebFrameworkForEveryLanguage.aspx
15:14 zarah masak's link is also http://tinyurl.com/38x3v2
15:14 masak Arc, Seaside and Haskell impress with their brevity.
15:14 masak what's the shortest we can make in Perl 6?
15:15 p6eval joined #november-wiki
15:16 p6eval joined #november-wiki
15:30 Tene joined #november-wiki
16:43 ruoso masak, they imply some kind of html generation embedded
16:43 masak ruoso: sure.
16:43 ruoso which seems to compromise view/controller separatino
16:43 masak ruoso: right.
16:43 ruoso which is not a very good idea, imho
16:43 masak but we're not _just_ building an MVC framework here.
16:43 ruoso right...
16:44 ruoso but compromising extensibility by coupling things is not a good idea in any case
16:44 masak sometimes what you want is something more like Sinatra.
16:44 masak well, it's like saying that Perl one-liners are bad.
16:44 masak everyone agrees, but sometimes they come in handy.
16:44 masak less to write.
16:44 masak quicker to create.
16:45 masak JFDI.
16:45 masak structure and orthogonality may come later in a project.
16:45 ruoso er... that's the main difference between catalyst and RoR
16:45 masak oh? please elaborate,
16:45 ruoso RoR makes easy things piece-of-cake and hard things impossible
16:45 masak :)
16:46 ruoso Catalyst makes easy things slightly more complicated and hard things possible
16:46 masak ruoso: so different frameworks have different complexity sweet spots.
16:47 masak that's not very surprising.
16:47 ruoso that's not what I meant
16:47 masak no, I understand that, too.
16:47 ruoso some frameworks take dirty shortcuts to provide ease of use in the very most common case
16:47 masak my point is, though, that you can't have a framework be both very simple for small things, and very orthogonal for big things.
16:47 ruoso compromising extensibility and flexibility
16:48 masak sometimes you want one, sometimes the other.
16:48 rkendall Just chipping in with half a cent: Most web-dev seems to be the easy stuff
16:48 ruoso masak, what I do think is that having a DSL solves the issue
16:48 masak ruoso: oh, did I mention that I don't like the term DSL? :)
16:48 masak I think it's mostly hot air and a buzzword.
16:49 ruoso masak, for RoR, that's for sure
16:49 masak I'd prefer if it were replaced with the three or four terms that people really mean when they say it.
16:49 masak ruoso: not just RoR. more or less the whole Ruby world.
16:49 wayland76 joined #november-wiki
16:49 masak it's like they have a crush on the very term.
16:49 ruoso but a DSL for Catalyst, for instance, would be very much usefull
16:49 * masak groans
16:49 ruoso because Catalyst has strong semantics support
16:50 ruoso so a DSL would hide that semantics for the common case
16:54 Tene +1 masak
16:54 masak http://use.perl.org/~Aristotle/journal/36223
16:54 zarah masak's link is also http://tinyurl.com/cc7uqr
16:55 masak Aristotle usually writes refreshing things about 'DSL' as a term.
16:56 masak http://use.perl.org/~chromatic/journal/34133
16:56 zarah masak's link is also http://tinyurl.com/2lf9ta
16:56 masak chromatic too.
17:00 masak ruoso: specifically, rejecting the challenge because it would 'compromise view/controller separation' is kind of missing the point, which is to show what your language, along with the right library, can hide away in terms of complexity.
17:00 ruoso masak, I'm not rejecting the challenge
17:00 masak ok.
17:01 masak good; for a while it sounded that way.
17:01 ruoso I'm just saying that I'm not sure avoiding controller/view separation for golf purposes might not be a good idea
17:01 ruoso gah...
17:01 ruoso let me rephrase
17:02 masak be my guest.
17:02 ruoso I'm just saying that I'm not sure loosing controller/view separation for golf purposes is a good idea
17:02 masak I'm curious how you arrive at that viewpoint.
17:02 masak specifically, why do you think that the same tool must serve both those who want golfers and those who want an MVC framework?
17:03 masak for me, those two have always been separate tools.
17:03 ruoso s/MVC//
17:03 ruoso I already worked with non-MVC frameworks as well
17:03 masak sure, fair enough.
17:03 masak still, it doesn't even have to be a framework.
17:03 ruoso but even in non-MVC, gluing the view in the logic is a bad idea
17:03 ruoso er
17:03 ruoso that page was about "frameworks"
17:03 masak ruoso: I think that's quite a categorical point of view.
17:04 masak I wouldn't go so far as saying that mixing view and logic is always bad.
17:04 masak just like goto isn't always bad.
17:04 ruoso it's like having prints inside the code to generate the output
17:05 masak no, it most decidedly is not.
17:05 masak that's just creating a strawman.
17:05 ruoso or using CGI.pm methods
17:05 masak we're here to help the programmer, not to point fingers.
17:06 ruoso anyway... as far as a "framework" is concerned, separating the view from the logic is usually the first step
17:08 ruoso also, as for code maintainance, the most usual problems arise from bad judgment of where the view/logic barrier is...
17:09 masak ruoso: and you still don't think that you're missing the point of the challenge? :)
17:09 masak it's about producing a small webapp in a few lines of code.
17:11 masak possibly sacrificing things such as view/model separation.
17:11 masak ruoso: besides, do you think that the Seaside example mixes view and logic too?
17:12 ruoso masak, I don't really understand what "request" and "inform" are
17:12 masak ruoso: neither do I.
17:12 masak my guess is that they produce widgets and text, respectively.
17:15 ruoso masak, but seaside takes a hard bet on continuations
17:15 masak indeed.
17:15 ruoso which takes them to a different land
17:15 masak true.
17:15 masak I'm still impressed.
17:15 ruoso and that really solves a completely different set of problems
17:16 masak they manage to hide the request/response part of the webapp, which is innovative to say the least.
17:16 ruoso masak, not really inovative...
17:17 ruoso I wrote a framework that did that in 2001
17:17 ruoso http://perl-oak.sf.net
17:17 masak oh, I didn't mean it's a completely new idea.
17:17 ruoso the use of continuations is the big deal
17:17 masak I just think it's one that doesn't get enough attention.
17:18 * masak needs to go soonish
17:18 ruoso masak, but take a look on the Reaction work
17:18 ruoso that mst and the people at shadowcat are doing
17:18 masak ruoso: url?
17:19 ruoso because seaside is cool, but it neglects completely the fact that URLs are a very important thing in web applications
17:19 ruoso specially idempotent URLs
17:19 masak ack.
17:19 masak that was my thought as well when seeing a demo of it.
17:19 ruoso masak, ask mst for it, I don't remember
17:19 masak ok.
17:19 masak that'll have to be tomorrow, though.
17:19 masak logs++
17:20 ruoso Reaction takes a similar bet of seaside
17:20 ruoso but still being URL aware
17:20 masak aha.
17:20 masak interesting.
17:20 ruoso it basically conceives an Abstract ToolKit
17:20 ruoso so you model your application interface
17:21 ruoso but it's still based on the Catalyst dispatcher
17:21 * masak found http://dev.catalystframework.org/wiki/reaction
17:23 masak gotta go.
17:23 * masak waves
19:23 moritz_ I've just sent a mail to the list with an idea for a simple, flexible dispatcher
19:24 moritz_ it seem to be too simple to be true ;-)
19:40 ruoso moritz_, I'm replying to that with where it becomes not so simple at all
19:45 ruoso moritz_, as a complement to that reply
19:45 ruoso I somehow think that the reduction operator could play some interesting role there
19:46 ruoso [something] url.split
19:47 ruoso then
19:49 ruoso multi something(Action::Root $root, 'blog', $blogname) { return Action::Chained('/blog') }
19:49 ruoso multi something(Action::Chained $root where { '/blog' }, 'category', $category) { return Action::Chained('/blog/category') }
19:49 ruoso sorry
19:49 ruoso multi something(Action::Chained $root where '/blog', 'category', $category) { return Action::Chained('/blog/category') }
19:51 moritz_ ruoso: I think that a chained dispatcher, once one is written, can easily be plugged in into "my" system
19:51 moritz_ anyway, I'll answer on-list
19:51 ruoso ok
19:52 ruoso moritz_, but reduce seems to be an interesting solution to that problem
19:55 moritz_ ruoso: so you have a system in mind where each reduction step knows how to get from one level to the next sub level?
19:56 ruoso no, it returns an identification of which step was realized
19:56 ruoso which is then used as input to the next call
19:57 ruoso muti something('blog', $blogname) { do-something(); return Action::Chained('/blog') };
19:58 ruoso muti something(Action::Chained $parent where '/blog', 'category', $category) { do-something(); return Action::Chained('/blog/category') };
19:58 moritz_ at the moment I can't wrap my head around that :)
19:58 moritz_ but probably I'm just too tired
19:58 ruoso [&something] 'blog', 'myblog', 'category', 'foo';
19:59 ruoso it will call &something trying to bind as much arguments as possible
19:59 ruoso take the result of that and use as the first argumetn with the rest of the list
20:00 ruoso so, it will first match something('blog', $blogname)
20:00 ruoso which returns Action::Chained('/blog')
20:00 ruoso and then it will call it again with that return and the rest of the list
20:01 moritz_ so that each part of the URL can decided how many arguments to use up
20:01 moritz_ clever
20:01 ruoso that's how reduce works, isn't it?
20:02 ruoso you just need to place two anchors before and after each URL part
20:02 moritz_ ususally not
20:02 ruoso one to mark the start
20:02 ruoso and other to mark the end
20:02 moritz_ this scheme requires you to keep state in the reduction function
20:02 Tene I have to use django at work, and today I am learning about django forms.  For each form, you need a class.
20:02 ruoso moritz_, the reduction does it already
20:02 Tene So if you want dynamic forms, or generated forms, you have to use the metaclass stuff.
20:02 ruoso [+] 1,2,3,4
20:02 Tene To dynamically generate a new class.
20:02 ruoso will first call 1 + 2
20:02 ruoso then call 3 + 3
20:02 Tene This is an awkward situation.
20:02 ruoso then call 6+4
20:03 moritz_ ruoso: I understand that...
20:03 ruoso it's the same here
20:03 moritz_ but if '/blog' wants three arguments, and '/post' wants two
20:03 moritz_ and all with the same reduction function
20:03 ruoso ok, we need a "multi" reduce
20:03 moritz_ ok ;-)
20:03 ruoso but
20:03 ruoso I think it might work already
20:03 moritz_ Tene: that's not something I'd like to have
20:03 ruoso since a multi is just a callable
20:04 moritz_ Tene: I'd like to decide myself for what I write a class, and for what not
20:04 Tene Yeah, really.
20:04 moritz_ ruoso: one problem with all MMD based approaches is that if the dispatch fails, the error message won't be very good
20:05 moritz_ it'll just tell us "dispatch failed at stage $stage", but not why
20:05 moritz_ like, missing arguments
20:05 moritz_ or arguments of the wrong type
20:05 moritz_ actually that bothers me a lot
20:05 ruoso moritz_, the error message would tell which argumetns it tried
20:06 ruoso in this case, Action::Chained('/blog'), 'category', 'foo'
20:06 moritz_ yes
20:06 ruoso which pretty much tells everything
20:06 moritz_ which is equivalent to telling you who far it got
20:07 moritz_ but even if there's only one multi left
20:07 moritz_ if will just tell you "dispatch failed"
20:07 ruoso but that happens in other dispatches as well
20:07 moritz_ and not `"category" doesn't accept "foo", because it doesn't match regex $bar"
20:07 moritz_ we can still try to do better ;-)
20:08 ruoso but the multi dispatch solution seems much more likely to require a sub-grammar
20:09 moritz_ why?
20:09 ruoso because it is heavily dependent on the return of each candidate
20:10 ruoso so it's better to generate it
20:10 moritz_ what do you mean by "the return of each candidate"?
20:11 ruoso actually I meant "reduction iteration"
20:11 moritz_ in "my" scheme not all candidates iterate
20:12 moritz_ only those that do sub-dispatch
20:13 ruoso yes, I'm talking about the "reduce dispatcher"
20:13 moritz_ ah
20:13 ruoso btw... reduce already supports multis ....
20:13 ruoso otherwise overloading + wouldn't work
20:15 moritz_ wait
20:15 moritz_ when you do @list.reduce: { $^a + $^b }
20:15 moritz_ then the closure does the multi dispatch
20:15 moritz_ not the reduce
20:16 moritz_ @list.reduce: &multisub; doesn't work in rakudo
20:16 ruoso [+] 1,$a,$b,2,3
20:16 ruoso that calls a multi sub
20:16 moritz_ yes, but that only works for operators
20:16 moritz_ not for ordinary subs
20:16 ruoso uh?
20:16 ruoso operators are ordinary subs
20:16 ruoso or is rakudo cheating?
20:17 moritz_ yes, and yes. But not all ordinary subs are also operators.
20:17 ruoso there is no difference between those
20:17 moritz_ [&your_sub] doesn't work, to the best of my knowledge
20:17 moritz_ there is
20:17 ruoso which difference?
20:17 moritz_ an operator also has associativity
20:17 moritz_ a sub does not
20:18 moritz_ (and precedence, for that matter, but that's irrelevant here)
20:18 ruoso moritz_, that's just about parsing
20:18 ruoso not runtime
20:18 moritz_ it's also about runtime
20:18 moritz_ [**] 1..10 works differently than [*] 1..10
20:18 moritz_ because ** has a different associativity than *
20:19 moritz_ the first is 1**(2**(3 ...)), the second is (1*(2*3(...)))
20:19 moritz_ which is why we use .reduce for subs and [...] for methods
20:35 ruoso moritz_, one way or another, you're allowed to define new subs defining associativity...
20:35 moritz_ if they are operators, yes.
20:35 ruoso I'm not sure there is this fundamental difference
21:23 szabgab joined #november-wiki
21:58 ruoso joined #november-wiki
22:25 wayland joined #november-wiki
22:37 Tene_ joined #november-wiki

| Channels | #november-wiki index | Today | | Search | Google Search | Plain-Text | summary