Showing posts with label REST. Show all posts
Showing posts with label REST. Show all posts

Friday, December 10, 2010

Beautiful Curl

The Curl language can have a strange beauty: consider that when mixing positional and keyword arguments to a method or procedure that the positions of the former need only be in relative order and that duplicate keyword arguments are permitted.

With access to the Curl AST and the power of Curl macros - and the fact that the  Arguments object is still part of Curl - a fascinating avenue opens for unusual programming paradigms.

Just consider the bug-bear of any Prolog which is the fact that the serial order of clauses and facts is critical and drives the need for cut.  But just imagine the kind of quasi-forward-chaining that can be done by parsing Arguments based on relative positions: remember that the keyword arguments can be in any order and can be duplicated.  Not only that, rest arguments can be given a type at compile time such as anonymous func {proc-type} (but in that case ... may not contain keyword arguments.)

My first experiments are simply

  {clausal goal, 1, clause: procC, clause: procB, 2, clause: procA , asserted-working-mem}

where {clausal} is just
{define-proc {goal:{proc-type}, branch:int, leaf:int, ...}(result:bool, depth:int, breadth:int)
Notice that in my example the rest keyword arg clause: is preceding the positional leaf arg!  There is order relied upon - but it is our order in our code-as-data.

But {define-proc} is itself a Curl macro ... which makes implementing logic in Smalltalk look like really hard work in comparison ...

My convention above is (Goal, [guard-clauses],branch,[clauses],leaf,[clauses],WM)

Anonymous Curl functions close-over their context and are first-class, so I do not explicitly return a solution set.  And of course I can pass in a logic procedure.

What is remarkable is to inspect rest arguments and lo-and-behold there are the multiple keyword arguments.  The convention is that a Curl function cascades to take the last of the duplicate keyword arguments - but now we place our own macro in the body of our clausal proc and proceed to evaluate, parse, ...

Immediately someone says 'But look at the performance hit!'  But if your problem is hard and your solution is elegant, performance will not be the issue - better an answer in 90 seconds or 42 minutes than in 90 centuries or more.

The next nay-sayer: 'But we have a C library that does this!'  And the answer is that we needed a dynamic solution responsive to the user's hunches and advice.  And we wanted a useful, debuggable trace, not a trace that now needs to be parsed and even then may not be useful.  And we want it to be more readable than LISP.

My point is only this: I can get this richness out of the macro {define-proc} itself.  And thankfully Curl 7.0 retained its Arguments class - unlike the fate proposed for Arguments in a harmonized ECMAScript5+ as it moves to its rest arguments convention.  To quote as AS3 author
The catch is to remember that the ...(rest) keyword can be defined only after explicit parameters because required parameters must come before optional ones
Now where had we seen that before ...

Monday, August 27, 2007

Links relating to Curl 5.0 as RIA + CSPD

Client-side persistent data or CSPD may be out of favor in the current "I'm OK, stateless's OK" buzz but I like the 'public library' model: I return a book and the only record of my having borrowed it is my own record. Just try to sell that to the Barnes&Noble / Borders / Amazon / BlockBuster / BestBuy / NetFlix "we've got your number crowd". The more radical option is the 'purchase' card whose record does not belong to a bank or credit card conglomerate: I pick the 'bank' for transactions based on interest rate. Talk about competition! Having data 'client-side' need not mean 'local to this box' but rather, "not on your server". On this model your medical records would not be held by doctor PA's, hospitals or insurers. And your privacy could be in much better hands. Ok, I'll give it a REST ...

But my links to Curl which are not links to cURL are slowly coming alive ... and Curl is CSPD friendly. It has not yet seen that client-side 'store' should be opaque to the server, but it may get there. Not middleware. Call it 'periware' and 'exolayer'.
Buy a book at Borders and then go borrow a book at your library. Now make a return at each (don't cheat and read that new book!) Now ask where your medical records belong ( "we know you are in pain, but we need at least 24 hours notice to have your records sent up." I only had to hear it once.)
Having my records at my beck-and-call does not mean that I can 'access' them. It means that I decide who can access them short of a court order. And when. And where. And that is just my medical records.
The fine print on your savings account book may explain that your money is not always available for withdrawal. And in some countries you pay to have an account and fill out forms to make any withdrawal. PayPal is as foreign to those 'service' banks as is client-side data in the current praise for HTTP.
Many years ago, when TCP/IP turned 15, we were asking when the protocol would be replaced altogether. About the same year as we asked 'Is this the year of Unix?' Perhaps the year that I finally see overhead wires go underground, I will see the system of record no longer be the central system, but the peripheral system. Periware. Exolayer. The Exonet, adumbrated. How apposite.