[x3d-public] ProtoBody completeness in nested Protos

[Andreas Plesch]

Thanks much for the review and revision effort.

The recursive case brings up circular dependencies. Proto A may use an
instance of Proto B, but Proto B in turn may use an instance of Proto A
unless some initial condition occurs, so that in theory a result can be
resolved.

The recursive clause in a way covers this in my view but perhaps circular
definitions could be made explicitly illegal.

Just a thought,

Andreas

---on the phone---

On Thu, Apr 28, 2022, 8:45 PM Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>
wrote:

> We reviewed closely.  Prose definitions are correct.  Slight editorial
> changes (essentially re-ordering sentences) hopefully make things clearer.
>
>
>
>    - Mantis 1395: improve clarity of prototype scoping rules
>    - https://www.web3d.org/member-only/mantis/view.php?id=1395
>
>
>    - -
>
>
>    - 4.4.4.4 Prototype scoping rules
>    -
>    https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-CD1/Part01/concepts.html#Prototypescopingrules
>
>
>    - -
>
> A prototype may be instantiated in a file anywhere after the completion of
> the prototype definition. Prototype definitions appearing inside a
> prototype definition (*i.e.*, nested) have scope local to the enclosing
> prototype. IS statements inside a nested prototype's implementation may
> refer to the prototype declarations of the innermost prototype. A
> prototype may not be instantiated inside its own implementation *(i.e.*,
> recursive prototypes are illegal).
>
>
>
> A PROTO statement establishes a DEF/USE name scope separate from the rest
> of the scene and separate from any nested PROTO statements. Nodes given a
> name by a DEF construct inside the prototype may not be referenced in a USE
> construct outside of the prototype's scope. Nodes given a name by a DEF
> construct outside the prototype scope may not be referenced in a USE
> construct inside the prototype scope.
>
>    - -
>
>
>
> Again thanks for all efforts to make the X3D4 specification clear and
> consistently repeatable.
>
>
>
> all the best, Don
>
> --
>
> Don Brutzman  Naval Postgraduate School, Code USW/Br
> brutzman at nps.edu
>
> Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA
> +1.831.656.2149
>
> X3D graphics, virtual worlds, Navy robotics https://
> faculty.nps.edu/brutzman
>
>
>
> *From:* Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>
> *Sent:* Wednesday, April 27, 2022 9:23 PM
> *To:* GPU Group <gpugroup at gmail.com>; Andreas Plesch <
> andreasplesch at gmail.com>; Richard F. Puk (puk at igraphics.com) <
> puk at igraphics.com>
> *Cc:* X3D Graphics public mailing list <x3d-public at web3d.org>; Brutzman,
> Donald (Don) (CIV) <brutzman at nps.edu>
> *Subject:* RE: [x3d-public] ProtoBody completeness in nested Protos
>
>
>
> Thanks for your precision and thoroughness Doug.
>
>
>
> Seems clear and unambiguous that it is scoped, as previously described.
> We’ll double check on phraseology.
>
>
>
> Dick can we please discuss in tomorrow’s meeting, TIA.
>
>
>
> all the best, Don
>
> --
>
> Don Brutzman  Naval Postgraduate School, Code USW/Br
> brutzman at nps.edu
>
> Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA
> +1.831.656.2149
>
> X3D graphics, virtual worlds, Navy robotics https://
> faculty.nps.edu/brutzman
>
>
>
> *From:* x3d-public <x3d-public-bounces at web3d.org> *On Behalf Of *GPU Group
> *Sent:* Tuesday, April 26, 2022 9:57 AM
> *To:* X3D Graphics public mailing list <x3d-public at web3d.org>
> *Subject:* Re: [x3d-public] ProtoBody completeness in nested Protos
>
>
>
>
> https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/concepts.html#Prototypescopingrules
>
>
>
> "A prototype may be instantiated in a file anywhere after the completion
> of the prototype definition."
>
> If the specs meant what you are suggesting --protos are self contained
> including proto definitions-- then it would have said "context" rather than
> "file"
>
> "Prototype definitions appearing inside a prototype definition ( i.e.,
> nested) are local to the enclosing prototype. "
>
> - refinement of the above file order rule.
>
>
>
>
>
> On Tue, Apr 26, 2022 at 9:51 AM GPU Group <gpugroup at gmail.com> wrote:
>
> "I really do
> not think that proto declarations should be required to inherit
> existing declarations from parent execution contexts"
>
>
>
> If C++ required each class definition to be self-contained --to redefine
> all the types it depends on-- it would be a very messy and onerous system.
> If you want a system that can build up types - types on top of types to
> make more complex types - then you need a way for a type to use previously
> defined types.
>
> In x3d -a prototyping language- that looks like a new type being able to
> use a type defined previously in the file. Extern ProtoDeclares are stored
> in scene files as ProtoDeclares. As such they should be able to use type
> defined previously in their host file.
>
>
>
>
>
> On Tue, Apr 26, 2022 at 9:37 AM Andreas Plesch <andreasplesch at gmail.com>
> wrote:
>
> > Date: Tue, 26 Apr 2022 07:56:47 -0600
> > From: GPU Group <gpugroup at gmail.com>
> > To: X3D Graphics public mailing list <x3d-public at web3d.org>
>
> > When I started with freewrl around 2009, it had a text-based system for
> > protos:
> > - when parsing a scene, if it found a proto declare, it would scrape the
> > text into a buffer. Then as it continued parsing, when it hit a proto
> > instance it pasted, and continued parsing over the pasted text as though
> it
> > had been there all along. Extern protos similar, it would pause parsing,
> go
> > to the file referenced, look for the proto declare by name, and scrape
> out
> > the text of the ProtoDeclare, for pasting in-scene.
> > And it worked a bit. But especially extern protos weren't working
> reliably.
> > As a casual volunteer I decided to fix the bugs. How hard could it be? A
> > little debugging and presto, I'd be a hero. As I got into it and saw more
> > scene failure examples there were several emotional stages like grieving
> > denial, shock, sadness, resistance etc. And a slow dawning realization
> the
> > whole system needed a rework.
> > And I didn't have support from others -just silence, perhaps they knew it
> > was a mess and wanted to stay clear.
> > It was a sickening feeling, and I needed to think for a few weeks
> whether I
> > even wanted to be a volunteer programmer if the system was rotten from
> the
> > core.
> > So it can not only be a monster task, but precisely because it's a
> monster
> > there's little support for those brave enough to tackle it.
> > (After a few weeks I got to the Acceptance stage of grieving, and spent 6
> > months of hobby time building the new proto system).
>
> Thanks for the story, and for engaging. To me, I became interested
> when I realized that x3dom is probably flexible enough to allow for
> parameterized definition and registration of new nodes dynamically
> which behave then exactly like native nodes. This is different from
> filling in templates. For example, there is no performance penalty
> during tree traversal and it enables instancing using xml nodes with
> the new names, just as in x3dv.
>
> I am pretty happy with how it came out. An additional complication is
> asynchronous loading of remote resources which is standard on the web.
> X3D should rely less on how nodes or statements are ordered in a
> scene.
>
> It is just frustrating that there are ill defined corners. I really do
> not think that proto declarations should be required to inherit
> existing declarations from parent execution contexts ( DEF/USE name
> scopes are different but there is still a separated execution context
> ). That means the protos array of a new execution context should be
> empty initially. The SAI spec. actually says so.
>
> Best, Andreas
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20220428/d408ce86/attachment.html>