00:00:00 --- log: started forth/20.07.29
00:24:53 --- join: xek_ joined #forth
00:28:53 --- join: proteus-guy joined #forth
00:44:41 --- join: shynoob joined #forth
01:05:30 <shynoob> is anyone here on discord?
01:05:45 --- quit: proteus-guy (Ping timeout: 256 seconds)
02:02:15 --- quit: boru (Quit: Patches.)
02:18:10 --- join: boru joined #forth
02:48:18 <proteusguy> shynoob, nope but I'm on gitter.
02:48:59 <shynoob> wew.. is it like matrix stuff?? or riot stuff
02:49:19 <proteusguy> ???
03:06:41 --- quit: shynoob (Ping timeout: 245 seconds)
04:04:06 --- quit: jsoft (Ping timeout: 256 seconds)
04:28:11 --- quit: xek_ (Ping timeout: 246 seconds)
05:15:52 <cmtptr> i'm on discord and it sucks
05:16:17 <cmtptr> i wish the people and communities i interact with there would come back to irc
05:27:33 --- join: xek joined #forth
06:16:41 <elioat> for gitter stuff, gitter maintains a very solid IRC <-> Gitter bridge! https://irc.gitter.im/ it works like a charm
06:28:26 <cmtptr> bridges are annoying, though
06:30:12 <elioat> whilst this is true, they're easier than getting entire communities of folks to shift platforms, in my limited experience ¯\_(ツ)_/¯
06:30:52 --- quit: xek (Ping timeout: 256 seconds)
06:31:46 <cmtptr> seems like the guy is trying to shift irc users to discord.  giving them a bridge only concedes ground
06:34:26 <elioat> legit, legit
06:58:55 --- quit: boru ()
06:59:14 --- join: boru joined #forth
07:07:13 <proteusguy> cmtptr, agree i like irc but it suffers from having no history when you're offline.
07:08:06 <proteusguy> we use gitter for our projects hosted on github because it has a nice integration. So the ActorForth project is over there.
07:09:58 --- join: xek joined #forth
07:20:01 <proteusguy> Anyone have a forth they would like promoted for people to try? Sadly mark4th hasn't been updated in ages and hasn't had any responses to issues so I think it's time we replaced it in the banner and gave some active projects some advertising.
07:20:46 <boru> ISTR seeing the maintainer in ##asm recently asking questions.
07:21:29 <boru> I may have one Soon™ for a new stack machine I am currently designing.
07:21:46 <boru> Bar of entry might be too high in terms of investment, however.
07:24:13 <cmtptr> i see not having server-side history (that's published, anyway) specifically has a benefit to irc
07:27:03 <alexshpilkin> cmtptr : well in the sense that running an IRC server for a given number of users is easier on the resources than a Matrix homeserver, probably
07:27:25 <proteusguy> boru, when you have something then feel free to point us to it.
07:27:45 <boru> It could be a while, but sure.
07:30:02 <proteusguy> cmtptr, how does not having server side history provide a benefit? meanwhile we're tracked and logged by at least two active bots.
07:30:29 <alexshpilkin> cmtptr : but there may be a situation similar to Git developing there—sure storing only delta-compressed source code history and only on the server was a great optimization back in the day, but are we sure that the convenience tradeoff makes as much sense now as it did then?
07:32:03 <cmtptr> proteusguy, because those platforms that provide the history also provide a mechanism to manipulate it
07:32:11 <cmtptr> i'd rather see logging outsourced
07:34:29 <proteusguy> cmtptr, so you want a decentralized irc. :-) interesting idea.
07:34:45 <cmtptr> it's already decentralized
07:35:24 <proteusguy> er... it's distrubuted but not really decentralized.
07:36:02 <cmtptr> you just acknowledged that two separate bots are logging this channel!  i'm assuming they're owned and maintained in complete independence
07:36:39 <cmtptr> and then there are the lurkers who each might have their own clients configured to log
07:45:54 <boru> It still doesn't solve the trust problem. The network should be the authorative log e.g. DHT a la bittorrent, or blockchains.
07:53:28 <cmtptr> i don't care about that, i just don't want power-happy moderators editing and deleting my messages from other users' clients
07:58:37 --- quit: jackdaniel (Ping timeout: 240 seconds)
08:00:10 <alexshpilkin> well, as long as you’re happy to give up any hope of a shared history and let each client maintain their own private log for only when they’re online, sure, IRC (or anything else without history storage in the protocol) works
08:00:13 --- join: jackdaniel joined #forth
08:01:52 <cmtptr> yes, i am happy to give up shared history.  i prefer it that way
08:02:50 * proteusguy has a policy where he doesn't say anything online that he's not willing for everyone to see. :-)
08:03:11 <alexshpilkin> ... if you want there to exist some objective truth as to what the history is, however, you need either a server (with all the attendant moderation problems) or distributed consensus (which is a minefield the size of the Korean DMZ)
08:04:05 <cmtptr> i think you're taking my comments to an extreme that's not what i'm trying to say
08:04:47 <cmtptr> i don't like that on platforms like discord, i might say something while you're away from your keyboard, and then proteusguy deletes it before you return to your keyboard
08:05:10 <cmtptr> i don't like sitting down and finding users have been banned or kicked, and i don't get to see what transpired to lead up to it
08:05:24 <cmtptr> i prefer my history to not be shared
08:05:54 <proteusguy> cmtptr, (I understand what you're saying) but if you're offline when someone is banned/kicked and return then don't you suffer the same effect?
08:06:39 <alexshpilkin> cmtptr: er, no, I’m trying to say that there really are two extremes — either the history is completely subjective (and if you want that, IRC and XMPP are happy to accommodate you) or it tries to be objective
08:06:47 <cmtptr> sure, but i'm never offline, and as you pointed out earlier, we have independent bots logging this channel
08:07:01 <proteusguy> cmtptr, gotcha
08:07:14 <cmtptr> you guys can argue theory all you want.  in practice, this doesn't happen to me in irc.  it does happen to me on discord
08:07:24 * proteusguy doesn't use discord
08:07:31 <cmtptr> don't, it sucks
08:07:36 * alexshpilkin neither
08:08:06 <cmtptr> anyways.  forth!
08:11:02 <proteusguy> forth is swell!
08:43:46 --- quit: Zarutian_HTC (Ping timeout: 240 seconds)
08:57:21 --- join: Zarutian_HTC joined #forth
09:05:23 --- quit: xek (Ping timeout: 264 seconds)
09:47:19 --- join: mark4 joined #forth
10:04:43 --- join: remexre joined #forth
11:36:06 --- quit: Croran (Ping timeout: 240 seconds)
11:44:27 --- join: Zarutian_HTC1 joined #forth
11:44:40 --- quit: Zarutian_HTC (Read error: Connection reset by peer)
11:46:41 --- join: Croran joined #forth
12:13:22 --- join: mtsd joined #forth
12:18:49 --- quit: mtsd (Quit: leaving)
12:34:00 --- quit: cp- (Read error: Connection reset by peer)
12:49:49 --- join: xek joined #forth
13:22:42 --- nick: Zarutian_HTC1 -> Zarutian_HTC
14:04:14 <mark4> may have just discovered a bug in x4 that has probably been there from day 1
14:04:40 <mark4> : foo 1 2 2>r r> . r> . ;  <-- what should this display ?
14:05:55 <mark4> ooh maybe not!
14:06:27 <mark4> yea my code is right lol but had to think about it
14:10:56 --- quit: xek (Ping timeout: 240 seconds)
14:25:19 --- join: WickedShell joined #forth
14:34:01 <cmtptr> is the correct answer 2 1?
14:35:19 <cmtptr> i want to say i remember feeling like 2>r should have the same effect as >r >r, but the conventional effect is more like a swap >r >r.  but maybe i'm remembering wrong
14:36:06 --- quit: spoofer (Ping timeout: 240 seconds)
14:38:04 <alexshpilkin> yes, ANS says 2>R is equivalent to SWAP >R >R
14:38:57 <cmtptr> oh, ok!  then all is right in the world, after all
14:39:10 <cmtptr> and the answer should be 1 2
14:39:37 <cmtptr> wait no
14:39:53 <cmtptr> i confused myself.  if only irc had a way to delete messages
14:39:58 <alexshpilkin> :)
14:40:59 <alexshpilkin> stack comments are wonderful when you have only one stack, but sometimes it’s easier to just run the damn thing
14:42:06 --- quit: gravicappa (Ping timeout: 256 seconds)
15:01:14 --- join: spoofer joined #forth
15:02:13 <alexshpilkin> (does nobody in #forth run a bot for computing stack effects?)
15:08:40 <remexre> I've considered making one, I probably will have one whenever I get around to writing an editor
15:09:02 <cmtptr> said like a real forther
15:17:20 --- join: dave0 joined #forth
15:39:24 --- quit: _whitelogger (Remote host closed the connection)
15:42:25 --- join: _whitelogger joined #forth
15:56:23 <mark4> 2>r should be like >r >r
15:56:33 <mark4> and ans is wrong again
15:57:06 <mark4> the original definition for it is : 2>r >r >r ;
15:57:45 <dave0> i think there's a swap
15:58:07 <mark4> it was my intent to write a bot in x4 and allow certain things to be done 
15:58:20 <alexshpilkin> mark4: well it depends on how you interpret the 2, doesn't it?
15:58:45 <mark4> if it was d>r i would say the swap might be right
15:59:03 <mark4> 2 swap is just treated ad dswap
15:59:11 <mark4> i dont think that translates with 2>r
15:59:17 <dave0> oh that's an interesting name
15:59:23 <alexshpilkin> if it simply means "twice", then sure
15:59:40 <mark4> with a double number what ever is on top of P stack has to be on top of R stack
16:00:00 <mark4> the swap just does not make sense to me because taht requires annother swap on 2r>
16:00:11 <mark4> just dont do the seap
16:00:25 --- quit: Zarutian_HTC (Read error: Connection reset by peer)
16:00:47 --- join: Zarutian_HTC joined #forth
16:00:59 <alexshpilkin> if it means "the two-cell piece", then ANS is probably right, you want the same thing to be on top of the return stack that used to be on top of the data stack
16:01:09 <alexshpilkin> yes, it might be more appropriate to call it D>R
16:01:15 <mark4> ans is never right :P
16:02:19 <mark4> what the swap guarantees is that top of P stack before the op is top of R stack after the op
16:03:33 <alexshpilkin> mark4: I don't think we actually disagree on anything except maybe naming :)
16:05:07 <mark4> heh
16:05:20 <mark4> i HATE postpone and invert
16:05:37 <mark4> i will never add either of those abominations to my forths :P
16:06:20 <mark4> alexshpilkin, what forth do you usually use?
16:07:24 <alexshpilkin> well, I'd say there's a certain point to POSTPONE, though I'm not sure that it's actually the best way to implement this point
16:08:06 <mark4> compile and [compile] did not need fixing
16:08:19 <mark4> and NOT was already fixed by the 83 standard
16:09:15 * alexshpilkin has spent two years on and off thinking about the connection between POSTPONE and metacompilation but still can't get it to work properly
16:09:49 <mark4> the purpose of postpone is to do the job of both compile and [compile]
16:10:10 <mark4> the preceived NON issue is that you need to know which words are immediate
16:10:22 <mark4> and an immediate word in my forth might not be immediate in yours
16:10:41 <mark4> so to facilitate the falacy of portability they invented a new word to do the jobs of both
16:11:23 <mark4> if ans forth was so damned portable why does every ans forth source file need duct tape definitions to account for the varios incantations of ans'ness
16:12:20 <alexshpilkin> I'd call it "the Scheme problem": the standard is so minimal it's difficult to actually do anything with it
16:12:49 <alexshpilkin> (in the Scheme case, it's the whole standard; in the Forth case, it's CORE)
16:14:27 <alexshpilkin> I don't think anybody ever succeeded in solving this. not many language standards strive for minimality in the first place
16:14:56 <mark4> actually java is damned good at acting identially on every system it runs on
16:15:03 <mark4> crappy but identically crappy :)
16:15:28 <alexshpilkin> yeah, but I don't think anybody could call it lightweight with a straight face
16:16:06 <mark4> actually that depends, you can embed java in very iminmal systems
16:16:16 <mark4> you just dont get 2756279298746592659243982346592435 terabytes of .jar files
16:16:35 <mark4> or maybe thats just whats inside every jar file :P
16:18:20 <alexshpilkin> literally the only thing I know about this is from watching a talk from 36C3 that said that the Java on Java Cards is at best a pretty esoteric form of Java and at worst not Java at all
16:18:29 <alexshpilkin> no idea how representative that is
16:18:39 <alexshpilkin> of Java on small systems
16:19:14 <mark4> dalvik was put on some really tiny phone systems origainally
16:19:26 <mark4> and dalvik is java-ish
16:19:32 <alexshpilkin> huh. ok
16:20:18 <mark4> dalvik being the original android vm
16:21:02 <mark4> the vm itself can be really tiny but the jar files tahat get loaded up at run time can have megabytes of byte code inside them
16:21:19 <mark4> and you cant really unzip them lol
16:21:38 <mark4> but im not saying java is good btw, it just does a good job of being portable
16:21:45 <mark4> and CAN be quite small
16:21:58 <mark4> hell they even embed LUA
16:23:23 <mark4> you never said what forths you use?
16:23:33 <alexshpilkin> ...
16:25:23 <alexshpilkin> I'm afraid I can't honestly say I "use" any Forth; that is Forth is not what I turn to for day-to-day tasks
16:25:54 <alexshpilkin> Forth is what I use to try insane ideas :)
16:26:17 <mark4> same same but i have had professional jobs coding forth :)
16:28:40 <alexshpilkin> on PC, I've mostly used Gforth. I tried pForth and... SwiftForth, I think, when I wanted to check compatibility across ANS systems, and was not impressed with the ergonomics
16:29:07 <mark4> exactly :
16:29:09 <mark4> :P
16:29:13 <mark4> what OS do you use?
16:29:55 <alexshpilkin> ... I don't much like Gforth's implementation ideology, but it's surprisingly convenient as an environment
16:30:32 <mark4> any forth that is written in C is not a forth
16:30:57 <mark4> another failed attempt to make forth portable
16:31:24 <alexshpilkin> well no, I'd say there's a valid use case in bootstrapping
16:33:12 <alexshpilkin> especially if the thing you want to bootstrap is nonstandard enough that you can't or don't want to use an existing Forth
16:33:20 <mark4> i was developing an android ndk forth and temporilly used some C glue code but was working on replacing all of that when google ripped the rug right out from under me and invalidated all my work lol
16:33:33 <alexshpilkin> ... and I can empathize with not wanting to implement an x86 assembler *shudder*
16:34:02 <mark4> actually the ONLY reason x86 assemblers are clusterfuck is because morons keep doing the opcode encodings in hex instead of octal
16:34:24 <alexshpilkin> 8086, yes
16:34:34 <alexshpilkin> x86-64, no
16:34:50 <mark4> yes even 64 bit encoding is expressed way better in octal
16:35:05 <alexshpilkin> I've done a 8086 assembler and yeah, it's mostly ok
16:35:24 <mark4> i wrote an 8051 assembler and an avr assembler
16:35:58 <mark4> was working on organizing tables for aarch64 and x86_64 but never completed that stage on either
16:36:18 <mark4> aarch64 assembler IS cluster fuck encoded lol
16:36:20 <alexshpilkin> but for x86-64 I've gotten one to the stage when encode every possibility of MOV for general-purpose registers and just gave up
16:36:33 <alexshpilkin> *when it could encode
16:36:35 <mark4> x86 encoding is pretty much uniform across their entire history
16:38:27 <alexshpilkin> as long as you limit yourself to scalar instructions, maaaybe
16:40:15 <alexshpilkin> though the 32/64-bit encoding of indirect addressing and its interactions with REX prefixes hurts my brain
16:40:25 <mark4> heh
16:40:31 <mark4> it hurts everyones brain
16:41:19 <alexshpilkin> anyhow, I'll probably try my hand at x86 sometime in the future, but at the moment being able to prototype what I want with VM in a couple hundred lines of C is damned convenient
16:41:38 <mark4> what OS do yo use?
16:41:51 <mark4> all my fun is in linux 
16:42:38 <alexshpilkin> I've been on Arch Linux for the last several years
16:42:50 <mark4> my x4 should run there no problem
16:43:00 <mark4> depending on where it puts the terminfo stuff
16:43:15 <alexshpilkin> ...
16:43:32 <alexshpilkin> still have things to say in the queue
16:43:35 <mark4> if it does the debian idiocy of putting it all under /lib you have to either copy it to its correct location in /usr/share OR you have to modify my sources
16:44:12 <alexshpilkin> (yes, it does)
16:44:19 <mark4> ugh lol
16:44:33 <mark4> FHS says /usr/share/terminfo not /lib/terminfo
16:44:58 <mark4> but i guess putting things in /usr is problematical when /usr is on a separate drive
16:44:58 <alexshpilkin> ah that. no, I've no idea
16:45:13 <mark4> but that is not even supporeted in linux now without an initramfs
16:46:48 <alexshpilkin> (it's also a bit difficult to say where the screwup began, given that originally /usr was for _user home directories_, and I have an old UNIX book to prove it)
16:47:30 <mark4> the screw up happened when 256398456842 people all disagreed where things should go
16:47:37 <mark4> and they still have not sorted it out
16:47:48 <mark4> but /lib for terminfo is just straight up WRONG lol
16:48:15 <alexshpilkin> ok, where was I
16:48:19 <alexshpilkin> right, Forths
16:48:21 <mark4> and i have been too pig headed to modify my terminfo parsing code to search in /etc/terminfo and /lib/terminfo and in ~/terminfo
16:49:26 --- quit: spoofer (Quit: leaving)
16:50:29 <alexshpilkin> another legit usecase for a Forth in C would be for a memory-checking Forth, i.e. one where a user program cannot actually corrupt the VM. writing this kind of thing in bare assembly is legitimately painful, and though it's probably not impossible to do with a good Forth DSL, I've never seen it done
16:51:10 <alexshpilkin> *not impossible to do well
16:51:41 <mark4> well its the sort of thing i would write in forth :)
16:51:53 <mark4> like my terminfo parser and text user interface and my memory manager
16:52:12 <mark4> i have just not been activly developing any of my projects for a long time
16:52:20 <alexshpilkin> well yeah, it sounds like it should be possible, doesn't it?
16:52:35 <mark4> if it can be done in C it can be done in visual basic :P
16:52:38 <mark4> or java
16:52:42 <alexshpilkin> but I wouldn't know where to start, honestly
16:52:46 <mark4> or BF :)
16:52:55 <mark4> no - thats the initial problem with problem solving
16:53:03 <alexshpilkin> *Turing tarpit alert*
16:53:04 <mark4> define the problem entirely so you can define the solution
16:53:24 <mark4> turing complete is more math bs anyway :P
16:54:35 <alexshpilkin> (you're laughing now, but the first thing I've done any programming worth mentioning in was VB for DOS)
16:55:01 <mark4> nah i dont hate on anything and everyone gets to make mistakes anyway :)
16:56:57 <alexshpilkin> * the "Turing tarpit" is exactly the opposite of what you appear to be thinking about. it's the observation that although most PLs are equally strong theoretically speaking, in practice, ergonomics matter
16:57:29 <mark4> i have never seen any language that is as mentally erganomic as a well defined forth
16:57:33 <mark4> i.e. not ans forth
16:58:04 <alexshpilkin> depends on what you use it for probably
16:58:26 <mark4> actually i have "used" forth for very little
16:58:35 <mark4> my development is not using it but developing it lol
16:58:46 <alexshpilkin> I've found it very, very difficult to do any actual data structures in Forth, for example
16:59:15 <mark4> data structures are not that difficult in forth
16:59:24 <alexshpilkin> in some kind of reasonably CS-theory-heavy task
16:59:36 <mark4> x4 and t4 both implement them
16:59:53 <mark4> like say a memory manager?
17:00:15 <alexshpilkin> (I don't mean C "struct"s, I mean working with data structures, conceptually)
17:00:19 <alexshpilkin> no
17:00:22 <mark4> oooh
17:00:42 <alexshpilkin> well if I wanted to be evil, I'd say a regex matcher
17:00:55 <alexshpilkin> (a linear-time one)
17:01:14 <alexshpilkin> but I've never actually done that in any language, so nah
17:01:15 <mark4> give me a BNF description for regular expression parsing and ill write a reg-x parser
17:01:22 <mark4> me either lol
17:02:13 <alexshpilkin> let's say just substring matching with Morris-Pratt
17:02:33 <mark4> how about an X protocl driver :)
17:02:44 <alexshpilkin> nonono
17:02:46 <mark4> also on my never to be reached todo list
17:02:58 <alexshpilkin> also not exactly what I'm talking about
17:03:34 <alexshpilkin> even simpler, something like topological sorting
17:04:47 <alexshpilkin> so you have to input, store and traverse a graph of more or less arbitrary size
17:04:49 <mark4> i would have to have a need for it
17:05:51 <alexshpilkin> well, toposort is something like "find a valid load order given a dependency graph", so not exactly exotic
17:07:18 <mark4> :)
17:09:02 <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
17:09:42 <alexshpilkin> * so I resort to toy examples from your average algorithms class
17:10:58 <alexshpilkin> * oh, and the code needs to work uniformly for three different floating-point precisions
17:11:28 <alexshpilkin> this is another thing I've found difficult to do, by the way
17:11:42 <mark4> lol
17:11:49 <mark4> iavoid FP lol
17:12:24 <alexshpilkin> manipulating arbitrary-sized things on the stack
17:13:23 <alexshpilkin> like, how do I write my 64-bit assembler so that the same code works on both 32- and 64-bit Forths
17:13:49 <mark4> actually that would need two assemblers
17:13:57 <mark4> either interleaved into the same sources or in separate sources
17:14:11 <mark4> code ..... end-code or code_64 ..... end-code
17:14:13 <mark4> or something
17:14:18 <alexshpilkin> (you can say 16 and 32 instead if you dislike the idea of a 64-bit Forth, but I find that less realistic)
17:14:36 <alexshpilkin> yes, and that sucka
17:14:39 <alexshpilkin> *sucks
17:14:53 <mark4> sort of
17:14:59 <mark4> you could also do the same as nasm
17:15:01 <mark4> bits32
17:15:03 <mark4> bits64
17:15:09 <mark4> and taht selects the assembler 
17:15:38 <alexshpilkin> no, that's not what I'm talking about
17:15:40 <mark4> vocabulary asm_x86 and vocabulary asm_x86_64
17:16:05 <alexshpilkin> nasm's bit* selects the target bitness
17:16:45 <alexshpilkin> what I want is an assembler that targets 64 bits, but runs on 32- and 64-bit hosts equally well
17:17:19 <mark4> oh nasm has a mechanism for that
17:17:25 <alexshpilkin> only your addresses need to be two cells on the former, and can fit into one cell on the latter
17:17:49 <mark4> -m elf_i386
17:17:53 <mark4> as a parameter
17:18:19 <mark4> that ensures the code will run on 32 and 64 bit systems
17:18:20 <alexshpilkin> also not what I'm talking about
17:18:25 <alexshpilkin> hmm
17:18:48 <mark4> i had to select it for x4 to be able to run on my 64 bit linux
17:18:54 <alexshpilkin> OK, forget about assemblers
17:19:02 <alexshpilkin> another example (same idea)
17:19:07 <mark4> ya
17:20:24 <alexshpilkin> let's say I have a variable that needs to be a 32-bit integer for objective reasons
17:21:10 <alexshpilkin> and I have compatible 16-bit-cell and 32-bit-cell Forths of your choosing
17:22:35 <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
17:23:06 <mark4> well C wont allow you to store a 32 bit integer in a char variable so i see no conflict here
17:23:24 <mark4> you could make ! smart and aware of the variable size
17:24:04 <alexshpilkin> well in C I could just say typedef uint32_t foo_t; and the rest of the code would be completely happy
17:24:15 <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.. .. .
17:24:42 <mark4> those are compile time checks 
17:24:51 <alexshpilkin> I can make ! smart, sure, or I can even implement a foo! in a portability shim
17:24:56 <mark4> forth cant have those so the checks would have to be run time
17:25:20 <mark4> agreed.
17:25:33 <alexshpilkin> but I can't make SWAP smart without type-tagging the whole stack
17:25:57 <mark4> : foo: create 0 size, does> size@ ; or something
17:26:01 <alexshpilkin> like, I know I have a boolean and a foo on the stack and I want to swap them
17:26:12 <mark4> no you NEVER have anything other than  cell size on the stack
17:26:27 <mark4> c creates packed structures called stack frames
17:26:31 <mark4> forth has THE STACK
17:26:49 <mark4> so 8 16 and 32 bit values that are fetched are cell with when on the stack
17:26:53 <alexshpilkin> but I don't _have_ a cell, conceptually speaking
17:27:04 <mark4> you do for the stack
17:27:13 <mark4> stack items are ONE SIZE fits all
17:27:22 <alexshpilkin> I mean in my problem spec
17:27:27 <mark4> chars take up 32 bits, words take up 32 bits .. . .
17:27:48 <mark4> well having a set size for items on the stack is not a problem for your scenario
17:28:07 <mark4> in fact it solves a huge pile of possible problems
17:28:19 <alexshpilkin> my problem spec doesn't want "a cell", it wants an integer of (at least) 32 bits
17:28:21 <mark4> such as getting swap and rot and nip and tuck to work at all
17:28:47 <mark4> it will be a zero extended 64 bit number on a 64 bit forth
17:29:34 <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)
17:32:34 <mark4> i think you would need to implement something i REFUSE to implement in my forths
17:32:38 <mark4> coditional compilation lol
17:33:04 <alexshpilkin> and that's a problem, yes
17:33:28 <alexshpilkin> because it's not like you refuse to implement that because you hate me
17:33:39 <mark4> yea my forths have no conditional compilation lol
17:33:48 <alexshpilkin> you refuse to implement it because it doesn't mesh well with the language
17:33:49 <mark4> no
17:34:01 <mark4> it does not mesh well with ANY language
17:34:31 <alexshpilkin> well LISPs beg to disagree somewhat, but OK :)
17:34:45 <mark4> lol
17:34:52 <alexshpilkin> though that is not even the point
17:35:50 <alexshpilkin> the point is that e.g. C doesn't actually need conditional compilation for this in the best case, it needs a typedef
17:36:01 <mark4> yup
17:36:26 <alexshpilkin> (in a worse case, it might need a couple of #defines to select the right library functions)
17:36:40 <alexshpilkin> and that _does_ mesh reasonably well with the language
17:36:53 <mark4> which make the selection using conditional compilation ?
17:38:44 <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
17:39:26 <alexshpilkin> (not a serious suggestion for C, but I've handled a bilingual TeX document this way)
17:41:08 <mark4> all above my pay grade :)
17:41:52 <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)
17:42:57 <mark4> lol
17:43:03 <alexshpilkin> I don't really know a way to do that in Forth except for reimplementing the floating-point wordset three times
17:43:03 <mark4> def above my pay grade :)
17:44:31 <alexshpilkin> it's literally a typedef and a couple of defines in C
17:44:36 <dave0> alexshpilkin: maybe keep pointers to the floats on the stack, instead of floats directly on the stack?
17:45:00 <dave0> so a float is a little struct
17:45:07 <mark4> therse a good idea maybe :)
17:45:17 <alexshpilkin> dave0: yeah, that would work to some extent
17:46:51 <alexshpilkin> with the obvious problems: tanking performance (maybe less important), need for (more) dynamic allocation (this one I definitely don't like)
17:47:19 <alexshpilkin> but yes
17:49:08 <alexshpilkin> (see also: various proposals for a string stack, etc.)
17:54:23 <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
17:55:17 <alexshpilkin> (though maybe you actually "want to manipulate an appreciable number of data types" less often that it seems)
18:05:53 --- join: boru` joined #forth
18:05:56 --- quit: boru (Disconnected by services)
18:05:58 --- nick: boru` -> boru
18:32:23 <tabemann> hey guuys
18:33:52 <tabemann> if I wanted Factor, I'd use Factor
18:34:03 <tabemann> but then, I'd probably just go back to programming in Haskell
18:53:28 --- quit: dave0 (Quit: dave's not here)
19:02:07 --- join: X-Scale` joined #forth
19:02:50 --- quit: X-Scale (Ping timeout: 246 seconds)
19:02:50 --- nick: X-Scale` -> X-Scale
20:56:41 --- join: spoofer joined #forth
21:09:40 <proteusguy> alexshpilkin, you're gonna hate ActorForth then... ;-)
21:32:38 --- join: jsoft joined #forth
21:50:29 --- quit: Zarutian_HTC (Ping timeout: 246 seconds)
22:04:41 --- join: Zarutian_HTC joined #forth
22:11:31 --- join: gravicappa joined #forth
22:15:20 --- quit: Zarutian_HTC (Ping timeout: 246 seconds)
22:15:56 --- join: Zarutian_HTC joined #forth
22:45:28 --- join: Zarutian_HTC1 joined #forth
22:45:47 --- quit: Zarutian_HTC (Ping timeout: 246 seconds)
23:19:02 --- quit: deesix (Ping timeout: 246 seconds)
23:19:26 --- quit: dddddd (Ping timeout: 240 seconds)
23:21:39 --- quit: WickedShell (Remote host closed the connection)
23:28:21 --- join: deesix joined #forth
23:28:31 --- join: dddddd joined #forth
23:36:21 --- quit: remexre (Ping timeout: 265 seconds)
23:36:50 --- join: remexre joined #forth
23:54:59 --- quit: gravicappa (Ping timeout: 260 seconds)
23:59:59 --- log: ended forth/20.07.29