Re^2: Mapping URLs to code - in search of perlish dispatch schemes

I wish I had seen this earlier. The patch I've looked at seems interesting and I'll see if I can fit it into to an "official" release this weekend. Does it support stuff like functions which keep returning different values, such as a call into a database? I've had some thoughts about that, but it would be tricky.

Cheers,
Ovid

New address of my CGI Course.

Comment on Re^2: Mapping URLs to code - in search of perlish dispatch schemes

Replies are listed 'Best First'.
Re^3: Mapping URLs to code - in search of perlish dispatch schemes by diotalevi (Canon) on Jul 28, 2006 at 19:30 UTC
Earlier? I wrote the patch hours before you noticed it. I was just another iteration of wishing outloud for that feature we've talked about before but have now. There are some major deficiencies with my patch. I think I need to call your unify function but didn't. I think that the normal perlcall/2 should only succeed and call the perl function if all the variables are bound. I think I made a mess of converting your Terms back into perl data. I did something that worked but I didn't understand your organization (you didn't document it!) and probably got it wrong. The current perlcall2/2 searches upwards through the call stack to find the function named X. That should probably be saner - maybe introduce a `perlpackage/1` builtin. Maybe tell perlcall2/2 how to tell the difference between fully qualified function names and relative names. There should be a perlmethod2/2 as well to support method calls. Yes? Much of this can be experimented with once there's a few builtins for looking back at perl. `perlcall(X,Y) :- boundp(X), % uh... a predicate for asking that X need no further u +nification so perlcall only gets complete answers boundp(Y), perlcall2(X,Y), !.` [download] ⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^3: Mapping URLs to code - in search of perlish dispatch schemes
by diotalevi (Canon) on Jul 28, 2006 at 19:30 UTC

Earlier? I wrote the patch hours before you noticed it. I was just another iteration of wishing outloud for that feature we've talked about before but have now. There are some major deficiencies with my patch. I think I need to call your unify function but didn't. I think that the normal perlcall/2 should only succeed and call the perl function if all the variables are bound. I think I made a mess of converting your Terms back into perl data. I did something that worked but I didn't understand your organization (you didn't document it!) and probably got it wrong. The current perlcall2/2 searches upwards through the call stack to find the function named X. That should probably be saner - maybe introduce a perlpackage/1 builtin. Maybe tell perlcall2/2 how to tell the difference between fully qualified function names and relative names. There should be a perlmethod2/2 as well to support method calls. Yes?

Much of this can be experimented with once there's a few builtins for looking back at perl.

perlcall(X,Y) :-
    boundp(X), % uh... a predicate for asking that X need no further u
+nification so perlcall only gets complete answers
    boundp(Y),
    perlcall2(X,Y),
    !.
[download]

⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊

[reply]
[d/l]
[select]