clipka <ano### [at] anonymousorg> wrote:
> Am 08.10.2018 um 22:16 schrieb jr:
> >> I think Tk would "fit the bill" in many respects.
> >> Don't come anywhere /near/ the POV-Ray code with C++/Tk! ...
> > I'd love to know though what makes it "monsterous").
> The C++/Tk authors boast that their library pretty much preserves the
> syntax familiar from Tcl/Tk.
this is the first time I have seen "C++/Tk" juxtaposed.
afaik, the only thing (Tcl/)Tk and C++ have in common is the (approximate) year
of when development began; Tcl turned 30 last year.
> The Tcl syntax is /very/ different from common C/C++, and to achieve
> this feat they used some features of the C++ language in manners that
> would make every sane C++ programmer's skin crawl.
and it does not make sense (to me, at any rate). the whole "idea" is either of
two deployment scenarios:
a) you have some kind of interpreter/shell and provide applications as scripts,
perhaps supported by custom shared libs.
b) you integrate one or more interpreters in your own, usually C, code, and
provide part(s) of the application functionality as scripts (built-ins or user
there's literally no point[*] in the exercise you described.
[*] again, just me.
> C++/Tk is, in every sense, a joke takem too far.
it does sound a little .. perverted.
> I didn't even know C bindings for Tk existed; maybe they are more
> faithful to the target language.
it's how it (Tcl) started. as a C library to provide a "tool control language",
to drive other command-line apps. Tk was (so I read) an effort to build on
Apple's HyperCard concept(s) but constrained by need to be modular.
the introduction to the first edition of the "Tcl and the Tk Toolkit" book by
*the man* John Ousterhout (Addison-Wesley Publ.) makes excellent reading.
gives an ok outline.
> I'm not sure how Tcl as a component in a C program would look like.
> After all, last time I checked, Tcl is a language, not a library.
a really sharp language lawyer might argue it isn't even a language - as such,
more a set of (12) rules for parsing + substituting strings (EIAS =="everything
is a string"). Tcl has no reserved "keywords", any and all commands can be
renamed (or deleted).
(as an analogy, think of each Tcl command as a separate "program", each taking
one or more argument "words" and returning one result (perhaps empty))
as component of a C (or other compiled) application, it provides access to
scripting via one or more interpreters you create; and has "goodies"
(conveniences?), like easy hash tables etc.
Post a reply to this message