Re: Planning work

[Rob Browning]

Keisuke Nishida <address@hidden> writes:

> >  {awk,elisp,whatever}-translator -> sexp -> compiler -> primitive-rep
> >    -> hobbit-codegen -> gcc -> .so - - -> dynamic-link

> How would you maintain source properties (i.e., rows and columns)
> when you translate a target language into Scheme?  Using
> `set-source-properties!'?

(begin thinking-out-loud)

Good question.  I hadn't thought hard about that yet, but I had
half-figured that the primitive-rep might be a superset of normal
scheme.  For example, you could have something like

  (define (foo bar)
    (low:src-pos 20 32)
    (do-foo bar)
    ...)

where the low: prefix is reserved in the intermediate representation,
and the compiler automatically renames any conflicts.  Then we can use
low:* to add whatever special annotations/operations are needed.  We
might also define the primitive-rep to only be a limited subset of
scheme (plus the "low:" ops that could hopefully be made fast and
ported easily to various backends.

And perhaps what I really meant was that the primitive rep should be
scheme-forms, not strictly speaking actual executable scheme code.

> I think translating into an intermediate representation is more
> convenient.  Is there a really good reason for a translator to
> target Scheme?

Well, in Hobbit's case, at least, that's the language it speaks, plain
old scheme. :>

Further, if we really do get a very smart compiler (where by compiler,
I'm using my terminology from the diagram above -- i.e. the front end,
post-translation compiler) with technologies from hobbit and/or
stalin, etc., then *all* translation languages may benefit whenever we
make the compiler smarter.  Also, adding an optimization to that
compiler is then just a matter, for some cases, of adding a new
transformation rule, and IMO parse-tree rewriting seems like something
scheme is particularly well suited for.

So these things seem like advantages to me, though there may be end up
being outweiging disadvantages.

> I'm thinking of the following compilation steps:
> 
>                reader               translator
>   Source code  ----->  Parse Tree    -------->  Intermediate Language
>     (text)        (language specific)         (internal representation)
> 
>   compiler                        codegen
>   ------->  Primitive Language    ------> tree, bytecode, machine code, ...
>          (internal representation)
> 
> The intermediate language should be based on Scheme, but not necessary
> to be Scheme itself, I think.

Well, I still tend to fell like having it be something that you can
manipulate as scheme forms may be a big win.  I.e. being able to do
things like this is really nice:

  Presume that the previous definition of and, was not so smart and
  didn't recognize at compile time, obvious short-circuits.  If the
  first compilation phase is scheme based, then we can just re-write
  and to add a new first clause like this:

  (define-syntax and
    (syntax-rules ()
      ((and #f other-value ...) #f)
      ...))

  Now, at compile time, any construct of the form (and #f x y z) gets
  immediately rewritten as just #f.

Now it could be the case that most of the things I'm thinking of are
really only good as optimizations to scheme code, but I'm not so sure
of that.  For example, the perl && construct might get rewritten to
scheme in such a way that it takes advantage of this optimization.

And as I mentioned, I *certainly* believe that writing parse-tree
manipulations is a job scheme was custom made for.

> We don't need to use lists to represent the intermediate language;
> instead; we can use more compiler-friendly representation during
> compilation.

So what are the disadvantages to using lists as you see them, or more
to the point, what would be the characteristics of a superior
representation?  BTW, I'm not trying to be argumentative here, I think
trying to enumerate what we need/want is a good idea.

-- 
Rob Browning <address@hidden> PGP=E80E0D04F521A094 532B97F5D64E3930