Boost logo

Boost-Build :

From: Vladimir Prus (ghost_at_[hidden])
Date: 2005-01-26 10:03:25


On Wednesday 26 January 2005 15:27, Zbynek Winkler wrote:

> >It would be good to handle other symbols ( '[', ']', ':' ) in the similar
> > way,
>
> So currently any character can be a part of string as long as there are
> no spaces in it? Or what is the exact rule? I don't see it in the
> documentation :(. I think it should be as understandable as possible -
> so either go with "no special characters outside of nonquoted string"
> (like all the other languages I know) or leave it the way it is (and
> document it).

I see your opinion. I planned that ';' can be placed everywhere and be
considered a token by itself.

> >but unfortunately, they can appear inside variable accesses, for example:
> >
> > gFILES($(targets[1])) = fff ;
> >
> >During scanning, it's not easy to find if we're inside variable access or
> >not, so those symbols can't be safely handled.
>
> Unfortunatelly, I do not understand what the problem is here. Going with
> the least surprise behaviour I'd say that 'targets' is an array, we take
> item with index '1' and give that as a parametr to function call of
> 'gFILES', take its return value and assign 'fff' to it. But then it
> would be php and not jam and there would be no problem with the
> scanning... Is it just me or is the jam language "strange"?

The problem is we want to allow '[' without spaces the you can have

local a = [foo 10];
gFILES($(targets[1])) = fff ;

In the first line, we have rule invocation and '[' must be a separate token,
in the second line -- variable access and '[' is part of variable reference
and should not be a separate token. But during scanning we can't tell if
we're inside variable reference so we cannot do different things in the case
above.

> I am eagerly
> waiting for the python port... ;-)

;-)

- Volodya

 


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