Subject: System

Keywords: ::tips
          ::search
          ::overview
          ::implementation

Title: queries

--------------------------------------------------

Expression Tree
  - object_ids
  - FAQ Search

Erlang Database
  - fragments
  - events

Include
  -term

Query : expr # source

Expression : filter  - term -> bool 
  - match
  - interpret
  - ML code

Source : list | generator
  - table
  - library
  - directory tree
  - list
  don't want to require list, for example if source is tree then walk tree
  and accumulate list. Certainly don't want to make list of library.
  Also if searching objects then might want more than term

Instantiation : some operations construct or access terms to  pass on.

Keys : really searching for key, but using term to filter the keys.

modes:
 - lib_query : lib filter -> obid # term list 
 - db_query : value filter -> (key # term list
     * not term is not necessary the same as value 
 - kv_query : key term list -> key list
 - choice : key list -> key # value

Searching for a key or an obid not the term.
 from the key we can find the term (and more in the case of obid)

Obid : prefilter with kind, liveness, and properties

Can compose with :
Choose : KEY list -> Key
  - nth
  - hd   
  no need for predicate since can filter with predicate first.

Lookup(Key) -> term


OR : first match (if match var occurs multiple times it is bound to first matching val)
AND : all match  (if match var occurs multiple times all occurences must be the same
        same meaning alpha-equivalent (or lexicographic equivalent?). 

Accessors : pattern want to apply predicate to subterm
  - find property in property list
      
 filter (p:term -> bool) ((a:term -> term list) term)  
 
 rather than produce list have implicit form with predicate and list generator.
   - list generator is spec for convert term to list of term
     mainly specify cons operator.


Want obid in expr terms to "de-syntax" constructions, but some applications
may want simple terms for ease of interpretation (eg. Erlang) thus in context
can make simpler sytactic terms.
 - specify precisely then reduce at call to context,

 


source 

mode switching
 ML nonsensical in some contexts (primarily Erlang query)
 so use sparingly and generally at highest (outermost) expr  

preferred terminionly

 eval : evaluate ML function
 interpret : intepret logic expression
 match : match pattern

 interpret:
  

 mat

 thus primarily matching and interpreting.
   generally interpreting a logical expression thus 
  could view as match and logic
  unfortunate choice is that syntax use pattern instead of logic or interpret in
  nameing, kind of deeply embedded at this point so live with-it for time being
  or define abs which unfolds to unfortunate version
start interpret 
  ⋅
--------------------------------------------------

Authors: 

Contributors: RICH:t

⋅

Home