vygr
Suggestions?
It is certainly like pushing boulders up hill as I am not truly grounded. I tend to need some basic framing and then I can soar into making changes with more confidence.
What would help me and I think any other contributor would be a kind of "Theory of Operations" or "Compass" document. Something that provides a fly-over from 'boot' to 'ready to execute' describing the order at key levels of what is happening and what files, etc. contribute to the levels.
I understand you may want to keep information in the doc/ folder but consider the GitHub Wiki as an alternative for some things.
Secondly, consider a Kanban type thing leveraging GitHub Projects so changes can be ordered and progressed.
I'm on the chat if you want to discuss....
Continuing the chat discussion... how about a 'day in the life' whereas you describe going about creating the lowest level function that get's promoted up and exposed to lisp/script writing? Including where to put files, etc. along with assembling or compilation steps. These 'steps' can reference out to the specific docs in the doc folder. Thoughts?
Great idea ! Now if only I had a personal biographer.... ;)
I will try to do this the very next time I do it.
(defmacro seq? (form)
; (seq? form) -> t|nil
`(or (lst? ,form) (str? ,form)))
I'm beginning to think that the (type-of) function should be a bit pattern. For instance a List is a seq, but it is also a List, and not a string, but a string is a sequence, and also a string....
So 64 bits available, give us reasonable scope for encoding the class structure and type info we need.
Funnily enough this is what I have done in the C++ (type-of) implementation, so this will bring the two closer together.
Thoughts?
Yes, in foidl I used a 64 bit with the high 32 representing a class and the lower 32 representing type. That supported class abstractions, like seq, with specificity on type (list, map, set, vector, streams, etc.). It also supported inferencing as, of course, a seq and it's subclasses were is_iterable? but that was for that language.
IMHO I wouldn't mind to see (type ...) return the concrete type in the form of a keyword. Whereas the (is...? ...) returning t | nil
I like it
No doubt a full Theory of Ops is a daunting specter so baby steps are a good start like a simple bullet list starting with the bootstrap (main) up through wherever the 'end' of the initialization is?
The quickest way to increase contributions in my mind... all kinds of talent can focus on the 'layer' as a starting point and chip away at what is needed.
(defun get-stream (args alen)
; (get-stream args argslen) -> file-stream
(file-stream
(cond
((or (= alen 0) (= alen 2)) 'stdin)
((= alen 1) (elem 0 args))
(t (if (= (find :count args) 0)
(last args)
(first args))))))
(defun get-count (args alen)
; (get-count args arglen) -> count
(cond
((or (= alen 0) (= alen 1)) 10)
(t (elem (inc (find :count args)) args))))
Here code like:
(or (= alen 0) (= alen 1))
Can just be (<= 0 alen 1)
And if you swapped these two lines over:
((= alen 1) (elem 0 args))
((<= 0 alen 2) 'stdin)
And in get-stream that last (if) is not needed as your allready in a cond so just do the ((= (find ...)) ...) and the cond t clause is the else....
(defun get-stream (args alen)
; (get-stream args argslen) -> file-stream
(file-stream
(cond
((= alen 1) (first args))
((<= 0 alen 2) 'stdin)
((= (find :count args) 0) (last args))
(t (first args)))))
(defun get-count (args alen)
; (get-count args arglen) -> count
(if (<= alen 1) 10 (elem (inc (find :count args)) args)))
Copied over from the IRC to make sure it dosn't get lost:
10:33 vygr: GUI properties are now keywords. 10:34 vygr: Plus you may want this for your property lists too ! And plain old lisp object use. 10:34 vygr: (defq props (env -101)) 10:34 vygr: () 10:34 vygr: (def props :a 10 :b "fred") 10:34 vygr: "fred" 10:34 vygr: props 10:34 vygr: ((:b "fred") (:a 10)) 10:34 vygr: (set props :b "albert") 10:34 vygr: "albert" 10:34 vygr: props 10:34 vygr: ((:b "albert") (:a 10)) 10:34 vygr: (eval :a props) 10:34 vygr: :a 10:34 vygr: (get :a props) 10:34 vygr: 10 10:34 vygr: (get :b props) 10:34 vygr: "albert" 10:35 vygr: (eval) is not the same as (get). (get) now replaces (def?) 10:38 vygr: (get) gives you the current binding for a symbol else nil if none. 10:39 vygr: It will search up any tree of (env) too, so we can use it to makes any heiarchy of properties we want etc. 10:40 vygr: It's seriously fast ! And can happily handle massive amounts of symbols as you can pick whatever size of buckets you like. 10:44 vygr: (get) now completes the (defq) (setq) (def) (set) group of functions.