Re: startup item generation

Well, if you shorten the question to "Why Tcl?" (entirely avoiding a 
comparative analysis of perl, which isn't something to get into), the 
short answer is:

I thought it was a good idea at the time. Ultimately, I chose Tcl for 
its syntax (Free Parser! See below ..)

The longer answer goes something like this.

Tcl provides certain advantages to writing a port system. When deciding 
on using it, I selected it for a few major advantages:
	1) Its syntax is incredibly versatile and extensible. Free parser!
	2) The C API is powerful and easy to use. Easy extension writing!
	3) It's a very straight-forward scripting language with an elegant 
grammar that is well suited for automating boring tasks. Building 
software is boring!

If I could pick any disadvantage, it would be this:
	* No pass by reference. Look at the dependency code. I think Kevin and 
myself are the only two humans on earth that understand it.

There are other disadvantages, of course. Every language has them. It's 
a little late to chose a new scripting language, though; we're much too 
dependent on Tcl through the entire infrastructure.

-landonf

On Jan 19, 2005, at 18:01, Salvatore Domenick Desiano wrote:

> Can I ask for a FAQ pointer on the issue of why we use Tcl rather than
> something like Perl? There are extensive writings on the differences
> between the two, and even the original writer of Tcl has retracted his
> ideas of what it is best for, so I'm curious (which, of course, is
> because I am about to have to learn tcl). -- Sal smile.
>
>
> On Wed, 19 Jan 2005, Toby Peterson wrote:
>
> o On 19 Jan 2005, at 19.39, Landon Fuller wrote:
> o
> o > Port groups provide a good example - changing the group code for
> o > python requires modifying base, whereas the group code should 
> really
> o > be modifiable by the port authors themselves.
> o
> o I agree. When I wrote the horribly hackish group code, I simply
> o couldn't reconcile Tcl's desire to evaluate *everything* with our
> o current "defaults" system. Certainly having something like the Mk/
> o directory on FreeBSD would be extremely useful, but port inheritance
> o needs to truly work properly. Specific problems include dealing with
> o overriding vs. appending/prepending to variants, pre-/post- 
> procedures,
> o etc... not to mention the defaults stuff.
> o
> o DarwinPorts does need some serious overhauling *soon*, before it 
> simply
> o collapses under the new features which are being added. Many of these
> o features are great additions, but it's important to keep an eye on 
> the
> o future.
> o
> o - Toby
> o
> o _______________________________________________
> o Darwinports mailing list
> o Darwinports <at> opendarwin.org
> o http://www.opendarwin.org/mailman/listinfo/darwinports
> o
> o
> o
>
> --------------
>   Salvatore Domenick Desiano
>     Research Scientist
>       NASA Ames Research Center (QSS Group, Inc.)
>