Please wait...
Another example is a codebase that is deployed to different targets. Like
server/client, say. I've seen a lot of people lay it out like:
server/foo_server.c
server/bar_server.c
client/foo_client.c
client/bar_client.c
I wrote something at $dayjob once that looked like this:
foo/server.c
foo/client.c
foo/debug.c
bar/server.c
bar/client.c
bar/debug.c
(The debug.cs were modules for the command line debug tool.) My tean acted like this was very confusing and they didn't like it. "Why are there so many server.cs? You gave so many files the same name." It seems like, at least where I work, there are a lot of programmers who don't understand the concept of context.
server/foo_server.c
server/bar_server.c
client/foo_client.c
client/bar_client.c
I wrote something at $dayjob once that looked like this:
foo/server.c
foo/client.c
foo/debug.c
bar/server.c
bar/client.c
bar/debug.c
(The debug.cs were modules for the command line debug tool.) My tean acted like this was very confusing and they didn't like it. "Why are there so many server.cs? You gave so many files the same name." It seems like, at least where I work, there are a lot of programmers who don't understand the concept of context.
At my $job that is the least of our worries. some are dangerously stupid
"i updated the connection string to the new DB" "ya, on a dev copy..."
Sat Jun 29 2024 09:48:13 EDT from zelgomerIt seems like, at least where I work, there are a lot of programmers who don't understand the concept of context.
I struggle with deciding on what order directory hierarchies should
appear in.
That's easy. You stick with the established convention for whatever environment you're working in. :)
Lately I've been quite enamored with the `wildcard` and `patsubst` functions of GNU Make. These wildcard functions have allowed me to greatly simplify my makefiles, allowing arbitrary directory hierarchies and names. It just goes in and compiles what it finds. When building modular software it's kind of wonderful.
That's easy. You stick with the established convention for whatever
environment you're working in. :)
The problem is that most of what I do for fun these days is in the "invent a new environment from scratch" type of domain.
Speaking of, I tend to write a lot of callback-driven C, and when I do, I have a rule: all callbacks should always take an arbitrary void * argument that is passed from the caller so that the caller can hand off user-defined context.
Now I'm trying to come up with a similar convention in FORTH. At first, I went with the same rule, except in FORTH it doesn't have to be a pointer, it can easily be an arbitrary value that's kept on the stack. E.g.,
: each ( n1 n2 x xt -- x') >r >r
swap begin over over > while
dup r> r@ execute >r
1+ repeat drop drop r> rdrop ;
: sum ( n1 n2 -- n3) 0 ' + each ;
1 4 sum . ( prints 6 because 1+2+3)
This is doable, though maybe a little clumsy. But then it occurred to me today that the more "FORTHy" way to do this is that the callback should be able to manipulate the underlying stack to its heart's content. In other words, the callback's context should be the entire stack before the outer word is executed, less the outer word's parameters. So the above example should look more like this:
: each ( i*x n1 n2 xt -- j*x) >r
swap begin over over > while
tuck r@ -rot >r >r execute r> r>
1+ repeat drop drop rdrop ;
: sum ( n1 n2 -- n3) 0 -rot ' + each ;
1 4 sum . ( still prints 6)
I really like this better semantically because it allows for the callback's context to be any number of underlying stack items that it wants. What I don't like is that god-awful implementation. "tuck r@ -rot >r >r execute r> r>" is just terrible, and it would be even worse if "each" had more to keep track of. Also, both methods are tricky if you ever want to put anything else on the return stack.
So now I'm thinking of maybe introducing a new set of primitives to automate some of this. Maybe something like
: each ( i*x n1 n2 xt -- j*x)
2 prepare ( ready a callback, indicate that 2 current stack items are mine)
swap begin over over > while
tuck 1 callback ( invoke the callback with only 1 of the 3 items currently on the stack)
1+ repeat drop drop cleanup ( need a better word here) ;
Don't know that I'm crazy about that, either. Just thoughts, it's still cooking...
By the way, I just saw that post above from the browser interface. My indentation
is completely gone. So to anyone viewing it with the browser: sorry. Use the
text interface to see a marginally nicer representation.
After arguing about it with some of the fine folks in the ##forth channel
on libera, I finally arrived at a good analogy of what it is that I'm trying
to do.
If you're familiar with Tcl, I'm trying to come up with a cheap and clever way to do something like Tcl's uplevel, in FORTH. Right now the best idea I have is to just play with juggling stack pointers around to create something kind of approaching a stack frame, so then "uplevel" will just execute an xt in the next-up frame.
If you're familiar with Tcl, I'm trying to come up with a cheap and clever way to do something like Tcl's uplevel, in FORTH. Right now the best idea I have is to just play with juggling stack pointers around to create something kind of approaching a stack frame, so then "uplevel" will just execute an xt in the next-up frame.
I understand why you wont, but over on FB we have a really great FORTH group i help moderate ( when i have time )
We have had several key people like Leo Brodie, a few i forget the names of right this second ( headache ).. and even Charles Moore himself, in the monthly zoom meetings. ( which are all posted on YT.. 'forth2020' is the channel )
Yeah, that won't happen. I've heard that Chuck made an appearance or two on
Freenode years and years ago. I have a feeling that if he saw what I'm talking
about, he'd tell me it's too complicated and I don't need it.
He'd be right that I don't need it, but I still want it. I don't like how I imagine I would implement it, though, so I wish I didn't, Like I said in the first post, really my goal right now is to settle on a convention that I'm happy with. I'm pretty sure most FORTH users would tell me "the convention is just use variables for your xt's context." The reason why I'm so attached to using the stack, though, is because it lets you seamless pass an xt along with its initial context to a higher order word. It starts to approach something that looks like composition and partial application and other functional programming buzzwords probably.
He'd be right that I don't need it, but I still want it. I don't like how I imagine I would implement it, though, so I wish I didn't, Like I said in the first post, really my goal right now is to settle on a convention that I'm happy with. I'm pretty sure most FORTH users would tell me "the convention is just use variables for your xt's context." The reason why I'm so attached to using the stack, though, is because it lets you seamless pass an xt along with its initial context to a higher order word. It starts to approach something that looks like composition and partial application and other functional programming buzzwords probably.
And again, as I said before: this is why I need to stay on the wagon and away
from FORTH. All of this effort and thought and I'm doing absolutely nothing
productive or of value to anyone.
2024-07-03 22:10 from zelgomer
And again, as I said before: this is why I need to stay on the wagon
and away from FORTH. All of this effort and thought and I'm doing
absolutely nothing productive or of value to anyone.
Welcome to my world.
Actually, my world is better. You spend a year working on something and then it turns out nobody wants it.
Who said it had to be?
Wed Jul 03 2024 22:10:39 EDT from zelgomerabsolutely nothing productive or of value to anyone.
Oh, and you don't have to be on FB to get into the zoom meetings if you are interested in them at all. Just the discussions between them.
( and yes i have suggested we move here, more than once. But i got " people are already here, we cant ask them to move to something they dont know " "we cant suggest we move, it will break up the group" . While i can appreciate the sentiment of being afraid of reducing your visibility, honestly i think a FORTH person would appreciate being here instead, due to the overall retro nature of things here. But that is just me *shrug*
Compromise I suggested was to lock the group down, and just have a pointer here.. Best of both worlds, so to speak. But it was vetoed.
( oh and i also suggested jitsi instead of zoom... :) )
Wed Jul 03 2024 22:08:50 EDT from zelgomerYeah, that won't happen.
Todays notice in group:
Next Forth2020 Zoom meeting is on 13.of July ( as usual always 2nd Saturday of the month ). Preemptive agenda is ONLINE https://www.forth2020.org/zoom.../meeting-47-13-july2024 , if any of you is interested to show your work with Forth, just post a message contact me over messenger or Rob Probin who takes care of the agenda , or Cornelius Keck or any other moderator...
Wed Jul 03 2024 22:08:50 EDT from zelgomerYeah, that won't happen.
And again, as I said before: this is why I need to stay on the wagon
and away from FORTH. All of this effort and thought and I'm doing
absolutely nothing productive or of value to anyone.
You might be the first person I've met who likes to write in FORTH that doesn't also have seriously awful social and mental problems.
You might be the first person I've met who likes to write in FORTH
that doesn't also have seriously awful social and mental problems.
Also, don't misunderstand. I actually don't enjoy writing in FORTH all that much. What I enjoy is that it's simple to DIY. And honestly, I'm starting to hit the "is it really worth it?" phase.
It used to be fun. Back when i still liked computers and stuff. Before they became toasters.
Sun Jul 07 2024 15:21:36 EDT from zelgomerYou might be the first person I've met who likes to write in FORTH
that doesn't also have seriously awful social and mental problems.
Also, don't misunderstand. I actually don't enjoy writing in FORTH all that much. What I enjoy is that it's simple to DIY. And honestly, I'm starting to hit the "is it really worth it?" phase.
The old noodle gears, they be turning.
One neat feature of FORTH is its natural support for multiprecision arithmetic. m* multiplies two integers and returns a double precision product, a high order integer and a low order integer. Similarly, m/mod is multiprecision division and modulus. You give it a double precision numerator, a single precision denominator, and it returns a single precision quotient and remainder.
Now, hypothetically, if you could extend the C language to support something like this, how would it look? I was thinking maybe you represent double precision operands with a new : operator, as in
int hi, lo;
hi:lo = x * y;
x = hi:lo / y;
z = hi:lo % y;
However, the colon is already used for labels and the ternary operator. Also[Do, I'm not sure how initialized declaration would look. Is "int x:y = z * 17000;" legal?
Thoughts?
One neat feature of FORTH is its natural support for multiprecision arithmetic. m* multiplies two integers and returns a double precision product, a high order integer and a low order integer. Similarly, m/mod is multiprecision division and modulus. You give it a double precision numerator, a single precision denominator, and it returns a single precision quotient and remainder.
Now, hypothetically, if you could extend the C language to support something like this, how would it look? I was thinking maybe you represent double precision operands with a new : operator, as in
int hi, lo;
hi:lo = x * y;
x = hi:lo / y;
z = hi:lo % y;
However, the colon is already used for labels and the ternary operator. Also[Do, I'm not sure how initialized declaration would look. Is "int x:y = z * 17000;" legal?
Thoughts?