Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!nuzba.szn.dk!pnx.dk!fu-berlin.de!uni-berlin.de!not-for-mail From: David Kuehling Newsgroups: comp.lang.forth Subject: Re: Quotations revisited Date: Wed, 13 Mar 2013 10:33:25 +0100 Lines: 52 Message-ID: <874ngf8x0a.fsf@mosquito.pool> References: <00808889968435@frunobulax.edu> <50040282.189860346@192.168.0.50> <771c3aa0-0b95-48af-b0fb-c6ae6269a266@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: news.uni-berlin.de 9GjcdpqaoRcB/KKH/1p2gwcKf++KY50eHGbhms7DEkvxJ2+LQ= Cancel-Lock: sha1:ksROqZ2HBZZPrWXmk2OaE+TqAxY= User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) Xref: csiph.com comp.lang.forth:20617 >>>>> "Michael" == Michael L Gassanenko writes: > 1. We need to decide what RECURSE means for quotations: call the > quotation or call the enclosing named definition? Maybe just declare use of RECURSE as an ambiguous condition? > 2. Closures (about which we sort of agreed to speak only > theoretically), resemble CREATE-DOES> definitions in the same way as > quotations resemble colon definitions. Quotations may reside in ROM; > closures will need some RAM. This idea is brilliant. I didn't think Forth could capture the notion of quotations, given its low-level nature, but your approach would nicely match Forth concepts. I don't think that quotations' data necessarily need to reside in RAM. There are scenarios where you just want to have constant data (e.g. compiled via CREATE an , ) associated with a closure. > 2.1. Closures assume run-time creation of execution tokens. Doesn't this creation of execution tokens create a memory leak? > 2.2. As to where the memory for data is allocated, I think, the best > answer is: let the user choose, it may be ALLOCATE or HERE SWAP ALLOT > . > 2.3. To create a closure, we will need to: allocate an area of memory > with some room for the "code field"; fill the "data field" with the > data; bind the closure with the desired behavior (writing to the "code > field"); create an xt for that "code field". In GCC this would be called a "trampoline", i.e. something like : make-trampoline ( xt1 a-addr -- xt2 ) :NONAME POSTPONE LITERAL COMPILE, POSTPONE ; created for every execution token. But how to track that memory? We'd have to provide a new word for freeing the trampoline. FORGET-[DOES>;] ( xt -- ) which cannot be implemented in ANS Forth for a definition of make-trampoline relying on :NONAME . cheers, David -- GnuPG public key: http://dvdkhlng.users.sourceforge.net/dk.gpg Fingerprint: B17A DC95 D293 657B 4205 D016 7DEF 5323 C174 7D40