Hi Holger, On Wed, Nov 03, 2004 at 04:40:01PM +0100, holger krekel wrote: > me hum, too :-) this means that > > http://codespeak.net/pypy/index.cgi?doc/architecture.html > > is not right when it says: > > The translation process is done in three steps: > > - producing a flow graph representation of the standard > interpreter. A combination of a plain interpreter and a > flow object space performs "abstract interpretation" to record > the flow of objects and execution throughout a python program > into such a flow graph. > > - ... > > because your current prescribed notion of abstract > interpretation starts with already existing flow graphs. Hum.
Abstract interpretation is the name of a very general technique: we use it twice. We use it to produce the flow graph (i.e. the architecture document is correct), and then we also use it to produce annotations on the graph (the architecture document doesn't say how we do that, so it's not wrong not to say we do it with another kind of abstract interpretation too). Now I see where the confusion comes from. The e-mails in this thread have nothing to do with the flowobjspace or the flow graph construction itself. What you said about it is correct but off topic: the topic is annotations and backends. All the "abstract interpretation" I talked about is the one we do to infer the annotations. > But if one part of the program uses the one branch and another > part uses the other branch then you will generalize the function > to annotate 'y' as being an integer. Right. Now I understand your question: > So we do already keep possibly different function versions > for differently typed sets of input parameters to this function? The original code example with "if type(a) is int and ..." was supposed to be inlined at a lot of places, i.e. to replace verbatim all the high-level "add" operations. You're right, I was quite vague. If that code example was put in a separate function, then probably all the branches would have to be analysed anyway, unless we kept different versions of the function for differently typed sets of inputs. Instead, to avoid the problem, it's better to create an inlined copy of the code everywhere and then solve the code bloat by optimizing away all branches apart one. A bient�t, Armin _______________________________________________ [EMAIL PROTECTED] http://codespeak.net/mailman/listinfo/pypy-dev
