From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-03-31 09:16:18
----- Original Message -----
From: "Rene Rivera" <grafik666_at_[hidden]>
> > $(foo<$(bar),$(baz)>) - scary, but visually superior?
> > confusable with grist
> No, it's not much better, IMHO, than $(foo($(bar),$(baz)).
What I like about it is that the <>s stand out from the parens for me,
making it easier to parse (note that you dropped one above -- an easy
mistake to make).
> > $(foo:$(bar),$(baz)) - minimalist
> Hmmm, kind of like it :-\ Different than anything else.
But the pseudo-function-ness is a little harder (for me) to see in this
> > Regular Variables:
> > $(this-and-that) - they all look alike; locals may
> > collide with intended globals
> > Rule names:
> > tea-for-two - Haven't we met somewhere before?
> >I note that pseudo-function variables are pretty much always intended
> >globals, for what that's worth. I like working mostly with lower case
> >and dash separators, but maybe intended globals should use
> >Initial-uppercase or something. I note that class data members are
> >intended globals, though they are used much differently.. Perhaps
> >m_whatever makes sense. I'm definitely open to suggestions here.
> I've never liked using "_" unless it's a macro of some sort.
> I'm trying different syntax in the "doc" module I'm putting together,
> one I briefly mentioned in a previous conversation, and so far this is
> Pseudo-function variables (examples are my actual code):
To really get a sense of these, you have to look at them the way they
are /evaluated/ also:
Does the pseudo-function-ness of it seem to be hidden among all those
No need for "doc," is there, since everything is strictly local to the
(BTW, I'm still worried about having to invoke 3 separate rules to write
the docs for a rule or variable. Lots of times I'm lucky if I can think
of one way to say it, much less 3. Won't we end up with a patchwork of
brief, short, long comments?
Also, I hope there will be few or possibly no variables introduced by
the system, so we won't need user-level variable docs
> I'm also thinking the above might be rearranged like so:
Better, to my eyes, though the multi-argument case (rare) is a little
less great. Still, it works IMO:
Yeah, we're back to that. Used in that order, the dot makes more sense
to me. I'm not terribly convinced of anything yet...
Note that this arrangement is used in modules.jam:
return $($(module).__binding__) ;
> Regular variables, locals only; I'd rather stick to var-dash &
> They are the most numerous and that's the easiest to type.
> Regular variables, globals, or pseudo-globals; I really don't like
> "_". Capitalizing things seems contrary to the Jam norm,
??? Perforce caps all their rule names.
> and looks very out of
> place. All CAPS I strickly think of builtins, or environment vars when
> I kind of liked the gCAPS, except for the caps. But without the caps
> it's gcaps :-(. So an initial character to identify globals would be
> And the only one I can think that sorta fits is "*". For example:
> *doc,variables += $(var-name)
> $(help) in [ modules.peek : *doc,variables ]
> The above if they where global pseudo-function vars:
Hmm, I'm probably headed off in a dangerous direction here, but what
.my-global = list of things ;
do-something $(.my-global) ;
That has a nice consistency with the idea of "." as scoping operator (we
use a :: prefix to reach global scope in C++).
> Rule names; Thinking that it would be a pain to switch to anything
> what we already have. I'd stick with the "do-this-now" syntax.
Agreed. I don't want to change it.
> Given that:
> 1)the context for rules is rather different than vars, and 2) rule
> usually verbs and vars nouns; I don't think it conflicts. Maybe we
> a rule, :-), to make rule names always noun-like, and conversly vars
I guess you meant to make rules always verb-like. I don't always like
that: see sequence.length for example. I'd rather have no rule for the
time being, I guess.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk