00:00:00 --- log: started forth/09.02.19 00:01:45 --- join: workthrick (n=mathrick@0x55529153.adsl.cybercity.dk) joined #forth 00:21:56 --- quit: H4ns ("Leaving.") 00:39:55 --- quit: nighty__ (Remote closed the connection) 01:01:29 --- quit: JasonWoof ("Leaving.") 01:10:03 --- nick: H4ns1 -> H4ns 01:18:02 --- join: qFox (i=C00K13S@132pc222.sshunet.nl) joined #forth 01:27:26 --- join: H4ns1 (n=Hans@p57BBA2A2.dip0.t-ipconnect.de) joined #forth 01:27:48 --- quit: H4ns (Nick collision from services.) 01:27:50 --- nick: H4ns1 -> H4ns 01:45:54 --- quit: blbrown ("Ex-Chat") 04:20:42 --- quit: proteusguy (Remote closed the connection) 04:21:13 --- join: proteusguy (n=proteusg@61.7.144.97) joined #forth 04:24:53 --- quit: proteusguy (Read error: 104 (Connection reset by peer)) 04:48:20 --- join: proteusguy (n=proteusg@61.7.144.97) joined #forth 05:36:17 --- quit: gogonkt (Read error: 60 (Operation timed out)) 05:41:54 --- join: gogonkt (n=info@59.38.201.242) joined #forth 05:50:36 --- join: gogonkt_ (n=info@218.13.54.113) joined #forth 05:50:57 --- quit: gogonkt (Read error: 60 (Operation timed out)) 05:57:01 --- quit: workthrick (Read error: 110 (Connection timed out)) 05:59:31 --- join: workthrick (n=mathrick@0x55529153.adsl.cybercity.dk) joined #forth 06:12:14 --- nick: gogonkt_ -> gogonkt 06:34:39 --- quit: workthrick (Read error: 110 (Connection timed out)) 06:34:51 --- join: workthrick (n=mathrick@0x55529153.adsl.cybercity.dk) joined #forth 06:49:40 --- quit: gogonkt (Read error: 60 (Operation timed out)) 06:54:57 --- join: gogonkt (n=info@218.13.61.76) joined #forth 06:59:39 --- quit: ASau` ("Off.") 07:23:42 --- quit: H4ns ("Leaving.") 07:26:10 --- quit: workthrick (Read error: 110 (Connection timed out)) 08:30:37 --- quit: proteusguy (Remote closed the connection) 08:33:24 --- join: tathi (n=josh@dsl-216-227-91-166.fairpoint.net) joined #forth 08:33:24 --- mode: ChanServ set +o tathi 09:09:01 --- join: JasonWoof (n=jasonwoo@c-66-31-44-71.hsd1.ma.comcast.net) joined #forth 09:09:01 --- mode: ChanServ set +o JasonWoof 09:17:16 --- join: hagna (n=hagna@70.102.57.178) joined #forth 10:31:40 --- join: kar8nga (n=kar8nga@e-146.vc-graz.ac.at) joined #forth 10:43:13 http://en.wikinews.org/wiki/Two_nuclear_submarines_collide_in_the_Atlantic_Ocean 10:44:54 Another fine example of British/French cooperation. 10:49:38 --- nick: TreyB_ -> TreyB 10:54:06 "but mommy, it was dark!" 11:17:22 --- join: H4ns (n=hans@p57A0C7BC.dip.t-dialin.net) joined #forth 11:24:48 --- quit: kar8nga (Read error: 60 (Operation timed out)) 11:36:51 --- join: impomatic (n=John@nat67.mia.three.co.uk) joined #forth 11:37:43 Js 11:38:14 Is the ANS/ISO document mentioned in the topic the best place to learn about modern Forth? 11:38:45 All I really need is a list of words with a short description 11:39:02 there's no such thing as modern forth, just 70's forth and 80's forth 11:41:24 --- join: kar8nga (n=kar8nga@i-225.vc-graz.ac.at) joined #forth 11:44:36 I've been using Fig Forth, so 80's forth is modern as far as I'm concerned ;-) 11:46:54 Fig Forth is very archaic. 11:47:32 There exist 90's Forth and 2000's Forth as well. 11:47:39 i'd be interested in a short reference to ans forth, too. 11:47:54 The standard is the shortest reference. 11:48:16 You can omit appendices. 11:49:30 "waiting for taygeta.com" *pause* 11:50:12 Same problem here with taygeta, I assumed it was my connection 11:52:30 --- join: rbla (n=rbla@dslb-084-057-154-106.pools.arcor-ip.net) joined #forth 11:53:01 ok 11:54:51 hagna: JFYI, last time I checked PLEAC it provided very stupid problems and very stupid solutions in Forth. 11:55:30 ASau: yes I noticed that 11:55:40 ASau: how did you know? 11:55:47 What? 11:56:38 ASau: " hagna: JFYI, last time I checked PLEAC it provided very stupid problems and 11:56:42 very stupid solutions in Forth." 11:56:59 I just checked their pages. 11:57:25 But this was long time ago, two or three years ago if not more. 11:58:06 ASau: yes ok, but why were you telling me? 11:58:16 I didn't say anything about it today 11:58:36 So what? 11:59:00 heh 11:59:01 You did mention it within recent two weeks. 11:59:12 nice 11:59:59 --- quit: JasonWoof (Read error: 104 (Connection reset by peer)) 12:00:11 Since PLEAC is simply irrelevant wrt Forth, the assumed implementation doesn't matter. 12:01:11 ASau: I don't remember my original question anymore 12:03:34 what forth is this written for http://pleac.sourceforge.net/pleac_forth/strings.html ? 12:04:00 PLEAC is very bad reference to Forth. 12:04:17 My opinion is they must be killed for misrepresentation. 12:10:40 murder is the ultimate punishment 12:11:48 --- join: JasonWoof (n=jasonwoo@c-66-31-44-71.hsd1.ma.comcast.net) joined #forth 12:11:48 --- mode: ChanServ set +o JasonWoof 12:11:51 Our dissidents taught us that: no man, no problem. 12:12:03 great 12:15:06 this from jacques 12:15:38 ASau: so yeah pleac is a bad reference to forth factor would be a better language for pleac 12:16:46 I'm not sure about it either. 12:40:20 Is there a word to drop N items off the stack? 12:40:46 No. 12:40:48 no but it could be defined easilly 12:40:56 Common use is "discard". 12:41:06 Though some prefer "ndrop". 12:41:12 : ndrop 0 do drop loop ; or : ndrop for drop next ; 12:41:20 or in isforth (the next release)... 12:41:25 _?do_ 12:41:26 : ndrop rep drop ; 12:41:33 yea it should be ?do 12:41:50 : ndrop 0 ?do drop loop ; <--- better definition 12:42:10 how about just subtracting n cells from the stack pointer? 12:42:29 that assumes a stack that grows in a specific direction :) 12:42:45 I'd still call it "discard" to reserve "n" for some type prefix. 12:42:47 and it would be "adding n cells" not subtracting (usually) 12:43:14 it could be called dropalot for all i care lol :) 12:43:30 Thanks, I wasn't sure if there was a standard word. I'll implement DISCARD in my Forth interpreter. 12:43:44 discard is a good name i guess 12:44:10 or call it drops as in plural 12:44:33 : drops ( ... n1 --- ) ... .. . ; 12:45:02 10 drops looks more english(ish) 12:45:17 I440r: so you're working on isforth again? 12:45:31 slava right now im working on its web site, but yes i am 12:45:50 i want to get the documentation done before i start working on the code again 12:46:15 ive got the kernel documented and am working on the extensions now 12:48:09 cool 12:49:15 I'm documenting my new gui toolkit 12:55:56 --- join: Twey_ (n=Twey@cpc3-brig15-2-0-cust781.3-3.cable.virginmedia.com) joined #forth 12:56:16 --- quit: Twey (Read error: 60 (Operation timed out)) 12:56:28 --- nick: Twey_ -> Guest51278 12:57:34 --- nick: Guest51278 -> Twey 12:58:12 --- nick: Twey -> Guest91438 12:59:18 --- nick: Guest91438 -> Twey 13:30:01 --- quit: kar8nga (Read error: 110 (Connection timed out)) 13:31:16 how do I free memory? 13:32:08 Give it financial security and a sense of civic responsibility. 13:33:18 that's way to high level 13:33:50 How have you acquired it? 13:34:26 create myptr 40 , 13:34:47 And what you want to free? 13:35:08 ASau: what myptr points to 13:35:43 What is at address "40"? 13:36:20 ASau: oh oops I mean get rid of the word that contains 40 13:36:31 Read about "marker" 13:36:35 ok 13:37:13 Some systems support old and more general way: "forget". 13:38:06 I used to know what that did. 13:38:44 doesn't it reset the dictionary pointer to before the current definition of the argument word? 13:39:08 Yes. 13:39:22 hagna: do you realize that the dictionary is a stack, too? 13:39:35 hagna: i.e. you cannot free something from the middle. 13:40:18 H4ns: don't mislead. 13:40:26 Dictionary isn't a stack. 13:40:39 A dictionary is not a stack, no matter what its default representation in memory may seem to be. 13:41:16 Even the traditional (read: ancient) linked-list implementation is not a stack. More modern hash-table dictionaries are even less like stacks. 13:41:41 It is not "ancient", it is archaic, but not ancient. 13:41:55 oh well - i'm only a beginner and i'm using an ancient forth, but in that forth, i cannot remove a word's definition without removing the definitions that have defined after that word. 13:42:04 archaic, ok. 13:42:52 You can find or implement pretty modern Forth, that uses same approach for the sake of simplicity. 13:43:36 ASau, I believe that we have disagreed on terminology before :) I won't bother you with again today. 13:45:35 H4ns: your old forth is that maisforth? 13:46:10 hagna: right. 13:46:29 * hagna waits for an atmel micro to come in the mail 13:46:31 hagna: i think it is close to ans, but it seems rather traditional. 13:47:28 gnomon: well, "ancient" means that you don't find it in modern use. 13:47:28 This isn't the case of linked dictionary. 13:47:39 H4ns: "ANS" is traditional. 13:48:08 Non-traditional Forth is represented by coloured and "machine" dialects. 13:48:09 ASau: ok, then i wanted to write "and" instead of "but" :) 13:48:55 You may be misled by the absence of obvious ANS roots. 13:49:57 ANS <- F-PC <- Laxen & Perry F83 (Forth 83 implementation) <- Forth-79. 13:50:27 One of major development lines. 13:50:38 ASau: to me, as a beginner, maisforth is very close to what the book by zech that i have describes. 13:52:28 Gee, Zech, that was early 80s. 13:53:00 rbla: 1985 it says 13:53:40 Must be a newer edition, mine is 2. edition, 1984 13:53:46 rbla: it is not terribly well written, but has some useful, and pretty-looking diagrams drawn with stencils 13:54:12 rbla: yes, it says 2nd, revised edition 13:57:56 AFAIR, Marcel Hendrix hosts revised "Starting Forth". 13:59:45 --- part: rbla left #forth 14:00:55 F-PC was where i learned forth :) 14:02:02 you missed FIG in that time line 14:02:33 FIG predates 79. 14:02:37 yup 14:03:56 I don't think that FIG is that necessary to show that ANS is a traditional Forth. 14:04:09 what do you mean by "traditional" 14:04:29 i dont think the ans forth standard is forth PERIOD. its a forthISH language however 14:05:08 I mean that it descends directly from the most popular Forth implementations of the peak popularity time. 14:06:09 no. i think the ans forth was "developed" by a committee of people with no regard for existing implementations 14:06:21 or else why would they break NOT again after it had already been fixed 14:06:34 why would the "invent" the abomination "postpone" 14:06:36 ugh 14:06:46 NOT wasn't fixed by that time. 14:06:51 i also do not like the way "ans forth" overly complicates things 14:07:10 for exaple. the ans standard says that the word LOOP is to resolve all LEAVES within said loop 14:07:13 thats DUMB 14:07:28 the word NOT was fixed by the 83 standard 14:07:34 FIG "LEAVE" is a hack. 14:07:45 A nasty one. 14:07:49 ? 14:08:02 what is the fig leave model? 14:08:07 how does leave work in fig 14:08:23 It just sets current counter to limit. 14:08:25 isforth uses the same technique that F-PC used 14:08:32 aha 14:08:42 Which is pretty evil. 14:09:00 ANS "LEAVE" is sane in this respect. 14:09:05 fpc compiled a dummy loop exit point after (do) which (do) collected at run time and placed on the return stack with the loop indicies 14:09:17 leave just drops two items off the return stack and does an exit 14:09:41 if im reading (loop) correctly ans leave is horendously complex 14:09:51 How does it disagree with ANS? 14:10:10 if (loop) has to back patch every single LEAVE within a loop (as stated by the standard) then ans leave is STUPID 14:10:32 Except doing it with run-time hack instead at compile time. 14:10:44 i can put 40000 leaves within my do loop and i dont need to back patch a single one of them 14:10:55 it IS a compile time operaion 14:11:02 dd (do), 0 14:11:06 dd lots of xt's here 14:11:11 dd (loop) 14:11:19 Is there a standard word which DUPs a number of stack items. E.g. DUP, 2DUP, NDUP? 14:11:28 when LOOP compiles (loop) it also resolves the forawrd reference at (do) 14:11:28 impomatic: no. 14:11:33 think of (do) as a branch 14:11:37 impomatic: there's no use for it. 14:11:50 impomatic, you dont want to get TOO complex with stack manipulations 14:12:04 Hmmm... okay 14:12:42 I was trying to make everything as general as possible. 14:12:49 impomatic: don't. 14:13:10 yea its good that you ask these questions AND its good that you experiment but you should keep your stack manipulations simple 14:13:19 impomatic, that's an excellent impulse to avoid. 14:13:24 dont try go deeper than 3 itmes 14:13:30 :-) 14:13:33 and some forths DO implement 3dup 14:13:39 I do. :) 14:13:39 isforth does. F-PC did 14:13:49 I implement 4dup too. 14:13:56 not sure about f83 but it probably did 14:13:56 * gnomon boggles 14:14:09 ASau, why? Were you working with quaternions? 14:14:34 i know fpc used 3dup in its definition for expect and i think that was pretty much a direct copy from f83 14:14:38 I don't remember if I need to copy 5 top values, but I shan't be surprised if I do. 14:14:47 i know this because that code somehow made it into isforth }:) 14:15:46 As for "postpone", there are problems with "compile" and "[compile]". 14:16:03 none that i agree exist 14:16:05 Several words have a special case for 1 and 2, then a gerneral word, e.g. dup, over, pick or swap, rot, roll 14:16:20 impomatic, they are actually MISS named 14:16:38 those are actually more correctly dswap dover dpick drot 14:16:53 because they are for use on double numbers. but the 2 prefix kind of stuck :P 14:17:07 I disagree. 14:17:36 They are for use on strings and memory regions, which are not double numbers. 14:17:36 2dup should have been called ddup 14:17:43 ooh, fun. 14:17:50 let's debate pointless trivialities. :) 14:18:05 It was right that "ddup" was renamed to "2dup" at last. 14:18:12 tathi: ;) 14:18:29 Is there any reason why I shouldn't allow traditionally compile only words to work when interepreted, e.g. DO LOOP 14:18:52 impomatic: yes. 14:18:58 impomatic, well it would complicate them somewhat :P 14:19:31 Not if I have a 3rd stack :-) 14:19:38 gegneral rule of thumb for you "KISS" <-- great english principal of Keep It SImple Stupid 14:20:00 even if you have a third stack you would have to make those words state smart. 14:20:19 which i dont say DONT do. i just say "dont do unless you have a real need" 14:20:28 and in the case of do or ." you dont have a real need 14:20:32 --- quit: hagna ("leaving") 14:20:40 In fact, you only need to split interpretation and compilation semantics. 14:20:53 Which is quite different from making words state smart. 14:21:15 how would you arbitrate that split without state smartness? 14:21:40 For instant, by using separate CFAs. 14:21:57 Or by using special vocabulary. 14:22:20 impomatic: you can get rid of interpret mode altogether and have the outer interpreter compile every line of input, run it, and discard it 14:22:48 Which is wrong. 14:23:14 its not wrong 14:23:17 It is. 14:23:26 Forth is not Factor. 14:23:49 you can get rid of interpret mode and still have an almost 100% standard forth system 14:23:50 that's irrelevant. you don't need types or gc to implement compile-only forths 14:24:09 the main problem with forth is people who consider anything that's not fig-forth or ans 'wrong'. 14:24:15 its not the 70's anymore 14:24:15 :) 14:24:53 The main problem is people who consider that Factor or colorForth is the only Forth. 14:24:58 interpret mode just confuses newbies (why can't I use IF/THEN here?) and doesn't bring anything new to the table 14:25:00 Forth isn't Factor still. 14:25:27 It doesn't confuse newbies. 14:26:07 you can't explain any advantage this approach brings, except that 'its always been done that way' 14:26:42 Interpreter simplicity and technical clarity. 14:26:47 Nope 14:26:52 Compile only is just as simple 14:26:55 if not more so 14:26:57 the latter is debatable, and the former is not a concern as far as the user is concerned 14:27:24 a language should not sacrifice user friendliness and consistency for the sake of making the implementor's job a bit easier 14:27:31 most users don't implement the language they are using 14:27:34 that too :) 14:27:48 except people who implement their own forth and then never write anything in it 14:27:53 slava: Forth is _not_ Factor. 14:28:01 ASau: that's totally irrelevant 14:28:04 Here implementation issues do matter. 14:28:21 slava at the same time though, complicating the internals of a language is bound to complicate the external view of that language 14:28:38 but as tathi said, its not even much of a complication 14:28:49 the only thing it would seem to complicate is neccessating that the compiler be re-entrant 14:28:50 like "postpone" is FAR more complex than compile and [compile] and i say it obfuscates things 14:29:02 so you can compile the top-level form of a source file, and then compile the word definitions which are nested in ti 14:29:06 because the person who uses postpone need have NO knowledge of weather the word is immediate or not 14:29:07 but that's pretty trivial 14:29:26 "thus relieving you of the responsibility of knowing the language you are programming in" 14:29:44 I440r: postpone is irrelevant to this discussion 14:29:58 I440r: anyway, in forth, when calling a word you need to know a lot about it -- what its stack effect is, whether or not it modifies memory locations, etc 14:30:03 so I don't think your concern with ans postpone is a big deal 14:30:06 it was an example of a decision to complicate the compiler internally in order to "simplify" end users use thereof 14:30:12 a FAILED example thereof 14:30:20 I440r: adding a single conditional is hardly complication 14:30:28 we're not talking about 300,000 lines of new code here 14:30:37 Alright, this is coming into pointless way. I just quit discussion, so that I don't waste time on it. 14:30:54 compile and [compile] are very simple. they do similar jobs. they both compile an XT into the definition being created 14:30:56 Ideological divides are very hard to bridge. 14:31:08 the difference is one takes said XT from the execution stream the other takes it from the input stream 14:31:33 postpone is overly complicated and merges two DIFFERENT words just because they have "similar names" and "similar functions" 14:31:36 bad 14:32:07 well, no, that's not really what it does. 14:33:03 but whatever 14:34:28 ok "it replaces the functionality of them both" 14:34:30 STILL bad 14:34:32 but whatever 14:38:15 well, before it existed, people had no choice but to use compile and [compile], even if neither of them did exactly what they really wanted. 14:38:57 --- join: Anixx (n=ask@s209-89-44-167.ab.hsia.telus.net) joined #forth 14:38:58 --- quit: impomatic ("mov.i #1,1") 14:39:24 --- join: gogonkt_ (n=info@218.13.55.74) joined #forth 14:39:50 I don't think I've ever seen a situation for which compile or [compile] was a better fit than postpone. 14:40:18 --- quit: gogonkt (Read error: 60 (Operation timed out)) 14:48:21 --- join: madmacs (n=madgarde@CPE001d7e527f89-CM00159a65a870.cpe.net.cable.rogers.com) joined #forth 14:48:43 The main problem with "compile-only" approach is you don't have clear rules, 14:48:43 where you are to stop compiling and start interpreting what you have just compiled. 14:48:57 Essentially, it kills REPL. 14:50:37 --- part: madmacs left #forth 14:53:45 And here it comes again: Forth differs from Factor. 14:58:40 --- quit: qFox ("Time for cookies!") 15:00:23 --- join: gogonkt (n=info@218.13.52.108) joined #forth 15:00:24 in the same way an electric guitar differs from a classical guitar? :) 15:00:53 Forth is more like a Theremin. ;) 15:01:18 hmmm fresh roasted coffee! 15:03:29 ASau: nope; you run it at the end of each line, just like in any other Forth system. 15:04:22 compile-only doesn't affect the interactivity at all 15:05:18 Advice needed: I'm trying to a help a non-profit build a database of wheelchair accessible campgrounds that can be displayed on their website, and be interactive so various campgrounds can enter thier info. I've been searching hotscripts.com but i've found no easy/clear way how to do this. Any suggestions would be appreciated. 15:06:18 tathi: how do you handle the case, where you switch to compile mode on the line? 15:07:07 Run the line at the end and forget it? 15:07:32 --- quit: gogonkt_ (Read error: 60 (Operation timed out)) 15:07:54 This is pretty wrong and violates Forth semantic rules. 15:08:18 You interpretation breaks semantics, thus it isn't Forth any more. 15:19:20 no, you run it when you switch to compile mode 15:19:29 It's basically like a cache. 15:20:39 Instead of running each word as it is encountered, you cache its behavior and flush (execute) the accumulated semantics when you hit a synchronization point. 15:21:09 I have a half-assed Forth-in-Forth implementation that passes the Hayes' suite 15:24:25 Thus it isn't so simple as declared. 15:25:09 Hayes' suite isn't comprehensive. 15:25:15 It isn't even close. 15:28:50 --- quit: Anixx () 15:29:34 Why do you think it isn't simple? 15:30:13 And yeah, I know the Hayes suite isn't comprehensive, but it covers a fair amount of the basics. 15:31:16 All I'm saying is that it is possible to have a compile-only Forth system with almost completely standard behavior, with about the same level of complexity as a usual system. 15:31:54 One of arguments was that traditional way is hard to understand for newbies. 15:32:16 How's that easy to understand what you describe? 15:32:31 Yeah. Almost half of the newbies we have in here (at least those of them who actually try using Forth) eventually trip over the distinction between interpret and compile modes. 15:32:44 i.e. the difference between CHAR and [CHAR] 15:33:00 that sort of thing 15:33:08 I don't see how it breaks the REPL 15:33:09 Instead of interpreter-compiler mode separation you introduce cache and points of immediate execution. 15:33:09 A compile-only Forth removes the distinction. 15:33:15 if you have ... IF 15:33:16 ... THEN 15:33:22 you don't run the first line, obviously 15:33:27 you read the second line, then run the whole thing 15:33:33 That's not what you told earlier. 15:33:53 Thus things are more complex than you declared it first. 15:34:08 no, they really aren't. You get that behavior essentially for free. 15:34:14 well, the fact that you'd need to handle multi-line expressions seems pretty obvious to me 15:34:15 slava: right, you can only execute if you have an empty control flow stack. 15:34:22 TreyB: exactly 15:36:07 But CHAR and [CHAR] solve a different problem. 15:36:11 Now you added another rule to repair what you've just broken. 15:36:33 that's the only rule you need 15:37:06 ASau: you haven't broken anything; you have added functionality. In standard Forth you can't generally use control-flow constructs in interpretation state at all. 15:37:08 : this ... if [ ... if ... then ... ] ... then ... ; 15:37:28 break into lines and apply your rule. 15:37:42 you wouldn't have [ and ] because there's no interpret mode 15:38:02 sure, you could do that 15:38:05 Those are standard words, you have to interprete them. 15:38:16 And save semantics. 15:38:24 why would you want exact semantics of ANS forth? 15:38:27 if and then have no interpretation semantics 15:38:36 because it eases the transition 15:38:40 BECAUSE THAT IS FORTH. 15:38:55 We're speaking about Forth now, not about Factor. 15:39:03 so ANS forth with no interpret mode is not Forth anymore? 15:39:08 Yes. 15:39:28 Here we go again :-) 15:39:46 If you want to avoid separate mode, go ahead. 15:39:53 You only need to preserve semantics. 15:40:02 why is ANS compatibility so important? 15:40:10 Because that is Forth. 15:40:12 you could be mostly compatible -- most of ANS doesn't depend on interpet mode 15:40:21 so Forth is a dead language? 15:40:40 ANS Forth defines ANS Forth. Other versions of Forth exist. 15:40:44 It depends on your subjective perpception. 15:40:52 But you might as well provide compatibility, because it doesn't really cost you anything. 15:41:11 I would much rather start with StrongForth. 15:41:19 And it lets people easily move any code they might have over to your system. 15:41:38 slava, wait a second - are you saying that a language with a rigorous specification is dead? 15:41:51 I don't think that's what you mean, but it sounds to me like what you said. 15:41:52 I was kind of disappointed in StrongForth, actually. 15:42:00 gnomon: yes, because it cannot evolve 15:42:17 I think StrongForth with some changes -- like removing interpet mode -- would be nice for low-level work 15:42:29 I thought it was going to have some sort of type analysis, instead of just doing the minimal thing. 15:42:36 slava, ah. I disagree very strongly with that point, but I'm glad that I didn't mis-read your assertion. 15:42:48 It's still neat though. 15:42:50 tathi: well, its forth, so its minimal :) 15:43:09 StrongForth provides just enough rigor to make agressive optimizations usable. 15:43:12 :) 15:44:29 OK. To be honest, I don't really know anything about type systems. 15:46:26 --- join: madmacs (n=madgarde@CPE001d7e527f89-CM00159a65a870.cpe.net.cable.rogers.com) joined #forth 15:48:09 tathi: strongforth does some type analysis, after all you don't have to declare types at every single word's call site 15:48:36 I occationally think about a merger between Holon Forth (IDE and umbilical development) and StrongForth (just enough typing). 15:49:30 Which, apart from working on the host image, would look a bit like Factor. 15:50:03 Rather, *not* working on the host image... 15:52:27 slava: er...it just does the obvious concatenation of stack effects, doesn't it? 15:52:49 tathi: well, yeah 15:53:06 tathi: i think the way they overload words is neat 15:53:09 It chooses between different implementations of a word based upon input stack pictures. 15:54:30 oh, right. I forgot about that. 15:56:09 and the return value of the chosen overload propagates onto the next stack item, etc 15:56:15 also they have some parametric polymorphism, for words like dup 15:56:21 so its not completely trivial 15:56:36 they can also express 'pointer to integer' -vs- 'pointer to pointer to char' etc 15:56:45 and @ and ! will typecheck correctly in these cases 15:57:37 sounds evil :) 15:57:42 slava: it basically only has parametric polymorphism. 15:58:02 the overloading of words on type is ad-hoc polymorphism 15:58:21 what they really need to do is some higher-order type inference so you don't need to annotate every single 'execute' 16:00:24 slava: Hmmm. I think you could write both " dup ( int -- 1st 1st ) " and " dup ( int int -- 1st 2nd 1st 2nd ) " and the type-matcher will deal with it. 16:00:43 i don' think it could, because that's ambiguous 16:00:49 how would it know what you have on the stack 16:02:00 It knows what you have on the stack by building the stack picture during compilation. I don't know what its word selection rules do with words with the same name that have different numbers of inputs. 16:02:55 It may have a match-deepest rule or a match-shallowest rule or something. 16:03:12 I haven't looked at it in several months, so I don't recall the details. 16:03:14 the best approach would be to prohibit such overloading 16:03:37 why would anyone do this to forth? 16:03:55 maybe because they're sick of constantly fixing trivial stack shuffling and data usage bugs 16:04:12 where? 16:04:15 and because they're tired of remembering which words have variants for double ints, floats, chars ,etc, and just want to remember one word per operation 16:04:18 citation needed 16:04:30 I440r: it also gives you a language much friendlier to inter-block optimization. 16:04:33 you're saying you've never had a bug where you made a mistake with stack shuffling and got your inputs and outputs wrong? 16:04:53 or accidentally used + instead of d+, or forgot to dereference a pointer with @, etc? 16:05:08 slava of course thats not what im saying. but when you develop forth correctly (i.e. interactivly) you fix it right there and then 16:05:09 or forgot a swap? 16:05:20 everyone makes mistakes but thats why you test as you go 16:05:23 and FIX as you go 16:05:42 sure, so you test interactively and the computer can tell you that there's a problem instead of your code just crashign in some random way 16:05:44 And StrongForth can catch some of that much earlier (at compile time). 16:05:53 also. if your word is THAT complex that it is subject to these types of errors its an indication that you need to rethink it 16:06:07 TreyB, compile time IS edit time IS debug time 16:06:17 also your strategy won't work when you're rfactoring an existing codebase 16:06:29 who says? 16:06:32 if you change a single word, its impractical to test the whole program and every code path in that program for every change 16:06:40 no bleh 16:06:58 you test THAT word and make sure it works in its new incantation 16:07:06 yes you now have to "fix" all the words that reference it 16:07:08 how do you know you haven't broken any usages? 16:07:13 and any words that reference those, etc 16:07:20 but you FIX the code the same way you implemented it in the first place 16:07:23 bottom up 16:07:37 the computer can automate at least some of this, and I don't see this as a problem 16:07:42 because you test things further up the chain as you go? 16:07:53 if there are BUGS thats YOUR fault, not the languages 16:08:08 no, because if I can write a program in language X with less effort than language Y, then language X wins 16:08:49 well i see language X imposing all kinds of restraints and playing mommy making sure the poor coder doesnt do something silly as being more effort to use 16:09:30 that's an irrational argument, because you're arguing in favor of making programming harder, and making stable software take more effort to implement, and the user will suffer 16:09:51 erm. no im arguing in favor of keeping the language and its compiler simple 16:10:06 and not imposing all kinds of bullshit restrictions on said coder because the compiler doesnt like it 16:10:19 ive broken this rule twice in isforth i think 16:10:27 maybe 3 times but i think only twice 16:10:38 and they are both SOFT breaks 16:11:02 my case construct does not allow for the poor practice of "case X of 2895624789 lines of code loop endof 16:11:06 " 16:11:10 for example 16:11:47 i forget where the other one is but i know thers at least two cases where the compiler enforces "good practice" 16:12:00 but it does not stop you implementing any variation of case that you want to use 16:23:06 --- quit: tathi ("leaving") 16:56:20 --- part: X-Scale left #forth 17:09:49 --- part: madmacs left #forth 20:22:44 --- quit: schme ("leaving") 21:25:22 --- join: ASau` (n=user@host65-231-msk.microtest.ru) joined #forth 21:39:46 --- quit: gogonkt (Read error: 54 (Connection reset by peer)) 21:42:00 --- join: gogonkt (n=info@59.39.12.61) joined #forth 22:26:21 --- join: harblcat (n=chris@c-71-201-98-174.hsd1.in.comcast.net) joined #forth 22:26:56 There's a question that's been on my mind: can you do things like SDL in forth? 22:30:43 Yes. 22:32:22 Interesting. Have you ever tried it, ASau`? 22:32:48 I did sound output. 22:35:00 Would you say it was easy to grasp, or did you have to do a lot of looking at reference pages? 22:50:12 It depends on your experience. 22:50:59 Well, in forth I have none. I find it to be interesting, and kinda weird, and it will probably be something I'll "play" with from time to time.. I was just wondering :) 22:51:19 Thanks for the input! 22:51:20 --- part: harblcat left #forth 23:59:59 --- log: ended forth/09.02.19