Re: TCL->Scheme

[Maciej Stachowiak <mstachow@mit.edu>]

ian@bickiia.earlhall.earlham.edu writes:
> Maciej Stachowiak writes:
> > I'm glad someone is working on this. Are you doing this specifically
> > for Guile, or trying to be portable to any RnRS Scheme?
> 
> Right now I'm doing it in SCM, because Simlix supports just SCM and
> Chez Scheme.  Of course, it should be quite easy to port to Guile, but
> I haven't bothered working through those details (I just got the
> partial evaluator to work on my code yesterday).  Mostly the module
> stuff in Similix would need to be ported (to get at slib), and I don't
> understand modules in SCM or Guile so I haven't tried yet.
> 

It's possible to get at slib pretty easily from Guile (although I
don't think the latest version works).

> It should be pretty easy to port to anything else -- Similix supports
> a functional subset of Scheme, so I'm fairly restricted in what I do.
> You can get at all the other stuff, but it's kept separate and defined
> differently -- which makes it pretty clear what would need to be
> ported.  Also it seems that using more exotic procedures (like (eval
> (string->symbol...))) might keep the evaluator from working as well,
> so it would be judicious for me to avoid them.  However, Simlix would
> need to be ported for it to be very useful (as a straight interpreter
> there are some wild inefficiencies put in to keep it functional --
> these should disapear during the partial evaluation stage, but leave
> the interpreter inefficient).
> 
> As it is, I've implemented a whole lot of little things which must
> exist in other places already (like streaming over a string) but which 
> may work differently with different implementations.  This should make 
> it even more portable.  (I've reimplemented some things to do things
> in a more functional fashion)
> 

Hmm, Guile already has string ports (call-with-input-string,
call-with-output-string), as do many other implementations, if that is
what you mean.

> > There were Gdb patches available, as Jim mentioned a while ago, but I
> > am not sure they are up to date.
> 
> Hmmmm... does anyone know of up-to-date archives of the list?  The
> ones at www.red-bean.com only go up to early August.  I didn't notice
> anything about gdb when I was browsing through them (though maybe I
> missed it).
> 

They seem to not have updated since then. Jim?

> [code examples]
> > ;; then insert in generated code:
> > (access-string-variable "*some-variable*)
> > ;; however, this expands at macro-expansion time, not runtime, which
> > ;; is a shortcoming for some cases in Tcl.
> 
> Yeah, macros wouldn't work on a few levels.  Does the REPL loop use
> plain evals?  (I suppose the "E" would stand for "eval", answering my
> own questions... but I was thinking there might be some deeper
> [structurally] manner of getting at that stuff)
> 

The REPL loop evals, yes. The original intended Guile formalism was
for translators to only replace `read', though, not the whole REPL -
the translator's reader would return Scheme forms in list
representation to be eval'd as appropriate by the REPL.

> > > How can I define a variable based on a string?  E.g., if the TCL
> > > wishes to export some procedure, how can I put that procedure's name
> > > in the global namespace?
> > 
> > Use the same hacks as above in combination with `define'.
> 
> So, if I do something like this:
> 
> (eval (cons (list 'define (string->symbol "mytclproc"))
> 	    (tcl-procedure->lambda tcl-context "mytclproc")))
> 

I'd just have something that would return 
(list 'define (string->symbol "mytclproc")
	(tcl-procedure->lambda tcl-context "mytclproc"))

Actually, I don't really understand the latter part - I'd expect
something more like 

`(define ,@(cons (tcl-string->symbol procname)
		 (map tcl-string->symbol (tcl-string->list arglist)))
   ,@(tcl-string->code procbody))


Where tcl-string->symbol is just string->symbol, assuming Tcl strings
are implemented as Scheme strings, tcl-string->list uses tcl's list
conversion rules and returns a list of strings, and tcl-string->code
recursively does the same string ==> scheme s-expression conversion as
your translator as a whole, recursively on the given string taken as a
list. Maybe a more accurate expression for this idea would be

(map tcl-statement->s-expression (tcl-string->list procbody))

which better expresses the idea that you treat the body of a tcl
"proc" as a list of statements, 

which expresses the idea of treating the body as a list of statements,
each of which is recursively turned into an s-expression.

> It should work?  How can I get it defined in the global scope?
> 

I think you should just write a replacement for `read' and leave it up
to the repl to put things in the global scope.

> I'm not trying to merge any of the local TCL stuff with Scheme -- the
> mixing of the languages at anything less that the global scope seems
> unnecessary.

Probably true.

> 
> [tcl type problems]
> > I don't think there is a better way. Note that you also need to
> > specify the return type unless it is possible to magically convert to
> > strings in a canonical way.
> 
> It should be possible to make a canonical form -- most Scheme data can
> be converted into some sort of TCL string, and the Scheme types are
> rich enough to figure out the method of conversion automatically.
> Anything which can't be converted into a string is going to be
> meaningless to a TCL program anyhow.  Oh.  Except if it passes that
> same value off to another Scheme procedure.  Hmm... I'll have to think
> about that.  There's also messy things like the fact that Scheme ports
> aren't necessarily named, where TCL channels are always named.
> Hmm... I guess it was worse than I thought.  Darn.

There's also the fact that a Scheme list has to be recursively
subconverted or whatever.

> 
> > > So far the translation seems like it's going fairly well -- I'm using
> > > a TCL interpreter written in Scheme, then applying a partial evaluator
> > > (Similix
> > > http://www.diku.dk/research-groups/topps/activities/similix.html).  I
> > > don't think there's really any other reasonable way to translate TCL,
> > > it being so context sensitive. 
> > 
> > I don't know if this will precisely reproduce semantics. There is
> > actually real Tcl code out there that depends on accessing a variable
> > through a name determined by accessing another variable (though I can
> > no longer remember the hairy syntax for this).
> 
> set a green
> set x a
> set $x blue
> puts $a
>   ==> blue
> 
> It actually isn't too hairy -- it falls right out of TCL syntax.  It's 
> just like LOGO, really:
> 
> MAKE "a "green
> MAKE "x "a
> MAKE :x "blue
> PRINT :a
>   ==> blue
> 
> There's some validity to the way TCL does this, theoretically.
> Assignment isn't a special form, much unlike most languages.
> 
> Now, expr is ugly (with it's double parsing), and lists are ugly too
> (with their double scanning).  Those feel like kludges in TCL -- the
> assignment thing is actually fairly elegant (IMHO).  OTOH, I haven't
> actually ever chosen to program anything in TCL :-)  (Hmm... I guess
> this means that necessity sometimes *isn't* the mother of invention?)
> 
> However, this stuff shouldn't be a problem.  While I still haven't
> implemented much of TCL, this works fine already.



> TCL is meant to be interpreted, which is fine, because I'm
> interpreting it.  The magic is all in the partial evaluator (and it
> isn't even all that magical -- just rigorous).  The partial evaluator
> preserves semantics (for it to do anything else is a bug), so even
> after translation this stuff should work.  *However*, some TCL code
> could translate very poorly, leaving it essentially interpreted.  The
> same goes for byte-code compiling (I imagine they use something
> equivalent to partial evaluational, just not as rigorous).
> 

I am impressed with how much your translator manages to handle. Are
you willing/able to post code somewhere? Maybe I can try some of my
extra-hairy old tcl code from the bad old days and see how it does.

Another interesting problem is how to deal with the fact that arrays
are not first-class in tcl.

> For instance:
> 
> set input [read stdin 1]   # get user input
> set block "puts \"you answered "
> if {"$input" == "y"} {
>     append block "yes\""  # paste 'yes"' onto the end of block
> } else {
>     append block "no\""
> }
> while {true} $block
> 
> (if you enter "y", it prints out "you answered yes" forever,
> anything else prints "you answered no")
> 
> This is nearly uncompilable but is perfectly legal TCL.  Heck, maybe
> people even write like this :-)  It's actually reminiscent of
> first-class functions.  Nevertheless, it's why direct translation
> doesn't seem like it could work.
> 

Yes, there always needs to be an interpretive fallback for really
hairy cases, I imagine.

 - Maciej Stachowiak