2026-07-28 06:58:38 re optimizing, I think mecrisp comes in at 20K so lots of functionality compared to size 2026-07-28 06:59:35 I've thought a lot about optimizing too. I think building in a few assumptions and telling the user (ie probably just myself) what they are is a reasonable compromise 2026-07-28 07:00:24 if the stack effect can be calculated at run time and assigned to registers good but if not and it spills, then that's on the user not to do that if they want optimization 2026-07-28 07:02:26 it seems you can get a pretty decent speed up without doing full optimization. even leaving off graph analysis is probably still worth it 2026-07-28 07:20:12 Is there a name for the pattern where you place some words in unclaimed memory addresses far above the usual dictionary, use them for a little while, then when you're done, snip them out of the dictionary linked list to reclaim their space? 2026-07-28 07:20:33 I think I ran into this in Forth Dimension at one point, but I forgot if the technique has a name. I know some Forths load their assembler this way so a program using the assembler doesn't need to permanently *incorporate* the assembler. 2026-07-28 07:24:45 Clarification: Of course removing them from the linked list doesn't "reclaim their space", but it does stop them from appearing in future dictionary searches, which is a good idea because eventually dictionary growth might overtake the space where those words once lived. 2026-07-28 07:57:40 Pygmy Forth supports "headerless words," which seem like what you describe: the dictionary entries are created at higher memory addresses than normal, and get "unlinked" from the "main" dictionaries before the memory image is saved. The definitions themselves live in the "main" memory space, though, so are never reclaimed. The technique is used for "internal" words. 2026-07-28 08:16:04 MrMobius: 20K is very good for what mecrisp can do 2026-07-28 08:17:45 Yes you can definitely get a big speedup, and close the gap to mainstream C compilers a small amount 2026-07-28 08:22:56 But then even that much code I'm thinking why are we still doing stack operations and reverse polish notation, and making the codebase harder to understand, it quickly moves away from the sweet spot where I get why Forth made sense 2026-07-28 08:58:30 running on small devices would be my answer 2026-07-28 08:59:12 my calculator has 8mb ram so not running a C compiler but it would be nice to get decent speed with forth 2026-07-28 08:59:40 all of these arguments end being very different for embedded vs running forth in a desktop or something which is where a lot of people are 2026-07-28 09:00:10 I probably wouldn't bother optimizing that. hard to think of what it would matter for 2026-07-28 09:29:51 iv4nshm4k0v: that's pretty interesting, I've used Pygmy's headerless words but didn't know they worked like that, thanks! 2026-07-28 11:18:25 you can totally run a C compiler in 8MB. the original C compiler ran in a 64KiB address space, or rather two or three of them 2026-07-28 11:19:25 lofty: have you used e-graphs? are thhey good? 2026-07-28 11:22:33 Shark8: C became popular because it was good. the management caste was pushing COBOL, Ada, 360 assembler, FORTRAN, PL/I, dBase II, etc. 2026-07-28 11:23:49 I think Rust's borrow checker can verify properties SPARK can't. I'm not sure if the converse is true 2026-07-28 11:24:20 I've found Rust's syntax to be tolerable for what iit is 2026-07-28 11:26:13 veltas: I think there are people who don't think RPN makes Forth code harder to understand. I do 2026-07-28 11:45:39 Fortran also used to be quite popular, among physicists at the least. Not sure which Fortran version got support for array slices (I'm pretty certain Fortran 77 didn't have them), but they're reportedly pretty handy for typical scientific computing problems. 2026-07-28 12:23:15 xentrac: I'm sure you could find something antiquated to run in just 8mb but at that point an optimizing forth starts to be attractive 2026-07-28 12:24:09 although none of the really old alternatives would output SuperH 2026-07-28 14:02:07 hypercard renew is going on https://ibb.co/F4qqJVBM 2026-07-28 14:10:32 "The first C compiler, written by Dennis Ritchie around 1972 for the DEC PDP-11, needed about 16 kilobytes (16KB) of RAM to run." from Gemini 2026-07-28 15:39:40 xentrac: I think it depends, like some stuff is actually easier. But for arithmetic I'd say not. 2026-07-28 15:40:21 `5 MS` is fun but when you're writing linear regression and it's essentially just maths from a parallel universe you wonder how hard it would be to add infix parsing 2026-07-28 15:41:27 X-Scale: That compiler had multiple stages, all of which used up most of that 16KB, and supported barely any of the C we know today 2026-07-28 16:23:52 xentrac, (re: C's rise to popularity) -- No, C /didn't/ reach prominence because it was good; it reached prominence because (a) Bell Labs gave Unix to the universities, who used it to teach; and (b) because those graduates pushed it into industry; while (c) C tends to have a bit of an "inducted into a secret language" mentality [or did], to the point that there's programmers that think that if the syntax /isn't/ C-like then it's 2026-07-28 16:23:52 wrong. -- Good examples against the notion of C being good are BLISS and Forth, even Pascal (which is largely the same a C, at the VERY coarse-grained resolution) is better than C simply because of how many easily detectable errors C lets through. 2026-07-28 16:27:45 xentrac, (re: Rust vs SPARK) -- I think SPARK's capabilities have been enhanced so there's no meaningful safety-features Rust has that SPARK doesn't (say 85% sure). Even the hyped up 'borrow checking' has been done in SPARK. 2026-07-28 16:30:41 "Why Pascal is Not My Favorite Programming Language" Brian W. Kernighan, April 2, 1981 2026-07-28 16:30:42 https://www.cs.virginia.edu/~evans/cs655/readings/bwk-on-pascal.html 2026-07-28 16:33:43 Doesn't this paper also explain why Pascal would've been unsuitable for writing Unix? Though I have to admit that I'm one of the C syntax fans myself, and not being "sufficiently C-like" is one of the reasons I've never adopted Lua and Go. 2026-07-28 17:04:11 X-Scale, That paper is /really/ old, and I'm not sure it should be taken seriously, even if it is from Kernighan, given how the next several decades show how much of a foot-gun C is. (It's been a few years since I read it.) 2026-07-28 17:06:44 iv4nshm4k0v, Maybe, but just because it's unsuitable for Unix doesn't mean it's /bad/, or even unsuitable for OS/systems programming. Multics, prior to Unix, was a tank. The Burroughs didn't have an assembler, using Algol directly. And VMS had the Common Language Environment, allowing you to use any language you wanted. 2026-07-28 17:09:59 There are a ton of people who hate on C these days, who I think underestimate how good C was in the 80's, and how good it is today. Shark8 you seem to know a bit about it but I disagree personally that it's just been forced down everyone's throats. 2026-07-28 17:15:32 veltas, Thank you. It has been forced down people's throats, I saw it in the 90s, when I was growing up and getting into computers. -- My distaste for C comes partly from my stance on programming and language design; even if it was 'good', there were a lot of languages that were better *in every area* that C was called good. The thing that I came to despise about C though, was the stance on errors, "just assume the programmer's right 2026-07-28 17:15:33 and DO SOMETHING", which has led to the massive software CVE-pile we have today. 2026-07-28 17:16:04 Kernighan may be the programmer I respect the most 2026-07-28 17:17:25 To be fair Shark8 I don't think people could have predicted the way that security would evolve in computing. I think experts in early networking got it immediately, but the rest of the ecosystem dragged its heels as long as possible 2026-07-28 17:18:13 If you go back to ANSI C you'll see they had a pretty reasonable take on undefined behaviour that's been warped into something it's not by pedants, language lawyers, and single-minded compiler optimisers 2026-07-28 17:18:14 These programmers of today need nanny languages to take care of their many shortfalls and misunderstandings. C really is not a good language for them. 2026-07-28 17:18:45 It was always permitted to make UB 'safer' and stuff like ubsan and Fil-C are good examples of this 2026-07-28 17:21:00 veltas, You will have to excuse me a bit: I view the 'security' and 'incorrect' as inextricably linked; things like buffer-overflow was solved at least by 1983 -- Ada's ability to initialize a constant/rename a function return unknown-sized value (ie perfectly sizing the buffer) proves it. 2026-07-28 17:23:08 veltas, undefined behavior, in the earliest days, was essentially saying "the implementer is free to do as he whishes with this ambiguous state, as befits the architecture", which is somewhere between "implementation defined" and Ada's notion of "bounded error". 2026-07-28 17:23:10 Sorry initialize a constant -- buffer-overflow -- what? 2026-07-28 17:23:53 It feels like you're flipping between a lot of things here Shark8 without really explaining what you mean, or at least I'm too stupid to understand 2026-07-28 17:23:54 I'm frankly not aware of even a single "common" programming language that explicitly allows for the correctness of the code to be formally proved. As to CVEs, the majority of those that affect me personally seem to come from Chromium, which, unless I be mistaken, is /not/ written in C. 2026-07-28 17:24:31 A lot come from Linux but a lot of those CVEs come from x86 as well as C 2026-07-28 17:24:42 Or the specific CPUs anyway 2026-07-28 17:24:59 veltas, In Ada, you could always "User_Input : String := Text_IO.Get_Text;" Which would size User_Input perfectly to the value. 2026-07-28 17:25:22 What has that got to do with initializing a constant? 2026-07-28 17:26:12 I misspoke; constant should have been variable. 2026-07-28 17:29:31 (Using RENAMES on a function-return is treated as constant in Ada.) / It matters because the perfect-sizing means that you aren't overflowing, as any value that is 'too large' fails to be initialized, instead raising Storage_Error. 2026-07-28 17:30:09 'raising Storage_Error' is that an exception? 2026-07-28 17:30:31 veltas, Yes. 2026-07-28 17:30:57 That's funnily enough not very safe, exceptions aren't a good design for all security 2026-07-28 17:31:11 In lots of contexts that would produce denial of service CVEs 2026-07-28 17:31:18 But in an aeroplane you might prefer it 2026-07-28 17:31:56 You need the right tool for the job, and I don't think Ada is always better than C for a job, personally. 2026-07-28 17:32:54 For one thing I can name a lot more people who know C than Ada, and that's not entirely because of hype. I also can name more C programmers than Rust or C++ programmers, even though the latter have much more hype. C is just really easy to learn compared to those langs. 2026-07-28 17:34:01 veltas, I mean, it depends on where you're handling the exception... One time I abused exception-handling in an equals operator, taking the values of pointers, on trying to dereference NULL I returned FALSE instead. (Horrible design, yes.) 2026-07-28 17:35:58 veltas, Not every job, but a surprising amount; certainly in any long-lived, medium or larger system. / For the smaller C projects, I think Forth or sometimes even LISP would be better. 2026-07-28 17:35:59 In those contexts where reliability is most important you want a strongly typed language that does stuff like optional-wrapped types or optional error types 2026-07-28 17:36:04 To make you explicitly handle the errors 2026-07-28 17:36:55 Which Rust supports but doesn't enforce, it uses panics which are kind of really bad exceptions, but at least you can write panic-free code and detect panics automatically to remove them all 2026-07-28 17:37:30 FWIW, I've "learned" C around 1996, and I can't say I've felt much, if any, pressure of any kind to do so. Given that a few years later I've become interested in free software in general and GNU/Linux in particular, I'd say it worked well enough for me. 2026-07-28 17:37:34 I'm assuming there's tools to do this for Ada too 2026-07-28 17:38:28 Shark8: Have you used SPARK? 2026-07-28 17:40:19 veltas, Yes. A little. I have a SPARK proved Base-64 encoder/decoder, and I'm working on (a) an implementation of Forth in SPARK, and (b) a 'utility' library most of which is SPARK. 2026-07-28 17:40:48 SPARK is more interesting to me than Ada, I will say 2026-07-28 17:41:04 It's closer to something I'd actually use for reliability/safety 2026-07-28 17:42:55 The worst thing about Ada is really its verbose english-like syntax, and I apologise if that touches a nerve as I suspect it will, but C-style syntax is the way to go 2026-07-28 17:43:06 veltas, ? -- I'm not sure I understand; SPARK is a subset of Ada [with provers], it uses the Aspect system of Ada 2012 to allow you to specify the properties (preconditions, postconditions, Invarients, etc) in syntactically valid Ada, thereby preventing the "comment-annotation" problem of the comment-annotation and code getting out-of-sync. 2026-07-28 17:43:46 It's a bit like saying I prefer C over C++, despite C being mostly a subset of C++ 2026-07-28 17:44:15 In SPARK's case its differences make it a better language than Ada for its stated goals 2026-07-28 17:47:38 ...the subset of SPARK covers is probably 80% of the language at this point. So, I'm curious as to your distinction there. -- What make you think SPARK is better than Ada at its stated goals? (And do you mean Ada's stated goals vs SPARK's stated goals; or SPARK's at addressing Ada's goals?) 2026-07-28 17:51:39 > SPARK is a formally defined computer programming language based on the Ada programming language, intended for developing high-integrity software used in systems where predictable and highly reliable operation is essential. 2026-07-28 17:52:10 Etc etc https://en.wikipedia.org/wiki/SPARK_(programming_language) 2026-07-28 17:55:02 I was reading about some examples: https://en.wikipedia.org/wiki/SPARK_(programming_language)#Contract_examples 2026-07-28 17:57:37 I mean SPARK is good at addressing its own goals, but I would say Ada was developed with the same goals in mind. SPARK is addressing pitfalls in Ada. 2026-07-28 17:57:56 Certainly the goals of most Ada programmers anyway because they always go on about the safety, and SPARK is safer 2026-07-28 18:00:58 The reason why Rust does panics instead of exceptions is just dreadful, it's because Rust was originally highly influenced by Erlang. They admit this in the Rustonomicon. https://doc.rust-lang.org/nomicon/unwinding.html 2026-07-28 18:01:52 veltas, While safety is certainly one of Ada's strengths, the design-goals for the language are: readability/maintainability, "programming as a human activity", correctness, and implementability. 2026-07-28 18:02:19 Okay well in that case I'm wrong about it being a goal of Ada 2026-07-28 18:02:29 But it's still a goal of Ada proponents 2026-07-28 18:02:46 veltas, Erlang? I thought Rust was [more] influenced by the MLs (SML, O'Caml). 2026-07-28 18:03:37 ACTION learned something new. 2026-07-28 18:03:49 https://en.wikipedia.org/wiki/Rust_(programming_language)#2006%E2%80%932009:_Early_years 2026-07-28 18:04:56 Although looking at history of Ada it looks like I'm right, they were considering safety as a goal from start? 2026-07-28 18:09:41 veltas, Yes; though I think they classified it under correctness... 2026-07-28 18:11:21 http://archive.adaic.com/standards/83lrm/html/lrm-01-03.html -- "Ada was designed with three overriding concerns: program reliability and maintenance, programming as a human activity, and efficiency." 2026-07-28 19:22:38 ACTION is working on some server configuration updates; forth.chat might be inaccessible for a short time as the changes propagate 2026-07-28 20:18:10 iv4nshm4k0v: yes, Fortran is still sort of popular for numerical computation 2026-07-28 20:18:43 MrMobius: I am guessing that there are versions of GCC that would output SuperH and run in 8MB 2026-07-28 20:20:30 Shark8: universities could teach any language they wanted; Bell Labs wasn't bribing them 2026-07-28 20:23:01 iv4nshm4k0v: it sort of explains why Standard Pascal would've been unsuitable for writing Unix, but it was in large part an experience report from rewriting a large subset of the Unix utilities in Standard Pascal. Most of its criticisms don't apply to particuular implementations of Pascal, just Standard Pascal 2026-07-28 20:25:25 Shark8: Multics was a tank in the sense that you couldn't drive it on normal roads and that it was unusably inefficient, yes 2026-07-28 20:27:16 in the 90s C *was* forced down people's throats, but not by the managerial caste; rather, by the previous generation of programmers who had intentionally switched from VMS and Algol and Pascal and assembly to Unix, Windows, and C 2026-07-28 20:27:49 there were not any languages that were better in every area than C 2026-07-28 20:29:10 buffer overflows were "solved" in the 60s but people chose to use compilers without bounds checking and turn it off when it was available 2026-07-28 20:29:58 iv4nshm4k0v: Chromium is written in C++, which inherits most of C's weaknesses 2026-07-28 20:30:48 veltas: famously an uncaughht Ada exception destroyed Ariane 5 on its first launch 2026-07-28 20:52:17 I didn't even know that 2026-07-28 20:55:59 A panic was one or more of the bugs in that recent list of CVEs in the Rust coreutils 2026-07-28 20:56:29 Which I did actually read a summary of because I find Rust interesting but want to know where the sharp corners are 2026-07-28 20:57:03 And I guess a panic is tantamount to an uncaught exception 2026-07-28 20:58:17 ACTION has finished the server updates on forth.chat 2026-07-28 23:33:00 I think exceptions are a good addition to Forth 2026-07-28 23:33:38 I hate the syntax though, it's rubbish 2026-07-28 23:34:14 And also... weirdly similar to Lua's syntax for exception handling! 2026-07-28 23:35:02 What is it about exceptions that makes people want to avoid adding actual syntax, and prefer some kind of weird indirect call method instead 2026-07-28 23:47:30 In my current design I'm looking at something like this: try ... catch ... end 2026-07-28 23:47:55 xentrac, veltas (re: Ariane 5) -- That actually was managerial interference. Ada caught "garbage data" and threw the exception; the garbage data came from correct assumptions for the Ariane 4 not being valid for the 5. (IIUC, it would be the equivalent of taking a RX7's Wankel, putting it in a VW bug, and then being alarmed at the RPM difference.) 2026-07-28 23:48:25 The root of all software evil 2026-07-28 23:49:01 veltas, (re: root of all SW evil) -- Assumptions? 2026-07-28 23:49:09 Managerial interference 2026-07-28 23:49:19 So the bit between 'catch' and 'end' is skipped normally and run immediately on exceptions 2026-07-28 23:49:36 The standard CATCH is just dreadful 2026-07-28 23:51:19 And my exceptions aren't typed or safe, and neither are my words or anything, it's a Forth after all 2026-07-28 23:52:19 I just think exceptions make tons of code easier to write and reason about, loads of code has a 'normal path' and a million ways for it to go wrong 2026-07-28 23:52:29 And feels like a natural extension to ABORT really 2026-07-28 23:55:58 Like an HTTP server, the normal path I generate the content and deliver it to the receiver. Exceptions cover lack of resources, internal server errors, permission errors, etc, with less room for mistakes handling the checking of result codes everywhere