[elephant-devel] Querying Advice

[Daniel Salama]

I agree that macros are not a necessity. I was thinking in  
abstracting the predicate building functions so that you wouldn't  
have to "hard-code" some of the functionality. In essence, kind of  
like building a querying language. Granted, I agree that it should be  
flexible enough to allow the user to provide custom predicate functions.

Thanks,
Daniel

On Nov 13, 2006, at 6:52 AM, Pierre THIERRY wrote:

> Scribit Daniel Salama dies 12/11/2006 hora 10:28:
>> I guess we would have to sequentially navigate thru the  results in
>> order to "manually" select each record based on all the other
>> possible search arguments. I suppose, in a way, this can be done
>> relatively painless by using macros
>
> I don't think custom macros are needed here. The search could be made
> with the various searching functions of Lisp and a predicate built  
> from
> the constraints. Here is an example of a predicate building  
> function for
> an application about real estate:
>
> (defun search-predicate (&key min-price max-price min-surface max- 
> surface)
>   (lambda (x)
>     (and
>       (if min-price (>= (price x) min-price) t)
>       (if max-price (<= (price x) max-price) t)
>       (if min-surface (>= (surface x) min-surface) t)
>       (if max-surface (<= (surface x) max-surface) t))))
>
> Macros could be used to return an optimized closure where some useless
> branching is avoided, but some implementation may already do that
> optimization by themselves (I think at least SBCL removes unreachable
> code when compiling).
>
> It should be pretty easy to write some macros to avoid writing the
> predicated building function by hand, and we may provide some more as
> some sort of query language for the most common cases (min and max for
> the result of a function, and so on). I think we should keep the  
> ability
> for the user to provide it's own predicate code (it would be so
> unlispy not to...).
>
>> Then we have the issue of the sorting. I suppose it falls into a
>> similar situation: once we get the matching resultset from the
>> previous step, we would have to perform some "efficient" sort
>> algorithm on the data set dynamically based on the user's sorting
>> desire. I also suppose we could create a macro for this as well.
>
> I'm sure sorting is an absolutely pure functional thing. It's "just" a
> matter of finding an efficient algorithm here. Beware of premature
> optimization though. I think we should build a correct solution first,
> and check the state of the art of database implementations if  
> profiling
> show us a bad performance.
>
> Functionally,
> Nowhere man
> -- 
> nowhere.man at levallois.eu.org
> OpenPGP 0xD9D50D8A
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel