<alexshpilkin>
well if I wanted to be evil, I'd say a regex matcher
<alexshpilkin>
(a linear-time one)
<alexshpilkin>
but I've never actually done that in any language, so nah
<mark4>
give me a BNF description for regular expression parsing and ill write a reg-x parser
<mark4>
me either lol
<alexshpilkin>
let's say just substring matching with Morris-Pratt
<mark4>
how about an X protocl driver :)
<alexshpilkin>
nonono
<mark4>
also on my never to be reached todo list
<alexshpilkin>
also not exactly what I'm talking about
<alexshpilkin>
even simpler, something like topological sorting
<alexshpilkin>
so you have to input, store and traverse a graph of more or less arbitrary size
<mark4>
i would have to have a need for it
<alexshpilkin>
well, toposort is something like "find a valid load order given a dependency graph", so not exactly exotic
<mark4>
:)
<alexshpilkin>
* I have a legit physics problem right now that has floating-point computation, (fairly simple) graph traversal, dynamic memory allocation and so on and generally sounds like _the worst_ thing to do in Forth (though it's fairly compact in C), but don't know how to describe it quickly
<alexshpilkin>
* so I resort to toy examples from your average algorithms class
<alexshpilkin>
* oh, and the code needs to work uniformly for three different floating-point precisions
<alexshpilkin>
this is another thing I've found difficult to do, by the way
<mark4>
lol
<mark4>
iavoid FP lol
<alexshpilkin>
manipulating arbitrary-sized things on the stack
<alexshpilkin>
like, how do I write my 64-bit assembler so that the same code works on both 32- and 64-bit Forths
<mark4>
actually that would need two assemblers
<mark4>
either interleaved into the same sources or in separate sources
<mark4>
code ..... end-code or code_64 ..... end-code
<mark4>
or something
<alexshpilkin>
(you can say 16 and 32 instead if you dislike the idea of a 64-bit Forth, but I find that less realistic)
<alexshpilkin>
yes, and that sucka
<alexshpilkin>
*sucks
<mark4>
sort of
<mark4>
you could also do the same as nasm
<mark4>
bits32
<mark4>
bits64
<mark4>
and taht selects the assembler
<alexshpilkin>
no, that's not what I'm talking about
<mark4>
vocabulary asm_x86 and vocabulary asm_x86_64
<alexshpilkin>
nasm's bit* selects the target bitness
<alexshpilkin>
what I want is an assembler that targets 64 bits, but runs on 32- and 64-bit hosts equally well
<mark4>
oh nasm has a mechanism for that
<alexshpilkin>
only your addresses need to be two cells on the former, and can fit into one cell on the latter
<mark4>
-m elf_i386
<mark4>
as a parameter
<mark4>
that ensures the code will run on 32 and 64 bit systems
<alexshpilkin>
also not what I'm talking about
<alexshpilkin>
hmm
<mark4>
i had to select it for x4 to be able to run on my 64 bit linux
<alexshpilkin>
OK, forget about assemblers
<alexshpilkin>
another example (same idea)
<mark4>
ya
<alexshpilkin>
let's say I have a variable that needs to be a 32-bit integer for objective reasons
<alexshpilkin>
and I have compatible 16-bit-cell and 32-bit-cell Forths of your choosing
<alexshpilkin>
I want a reasonable way to manipulate such a variable (compute reasonably complicated functions of it, etc) in a way that is portable across those two Forths
<mark4>
well C wont allow you to store a 32 bit integer in a char variable so i see no conflict here
<mark4>
you could make ! smart and aware of the variable size
<alexshpilkin>
well in C I could just say typedef uint32_t foo_t; and the rest of the code would be completely happy
<mark4>
for example you could have a var16 and a var32 and a var64 and make ! peek at the CFA to see which word is referenced and if its dobvar16 and you have a number greater than 65535.. .. .
<mark4>
those are compile time checks
<alexshpilkin>
I can make ! smart, sure, or I can even implement a foo! in a portability shim
<mark4>
forth cant have those so the checks would have to be run time
<mark4>
agreed.
<alexshpilkin>
but I can't make SWAP smart without type-tagging the whole stack
<alexshpilkin>
like, I know I have a boolean and a foo on the stack and I want to swap them
<mark4>
no you NEVER have anything other than cell size on the stack
<mark4>
c creates packed structures called stack frames
<mark4>
forth has THE STACK
<mark4>
so 8 16 and 32 bit values that are fetched are cell with when on the stack
<alexshpilkin>
but I don't _have_ a cell, conceptually speaking
<mark4>
you do for the stack
<mark4>
stack items are ONE SIZE fits all
<alexshpilkin>
I mean in my problem spec
<mark4>
chars take up 32 bits, words take up 32 bits .. . .
<mark4>
well having a set size for items on the stack is not a problem for your scenario
<mark4>
in fact it solves a huge pile of possible problems
<alexshpilkin>
my problem spec doesn't want "a cell", it wants an integer of (at least) 32 bits
<mark4>
such as getting swap and rot and nip and tuck to work at all
<mark4>
it will be a zero extended 64 bit number on a 64 bit forth
<alexshpilkin>
and computing with one in a 16- and a 32-bit Forth is fundamentally different (possible in both cases if you have double arithmetic, yes, but different)
<mark4>
i think you would need to implement something i REFUSE to implement in my forths
<mark4>
coditional compilation lol
<alexshpilkin>
and that's a problem, yes
<alexshpilkin>
because it's not like you refuse to implement that because you hate me
<mark4>
yea my forths have no conditional compilation lol
<alexshpilkin>
you refuse to implement it because it doesn't mesh well with the language
<mark4>
no
<mark4>
it does not mesh well with ANY language
<alexshpilkin>
well LISPs beg to disagree somewhat, but OK :)
<mark4>
lol
<alexshpilkin>
though that is not even the point
<alexshpilkin>
the point is that e.g. C doesn't actually need conditional compilation for this in the best case, it needs a typedef
<mark4>
yup
<alexshpilkin>
(in a worse case, it might need a couple of #defines to select the right library functions)
<alexshpilkin>
and that _does_ mesh reasonably well with the language
<mark4>
which make the selection using conditional compilation ?
<alexshpilkin>
most reasonably yes, though you could avoid that with two driver files that make the definitions for the two different cases and then include a file with the common code
<alexshpilkin>
(not a serious suggestion for C, but I've handled a bilingual TeX document this way)
<mark4>
all above my pay grade :)
<alexshpilkin>
... let me give a real-world case of this: I have a reasonably complicated algorithm that involves floating-point computation, and I want to compare its results as computed in single, double, and quad (yes, really) precision, while not implementing it three times over (obviously)
<mark4>
lol
<alexshpilkin>
I don't really know a way to do that in Forth except for reimplementing the floating-point wordset three times
<mark4>
def above my pay grade :)
<alexshpilkin>
it's literally a typedef and a couple of defines in C
<dave0>
alexshpilkin: maybe keep pointers to the floats on the stack, instead of floats directly on the stack?
<dave0>
so a float is a little struct
<mark4>
therse a good idea maybe :)
<alexshpilkin>
dave0: yeah, that would work to some extent
<alexshpilkin>
with the obvious problems: tanking performance (maybe less important), need for (more) dynamic allocation (this one I definitely don't like)
<alexshpilkin>
but yes
<alexshpilkin>
(see also: various proposals for a string stack, etc.)
<alexshpilkin>
the point is, as soon as you want to manipulate an appreciable number of data types, your proposal essentially ends up treating the stack as containing object references to dynamically allocated objects, and you end up with a badly done Factor instead of a Forth
<alexshpilkin>
(though maybe you actually "want to manipulate an appreciable number of data types" less often that it seems)
boru` has joined #forth
boru has quit [Disconnected by services]
boru` is now known as boru
<tabemann>
hey guuys
<tabemann>
if I wanted Factor, I'd use Factor
<tabemann>
but then, I'd probably just go back to programming in Haskell
dave0 has quit [Quit: dave's not here]
X-Scale` has joined #forth
X-Scale has quit [Ping timeout: 246 seconds]
X-Scale` is now known as X-Scale
spoofer has joined #forth
<proteusguy>
alexshpilkin, you're gonna hate ActorForth then... ;-)
jsoft has joined #forth
Zarutian_HTC has quit [Ping timeout: 246 seconds]
Zarutian_HTC has joined #forth
gravicappa has joined #forth
Zarutian_HTC has quit [Ping timeout: 246 seconds]
Zarutian_HTC has joined #forth
Zarutian_HTC1 has joined #forth
Zarutian_HTC has quit [Ping timeout: 246 seconds]
deesix has quit [Ping timeout: 246 seconds]
dddddd has quit [Ping timeout: 240 seconds]
WickedShell has quit [Remote host closed the connection]
deesix has joined #forth
dddddd has joined #forth
remexre has quit [Ping timeout: 265 seconds]
remexre has joined #forth
gravicappa has quit [Ping timeout: 260 seconds]
tabemann has quit [Ping timeout: 244 seconds]
xek has joined #forth
xek has quit [Ping timeout: 240 seconds]
jsoft has quit [Ping timeout: 240 seconds]
gravicappa has joined #forth
_whitelogger has joined #forth
deesix has quit [Remote host closed the connection]
deesix has joined #forth
dddddd has quit [Ping timeout: 256 seconds]
dddddd has joined #forth
jackdaniel has quit [Remote host closed the connection]
Zarutian_HTC1 has quit [Read error: Connection reset by peer]
Zarutian_HTC has joined #forth
proteus-guy has joined #forth
Zarutian_HTC has quit [Remote host closed the connection]
xek has joined #forth
jsoft has joined #forth
`presiden has joined #forth
<`presiden>
morning forthnighter
proteus-guy has quit [Ping timeout: 256 seconds]
jsoft has quit [Ping timeout: 240 seconds]
xek_ has joined #forth
xek has quit [Ping timeout: 256 seconds]
WickedShell has joined #forth
jsoft has joined #forth
xek has joined #forth
xek_ has quit [Ping timeout: 240 seconds]
jsoft has quit [Ping timeout: 240 seconds]
Zarutian_HTC has joined #forth
Zarutian_HTC has quit [Remote host closed the connection]