seninha has quit [Remote host closed the connection]
seninha has joined #picolisp
seninha has quit [Remote host closed the connection]
isaneran has joined #picolisp
Riffer has joined #picolisp
Riffer has quit [Remote host closed the connection]
Riffer has joined #picolisp
seninha has joined #picolisp
Riffer has quit [Remote host closed the connection]
Riffer has joined #picolisp
Riffer has quit [Remote host closed the connection]
Riffer has joined #picolisp
isaneran has quit [Remote host closed the connection]
Riffer has quit [Remote host closed the connection]
Raifer has joined #picolisp
Raifer is now known as Reifner
Reifner has quit [K-Lined]
pablo_escoberg has joined #picolisp
<pablo_escoberg>
So, I started work on this document: http://pb1n.de/?c7f03a . I haven't posted it to the wiki yet because there is nothing useful in it yet (well, maybe kinda useful, but very little), and I'll need a good deal of help completing it. Please have a look and point me to any existing documentation I've missed or code I should look at to figure
<pablo_escoberg>
out how to fill in the missing parts.
<abu[7]>
Hi pablo_escoberg! Cool, I'll take a look
<abu[7]>
Looks very good!
<abu[7]>
With "DDL" you mean "data description language"?
<abu[7]>
I would not put too much emphasis on 'collect'
<abu[7]>
It is not as useful as it might look, because it is efficient only for small data sets
<pablo_escoberg>
oh, ok. ISTR a discussion a while back when you said we basically use collect where we use select in sql.
<abu[7]>
it is an executable specification
<abu[7]>
'collect' is useful sometimes
<pablo_escoberg>
well, the way I see it, in most frameworks, you write DDL, then you write classes to describe the DDL in an object-like way.
<pablo_escoberg>
So here, you just write the classes; no DDL needed.
<abu[7]>
yeah, good
<pablo_escoberg>
so I should recommend `db` over `collect` ?
<pablo_escoberg>
is that the standard `select` replacement?
<abu[7]>
The most general access is select/3
<abu[7]>
but also 'init' / 'step' and/or 'iter' and 'scan'
<pablo_escoberg>
right, but that's complicated and involves pilog, which I'm not quite ready for, and also not strictly needed, as I currently understand it.
<abu[7]>
'collect' is tempting because it is so easy
<pablo_escoberg>
init/step is more of a relational algebra thing, right?
<abu[7]>
But you wont want to collect lests of millions of items
<abu[7]>
init/step is the internal primitive of collecw and the pilog predicates
<abu[7]>
The problem is that select/3 is rather tough
<pablo_escoberg>
yeah, I noticed :D
<abu[7]>
Actually, I'm working on a more comfortable Lisp 'search' function
<abu[7]>
But this will take time
<abu[7]>
I'm not so happy any more of having two worlds
<abu[7]>
Lisp vs. Pilog
<pablo_escoberg>
Hmmm.... OK, but ITMT, what I'm trying to accomplish is just the basic sql CRUD stuff in the most accessible-to-sql-folks-like-me way.
<abu[7]>
But at the moment Pilog is needed
<pablo_escoberg>
Happy to hear that. Maybe I won't need to learn Prolog after all :D.
<abu[7]>
let's hope :)
<abu[7]>
As you said, 'db' is fine for direct access
<pablo_escoberg>
So really, the way to access data, the way to replace `select` is by iterating over `scan` results?
<abu[7]>
This is always good
<pablo_escoberg>
or use pilog
<abu[7]>
right
<abu[7]>
or direct 'db' or 'aux'
<abu[7]>
This is very efficient
<pablo_escoberg>
ok, I'll read through the docs on those functions.
<abu[7]>
What is the starting point you have in mind? I.e. a known key?
<abu[7]>
or a combination of keys? Or a range?
<pablo_escoberg>
Good question. I am very used to thinking in terms of sql.
<abu[7]>
For a given key just use 'db'
<abu[7]>
eg. the REST stuff you talked about
<pablo_escoberg>
I did some work back in the 90's in a system called BTrieve, which was a relational algebra system.
<pablo_escoberg>
That worked more or less like this, I think. You searched by key, then iterated over the results.
<abu[7]>
yes, sounds similar
<pablo_escoberg>
Is there any way to do wildcards?
<abu[7]>
yes, similar, using 'match'
<abu[7]>
bpt you need proper keys
<pablo_escoberg>
ah, I was hoping that was the case. And yes, I get that you need the right keys.
<abu[7]>
like +Idx or +IdxFold
<abu[7]>
so you iterate by substrings and then 'match'
<abu[7]>
I don't support general wildcards in my apps
<abu[7]>
Users don't understand them anyway?
<abu[7]>
Just tolerant (sub)strings are usually ok
<pablo_escoberg>
Yeah, that should work fine.
<abu[7]>
For personal names I add +Sn sometimes to cover typical similarities
<pablo_escoberg>
Yeah, that's a great feature to have built in.
<pablo_escoberg>
IAC, looks like I need to look deeply into `scan` `init` `step` `db` `aux` and what else?
<abu[7]>
I wouls say we have three layers: (external) symbols, trees and e/r
<abu[7]>
symbols can be directly traversed with 'forall' or 'seq'
<abu[7]>
trees are accessed with store, fetch, init, step, scan etc.
<abu[7]>
And e/r typically with Pilog
<abu[7]>
But the layers can all be used at the same time
<pablo_escoberg>
ah, ok! That is extremely helpful.
<abu[7]>
db, aux and collect are also on the e/r level
<pablo_escoberg>
I'll look into all of that in depth and see what I can do with the document. It's not going to be as simple as I'd hoped, but I'll get myself up and running and document it as I go.
<abu[7]>
great!
<abu[7]>
Just ask here
<pablo_escoberg>
will do, and thanks as always.
<abu[7]>
☺
pablo_escoberg has quit [Ping timeout: 245 seconds]