00:00:00 --- log: started forth/14.10.03 00:17:32 --- quit: impomatic_ (Quit: impomatic_) 00:17:33 --- quit: impomatic (Quit: ChatZilla 0.9.90.1 [Firefox 32.0.3/20140923175406]) 00:42:06 --- join: dys (~user@2a01:1e8:e100:8296:21a:4dff:fe4e:273a) joined #forth 01:02:44 --- quit: irsol (Ping timeout: 250 seconds) 01:08:28 --- join: bbloom_ (~bbloom@cpe-68-175-72-82.nyc.res.rr.com) joined #forth 01:10:38 --- quit: bbloom (Ping timeout: 244 seconds) 01:13:11 --- join: irsol (~irsol@unaffiliated/contempt) joined #forth 02:38:12 --- join: true-grue (~grue@95-25-86-123.broadband.corbina.ru) joined #forth 03:02:57 http://repl.it/languages/Forth 03:42:04 --- join: nighty^ (~nighty@hokuriku.rural-networks.com) joined #forth 04:31:58 --- quit: proteusguy (Remote host closed the connection) 04:34:33 --- join: proteusguy (~proteusgu@ppp-110-168-229-122.revip5.asianet.co.th) joined #forth 04:52:51 --- quit: proteusguy (Remote host closed the connection) 04:54:31 --- join: elaforest (~elaforest@unaffiliated/elaforest) joined #forth 04:55:23 --- join: proteusguy (~proteusgu@ppp-110-168-229-122.revip5.asianet.co.th) joined #forth 05:07:01 --- join: Zarutian (~zarutian@168-110-22-46.fiber.hringdu.is) joined #forth 06:04:56 --- quit: proteusguy (Remote host closed the connection) 06:09:56 --- join: joneshf-laptop (~joneshf@98.208.35.89) joined #forth 07:12:06 --- join: aranhoide (~smuxi@130.Red-81-32-187.dynamicIP.rima-tde.net) joined #forth 08:29:33 --- join: daowee_ (~daowee@m80-170-136-251.cust.tele2.se) joined #forth 08:29:47 --- quit: protist (Quit: Konversation terminated!) 08:32:23 --- quit: daowee (Ping timeout: 260 seconds) 08:34:02 --- quit: daowee_ (Ping timeout: 250 seconds) 08:34:31 --- join: daowee (~daowee@m80-170-136-251.cust.tele2.se) joined #forth 08:49:12 --- quit: Zarutian (Quit: Zarutian) 09:12:07 --- quit: joneshf-laptop (Remote host closed the connection) 09:45:29 --- join: Zarutian (~zarutian@168-110-22-46.fiber.hringdu.is) joined #forth 09:45:52 --- quit: Zarutian (Read error: Connection reset by peer) 09:46:24 --- join: Zarutian (~zarutian@168-110-22-46.fiber.hringdu.is) joined #forth 09:56:02 --- join: IronTree9 (~irontree9@c-76-120-0-183.hsd1.co.comcast.net) joined #forth 10:17:44 --- quit: IronTree9 (Ping timeout: 260 seconds) 10:22:31 --- join: joneshf-laptop (~joneshf@69.194.128.253) joined #forth 10:33:27 --- join: IronTree9 (~irontree9@c-76-120-0-183.hsd1.co.comcast.net) joined #forth 10:37:21 --- quit: dys (Read error: Connection reset by peer) 10:55:06 --- join: dys (~user@2a01:1e8:e100:8296:21a:4dff:fe4e:273a) joined #forth 11:05:05 --- join: _spt_ (~Jaat@unaffiliated/-spt-/x-5624824) joined #forth 11:24:56 --- join: xyh (~xieyuheng@2001:250:3002:5550:6ea1:cc0f:bcb2:b187) joined #forth 11:27:32 --- join: proteusguy (~proteusgu@ppp-110-168-229-122.revip5.asianet.co.th) joined #forth 11:29:00 --- quit: daowee (Ping timeout: 245 seconds) 11:32:37 how about a web browser parses yaml (or something alike) instead of html, and Forth (or something alike) instead of javascript :) 11:36:33 --- quit: proteusguy (Remote host closed the connection) 11:39:34 --- join: proteusguy (~proteusgu@ppp-110-168-229-122.revip5.asianet.co.th) joined #forth 11:44:05 I am curious to know what attempts have been made at bringing type checking into Forth. 11:45:48 I can imagine something like a standard comment format for each word, whereby a lint-type process would be able to do rudimentary checking of types left on the stack (admitted hand-waving here). 11:47:03 So perhaps this would happen at the editor level, transparent to the interpreter/compiler. 11:47:45 This would obviously be a problem where a word accepts or returns different sets of arguments depending on runtime conditions... 11:49:35 Would writing a definition to check the type of definition work? Like a pseudo prefix? (new here, been ages since I wrote forth.) 11:50:13 correction check type of data 11:52:15 Well, it seems that the transparent use of stacks in Forth is both a source of power (and compactness of code) as well a risk to the programmer. 11:53:24 And it isn't completely obvious how dynamic type checking would be done, given that the stack is just a stack of cells with no concept of types. 11:54:29 --- quit: proteusguy (Remote host closed the connection) 11:56:20 However, would it be possible to have a static type checker which, using type information stored in code comments, could reveal overt type conflicts? 11:57:29 --- join: proteusguy (~proteusgu@ppp-110-168-229-122.revip5.asianet.co.th) joined #forth 11:58:46 how would the syntax work? converting from 1 + 1 to 1_int + 1_int is that possible without writing a definition for every possible number? 12:00:55 I am more thinking of expanding the stack picture comment so that the lint-type process or editor function can match word results with word arguments. 12:03:25 Are you limiting the resulting type to the argument type? 12:03:51 question: what would a strongly typed forth be called? 12:03:56 answer: a Fort! 12:03:57 :D 12:04:08 i'll see myself out. 12:04:12 haha 12:04:50 XD 12:07:39 I haven't looked at the source code yet, still reading documentation and blogs. 12:08:53 Going to be a bit before I am caught up. 12:10:28 My simpleton cursory approach would be to take a basic block stretch of code, and - assuming all the words involve have only one stack picture (meaning they don't accept or return varying number or types of arguments) - build an internal representation of the stack content in terms of types. For each word in the basic block, check that the input argument list matches the top of this internal 'type' stack. 12:11:41 so different stacks for different types? 12:12:09 oh? type stack that syncs up with the data stack? 12:13:17 this all seems vaguely familiar. 12:13:21 No, actually the interpreter / compiler would not operate any differently. The stack I'm talking about would be internal to this autonomous 'type checker' function. 12:13:24 --- quit: proteusguy (Ping timeout: 260 seconds) 12:13:56 I see 12:13:58 I would not want to have to store type information on my MCU with 16KB RAM. :-) 12:14:12 you got 16KB? 12:14:19 I have no desire for type checking, just keeping the brain warm 12:14:22 holy crap! babbage would be soooo jealous! 12:14:25 i should text him. 12:14:36 sorry. telegraph. 12:14:41 --- join: daowee (~daowee@m80-170-136-251.cust.tele2.se) joined #forth 12:15:18 Morse code 12:15:28 No. that's ancient tech. 12:15:41 signal flares 12:15:41 Babbage is a man with modern tendencies. 12:15:48 ahead of his time. 12:16:01 I shall send him a fax. he no longer telegraphs. 12:16:14 So, I should clarify that I am not really interested in adding strong type checking to the language itself. I'm more looking for a lint function used during development. 12:16:20 morse code in smoke signals + plus a error correction bit. That enough tech? 12:16:43 smoke signals attract firemen (and woman). 12:16:50 ... they send the wrong signal. 12:16:52 which woman? 12:16:59 the one they hired, i hope. 12:17:07 wait, that should be 'women'. 12:17:09 firewomen. 12:17:11 ;) 12:18:08 that anachronism will be changed to firequencher: a gender neutral description of the noble profession. 12:19:07 So, annotated comments act as the scaffolding for the program, and the interpreter/compiler remain as oblivious as ever. 12:20:10 well the male pronouns are default to gender neutral if the gender is not given in context. But that is pretty old grammar, but I go by it. new shit just makes me type more. 12:21:40 --- join: Mat3 (~Mat@91.65.76.247) joined #forth 12:21:42 hello 12:21:46 Hi Mat3 12:22:08 hi backer 12:26:09 --- join: proteusguy (~proteusgu@ppp-110-168-229-87.revip5.asianet.co.th) joined #forth 12:27:15 hello Mat3 12:27:36 hi IronTree9 12:27:41 are you new here ? 12:27:44 In essence the lint function is just matching string names. Casts could be implemented in the comments as a set of equivalent strings. 12:28:16 Sorry folks, I'm just thinking out loud here without doing any real due diligence. I am just curious if this rings a bell with anyone... 12:28:49 yes 12:31:13 what you guys here thinking about circular stacks ? 12:32:01 in combination with pick I have found them quite useful in reducing stack arithmetic to bare minimum 12:34:04 Mat3: I've been thinking about a lint-style type checker for Forth, based on stack comments with type annotations. 12:39:50 Mat3: unless the target is resource constrained, I'd prefer having deep stacks 12:39:52 backer: do you think it is acceptable to limit functions to ``not accept or return varying number or types of arguments'', this is a common problem of a type checker or type inferring 12:40:32 interesting. For my language project I discarded a data-type system but implement storage types. This way the parser is able to perform not only implicit type checks but also detect logical and arithemtic errors at compilation time (the code is interpreted at typing and then compiled if no error is detected) 12:41:24 --- quit: IronTree9 (Quit: Leaving) 12:41:25 xyh: No. What I'm thinking of is along the lines of static analysis / lint. If it were possible to have stack pictures for all possible outcomes, perhaps there would be a way to recursively check possible stack usage. 12:42:34 --- join: IronTree9 (~irontree9@c-76-120-0-183.hsd1.co.comcast.net) joined #forth 12:44:41 crc: The problem I have with deep stacks is simple that I can't hold them in CPU registers by static referencing (dynamic register sheduling in software is somewhat more complex for a stack-based language which code tend to use only 1-3 stack slots) 12:45:22 Mat3: Maybe that's along the lines of what I'm thinking... My view is that Forth, like C, can be used dangerously. It is up to the programmer to be certain of proper data use during runtime (the norm), but having greater information surrounding the program (e.g. annotated comments) can help mitigate this risk by allowing static analysis / verification prior to compilation. 12:47:14 backer: ``stack pictures for all possible outcomes'' is impossible 12:47:59 this approach is somewhat related to mine. However, my language is complete type safe in the sense that storage accesses are only possible by type 12:48:15 xyh: That's why I said "if it were possible." ;) 12:48:34 Mat3: that's less crucial for me, since most of my code runs under byte coded virtual machines 12:48:42 I am on the side of not catering to programmers that are not good at data management at the cost of simplicity. 12:49:31 xyh: Do you think it is impossible even for a basic block (no branches)? 12:51:09 backer: basic block as "if else then" or just "if then" ? 12:51:46 IronTree9: I agree, but there is a difference between incompetence and making typographical errors (e.g. inadvertently swapping two integers). 12:51:50 or basic block as in: serial code sequence ? 12:52:25 Mat3: yes, the latter - a straight line of code with no branches 12:53:48 then I think it is possible because such sequences can be parsed in context of the interpreter state (not possible within AOT compilation however) 12:53:49 backer: ``a straight line of code with no branches'' is not Turing complete 12:55:35 I have had great success using external tools to check for typographical errors. For me I must catch them in real time, so I am fond of using color. just my style 12:55:49 bbl 12:56:49 sorry, what you mean with color here ? 12:57:13 * Mat3 thinks he referenced to flowchart analysis 12:58:40 xyh: I don't expect it to be 100% certain of a program's type safety from static analysis. I am just saying that a simple check - such as verifying that stack arguments match up within each basic block of a program - would help uncover stupid mistakes before they are executed. 13:02:16 And by "stack pictures for all possible outcomes," I don't mean of the dynamic execution. I just mean that a given word would have an annotation for each possible stack usage, e.g. ( n -- T a | F ) expresses two possibilities. 13:02:35 color in the editor that paints syntax elements in different colors. vim has a few. example all strings are red. commands are green or what ever. typos change the color and my eye sees it in that moment. 13:03:12 that should be ( n -- a T | F ) 13:05:21 --- quit: joneshf-laptop (Remote host closed the connection) 13:05:51 backer: yeah, it will be a good design, static-type-check only locally when a programer wish, and do NOT guarantee to work with all functions, otherwise it must limit the power of the language :) 13:07:04 IronTree9: emacs have good syntax-highlighting support too , for example :: http://cicada-language.github.io/source-code/english-core.org.html 13:07:19 xyh: Absolutely. And it is "understood" that the programmer is taking all risks as usual; the type checker is an aid and not a crutch. 13:08:31 I've been getting ideas for an editor / development environment. But who hasn't? 13:08:57 backer: MPE made an atempt [[http://www.mpeforth.com/arena.htm][FLint]]. I heard of StrongForth and Factor ("a practical concatenative programmng language"). I guess concatenative programming is a sinonim for point free programming (see Haskell). 13:10:31 backer: I may implement this in my development environment :) 13:10:42 it is good to see some language research happen again 13:11:22 DKordic``: what is ``sinonim'' ? 13:11:47 synonym ? 13:11:54 Mat3: language research never stop :P 13:13:13 xyh: You mean starting with Forth? Yes a typo, thank You. 13:15:11 DKordic``: Thanks for the links. The first thing looks similar to what I'm talking about. "Variable stack effects at the inputs and outputs are to be treated as illegal." 13:17:06 backer: Should be a way to declare exception which prints a warning. 13:19:00 crc: what you are working on recently ? I see parable :) , and retro-12 ? 13:20:04 xyh: You may want to check out that Flint paper. 13:21:54 xyh: I mean somewhat Forth releated language research and improvement 13:24:12 Mat3: Charles H. Moore comes to my mind :) . 13:24:14 xyh: Thanks to you I started checking out org-mode. I've been wanting something like that for a while now. 13:28:01 backer: :) please use the new version from the orgmode.org , the old version build-in emacs is buggy 13:30:53 DKordic``: Yes and his ColorForth is somewhat an inspiration to me (I must note that I know similar token-based interpretation ideas from some early Basic systems) 13:31:57 xyh: parable and retro, and some small iOS applications 13:32:31 spent a few weeks building an interface to parable for iOS devices, and doing something similar for retro currently 13:33:54 --- quit: proteusguy (Remote host closed the connection) 13:34:38 --- quit: dys (Ping timeout: 260 seconds) 13:35:11 xyh: I am, thanks. I'm just getting started with it. Really digging the folding with TODO lists! 13:54:32 --- quit: nighty^_ (Ping timeout: 250 seconds) 13:59:50 --- join: nighty^_ (~nighty@static-68-179-124-161.ptr.terago.net) joined #forth 14:02:59 ciao 14:03:00 --- part: xyh left #forth 14:40:19 --- quit: daowee (Ping timeout: 260 seconds) 14:58:25 --- quit: _spt_ (Quit: irc- et) 15:02:05 --- join: Azel (~Thunderbi@ANice-653-1-452-34.w83-201.abo.wanadoo.fr) joined #forth 15:24:38 more on type checking: http://www.complang.tuwien.ac.at/anton/euroforth/ef02/poial02.pdf 15:51:36 re types in forth: wasnt there something called strongForth? 15:53:58 StrongForth implements a strict type system which I doubt would be not favioured by backer 15:54:51 --- quit: Mat3 (Quit: Verlassend) 16:00:54 I'd like to check it out, but the site is not responding. (http://home.vrweb.de/~stephan.becher/forth) 16:01:57 use the wayback machine 16:12:59 --- join: daowee (~daowee@m90-141-145-61.cust.tele2.se) joined #forth 16:26:15 --- quit: nighty^ (Quit: Disappears in a puff of smoke) 16:28:36 --- quit: true-grue (Read error: Connection reset by peer) 16:39:07 --- join: elaforest_ (~elaforest@unaffiliated/elaforest) joined #forth 16:39:10 --- quit: elaforest (Ping timeout: 258 seconds) 17:24:31 --- nick: elaforest_ -> elaforest 17:33:58 backer: http://kittenlang.org/ is a strongly typed concatenative language similar to forth. 17:34:15 (well similar in some ways. obviously quite different in others) 19:06:12 --- quit: elaforest (Ping timeout: 240 seconds) 19:39:14 --- quit: nighty^_ (Read error: Connection reset by peer) 19:41:59 --- join: nighty^ (~nighty@static-68-179-124-161.ptr.terago.net) joined #forth 19:42:52 --- join: bbloom (~bbloom@cpe-68-175-72-82.nyc.res.rr.com) joined #forth 19:46:00 --- join: backer_ (~backer@user-1087i73.cable.mindspring.com) joined #forth 19:55:58 --- quit: Zarutian (*.net *.split) 19:55:58 --- quit: bbloom_ (*.net *.split) 19:55:59 --- quit: backer (*.net *.split) 20:03:32 --- join: saml_ (~saml@pool-71-190-7-10.nycmny.east.verizon.net) joined #forth 20:08:27 --- quit: aranhoide (Ping timeout: 272 seconds) 20:09:16 --- join: joneshf-laptop (~joneshf@98.208.35.89) joined #forth 22:06:58 --- join: xyh (~xieyuheng@2001:250:3002:5550:6ea1:cc0f:bcb2:b187) joined #forth 22:08:36 way these two functions do not work ? https://www.refheap.com/91146 22:08:40 * why 22:27:04 --- nick: Anarch_ -> Anarch 22:30:49 Because you didn't write them correctly. :D 22:31:22 x86 assembler? 22:31:43 What's your input, your expected output and your actual output? 22:33:04 xyh: ^^ 22:34:41 You're making a call to the contents of the dlopen variable. What's that about? 22:34:56 As in why are you doing call [dlopen] instead of call dlopen? 22:49:23 ttmrichter: it is fasm on x86_64 linux, I am trying to implement ``dynamic shared-lib call'' in forth interpreter. input is :: :" libtest.so" dlopen :" test" dlsym , where test is a funciton compiled by "-fPIC" and "libtest.so" is the shared-lib made by it. I am just too bad at C ... and never want to learn it ... 22:49:42 --- join: aranhoide (~smuxi@130.Red-81-32-187.dynamicIP.rima-tde.net) joined #forth 22:53:14 ttmrichter: just about to give up implementing such ``dynamic shared-lib call'' support ... with that amount of time struggling in C , I can write everything by my own language ... 22:59:09 Interfacing Forth with C is always a pain. 23:59:59 --- log: ended forth/14.10.03