This is the mail archive of the mailing list for the guile project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: TCL->Scheme writes:
> I've been working on a TCL to Scheme translator, and I have a few
> questions to throw out there.

I'm glad someone is working on this. Are you doing this specifically
for Guile, or trying to be portable to any RnRS Scheme?

> Is there anyone else actively working on translating languages to
> Scheme?

Someone fixed up the translator code from the lang package a while
back, I do not know if this has percolated into the CVS version yet.

> I've heard references to being able to use gdb to debug Scheme/Guile
> source.  Is this true?  Can someone point me to how I can do this?

There were Gdb patches available, as Jim mentioned a while ago, but I
am not sure they are up to date.

> I'm trying to figure out how to integrate TCL and Scheme code -- in
> some ways it seems hopeless.  However, that aside, maybe there's some
> ways to do some of these things:
> How can I convert a string to a variable.  E.g., if the TCL tries to
> call a variable "*some-variable*" how can I use that string to get the 
> value of *some-variable?

Approaches with varying degrees of cleverness/guile-specificity:

;; insert this code:
(eval (string->symbol "*some-variable*"))
;; however, this won't respect the local lexical scope.

(defmacro access-string-variable (var-string-name)
	(symbol->string var-string-name))

;; 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.

I'm sure there's got to be a way to do the version that can turn the string into a symbol

> 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'.

> Can anyone see possible solutions to the type problem -- i.e., that
> TCL has only one type (strings)?  I think this will be a general
> problem for translated languages, because the type system of one
> language won't translate one-to-one to the type system of Scheme.  If
> it is staticly typed you can munge your way around this, but most
> scripting languages aren't statically typed.
> The specific problem is that if a TCL program tries to call a Scheme
> program, how will it pass its arguments?  
> A TCL string can be a list:
> "1 2 {3 4}" -> '(1 2 "3 4"), or maybe '(1 2 (3 4))
> A number:
> "432.4e4"
> A channelId (a port):
> "file3"
> A block:
> "{puts hello ; puts world}"
> A variable reference:
> "x" as in "set x YYY"
> And, of course, a string.  There's probably a number of other things
> it can be as well, all depending on the context.  Even if some of
> these data types are not stored internally as strings, they are still
> essentially strings.  For instance this:
> string compare [list member1 member2] "member1 member2"
> Must be true (and all the more subtle ways of expressing the same
> thing).
> One possiblity, of course, is to make any callouts by the TCL program
> use special type-identifiers.  For instance:
> scheme:append [scheme:list "member1" "member2"] [scheme:list "member3"]
> It would be nice is there was something cleaner, though.  Maybe there
> isn't.

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.

> So, those are my questions.  Hopefully you all can help me out.  
> 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
>  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).

> (I don't know how they byte-compile
> TCL -- the language seems practically designed to make it hard to
> compile by convential means).

Tell me about it.

 - Maciej Stachowiak