Zarutian_HTC has quit [Remote host closed the connection]
shmorgle has quit [Quit: [TalkSoup] via NEXTSPACE]
shmorgle has joined #forth
<KipIngram>
Howdy.
gravicappa has joined #forth
<proteusguy>
KipIngram, is your forth in a github repo already?
<proteusguy>
neuro_sys, the FigForth manual and JonesForth source code (if you're target is x86) are definitely great canonical references for people wanting to build their own forth for the first time. Also Brad Rodrieguz' "Moving Forth" articles are outstanding supplements.
lispmacs has joined #forth
dave0 has joined #forth
<dave0>
maw
gravicappa has quit [Ping timeout: 268 seconds]
gravicappa has joined #forth
xek has joined #forth
gravicappa has quit [Ping timeout: 268 seconds]
Zarutian_HTC has joined #forth
proteusguy has quit [Ping timeout: 240 seconds]
xek has quit [Quit: Leaving]
proteusguy has joined #forth
gravicappa has joined #forth
Zarutian_HTC has quit [Read error: Connection reset by peer]
dave0 has quit [Quit: dave's not here]
Zarutian_HTC has joined #forth
dddddd has quit [Quit: dddddd]
rprimus has quit [Remote host closed the connection]
rprimus has joined #forth
Zarutian_HTC has quit [Ping timeout: 240 seconds]
gravicappa has quit [Ping timeout: 268 seconds]
gravicappa has joined #forth
tech_exorcist has joined #forth
tech_exorcist has quit [Remote host closed the connection]
tech_exorcist has joined #forth
tech_exorcist has quit [Remote host closed the connection]
tech_exorcist has joined #forth
tech_exorcist has quit [Remote host closed the connection]
tech_exorcist has joined #forth
tech_exorcist has quit [Remote host closed the connection]
tech_exorcist has joined #forth
tech_exorcist has quit [Remote host closed the connection]
tech_exorcist has joined #forth
tech_exorcist has quit [Remote host closed the connection]
<KipIngram>
No, it's not yet. I'm not ready.
<KipIngram>
Also Kevin McCabes's "Forth Fundamentals." Especially volume one.
<KipIngram>
Volume 2 is just a compendium of definitionns, but volume 1 goes deep under the hood. It's where I really got my first proper training.
<KipIngram>
I don't think it's in print anymore, though.
<KipIngram>
I think it mostly documents FIG Forth.
<KipIngram>
But my first "Forth," written on a TRS-80 Color Computer in assembly, was a horror to look upon. I didn't know how anything under the hood was supposed to work, so I just made it behave the way it was supposed to behave, and it was probably 5-10 times longer than it needed to be.
<KipIngram>
I read McCabe and the scales fell from my eyes, and after I shuddered when I thought of that first one. :-|
<KipIngram>
So, it's probably good to keep in mind that merely seeing Forth operate is almost certainly not going to convey to a new student how elegant and simple it is internally.
<KipIngram>
I was first drawn to it because it was an "RPN language." I was in college and used an HP-41 CV calculator, and swore by RPN. So that was the hook that first hooked me. But once I learned how brilliantly it's put together internally, that's what's kept me over the years.
<KipIngram>
It's also why I have remained a fan of indirect threading. Code threading just doesn't really "feel like Forth" to me.
<KipIngram>
dave0: Your "return threading" definitely still feels like Forth to me. Yes, it's direct threading instead of indirect, but it's a fairly ingeneius way to get the uP to do next for you.
<veltas>
And I'll have another soon enough hopefully
Zarutian_HTC has joined #forth
<KipIngram>
I have a friennd I chat with elsewhere on irc, who is a former Dell dude and living a relaxed retirement as a consequence. CS training. He's fond of saying Forth looks like a slightly glorified macro assembler to him.
<KipIngram>
I see what motivates the comment, and I can't exactly say he's "wrong," but at the same time he just doesn't have a full appreciation.
<KipIngram>
And I haven't figured out how to give him one - he's not interested in actually diving in.
<KipIngram>
I've posted some code snips for him, but he hasn't taken the effort to actually pick through any of them.
<KipIngram>
I think it's very much like reading English, though - when you first learn to read, perhaps you look at individual letters and "piece together" words. Then you reach a stage where it's just the shape of the word, injecting meaning into your mind. And if you get really good, you get where the shape of whole phrases shove meaning into you. And then you'll read right over typos and grammar errors and so on
<KipIngram>
without noticing them - you just aren't looking at the structure at that fine a level any more.
<KipIngram>
But you have to spend a lot of time working with Forth to get to that level of "idiomatic comprehension."
jess has quit [Quit: updates]
<neuro_sys>
proteusguy: Thanks. I'm currently reading Threaded Interpretive Languages by R. G. Loeliger, it seems to be very decent so far.
<neuro_sys>
Speaking of which, it mentions (I've read it before elsewhere), the way they implement the dictionary is such that the it stores only the first 3 letters of the word names. Does it mean if the user defines two words with overlapping initial 3 letters, that would cause an overwrite?
<neuro_sys>
Ah yes, that's exactly what it mentions in the same paragraph. :)
gravicappa has quit [Ping timeout: 265 seconds]
<KipIngram>
Yes, some of the old systems did that, when RAM was precious.
<KipIngram>
It sped up dictionary searches too.
<KipIngram>
I wrote one of my early ones like that.
<KipIngram>
It stored the *count* and the first three letters.
<KipIngram>
So your candidate word had to be the right length, but only the first three letters had to match.
<KipIngram>
So it would only be a redefinnition if it was the same length and had matching first three letters.
<KipIngram>
Also, very few of the early systems would actually overwrite something already in the dictionary. The new word would still get added at the end. You couldn't know ahead of time that the new word would fit in the space occupied by the old one.
<KipIngram>
So what really happened is you just made the old definition "unfindable," because your search would terminate when it found the redefine word.
jess has joined #forth
<KipIngram>
It occurs to me that it would be possible to scan a dictionary and identify how many first characters needed to match to be sure of no collisions. Then you could limit searches to that to gain speed later.
<kiedtl>
Are concatenative FORTH-inspired (but not actually FORTH) languages welcome here?
<KipIngram>
Another way to speed up searches is to invest 1kB or so in a small hash table, and load it with pointers to various words. You'd always confirm a match, but you could go straight to the right place instead of searching for it.
<KipIngram>
I'm not sure how well that would play with vocabularies, though.
<KipIngram>
kiedtl: For me that would depend on the exact discussions that came up - on how "applicable" they were to Forth. I'd be fine with some leeway there, but I'd want others to express an opinion as well.
<KipIngram>
What's an example of such a language?
<KipIngram>
I'm prone to including non-standard mechanisms in my Forths, so I might learn something fun. :-)
<neuro_sys>
I for one (being a newcomer to Forth) think one of the nice things about Forth is that it's not too strictly defined. So I'd definitely welcome it, even though there's a separate concatenative languages channel, I like it here. :)
<KipIngram>
I agree.
<KipIngram>
I'm not a CS guy - I'm not even sure what a "concatenative" language is.
* KipIngram
is googling...
dave0 has joined #forth
<kiedtl>
KipIngram: Factor, Kitten (abandonware as far as I can tell), Joy, the language I'm working on
<kiedtl>
re examples of languages
<neuro_sys>
CS folk likes to think in terms of abstract notions, and aversive to physical, earthly contraptions that deal with the ugly and gruesome facts of life.
<dave0>
maw
<neuro_sys>
Or in other words, they want to be mathsy, and not "machine operators".
<kiedtl>
lol
<KipIngram>
That is true, but both approaches have merit.
<KipIngram>
Forth definitely has an "informality" to it.
<KipIngram>
I've had it in mind for a while that at some point I want to investigate the use of regular expressions in a Forth system.
<KipIngram>
I have no idea how yet, but it just seems like it might be fruitful.
<neuro_sys>
Hmm that's a good idea.
<KipIngram>
In one of Chuck's old books he discusses the idea of first trying to find a word in the dictionary, and if you can't you peel a prefix or suffix character off of it and try again.
<KipIngram>
Eventually when you do find a match, the prefix/suffix is then applied as a parameter.
<KipIngram>
He had some examples of situations where it looked useful, but I can't remember what any of them are.
<KipIngram>
This was something he wrote in the VERY VERY early days, before Forth really had the final form it took.
<KipIngram>
Anyway, though, both of those things (regular expressions and prefix/suffix processing) are kind of a step away from standard Forth and toward a stronger "syntax."
<KipIngram>
Though one of the things I do love about Forth is its "rabid simplicity."
<kiedtl>
Anyone mind critiquing the syntax/design for the previously-mentioned language I'm working on? Here's a sample: http://0x0.st/-cXq.txt
<remexre>
are : ;; delimiting the "body" of the IF?
<KipIngram>
I'll take a look.
<remexre>
and is there a reason for them to be necessary? as it's usually implemented, IF embeds the branch by being immediate
<kiedtl>
remexre: Yeah, they are. {} is taken up by tables/arrays.
<kiedtl>
Yes, they are necessary. There are no immediate words in this language; parsing isn't done with the traditional FORTH way.
<kiedtl>
i.e. the parser is always in COMPILE mode.
<kiedtl>
s/COMPILE/compile
<KipIngram>
Is that the definition of "word"?
<remexre>
of .n, I think?
<kiedtl>
No, it's the definition of .n
<kiedtl>
Yeah, .n prints out a number.
<KipIngram>
I see.
<KipIngram>
It seems long, for a single definition. Has the look on the page that a c function might.
<KipIngram>
I'm afraid I've swallowed the "factor, factor, factor" pill rather firmly. :-|
<remexre>
yeah, I get that feeling too, but I'm not sure how much of that is 8ch tabs and only using 10 or so chars per line
<KipIngram>
Right.
<kiedtl>
The compiler can *almost* compile that rn. Just the `until` needs to be implemented, I'm using a retro-forth esque until implementation that works with quotations for now
<kiedtl>
8ch tabs and 10chars per line are optional ofc, I just find that using less per line keeps things clear
<kiedtl>
for me, anyway
<kiedtl>
I know a lot of people hate 8ch tabs with a passion, heh
<remexre>
which yeah, is much more aggressively factored
<KipIngram>
I don't have mine in one place right now. Let me go see if I can pull it out - I have the forth interspersed with the assembly as "comments"
<remexre>
(this has prefixes on "private things" because it was written before I'd implemented "namespaces")
<kiedtl>
It's possible that factoring that into several definitions is something I'd do later, but I'm a bit concerned more with stabalising the syntax/lang impl atm than opimisations
<remexre>
well, I'd consider factoring to be a readability optimization :)
f-a has joined #forth
<kiedtl>
I felt like an amalgated version (mine) was more readable than yours, but that's probably because I hate SCREAMING FORTH CODE with a passion :^)
<remexre>
so if you're trying to determine how readable/not it is, I'd try to figure out what very readable programs in your syntax are, and how readable they are / how much pain it is to write them that way
f-a has left #forth [#forth]
<remexre>
ah, yeah, that's yet another thing I did before I finally bit the bullet and implemented namespaces -- I was gonna make everything provided by the forth system CAPS and everything in user code small
<remexre>
and some private things in the system are PREFIX/name...
<remexre>
really I should go back and fix all that...
<kiedtl>
How are you implementing namespacing? I was just going to define an `import' word that loads a file and prefixes all definitions with 'module:'.
<kiedtl>
Ah, you're the nondocumented stahl fellow :P
<kiedtl>
s/non/un
<remexre>
there's a website with.... some documentation now
<kiedtl>
Nice. I'll have to remember to take a look at some point.
<remexre>
but yeah basically, END-MODULE( goes and rewrites the dictionary; first smudging everything since MODULE, then unsmudging everything mentioned before a )
<kiedtl>
Interesting. It's a nonoption for me, though, since I'm eschewing immediate words.
<KipIngram>
That definition of FOLD looks hideously long to me now.
<KipIngram>
Words defined with :: instead of : are "temporary" - after defining NUMBER I would use .wipe to remove those headers.
<KipIngram>
Floating point numbers are left on the FPU stack.
<KipIngram>
And only base 10 is supported for floats.
<KipIngram>
Yeah, immediacy doesn't combine well with a more formal language structure.
<KipIngram>
It's really sort of a hack, but Forth is "hack-tolerant."
<kiedtl>
Are the temporary words inlined where they are called?
<kiedtl>
Forth *is* a hack, if you think about it. It's just a list of functions to call :P
<kiedtl>
A hack to save memory.
<KipIngram>
No, but the space taken by headers is completely recovered.
<KipIngram>
They do have a permanent CFA/PFA pair, though.
<kiedtl>
uh
<kiedtl>
If they're wiped
<kiedtl>
How would they be called when the word calling them was called?
<remexre>
cfa/pfa is all that's needed to call it if you have the address
<KipIngram>
After compilation you don't need the headers anymore - the definition that uses a temp word has its CFA in the definition.
<KipIngram>
My current effort has some programming constructs I didn't have when I wrote this, so I will be endeavoring to do better.'
<kiedtl>
Ahhh. I misread and thought you said that the entire dictionary entry was wiped, not just the heads.
<kiedtl>
*headers
<KipIngram>
No, the CFA/PFA pair and the definitions themselves are permanennt.
<kiedtl>
Yes, I understood now.
<kiedtl>
It'd be intersting to make a Forth that inlined everything.
<kiedtl>
Though it wouldn't work if an entry did magic with the return stack.
<KipIngram>
Implementing that temporary def support was rather involved - I'm taking a simpler approach this time.
<KipIngram>
Temporary words will just have a bit set in their header that makes them unfindable later.
<KipIngram>
Dictionary searches will still have to pass over them - they just won't match.
<KipIngram>
Also these days I use .: instead of ::
<KipIngram>
It's supposed to evoke the hiding of Linux filenames when they begin with .
<kiedtl>
Neat.
<KipIngram>
So, what exactly is the payoff in your case for avoiding immediate words?
<kiedtl>
A cleaner interpreter, imho. No compiling modes (everything's in COMPILE mode), everything's parsed/executed as it would be in another languages' VM, slightly more conventional syntax, etc
<KipIngram>
So you don't really have an interactive interpretive environment?
<KipIngram>
Chuck got rid of his STATE as well - he started controlling the color of each word he typed, and let the color determine that stuff.
<KipIngram>
So you could always compile, anytime, and always execute, anytime, and so on
<KipIngram>
He got rid of BASE by using different colors for decimal and hex numbers.
<KipIngram>
I got rid of base by requiring expicit inclusion of non-decimal base information in the number.
<KipIngram>
And for outputting numbers in various bases, I have a setup that uses a C-like formatting string.
<KipIngram>
A version of TYPE that you pass a formatting string to as well - everytime it encounters and escape character it plucks a number from the stack and outputs it as directed by the format field.
<remexre>
does your system "interpret" format strings or "compile" them?
<KipIngram>
It interprets them - it actually implements a little baby stack machine in a stack cell.
<remexre>
huh, neat
<KipIngram>
There's a little snip of code it runs for each encountered format string.
<KipIngram>
Yeah, it was fun to put together.
<KipIngram>
Did a whole lot of what printf does, and I feel like it must be smaller.
<remexre>
yeah, glibc printf supports the kitchen sink...
<remexre>
including stuff for which the solution is "want different things"
<KipIngram>
I'll use the same approach this time, but I'll probably re-write it.
<KipIngram>
Never hurts to rewrite a piece of code - it almost always turns out better.