From: "nemesis"
> No one wants naming conflicts:  they are bad, very bad.  That's why i
> proposed having included items being local to the file including them.

That's what I was getting at - "local to the file."

I've been thinking "Who uses POVRay?" and "What is POVRay script?"
At this time, my answers are:
    "POVRay users are individuals with active visual imaginations who want
to share their visions with the world - whether it be artistic, scientific
or mathematical."
and:
    "POVRay script is a descriptive language, functionally equivalent to
HTML.  The ability for users to define functions and macros and pre-defined
objects are meant as a convenience.  These features enable a user to produce
variations on a theme.  They also enable the graphical analog to the DJ's
craft of recording original mixes of sampled prior works."

Although the added functionality of POVRay makes it seem like a programming
language, let's not treat it as such.  I recently downloaded TrollTech's QT
4.2 C++ library.  They have a slogan: "Code less. Create more."  I like
that ethic.  Good software - whether its for publishing, software
development or ray-tracing - is designed to meet the needs of its end-user.

It's along these lines I've been thinking.  A lot of ideas in this threads
have been pointing in the direction of giving the user the ability to
manage naming conflicts themselves.  But, what if the user doesn't want the
added responsibility.  Then s/he might have a disincentive to use the new
extended includes library.  Then the library is actually not going to be of
value to them.

So then I thought, what if we turn the direction of namespace management
responsibility around 180 degrees?  What if you made it so that the names
of macros and declares written in the past were not allowed to conflict
with those of the future, while putting very little restriction on present
naming provided by the user.  What I came up with is described in my last
posting.

Here are a few more details:

1) When a user defines a macro or a declare, s/he is limited to the
characters "0-9", "_", "a-z", "A-Z".  That's only 63 out of 255 ascii
values.

2) Let's let the parser make use of the remainning ascii values to
internally rewrite includes, editting each 'declaration' and corresponding
'call' identically.  A set of special characters "{(<,.#*>})..." will
most-likely have to be off-limits to the parser as well.  I'm thinking
ascii 128-255 is free. (I am unfamiliar with the numbers for users who use
character codes other than ascii.  But, I suspect the priciple will still
hold
true.)

3) By giving this unused subset of characters to the parser and an algorithm
with which to use it, the parser is essentially rewriting the past, renaming
macros and declares in a way that no user possibly could in the present.
This renaming occurs only once the includes are in the buffer.  No include
files would actually be rewritten.

I hope I've shed some light on my line of thought.  BTW: I started reading
the source code last night.

-Randall

Post a reply to this message