Tcls paradigms
skuh...@web.de
Some time ago I started a small thread here about the different
categories of programming paradigms listed on Wikipedia and in which
of them Tcl appears in the list. While I programm Tcl mostly in a
mixture of imperative and object-oriented style with some influences
by functional programming, I think my style is pretty narrowed to few
paradigms. But I'm very interested not only in programming itself but
also in thinking about programming in a more "philosophical" approach
(if you think, that's nuts, you should hear me talk about
biking... ;-). So yesterday I had a discussion with someone about what
type of language Tcl is...
It's clear, that by it's roots, Tcl is imperative, but I also read
somewhere (can't remember where), that Tcl is an "agnostic" language,
meaning, that it does not favour any paradigm over another and let's
the programmer the freedom of choice. I think, this fits very well and
may be a reason for it's beauty. But I wonder, if there are really
programmers out there, who really use the possibilities of Tcl
programming paradigm agnosticism. So here's the question: Does anyone
here use Tcl sometimes with other paradigms as imperative and OO
programming? What about functional programming in Tcl, or logical
(like Prolog), declarative, aspect-oriented or whatever? I'm
interested in what type of thinking can be done with Tcl, tell your
story!
FYI, what I'm referring to:
Programming Paradigms:
http://en.wikipedia.org/wiki/Programming_paradigm
Categorical list of programming languages
http://en.wikipedia.org/wiki/Categorical_list_of_programming_languages
Regards
Stephan
Jonathan Bromley
> I'm interested in what type of thinking can be done
> with Tcl, tell your story!
A very smart colleague, on being introduced to Tcl,
said to me "But it's just a big text-substitution
engine!". And indeed, there are some nifty things
that you can do with Tcl that depend on it acting
as the best-ever macro preprocessor.
I don't imagine that's the kind of story you
really wanted :-)
--
Jonathan Bromley, Consultant
DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan...@MYCOMPANY.com
http://www.MYCOMPANY.com
The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
skuh...@web.de
Jonathan Bromley wrote:
> A very smart colleague, on being introduced to Tcl,
> said to me "But it's just a big text-substitution
> engine!". And indeed, there are some nifty things
> that you can do with Tcl that depend on it acting
> as the best-ever macro preprocessor.
>
> I don't imagine that's the kind of story you
> really wanted :-)
Well, depends... Tcl really is a really powerful macro processor.
Maybe you heard of "Gödel, Escher, Bach" a famous book from Douglas
Hofstadter about... ahm... anything from programming, AI, mind, etc.
It contains some kind of "game" for explaining some concepts of the
book (self referencing, meta rules, formal systems and such), called
the "MU puzzle" (not sure, in the german version it's "MU-Rätsel"),
which is nothing more than a ruleset for recursive string-replacement
and the question, if a given start-word can be transferred into "MU".
Programming this in Tcl is just a few lines of code, so Tcl can be
used very good for the purposes of AI programming. But my question
was, who really uses Tcl for programming with different programming
paradigms other than the usual and how people can think with/in Tcl.
Thanks anyway, regards
Stephan
Larry W. Virden
> While I programm Tcl mostly in a
> mixture of imperative and object-oriented style with some influences
> by functional programming, I
>
> Does anyone
> here use Tcl sometimes with other paradigms as imperative and OO
> programming? What about functional programming in Tcl, or logical
> (like Prolog), declarative, aspect-oriented or whatever?
Have you browsed http://wiki.tcl.tk/ ? I see pages where people have
experimented with quite a variety of approaches. I recall a
presentation at one of the Tcl conferences (and I do hope that all of
comp.lang.tcl readers are planning on attending this year -
registration is open and operators are standing by...) by some work
being done on an extension for doing tcl functional programming.
skuh...@web.de
Yes, I read the wiki quite often. I found some of the stories about
functional programming in Tcl some time ago (and I implemented such
things as map, lambda, reduce and others just for fun in Tcl). But
that was only functional (haven't found other unusual approaches), and
looking at the wiki is not that "interactive" as getting stories here
in c.l.t...
> I see pages where people have
> experimented with quite a variety of approaches. I recall a
> presentation at one of the Tcl conferences (and I do hope that all of
> comp.lang.tcl readers are planning on attending this year -
> registration is open and operators are standing by...
I'd love to, but it's in the wrong country for me, even the continent
doesn't match... ;-)
> ) by some work
> being done on an extension for doing tcl functional programming.
Do you possibly have a link to a paper or site about that?
Regards
Stephan
Neil Madden
> Hello everybody
>
> Some time ago I started a small thread here about the different
> categories of programming paradigms listed on Wikipedia and in which
> of them Tcl appears in the list. While I programm Tcl mostly in a
> mixture of imperative and object-oriented style with some influences
> by functional programming, I think my style is pretty narrowed to few
> paradigms. But I'm very interested not only in programming itself but
> also in thinking about programming in a more "philosophical" approach
> (if you think, that's nuts, you should hear me talk about
> biking... ;-). So yesterday I had a discussion with someone about what
> type of language Tcl is...
I don't think that's nuts. Indeed, it sounds like a jolly good idea!
>
> It's clear, that by it's roots, Tcl is imperative, but I also read
> somewhere (can't remember where), that Tcl is an "agnostic" language,
> meaning, that it does not favour any paradigm over another and let's
> the programmer the freedom of choice. I think, this fits very well and
> may be a reason for it's beauty. But I wonder, if there are really
> programmers out there, who really use the possibilities of Tcl
> programming paradigm agnosticism. So here's the question: Does anyone
> here use Tcl sometimes with other paradigms as imperative and OO
> programming? What about functional programming in Tcl, or logical
> (like Prolog), declarative, aspect-oriented or whatever? I'm
> interested in what type of thinking can be done with Tcl, tell your
> story!
Well, I wouldn't call Tcl entirely agnostic. Tcl was conceived as a
"command language" which explains the imperative nature, and this is
still one of the best fits for the language -- sending commands to an
interactive application. On the other hand, Tcl is also very flexible. A
browse through the wiki would show a number of paradigms that Tcl can
support to some degree: OO, FP, concurrency, event-based, etc. There are
many other areas too. We could perhaps grade support for paradigms in
terms of what is possible (1), what is available (2), and what is
idiomatic (3, i.e., widely used and supported). Lots of programming
paradigms fall into category (1) for Tcl, several into category (2), and
a handful into category (3). The capabilities are there (especially in
8.5), but it takes quite a bit of polish to really support a paradigm well.
For instance, I currently use a language called Jason[1] for programming
complex behaviours for a multi-agent system. This is a logic programming
language in some respects similar to Prolog, but with support for
event-based programming, plans, interactivity, etc. Some program
fragments there are really particularly elegant. For instance, the
following plan:
+report(Event)[source(Agent)] :
focus(Team,Focus) &
matches(Focus,Event) &
role(Team,editor,Ed)
<-
!send_report(Ed,Event,Agent).
This plan handles the event created when a new report is received (sent
from another agent), and checks to see if we have a "focus" goal for
some team that matches the content of the report. If so, then we send
the report on to whatever agent is fulfilling the "editor" role for that
team. I find this style of programming incredibly clear and succinct. So
much work is taken care of: finding a combination of beliefs that
satisfy the plan (e.g., finding a matching focus goal), retrieving data
from a relational database via JDBC (some of the beliefs are persistent
and held on a separate database server), implementing high-level
communication protocols, annotating facts with meta-data about their
origin and other properties, etc. Undoubtedly you could do all this with
Tcl, but it would take quite a bit of work to reach that stage.
On the other hand, when I wanted to publish reports to a weblog via Atom
Publishing Protocol, I had to drop down to Java and hand-code all that,
whereas in Tcl I could just [package require tdom] and used the http
package to knock up a solution in a few hours.
So, yes, Tcl supports lots of paradigms to varying degrees. For some of
these, like OO, we can point to some really top-notch production quality
implementations (like XOTcl). For others, like functional programming,
we can point to pretty decent implementations of much of the basics on
the wiki and in Tcllib. For others still, like logic programming or
constraint programming, there are some bits and bobs but nothing I'd
really feel confident recommending to somebody as a tried and tested
solution.
[1] http://jason.sourceforge.net/
-- Neil
Gerald W. Lester
> Larry W. Virden wrote:
>> Have you browsed http://wiki.tcl.tk/ ?
>
> Yes, I read the wiki quite often. I found some of the stories about
> functional programming in Tcl some time ago (and I implemented such
> things as map, lambda, reduce and others just for fun in Tcl). But
> that was only functional (haven't found other unusual approaches), and
> looking at the wiki is not that "interactive" as getting stories here
> in c.l.t...
>
>> I see pages where people have
>> experimented with quite a variety of approaches. I recall a
>> presentation at one of the Tcl conferences (and I do hope that all of
>> comp.lang.tcl readers are planning on attending this year -
>> registration is open and operators are standing by...
>
> I'd love to, but it's in the wrong country for me, even the continent
> doesn't match... ;-)
Take a plane or even a boat -- but do come.
--
+--------------------------------+---------------------------------------+
| Gerald W. Lester |
|"The man who fights for his ideals is the man who is alive." - Cervantes|
+------------------------------------------------------------------------+
skuh...@web.de
Neil Madden wrote:
> Well, I wouldn't call Tcl entirely agnostic. Tcl was conceived as a
> "command language" which explains the imperative nature, and this is
> still one of the best fits for the language -- sending commands to an
> interactive application.
True. When I started using Tcl, I used to programm assembler only. I
tried to learn BASIC and C years before, but hated both of them. Then
found 68k Assembler in my beloved Amiga and did nothing else for years
- to hell with function calls and variable declaration, if you have
setable programm-counter and direct register access!). So Tcl was my
first higher-level-language (needed to find one, because only a few of
the SUNs at university still had 68k-CPUs, the new ones all came with
sparkling SPARCs, which is not that much fun to programm...) and I
"got it" immediately, although the first time I thought of Tcl as a
kind of assembler-like language: one line, one command + args all
written in a tabular form line after line (seldom used higher level
constructs and produced pretty much of what is called "spaghetti-
code", which is misleading, since spaghetties don't get that long). So
this is another paradigm for Tcl: assembly language alike... ;-)
I think "agnostic" was used in a sense of making it possible to use
various paradigms without preferring one or forcing the programmer to
a specific kind of thinking. This is how I often see Tcl today. Since
my assembly language times (still missing them sometimes) I found
several ways of thinking about something and always found in Tcl a
flexible and friendly language for that. One of the reasons for that
is the simple structure, which allows one to implement the language
you need first and then use that to solve the problem.
Here's another "paradigm" for Tcl that I'm thinking about for some
years now (but lacking the time to fully implement it, it's still a
bunch of ideas, to do file and partial prove of concept
implementations of commands and such, but someday... ;-) : Using Tcl
as a modeling language for 3D scenes. My ideas are inspired by Tk, for
example creating objects creates new commands, for manipulating the
objects or hierarchies of objects as widget-hierarchies in Tk for
animation, or "-command" and (physics-)events for objects so you can
do simulations with it. Writing scenes in Tcl look really good and
naturally, I tried the same idea with Python, but it didn't match...
> On the other hand, Tcl is also very flexible. A
> browse through the wiki would show a number of paradigms that Tcl can
> support to some degree: OO, FP, concurrency, event-based, etc. There are
> many other areas too. We could perhaps grade support for paradigms in
> terms of what is possible (1), what is available (2), and what is
> idiomatic (3, i.e., widely used and supported). Lots of programming
> paradigms fall into category (1) for Tcl,
That was my main argument here (and in the discussion mentioned in the
first posting) and the base question: not only, what can be done, but
what *is* *actually* done by people with Tcl?
> several into category (2), and
> a handful into category (3). The capabilities are there (especially in
> 8.5), but it takes quite a bit of polish to really support a paradigm well.
Your example with Jason shows this quite good:
...
> communication protocols, annotating facts with meta-data about their
> origin and other properties, etc. Undoubtedly you could do all this with
> Tcl, but it would take quite a bit of work to reach that stage.
True, but Tcl is very good at creating a domain specific language
first and then use that language to look at the given problem in a
more natural way. To have all the supporting libraries at hand is one
thing, which may need much work, so you won't do it in Tcl, because of
all the missing ground work. But the other thing is, if you can use
Tcl directly or by modifying/extending it (which is pretty easy, since
we have no keywords, and syntax is very flexible) to express your
thoughts (and solutions) about a problem in a comfortable and natural
way.
> So, yes, Tcl supports lots of paradigms to varying degrees. For some of
> these, like OO, we can point to some really top-notch production quality
> implementations (like XOTcl). For others, like functional programming,
> we can point to pretty decent implementations of much of the basics on
> the wiki and in Tcllib. For others still, like logic programming or
> constraint programming, there are some bits and bobs but nothing I'd
> really feel confident recommending to somebody as a tried and tested
> solution.
Certainly not, but I'm interested in everything, that is tried or done
by people.
> [1] http://jason.sourceforge.net/
Maybe worth a look, although it's not really my area of programming.
Regards
Stephan
Uwe Klein
> Here's another "paradigm" for Tcl that I'm thinking about for some
> years now (but lacking the time to fully implement it, it's still a
> bunch of ideas, to do file and partial prove of concept
> implementations of commands and such, but someday... ;-) : Using Tcl
> as a modeling language for 3D scenes. My ideas are inspired by Tk, for
> example creating objects creates new commands, for manipulating the
> objects or hierarchies of objects as widget-hierarchies in Tk for
> animation, or "-command" and (physics-)events for objects so you can
> do simulations with it. Writing scenes in Tcl look really good and
> naturally, I tried the same idea with Python, but it didn't match...
Not 3D but afaik Abuse used that concept ( via some Lisp variant)
http://en.wikipedia.org/wiki/Abuse_(computer_game)
uwe
skuh...@web.de
Uwe Klein wrote:
> Not 3D but afaik Abuse used that concept ( via some Lisp variant)
> http://en.wikipedia.org/wiki/Abuse_(computer_game)
Thanks, I heard of Abuse before, but never looked at it. From the
article I understand that the language is used a extension language,
that's not really what I mean. For a very primitive example of what I
mean you can think of the input language of PoVRay or better MEL, the
scripting interface of Maya.
Regards
Stephan
Uwe Klein
I have looked at abuse as contained in the LiveCD from SuSE November 1995 ;-)
It is pure lisp.
i.e. you seem to have some extra functions that pertain to the gamemechanics
and fx
the rest is lisp.
want a copy?
>
> Regards
> Stephan
>
uwe