Path: csiph.com!usenet.pasdenom.info!aioe.org!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Helge Blischke Newsgroups: comp.lang.postscript Subject: Re: ps scanner - finishing touches Followup-To: comp.lang.postscript Date: Fri, 21 Jun 2013 11:22:40 +0200 Lines: 41 Message-ID: References: <32b7fc2b-80d9-4855-887f-dce2f1bb9f54@googlegroups.com> <0e4500fe-648e-4362-b4cf-9e34a5384da2@googlegroups.com> <1c6b4a1e-c7a6-423e-9457-6a1e7da172d4@googlegroups.com> <815bcdb9-88ae-4104-adf6-97d533e55930@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8Bit X-Trace: individual.net UxacmsbW32yjmfGmWN5AWgAaZgIaKQr+r2e5X+82IYAe4XlK3X Cancel-Lock: sha1:KOEnkP+SOZ1hLJ1O0bmMf0sR59Y= User-Agent: KNode/0.99.01 Xref: csiph.com comp.lang.postscript:1404 luser- -droog wrote: > The scanner is working and mostly complete. Re-wrote most > of the postscript to remove local dictionaries. This should make the > scanner re-entrant. http://code.google.com/p/xpost/source/browse/optok.c > > Remaining issues: //immediate names. A naïve approach would be to add a > variable to toke_dict to track whether we're inside a procedure (so > immediate names are allowed) or outside (where immediate names are > disallowed). Where does the PLRM state that immediate evaluated names are disaloowed outside of procedures???? > But grok_dict might be shared by several contexts. Another > option is to push a new dictionary with this name. Perhaps toke_dict > defines /in_executable_array to false, but when scanning a proc, do > `<>begin` ... `end` around the recursive calls. This > approach seems viable. > > Another piece is ASCII85. I don't have the energy right now. :) > > Another piece (that I'm putting off still, but the day looms closer) is > Binary encodings. > > But the piece standong in the way of running the interpreter > interactively, is dealing with the file/string polymorphism in the token > operator. I've kept this scanner code under the name `toke` as it's > clearly not a full implementation of `token`, since it only accepts > strings. But files can easily be read-off into strings. It's called > buffering and happens all the time. So my thought is, to use the function > that implements the %statementedit special file to read-off a statement > into a string, then call `toke` on that string, and stash the remainder > (the returned substring) into the file object's payload structure (the > shared part), modifying all file-reading operators to read first from this > lookahead_buffer, if present. > > This appears to let me re-use a lot of existing code to get this working. > But something about it leaves me uneasy. Adding a buffer to the file may > have unforeseen consequences. Or so I fear. Helge