Sabrina Kilian <ykg### [at] vtedu> wrote:

> > "Charles C" <nomail@nomail> wrote:
>My worry would be about files that are expecting to see a global variable by >one
name and get the prefixed version in
stead.
>
> nemesis wrote:
> > but the alias is given by the user of the include file in his own file.  So,
> > the prefix is necessary and he is well aware of it, since it was him who
> > named it in the first place.
> >

>
> Everything in just bike.inc is prefixed with nem. If bike.inc includes
> another file, are those prefixed or not? If not, we run the risk of name
> overlap again because those items are probably going to be less likely
> to be checked. If they are, how will bike.inc know what variable names
> to call?
>
> Will #as tags stack like namespaces, or when a new one is created is the
> last one automatically closed?

Yes this is what I meant.  I was just trying to say includes called from
within includes would need to inherit the prefixes all the way down. That
way, they'll all be expecting to see variables that match.  The only issue
I see is for example things like #ifndef(something) #include
"something.inc" #end might tend to duplicate things in memory.

Post a reply to this message

"Charles C" <nomail@nomail> wrote:

> Yes this is what I meant.  I was just trying to say includes called from
> within includes would need to inherit the prefixes all the way down.

In my "#declare whose" model above, I didn't address includes calling other
includes.

I've been thinking about how folks would actually be using includes.  Naming
conflicts will occur.  But, I don't think we need to make them idiot-proof,
just manageable.  This is the possibility I imagine:

Think of each include file as a locked room.  On the door of that room is a
sign that tells you what key you need to get in ( whose ).  It tells you
what's in the room ( Manifest ).  It tells you what rooms it leads to (
Dependencies ).

If you are already in possesion of an item with the same name as something
on the 'Manifest' and you don't want to loose it, then declare it as
something else before you go in.  While you're at it, check the 'Manifests'
of the 'Dependencies' as well, renaming anything you have that you might
need to protect.

Then, make the key (#declare whose = "the_key") and enter (#include
"the_room.inc").  Once you're in the room your key might change (an include
file including another).  But, that doesn't matter.  You're already in the
room and you don't need any key to get out.

-Randall

Post a reply to this message

Okay, I'll admit that the "#declare whose" idea was a bit silly.  And I'll
admit that some of my ideas are made of cork.  But, I've just been getting
them out there so that we can all find the one made of tungsten.

This one might be just in that direction:

As long as we're asking the parser to rename macros and declares at the
front end (e.g. #include ... #as), couldn't we just ask the parser to
rename them for us in the Backend.  And to do so in a way that none of us
possibly could with our keyboards?  There are ascii values that are
unavailable to us when we name macros; but, couldn't we make them available
to the parser?  This is what I have in mind:

Okay, let's say there are a few includes you want to use in your scene.
Let's call these "first-level includes."  You're familiar with them already
or you wouldn't be using them.  So, you're obviously going to be able to
avoid naming conflicts from items in those particular includes.

Now, assume that one or more of them also call includes.  Let's call them
"second level."  And, some of those includes might call still more - "third
level" - and so on.  That's where you might run into a naming issue.  Who
wants to have to read all those other files?

So, what if the parser could keep track of its 'include depth' and its
'include count' and then give it a renaming algorithm so that every macro
or declare 'call' in the first level and every macro or declare
'declaration' in the second level is altered identically - using
parser-only characters.  Once in the second level each call is altered
uniformly and identically to each declaration at the third level and so on.

I realize that the #ifndef() at the front of each include may interfere with
this strategy.  (User includes "A.inc" and "B.inc" and "A.inc" includes
"B.inc".  Parser thinks "already been there" and doesn't give you what
"B.inc" has to offer you.)  That needs to be addressed.

Admittedly, the parser is a black-box phenomenon to me.  I have not looked
at its source.  So, I have a question:  Could this method result in strings
of redundant macro code called by different names taking up too much memory?
 If so, would a sort of staging area of compilation be appropriate upon
exiting an include whenever it is one that has called includes itself?

Well, that's the best I've got for now.

-Randall

Post a reply to this message

"Randall Sawyer" <sra### [at] yahoocom> wrote:
> But, I've just been getting
> them out there so that we can all find the one made of tungsten.

That's the whole point of this thread.  And indeed perhaps none of them is
actually made of tungsten, but if we mix them in an alchemists way, we may
eventually get gold. :)

> some of those includes might call still more - "third
> level" - and so on.  That's where you might run into a naming issue.  Who
> wants to have to read all those other files?

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.  And
it really doesn't seem much difficult to make the parser handle it that way
and aliases.

> I realize that the #ifndef() at the front of each include may interfere with
> this strategy.  (User includes "A.inc" and "B.inc" and "A.inc" includes
> "B.inc".

I believe such metaprogramming #ifdefs and whatnot should be in charge of
the parser, not the user.  If includes are local, there should be no need
for them.

Post a reply to this message

"nemesis" <nam### [at] gmailcom> wrote:
> "Randall Sawyer" <sra### [at] yahoocom> wrote:
> > But, I've just been getting
> > them out there so that we can all find the one made of tungsten.
>
> That's the whole point of this thread.  And indeed perhaps none of them is
> actually made of tungsten, but if we mix them in an alchemists way, we may
> eventually get gold. :)
>
> > some of those includes might call still more - "third
> > level" - and so on.  That's where you might run into a naming issue.  Who
> > wants to have to read all those other files?
>
> 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.  And
> it really doesn't seem much difficult to make the parser handle it that way
> and aliases.
>
> > I realize that the #ifndef() at the front of each include may interfere with
> > this strategy.  (User includes "A.inc" and "B.inc" and "A.inc" includes
> > "B.inc".
>
> I believe such metaprogramming #ifdefs and whatnot should be in charge of
> the parser, not the user.  If includes are local, there should be no need
> for them.

If you want the #declare of a sub-include to have local-status of a
current-level include, then that seems like it'd work just as long as the
#declare was meant to be used at a one-up level (one-up from the
sub-include).  I've got a lot of stuff which I think this system would
break.  It's seems hard to come up with a system that won't break
something.

How about different namespaces plain & simple, but with two additions:  The
ability to define a global namespace, and the ability to combine
namespaces. If multiple namespaces are activated at once via a command
#namespace(Jake,Sam) the parser should automatically give an error if there
are conflicts.  New #declares that are created when multiple non-global
namespaces are active will remain accessible to the individual namespaces.

#namespace (global) //brings scope up to global namespace only (default)
#include "colors.inc"

#namespace (Jake) //namespace Jake is defined and activated.
//global namespace is still accessible and therefore had better not conflict
with Jake.
#include "jakes_objects.inc"

#namespace (global) //brings scope up to global namespace only

#ifdef(jakes_doorknob)
    #debug "huh? jakes_doorknob shouldn't be accessible now."
#end

#namespace (Jake) //switch back to jake's namespace as remembered by parser

#object{ jakes_doorknob pigment{White}  }

Post a reply to this message

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

"Charles C" <nomail@nomail> wrote:
> If you want the #declare of a sub-include to have local-status of a
> current-level include, then that seems like it'd work just as long as the
> #declare was meant to be used at a one-up level (one-up from the
> sub-include).  I've got a lot of stuff which I think this system would
> break.  It's seems hard to come up with a system that won't break
> something.

Yes, i can think of a clear example:  global includes which are just meant
to include other files to files including it, like:

/* scene.pov */

#include "main.pov"
....

/* main.inc */

#include "foo.inc"
#include "bar.inc"
....


No big deal.  Just #include them without #as and the original #include
behaviour should be the same.  So:

#include "foo.inc"

makes all declared foo items available to whomever includes the current
file, while:

#include "foo.inc" #as foo

makes declared foo items local to this file and prefixed with the foo alias.

I took the as syntax from the python programming language imports, which are
java's one better. :)

I have a little problem with the "namespace" term:  what does it mean to
someone who's not a programmer?  Anyone can understand "include", not so
with "namespace".  is it edible? :)

What to do?  what to do?  overload #include to handle more meanings?  add
yet more specialized syntax?  The former is C++ way, while the latter is
the Perl way and seeing how POV-Team members are knowledgeable in both, i
can't see what the future reserves... :)

Anyway, nice to see real efforts to bring the SDL a step further in design.
I hope the POV-Team pick some of our best efforts and give it a thought and
a spin.

Post a reply to this message

"Randall Sawyer" <sra### [at] yahoocom> wrote:
> I hope I've shed some light on my line of thought.  BTW: I started reading
> the source code last night.

I would like to continue to clarify the naming model I am suggesting with
some vocabulary.  This is my own vocabulary.  If my idea has already been
implemented in some other application, and there is a pre-existing
vocabulary, then I would like to know that.



I am now thinking of files (include and renderable files both) in terms of
"spaces."

"Declaration Space":
The set of declares and macros defined in an include file.

"Implementation Space":
The set of code snippits which make use of any and all declares and/or
macros from a given include file.  (Note:  A file which calls more than one
include will have the same number of "implementation spaces".)


I am thinking of the set of named macros and declares - defined in an
include file - and those same macros and declares - implemented in a file
which calls that include file - in terms of a "membrane."

"Namespace Membrane":
A virtual structure implied by a single line in a file beginning with the
directive "#include ".  On one side of the 'Namespace Membrane' is the
'Declaration Space' of the called include file.  On the other side of the
same membrane is the 'Implementation Space' of the file containing the
'#include directive'.



I am thinking of the set of files (one renderable file, its includes, those
includes' includes, and so on) in terms of a tree - along the lines of a
'directory tree'.  At the bottom is the renderable file - the single trunk
of the tree.  Includes called by the renderable file are 'lower' and
includes called by other includes are 'upper' (as in branches).

"Upper Namespace Membrane":
Each include file has an 'Implementation Space' for each include file it
calls - thus implying the same number of 'namespace membranes'.  (This
number may be zero (0) or positive.)  Lets call each of these an "Upper
Namespace Membrane".

"Lower Namespace Membrane":
Every include file has exactly one "Lower Namespace Membrane".  It is
implied each time the include file is '#include'd by another file.

[Note:  The same include file may be called more than once in the same tree.
 However, after being altered by the parser to avoid naming collisions, it
will have been transformed into a number of unique manifestations.]



An important rule to note:
In the model I propose, names are prevented from migrating from an 'upper
namespace membrane' to a 'lower namespace membrane' by virtue of the
parser's treatment of the file tree.  Therefore, if your renderable file
'#include's "A.inc" - and - file "A.inc" '#include's "B.inc", then you
would not be able to access the 'declaration space' of "B.inc" unless your
file also includes "B.inc".


I hope this glorious mish-mash of metaphors is somewhat helpful in
communicating my vision.  Next, I think I'll tinker with a C++ mock-up.
But, please stop me from just spinning my wheels if it turns out that's all
that I'm doing.


Thanks,
Randall

Post a reply to this message

I've had a look through this thread and there are a lot of ideas there. 
There certainly seem to be some consistent themes emerging but before trying 
to summarize them I'd like to clarify one point.

One large part of the thread discusses the potential to implement name 
spaces in the POV-Ray parser and there are a couple of other ideas to 
address naming conflicts and other issues that would require parser changes.

This seems great to me for the future, but it seems that if parser changes 
are introduced then people are likely to take a while to get used to them 
and start to develop techniques around them. Some time after that we would 
be well positioned to discuss how to use them to implement standards.

I don't dispute that it would be good to anticipate such potential future 
parser changes and build our current standards in a way that might be 
compatible with them, but it seems to me that to get this collection off the 
ground in the near future we'd be well advised to implement standards that 
we're able to adhere to with existing versions of POV-Ray.

Would everyone be ok to limit the 'standards' discussion to existing, well 
established features for now. This would also enable a greater number of 
people to use the collection from the outset, without forcing everyone to 
upgrade the moment the new version is released.

Regards,
Chris B.

Post a reply to this message

"Chris B" <c_b### [at] btconnectcomnospam> wrote:
> Would everyone be ok to limit the 'standards' discussion to existing, well
> established features for now.

yeah, sure.  Let's get back down to Earth and get the wheel moving! :)

Post a reply to this message