This is another off-shoot from a previous thread.

Currently, authors of POV-Ray files manage naming collisions themselves.
They know the identifiers declared in their include files as well as the
ones they write themselves.  Let's not try to fix what isn't broken.

What if an author wants to include a file which also includes still more
files?  In that case - as POV-Ray exists now - unforseen naming conflicts
may occur.  To address this issue, I propose the following concept:

Modify the parser in such a way that it assembles each include file as it
goes.  Then, whatever identifiers were used to create the include file in
the first place are available for reuse in any file which '#include's that
include:

    /-----------  B1 Names   /-----------
    |  B1.inc  | ==========> |          |
    -----------/             |          |  A1 Names   /---------------
                             |  A1.inc  | ==========> | My_File.pov  |
    /-----------  B2 Names   |          |             |  (or .inc)   |
    |  B2.inc  | ==========> |          |             |{I cannot use |
    -----------/             -----------/             |names used in |
                                                      |B1.inc or used|
                             /-----------  A2 Names   |in B2.inc.}   |
                             |  A2.inc  | ==========> |              |
                             -----------/             ---------------/
    is transformed into:

    /-----------  A1 Names   /---------------
    |  A1.inc  | ==========> | My_File.pov  |
    -----------/             |  (or .inc)   |
                             |{Now I can use|
    /-----------  A2 Names   |names used in |
    |  A2.inc  | ==========> |B1.inc or used|
    -----------/             |in B2.inc.}   |
                             ---------------/

I am uncertain as to the best means for implementing this idea.  I have
already suggested one possibility though:

One way is to retroactively rename all of the identifier declarations in
B1.inc and B2.inc and all of their corresponding implementations in A1.inc
uniformly.  Renamimg the identifiers would be done by the parser once the
files are loaded into the buffer.  The parser would append each identifier
string using character values that no user could with a keyboard (ascii
128-255).

I would appreciate some feedback.

-Randall

Post a reply to this message

Opps! :D
This thread title is meant to be titled "WHY Not Make Naming Conflicts
Disappear?"
-Randall

Post a reply to this message

"Randall Sawyer" <sra### [at] yahoocom> wrote:
> Currently, authors of POV-Ray files manage naming collisions themselves.
> They know the identifiers declared in their include files as well as the
> ones they write themselves.  Let's not try to fix what isn't broken.

ok.

> Modify the parser in such a way that it assembles each include file as it
> goes.

Sounds a lot like prefixing each declare in the include with a unique
identifier, perhaps chosen by us. ;)

> I cannot use names used in B1.inc or used in B2.inc.

You could use them freely if they were local to the files including them. ;)

Ok, now reasoning with your suggestion further, say i can now use the same
identifier declared in B1.inc for another object/texture/whatever.  Great,
all fine and dandy.  Now, what if i also want to use the original B1.inc
declared object under that identifier?  How do i do that if the parser
mangled the name with some random string which i don't know of (automatic
naming collision management)?

That's not a problem with aliases i get to choose myself.  Sometimes,
explicit is better than implicit...

this discussion should probably be better off under the Standards thread...

Post a reply to this message

nemesis - Thank you for your prompt response.

From: nemesis
> Sounds a lot like prefixing each declare in the include with a unique
> identifier, perhaps chosen by us. ;)

Actually, I saw the prefixing as extra work for the author.  I thought it
could be avoided.

From: nemesis
> > I cannot use names used in B1.inc or used in B2.inc.
>
> You could use them freely if they were local to the files including them. ;)

That's the whole point: Have the names declared in an include be local ONLY
to the file that '#include'd it.

From: nemesis
> Now, what if i also want to use the original B1.inc
> declared object under that identifier?

Then, your file would also contain the line: '#include "B1.inc" '
From the perspective of your file then, B1.inc is parallel to A1.inc and
A2.inc.  In that context, you - the author - are responsible for managing
naming - just as the author of A1.inc was.

Once again from the perspective of your file:
"B1.inc", as it is implemented in "A1.inc" is invisible to you.  You only
need to concern yourself with the contents of "B1.inc" if you include it
directly.

> this discussion should probably be better off under the Standards thread...

Our topics under that thread have evolved.  Ben Chambers set up camp at
"Warn About Naming Conflicts?"  I set up this post because I feel that my
idea is divergent enough from the original discussion, that it meritted its
own position.  Besides, I was getting no response at the previous site.

I have no attachment as to the outcome of these discussions.  I would like
to see a solution that makes the POV-Ray experience as enjoyable for
everyone as possible.  And, I would like to increase my understanding of
namespace management.

-Randall

Post a reply to this message

In article <web.4577238990cd3dbce81faf070@news.povray.org>, 
sra### [at] yahoocom says...
> This is another off-shoot from a previous thread.
> 
> Currently, authors of POV-Ray files manage naming collisions themselves.
> They know the identifiers declared in their include files as well as the
> ones they write themselves.  Let's not try to fix what isn't broken.
> 
> What if an author wants to include a file which also includes still more
> files?  In that case - as POV-Ray exists now - unforseen naming conflicts
> may occur.  To address this issue, I propose the following concept:
> 
> Modify the parser in such a way that it assembles each include file as it
> goes.  Then, whatever identifiers were used to create the include file in
> the first place are available for reuse in any file which '#include's tha
t
> include:
> 
>     /-----------  B1 Names   /-----------
>     |  B1.inc  | ==========> |          |
>     -----------/             |          |  A1 Names   /---------------
>                              |  A1.inc  | ==========>
 | My_File.pov  |
>     /-----------  B2 Names   |          |             |  (or .inc)   |
>     |  B2.inc  | ==========> |          |            
 |{I cannot use |
>     -----------/             -----------/             |names used in |
>                                                       |B1.inc or used|
>                              /-----------  A2 Names   |in B2.inc.}   |
>                              |  A2.inc  | ==========>
 |              |
>                              -----------/             ---------------/
>     is transformed into:
> 
>     /-----------  A1 Names   /---------------
>     |  A1.inc  | ==========> | My_File.pov  |
>     -----------/             |  (or .inc)   |
>                              |{Now I can use|
>     /-----------  A2 Names   |names used in |
>     |  A2.inc  | ==========> |B1.inc or used|
>     -----------/             |in B2.inc.}   |
>                              ---------------/
> 
> I am uncertain as to the best means for implementing this idea.  I have
> already suggested one possibility though:
> 
> One way is to retroactively rename all of the identifier declarations in
> B1.inc and B2.inc and all of their corresponding implementations in A1.in
c
> uniformly.  Renamimg the identifiers would be done by the parser once the
> files are loaded into the buffer.  The parser would append each identifie
r
> string using character values that no user could with a keyboard (ascii
> 128-255).
> 
> I would appreciate some feedback.
> 
> -Randall
> 
Actually, the thing that would make the most sense would be to use 
something like procedure "scope". Each include can refer "directly" to 
it own names, but anything deeper needs to be "explicit" about what is 
used. Lets say you have:

fred.inc>
  #define abc blah1

jed.inc>
  #include fred.inc
  #define abd blah2

sed.pov>
  #include jed.inc
  #define abc blah3

Sed would need to "explicitly" ask for jed.fred.abc to use it.
Jed needs to "explicitly" ask for fred.abc.

The problem is, this "breaks" current implementation. Now, that doesn't 
mean you couldn't write a failure simply recursive system to "find and 
fix" such references, or even eventually design the editor to 
"recognize" them and automatically give you MS Studio style recall, like 
typing "jed." and having a pop-up list of thing "in" jed.inc, including 
fred.jed.<blah>. In other words, its not trivial, but hardly impossible 
to write a function like "Convert this scene and its includes to new 
naming system", and automatically fix all of it, saving the new files 
under slightly different names, to preserve the originals.

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
 
3D Content, and 3D Software at DAZ3D!</A>

Post a reply to this message

Patrick - Thank you for your response

Patrick wrote:
> The problem is, this "breaks" current implementation. Now, that doesn't
> mean you couldn't write a failure simply recursive system to "find and
> fix" such references, or even eventually design the editor to
> "recognize" them and automatically give you MS Studio style recall, like
> typing "jed." and having a pop-up list of thing "in" jed.inc, including
> fred.jed.<blah>.

I had been thinking along these lines before.  However, once I started
asking myself the rhetorical question "What is POV-Ray?", I realized that
the word "editor" does not appear in the answer.  POV-Ray - as it exists
now - does not require the use of a specific editor.  To add that
requirement to its use would make it more costly and less accessible.

> In other words, its not trivial, but hardly impossible
> to write a function like "Convert this scene and its includes to new
> naming system", and automatically fix all of it, saving the new files
> under slightly different names, to preserve the originals.

What I am proposing would actually rewrite the deeper includes (those called
by other includes).  The rewriting would occur in the buffer - not in the
files themselves, thus protecting the contents of the original includes.
The rewriting would follow a fail-safe algorithm, applied the same way onto
every includes-tree.  There would be no need to "ask" to reuse an identifier
from a deeper include.

-Randall

Post a reply to this message

Randall Sawyer wrote:
> nemesis - Thank you for your prompt response.
> 
> From: nemesis
>> Sounds a lot like prefixing each declare in the include with a unique
>> identifier, perhaps chosen by us. ;)
> 
> Actually, I saw the prefixing as extra work for the author.  I thought it
> could be avoided.
> 

Why extra work for the author? If the library/include is prefixed, the
author of any given scene doesn't need to prefix their work. It would be
extra work for the library maintainers, however. A simple perl script
should be able to locate any variables #declared in separate files. I
don't know perl too well, but I'll see if I can cook up something anyways.

> From: nemesis
>>> I cannot use names used in B1.inc or used in B2.inc.
>> You could use them freely if they were local to the files including them. ;)
> 
> That's the whole point: Have the names declared in an include be local ONLY
> to the file that '#include'd it.
> 

If you mean local in the same sense as the #local command, what happens
with collection includes like stones and shapes.inc? Making the user
include each subfile just to have access to it seems like a good way to
increase parse time and annoy the user.

>> this discussion should probably be better off under the Standards thread...
> 
> Our topics under that thread have evolved.  Ben Chambers set up camp at
> "Warn About Naming Conflicts?"  I set up this post because I feel that my
> idea is divergent enough from the original discussion, that it meritted its
> own position.  Besides, I was getting no response at the previous site.
> 
> I have no attachment as to the outcome of these discussions.  I would like
> to see a solution that makes the POV-Ray experience as enjoyable for
> everyone as possible.  And, I would like to increase my understanding of
> namespace management.
> 
> -Randall
> 
> 
> 
> 

This isn't really limited to the library project but POV in general.
Let's see where the conversation leads.

Post a reply to this message

Sabrina - Thank you for your response

Sabrina Kilian <ykg### [at] vtedu> wrote:
> Why extra work for the author? If the library/include is prefixed, the
> author of any given scene doesn't need to prefix their work. It would be
> extra work for the library maintainers, however. A simple perl script
> should be able to locate any variables #declared in separate files. I
> don't know perl too well, but I'll see if I can cook up something anyways.

I am not addressing file names here - just their contents - the '#macro's
and '#declare's you want to import to your scene.

> If you mean local in the same sense as the #local command, what happens
> with collection includes like stones and shapes.inc? Making the user
> include each subfile just to have access to it seems like a good way to
> increase parse time and annoy the user.

By 'local' I mean the local interface between a top-level file - be it a
scene or another include file - and the set of files it immediately
'#include's.

The visual/tactile metaphor I have in mind is a 'membrane'.  On the input
side of the membrane is the 'declaration space' of a file's include files.
The 'declaration space' is the set of objects and such defined by "#macro
foo() ..." and "#declare bar = ...". On the output side of the membrane is
the 'implementation space' of the file the author writes - be it another
include or a scene.  The 'implementation space' is the set of code snippits
that make use of aforementioned 'foo' and 'bar'.

A given collection of 'foo's and 'bar's is what I think of as the 'membrane
namespace.'  In the model I propose, a namespace would be 'local' to a
membrane.

A scene file has only an 'input membrane' (assuming it includes other
files).  A raw-code-written include file has only an 'output membrane'.  An
include file which '#include's other files has both an 'input membrane' and
an 'output membrane'.  In the model I propose, declaratives would be
prevented from migrating from an include file's input membrane to its
output membrane.

> This isn't really limited to the library project but POV in general.

Yes, exactly.  One of the questions I asked myself is "How do you accomodate
a large includes library without dramatically changing the way people use
POV-Ray?"

> Let's see where the conversation leads.

Yes, I am curious too.

-Randall

Post a reply to this message

Sabrina, I just realized that I failed to respond to one of your concerns in
my last post.

Sabrina Kilian wrote:
> Making the user
> include each subfile just to have access to it seems like a good way to
> increase parse time and annoy the user.

I have given this some consideration.

First of all, will it actually be a common occurence that a POV-Ray author
will want to include both an include file and one-or-more of the include
files which that include file also includes?  It's question worth
considering, especially if the library is made up of files with fairly
discrete contents.

For arguments sake, I'll assume that this is indeed going to happen
frequently.  One idea I have is that each include file would be parsed to
the point of containing raw-code-tokens only before it is actually included
into the next file up the chain.

Otherwise, perhaps there is a way to modify the aliasing algorithm to allow
for 'membrane namespaces' to overlap, thus demanding that each include file
in the tree be accessed only once.  Of course, if an author includes a file
which is also included by another include file, then its namespace will
have to be restored before the parser includes it in the root file.

-Randall

Post a reply to this message

"Randall Sawyer" <sra### [at] yahoocom> wrote:

> Otherwise, perhaps there is a way to modify the aliasing algorithm to allow
> for 'membrane namespaces' to overlap, thus demanding that each include file
> in the tree be accessed only once.  Of course, if an author includes a file
> which is also included by another include file, then its namespace will
> have to be restored before the parser includes it in the root file.

Yes, that's it.

When you 'run' POV-Ray, it would first have to scan your file, then its
'#include'd files and then those files' '#include'd files and so on,
building a map of the 'includes tree'.

Then, it would run an algorithm to generate an 'alias table' based on the
'includes tree' - accounting for any redundant includes.

Then, as each include file is loaded into the buffer, its 'declaration
space' and 'implementation space' (if appropriate) would be aliased
according to the values in the 'alias table'.

The 'declaration space' of any immediate includes would not receive any
aliases (That would still be the author's responsibility).  Finally, the
whole assemblage would be parsed.

Now, you're good to go.

Did I overlook anything?

Well, talk is cheap.  I'd better get to work on a mock-up.

-Randall

Post a reply to this message