Re: [stack] Constant folding algorithm
"Daniel Ehrenberg" <[email protected]>
| Newsgroups | gmane.comp.lang.concatenative |
|---|---|
| Message-ID | <[email protected]> |
Thanks for your response, Chris, > Have you considered the brute force approach? Try to evaluate a > sub-expression: if it throws an error it doesn't work, otherwise go > ahead and replace the subexpression with its evaluateion. Pretty > naive, but very easy to code. This is how I implemented partial > evaluation in an earlier version of Cat (currently broken, while I > focus on other issues). > That might work, but using that approach, how can I tell where a successful partial evaluation begins and ends? Is it like you take each possible starting point in the code? Maybe something like that, though not necessarily relying on the exception system, is possible. > > > The Factor compiler implements constant folding, but it operates on an > > intermediate dataflow representation rather than quotations. > > What does the representation look like? > I've never looked into it, but Slava has said it's basically Single Static Assignment. It can't easily be converted back into a quotation. > > > This > > looks like one area where it's a little easier to manipulate an > > applicative programming language than a concatenative one, > > Can you tell me more why you feel this is? I am skeptical about this claim. In an applicative language, or at least one with a readily inspectable AST like Lisp, you could just traverse the code in postorder, evaluating all code which doesn't refer to variables and calls a function on a known list. For example, you could tell that (+ x (* (- 4 5) 2)) can reduce, from the inside, to (+ x (+ -1 2)) and then to (+ x 1), though no further, since x is a (free) variable. But I hope I'm wrong and that a similarly simple, explicit algorithm is possible. The brute force approach sounds a little complicated to get right, but I'll see if I can get it to work... Daniel Ehrenberg