<KipIngram>
Well, I'm now kind of fascinated with the internals of Lisp. I ran across a package out there called PicoLisp. The documentation essentially says that the goal of the package was "the simplest possible virtual machine." And it makes reference to early versions of the product as having been more Forth-like; it explicitly says that. But it says that the Lisp approach turned out to have the simplest VM.
<KipIngram>
Well, THAT got m attention.
<KipIngram>
Plus I keep seeing all these commentaries by people implying that learning Lisp was some sort of borderlinen religious experience for them.
<KipIngram>
I don't know that I'll become a big time Lisp programmer, but that's enough for me to want to have a deeper understanding. Pushes my "me too" button.
<KipIngram>
PicoLisp seems a bit unstable though. It says right in the docs that it's easy to make it segfault - they seem to have taken a "don't do that" approach to the things that will cause that.
<KipIngram>
But then I discover that this:
<KipIngram>
((+ -) 3 4)
<KipIngram>
returns -1, but
<KipIngram>
((- +) 3 4)
<KipIngram>
segaults.
<KipIngram>
Segfaults
<KipIngram>
That seems a tad... "inconsistent" to me. After seeing the first result, I expected 7 from the latter.
<KipIngram>
And before runningn either one I expected (7 -1) or (-1 7).
Zarutian_HTC has joined #forth
gravicappa has joined #forth
dave0 has quit [Ping timeout: 245 seconds]
dave0 has joined #forth
<KipIngram>
One comment I have about Picolisp is that it seems to be trying to be everything.
<KipIngram>
It has OO extensions. It has database extensions. And so on.
<KipIngram>
I'm really interested in the fundnamental list processing logic.
<KipIngram>
The Lisp "heart and soul" stuff.
<KipIngram>
The rest is kitchen sinking as far as I'm concerned.
Zarutian_HTC has quit [Remote host closed the connection]
<KipIngram>
Oh, and it also tries to provide "the semantics of Prolog, with the syntax of Lisp."
<KipIngram>
Like I said - a "Swiss Army Language."
<KipIngram>
Which means that the original goal - for it to be "as simple as possible" - was almost certainly not achieved.
<KipIngram>
It does have a description of the internal representation of things, though. Everythingn is made of 16-byte cells, so that automatically gives you four bits in the LSB nibble that you don't need for addressing. They use those as tag bits to distinguish the different things cells can be.
<KipIngram>
It's described in an odd way, though - they still talk about them as though they are address bits, and say things like "for symbols the pointer points to the middle of the cell" - I think I'd just forget about them being adjacent to the address and treat them as tag bits.
Regenaxer has joined #forth
<KipIngram>
Memory management is described well. Very simple - just a mark and sweep garbage collection when necessary.
<KipIngram>
Probably could be made more efficient by intelligently releasing things instead of just abandoning them.
<Regenaxer>
KipIngram, ((+ -) 3 4) is an interesting idea
<KipIngram>
When they mentioned "maps" for iteration it led me to expect something of the sort I described.
<KipIngram>
List of functions - apply them all to the same arguments.
<KipIngram>
And get a list of outputs.
<Regenaxer>
Nope
<KipIngram>
Seems natural.
<KipIngram>
Right - nope.
<KipIngram>
It's just what I expected; I was wrong.
<Regenaxer>
The CAR of the list is taken as a function
<KipIngram>
I'm not sure yet what it's actually doing.
<KipIngram>
But isn't the CAR of the outer list (+ -)?
<Regenaxer>
(+ -) gives the value of '-'
<KipIngram>
Oh, I see.
<Regenaxer>
But (- +) negates the value of +
<Regenaxer>
so a negative pointer
<KipIngram>
It evals the list BEFORE applying to the args.
<Regenaxer>
right
* KipIngram
is a beginner on Lisp.
<KipIngram>
Ok, that explains the segfault quite well.
<Regenaxer>
You perhaps mean
<Regenaxer>
: (mapcar '((F) (F 3 4)) '(+ -))
<Regenaxer>
-> (7 -1)
<Regenaxer>
The "description of the internal representation of things" is in a file doc/structures
<KipIngram>
Ok, that's the effect I was going for, but I really can't say that what you just typed seems "intuitive" in any way.
<KipIngram>
F is just a dummy there, right?
andrei-n has joined #forth
<KipIngram>
Successively replaced by + and -?
<Regenaxer>
F is the function parameter
<KipIngram>
The quotes prevent evaluation of those lists.
<Regenaxer>
((F) ...) is a function
<Regenaxer>
right
<KipIngram>
Without that last quote it would evaluate that (+ -) to - just like in my original case?
<Regenaxer>
yes
<KipIngram>
I'm not particularly all hot here to learn Lisp, though I am a little. I just saw "simple VM" and wanted to understand more. :-)
<KipIngram>
I like simple VMs.
<Regenaxer>
the value of the symbol '-' is a function pointer
<Regenaxer>
: -
<Regenaxer>
-> 25843260304
<Regenaxer>
so (+ -) gives the same
<KipIngram>
Ok. So if I took that number and parsed the bottom four bits I'd find it qualifed in whatever way it describes those pointers as working.
<Regenaxer>
The simple VM referst to the internal strucwure. The single cell for everything
<Regenaxer>
bottom four bits: correct :)
<KipIngram>
Well, the VM to me would be the bit of code that rips around those structures.
<Regenaxer>
yes
<Regenaxer>
you know "next" in Forth
<KipIngram>
Yes.
<Regenaxer>
in pil it is a little more involved
<Regenaxer>
number -> number
<Regenaxer>
symbol -> value
<KipIngram>
It felt like they were claiming it was simpler.
<Regenaxer>
lisw -> call fun
<KipIngram>
Simpler than their earlier language which was "forth like"
<Regenaxer>
It was a Lisp with RPN
<Regenaxer>
(fun a b) was a b fun
<Regenaxer>
but with those cells
<KipIngram>
Forth achieves its simplicity by using CFA's that point to different functionalities.
<KipIngram>
I suppose truthfully you'd need to consider all of the CFA target code "part of the machine" too.
<KipIngram>
And not JUST next.
<KipIngram>
Certainly at least docol, dovar, etc.
<KipIngram>
Maybe we cheat a little by not counting all the primitives.
<Regenaxer>
Forth is of course a lot simpler
<Regenaxer>
But among Lisps PicoLisp is probably the simplest
<Regenaxer>
not in terms of code, but in terms of *concepts*
<KipIngram>
I was a bit put off by that first thing I tried not working, but I see now what I was overlooking.
<KipIngram>
The (+ -) just *happened* to evaluate to something that would work there.
<Regenaxer>
Good podcast. I listened to almost all episodes
<veltas>
picolist sounds interesting, and interesting example of KipIngram's mistake, I was wondering if that was really valid!
<veltas>
picolisp*
<Regenaxer>
yeah, both ((+ -) ...) and ((- +) ...) are valid, just that the second one crashes ;)
<KipIngram>
Well, thinking of it as the negative of a pointer maks that very intuitive (that it will crash).
<KipIngram>
That link I shared is mostly about web stuff, but at the beginning it has some nice thoughts that touch on what we do in Forth.
tech_exorcist has joined #forth
wineroots has quit [Remote host closed the connection]
jess has quit [Ping timeout: 622 seconds]
<KipIngram>
veltas: One nice thing about PicoLisp is that it's available in the Ubuntu 16.04 package repositories.
<Regenaxer>
yes, but very old
<KipIngram>
True.
<KipIngram>
So, a thought occurs to me. All of my "internal addresses" in my Forth are represented in 32-bit cells, but my data cells (on the stack, in variables, etc.) are 64-bit. I could fairly easily add some degree of list handling similar to that in Lisp by putting the CAR and CDR pointers in halves of a 64-bit cell.
<KipIngram>
Then that could live very happily on the Forth stack as a single item.
<KipIngram>
Any word that wanted to could decide to treat it in that way.
<KipIngram>
It could even offset into an altogether separate section of RAM if I wanted it to.
<KipIngram>
In theory it ought to be possible to have Lisp-like stuff annd Forth-like stuff just exist side-by-side in there.
<KipIngram>
The issue of tag bits exists, though - I guess you'd need tag bits in both pieces, so that might bring me down to 28 bits per for the actual address.
<KipIngram>
And since my pairs would be 8 bytes total instead of 16, only three bits per would naturally offer themeselves. Might not be enough to cover what they did in Picolisp.
Zarutian_HTC has joined #forth
<Regenaxer>
32-bit PicoLisps used also only 3 tag bits
<KipIngram>
Ah, ok.
<Regenaxer>
They are no longer really maintained though
<KipIngram>
Well, if I did something like this I'd do it myself.
<Regenaxer>
You could take a look at MiniPicoLisp
<KipIngram>
But the structure docs would be intneresting to peruse.
<KipIngram>
Having the cell look like a single item to Forth seems like a nice feature.
<Regenaxer>
(the other picolisps are arch-dependent)
<Regenaxer>
Newer and current ones are all 64 bit
<Regenaxer>
except ErsatzLisp which is in Java (limited a bit, like mini)
<KipIngram>
Aw man. Quote from a paper I'm reading: " It seems to me that there have been two really clean
<KipIngram>
consistent models of programming so far the C model and the Lisp model"
<KipIngram>
What about the Forth model? That's high ground.
<KipIngram>
No one appreciates Forth. :-(
<Regenaxer>
I do :)
<KipIngram>
Present company excepted.
<Regenaxer>
true
<KipIngram>
It's like this amazing little jewel just lying there on the ground, and people just walk right by it.
WilhelmVonWeiner has joined #forth
<KipIngram>
It also occurs to me that in my system, which has a pointer to the parameter field instead of the parameter field itself follow the CFA pointer, I more or less already have this dual pointer structure going on.
<KipIngram>
Pointer to code, followed by pointer to data.
<KipIngram>
CFA/PFA instead of CAR/CDR.
<KipIngram>
This is the paper that quote came from:
<KipIngram>
He points out that McCarthy boiled it down to seven items: quote, atom, eq, car, cdr, cons, and cond. So does that really mean if I implemented those seven things I could build up an aribtrary Lisp system from there?
<KipIngram>
I guess it would be missing syntax sugar, like '? Everything would have to be fully written out?
<Regenaxer>
You also need 'set' if you don't want to be purely functional
<Regenaxer>
I never cared about *such* minimal systems, I care about practical usability
Zarutian_HTC has quit [Ping timeout: 240 seconds]
<dave0>
time for bed! nite all
<Regenaxer>
Good night!
dave0 has quit [Quit: dave's not here]
Zarutian_HTC has joined #forth
Zarutian_HTC has quit [Ping timeout: 246 seconds]
wineroots has joined #forth
kiedtl has joined #forth
kiedtl has quit [Changing host]
<lispmacs[work]>
KipIngram: those words by themselves do not I think give you any way to interact with abitrary memory or to make i/o system calls
gravicappa has quit [Ping timeout: 252 seconds]
DKordic has joined #forth
<KipIngram>
That's a good point.
spoofer_ has joined #forth
spoofer has quit [Ping timeout: 265 seconds]
gravicappa has joined #forth
<kiedtl>
What are some good resources/papers regarding optimizations that could be performed on FORTH/stack-based code?
Zarutian_HTC has joined #forth
<WilhelmVonWeiner>
all of Chuck Moore's stuff
<WilhelmVonWeiner>
there is a superoptimiser for F14a code as well out there
<KipIngram>
One issue I have with Picolisp is that it's fairly non-standard.
<KipIngram>
No lambda, for one thing. I feel like for my very first forray into it, I probably should work with a standard version.
<KipIngram>
I mean, it's fine for poking around. But if I'm really going to roll up my sleeves, I want to know I'm somewhere close to the main tent.
<Regenaxer>
If you want lambda, do (setq lambda quote)
<Regenaxer>
You should discuss such things in #picolisp, it is off-topic here
gravicappa has quit [Ping timeout: 268 seconds]
sts-q has quit [Remote host closed the connection]
sts-q has joined #forth
<KipIngram>
Yeah; we had a bit of a lisp kick a couple of days ago, but best to let it go I guess.
<KipIngram>
((lambda (x) (cons x '(b))) 'a)
<KipIngram>
Ooops.
<KipIngram>
Sorry about that guys.
<MrMobius>
I heard a talk by cm on the ga144 last week
<WilhelmVonWeiner>
recent?
<MrMobius>
i kind of wrote the whole thing off years ago when i found out how much memory each core has but the talk got me curious again
<MrMobius>
WilhelmVonWeiner, i dont think so
<WilhelmVonWeiner>
KipIngram: I don't mind. #forth seems more like a community than about a particular language.
<KipIngram>
Well, but that's the kind of thing where if even one person is bothered it's best to do it right.
<KipIngram>
I don't mindn either.
<MrMobius>
seems you can somehow supply instructions from the memory of one core to another
<KipIngram>
I agree re: the community thing.
<KipIngram>
Oh, Chuck's Greene Arrays chip could do that.
<KipIngram>
The cores could execute an instruction stream from a message queue, I think.
<MrMobius>
is there a speed penalty?
<KipIngram>
I don't know.
<KipIngram>
He was real proud of how fast the thing was.
<KipIngram>
And how low power.
<MrMobius>
i dont think ive ever met anyone who has written anything for that chip
<KipIngram>
But I don't know numbers.
<KipIngram>
Right, and you still haven't.
<KipIngram>
I thought it looked fascinating, but never sprung for the kit.
<WilhelmVonWeiner>
MrMobius: I did at university, on the uhh simulator
<WilhelmVonWeiner>
that comes in ArrayForth?
<MrMobius>
he mentions that in the talk. 600mips fwiw
<KipIngram>
I got the impression he was hoping to hit military applications.
<WilhelmVonWeiner>
KipIngram: hoping to hit anything they could, bespoke military and some huge LED panels iirc
<MrMobius>
WilhelmVonWeiner, hmm, the simulator works without the board? also, isnt the imput dvorak or something absurd?
<MrMobius>
i honestly think there is very little application for something like that. it seem extrememly unflexible
ovf has quit [Ping timeout: 260 seconds]
<WilhelmVonWeiner>
i think arrayforth 3 is qwerty..
<WilhelmVonWeiner>
colorforth is dvorak definitely.
ovf has joined #forth
<lispmacs[work]>
does somebody know of a word I can copy to do make inputting a large amount of memory data more concise? I.e., instead of typing $5274 , $4000 , $538d , $4000 I could type C { $5274 $4000 $538d $4000 } or something
<lispmacs[work]>
or W { ... } I meant, for word
<MrMobius>
lispmacs[work], you can certainly make a word like that
<lispmacs[work]>
MrMobius: in principle, but was wondering if somebody had a snippet of code already I could copy
<WilhelmVonWeiner>
using what, gforth? lispmacs[work]
<WilhelmVonWeiner>
i mean you can just compare DEPTH before and after
<lispmacs[work]>
WilhelmVonWeiner: flashforth
<lispmacs[work]>
well, not too important - i just inserted the version using `,'
<WilhelmVonWeiner>
the depth thing would be totally easy though
<lispmacs[work]>
WilhelmVonWeiner: i do not know what you mean, but would be glad to look at an example
<KipIngram>
lispmacs[work]: I don't think there is such a word that's extant, but surely we could come up with something. You just need something like the compiler handling of literals, without actually inserting the (lit) handler.
<KipIngram>
Because that's more or less what happens to a stream of numbers when you're in compile mode, except they alternate with (lit).
<KipIngram>
I take it you want this is a selected range of memory, not "into the dictionary"?
<WilhelmVonWeiner>
lispmacs[work]: something like ` : { sp@ s0 @ - 2/ ( store this depth value somewhere) ; `
wineroots has quit [Remote host closed the connection]
<WilhelmVonWeiner>
and then `: } sp@ s0 @ - 2/ ( fetch depth and diff, then loop , that many times) ; `
<MrMobius>
WilhelmVonWeiner, but then you have to worry about stack depth
<lispmacs[work]>
what I am doing now is `create arrayname $5274 , $4000 , $538d , ...'
<lispmacs[work]>
if solution creates a large stack then it is not worth the bother
<MrMobius>
you could use parse-name to grab the next space delimited thing. make sure the first one is "{" then use number or whatever the gforth equivalent is to convert that. keep looping until you hit "}" with parse-name
<lispmacs[work]>
MrMobius: that makes sense. it seems simple enough in principle I figured somebody else would have done it already.
<lispmacs[work]>
well, maybe I implement it later. I don't really care about the source code density that much so probably isn't worth the bother
<WilhelmVonWeiner>
i dont think parse-name is part of flashforth
<lispmacs[work]>
compiled density is another matter
<WilhelmVonWeiner>
idk why you care about stack depth really when you clean it up immediately
<MrMobius>
: W parse-name "{" compare if begin parse-name 2dup "}" compare not while number , repeat else abort then
<MrMobius>
;
<MrMobius>
untested but something like that
<lispmacs[work]>
MrMobius' solution was along the lines of what I was looking for. Maybe give that a trying during my next lunch break
<MrMobius>
it might just be parse in flashforth
<WilhelmVonWeiner>
oh that is how parse works
<WilhelmVonWeiner>
i was thinking of uhh
<WilhelmVonWeiner>
like a gforth one that parses a word and looks for it in the dictionary then returns that xt
<MrMobius>
'
<MrMobius>
?
<WilhelmVonWeiner>
not that
<KipIngram>
Oh, ok, so you do want it to go into the dictionary.
<KipIngram>
You could write a word that runs find until it succeeds. Each time it fails, run NUMBER ,
<KipIngram>
Use any word in the dictionary as a termination.
<KipIngram>
You'd have to flesh out the details; I don't know exactly how FIND and NUMBER work on your system.
<KipIngram>
You could define } so that it will be found, and then use { for the working word. Then you'd get that C-like behavior { n1 n2 n3 }
<KipIngram>
And when you're done you've cleaned the } out of the way, and interpretation will pick up right after it.
<MrMobius>
KipIngram, why not just do it the way I posted? searching the entire dictionary until you fail for every value wastes a huge number of cycles
<KipIngram>
I haven't read everything I missed yet.
tech_exorcist has quit [Quit: tech_exorcist]
<KipIngram>
I just read far enough to find the answer to my question about the dictionary. :-)