I didn't know about the seekable streams implementation in factor: https://docs.factorcode.org/content/article-stream-protocol.html
We have: "/tmp/toto" ascii <file-reader> stream-seekable? f "/tmp/toto" (file-reader) t ! it works, stream-seek can rewind or fast forward and stream-read1 will get the bytes For some variable length encodings (utf8), seeking is going to be pretty expensive, but for ascii it's transparent so maybe it should work in <file-reader> ? Anyway you're right, although the peg vocabulary currently uses the sequence protocol (mainly through slices from what I see), maybe it could be rewritten to use the seekable stream protocol ? Still seems like quite a lot of work though. Jon On Sat, Nov 21, 2020 at 11:49 PM Alexander Ilin <ajs...@yandex.ru> wrote: > > What's the problem backtracking through a file? Streams can have arbitrary > positioning. > > Alternatively, there must be a simple way to "wrap" a random access file > stream with an array-like interface, right? Don't we have a class like that > somewhere? > > Like the reverse of <string-reader> and <byte-reader>? > > I will definitely use the tokenizers, thanks. > > 22.11.2020, 01:34, "Jon Harper" <jon.harpe...@gmail.com>: > > What you are describing reminds me of the built-in nesting of parsers with > the ebnf tokenizer : > https://docs.factorcode.org/content/article-peg.ebnf.tokenizers.html > > Not sure if it's really applicable to your use case though. > > > As for streams, aren't packrat parsers backtracking (with memoization)? So no? > > > > _______________________________________________ > Factor-talk mailing list > Factor-talk@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/factor-talk _______________________________________________ Factor-talk mailing list Factor-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/factor-talk
