POV 3.5 b 12 for Win

(note: some suggestions are connected also with conventional part of SDL
refenrence - it is just simpler to dig on quick reference)

10.1.4.2  Identifier Declaration

  I can't find function() case in possible RVALUE

10.1.4.3  File Input/Output

  Considering discussion about array entries and final "something can be
  declared but not assigned" I suggest to change:
  DATA_IDENTIFIER: 
    UNDECLARED_IDENTIFIER | (...)
  to
  DATA_IDENTIFIER: 
    UNDECLARED_IDENTIFIER | UNASSIGNED_IDENTIFIER | (...)

10.1.4.3  File Input/Output

  I suggest to add to File Input/Output quick ref section about EOF detecting.

10.1.4.8  Macro

  Describes MACRO_DEFINITION as
    #macro MACRO_IDENTIFIER ( ... ) SCENE #end
  where SCENE is:
    LANGUAGE_DIRECTIVE|CAMERA|LIGHT|OBJECT|ATMOSPHERIC_EFFECT|GLOBAL_SETTINGS
  So how it can return texture or function with macro ? I think good
  replacement could be:
    #macro MACRO_IDENTIFIER ( ... ) SCENE | RVALUE #end
  or as in conventional syntax frame:
    #macro MACRO_IDENTIFIER ( ... ) TOKENS #end

Additional feature request (but probably not a simple task): could it be
possible to replace all identifiers with links to aproprioate quick ref part ?

ABX

Post a reply to this message

>
> 10.1.4.2  Identifier Declaration
>
>   I can't find function() case in possible RVALUE

The RVALUE item is part of the ARRAY_INITIALIZER and ARRAY_ELEMENT_ASSIGNMENT items. 
In testing possible assignments of
RVALUEs to array elements, I could not get a user-defined function item to work.  So I
left it out of the RVALUE list.  Was
this a bug that has been corrected?  If so, I'll simply add USER_FUNCTION to the list
and also correct the Macro's ACTUAL_PARAM
item.  Let me know.

The assignment to a user-defined function is also covered in section 10.1.3.4 with the
USER_FUNCTION_DECLARATION item.

> 10.1.4.3  File Input/Output
>
>   Considering discussion about array entries and final "something can be
>   declared but not assigned" I suggest to change:
>   DATA_IDENTIFIER:
>     UNDECLARED_IDENTIFIER | (...)
>   to
>   DATA_IDENTIFIER:
>     UNDECLARED_IDENTIFIER | UNASSIGNED_IDENTIFIER | (...)

I am not sure what you mean here.  Outside of arrays, I don't think there is such a
thing as an unassigned identifier.  And
even for the arrays, it would be an unassigned element, would it not?  I cannot use
#read to read a value directly into an
array element.  Please correct me with an example!

> 10.1.4.3  File Input/Output
>
>   I suggest to add to File Input/Output quick ref section about EOF detecting.

This appears to be something that might go against my statement, "It does not provide
definitions for the numerous keywords nor
explain their usage!"  Perhaps a better item would be a "Jump to SDL" link that sends
us to section 6.2.3 ?

> 10.1.4.8  Macro
>
>   Describes MACRO_DEFINITION as
>     #macro MACRO_IDENTIFIER ( ... ) SCENE #end
>   where SCENE is:
>     LANGUAGE_DIRECTIVE|CAMERA|LIGHT|OBJECT|ATMOSPHERIC_EFFECT|GLOBAL_SETTINGS
>   So how it can return texture or function with macro ? I think good
>   replacement could be:
>     #macro MACRO_IDENTIFIER ( ... ) SCENE | RVALUE #end
>   or as in conventional syntax frame:
>     #macro MACRO_IDENTIFIER ( ... ) TOKENS #end

I am avoiding TOKENS because that includes punctuation.  Can we have a macro that
returns just a plus sign or a parenthesis?

I have replaced SCENE with MACRO_ITEM... and added the following definition:
MACRO_ITEM:
    SCENE  |  RVALUE

Now that I look at this though, is it possible to have more than one RVALUE?  If not,
we'll have to come up with something
else.

> Additional feature request (but probably not a simple task): could it be
> possible to replace all identifiers with links to aproprioate quick ref part ?

Well, of course, I cannot speak for the distributed documentation.  For the web page I
decided to not link anything that could
be found in the table of contents at the top of the page.  While creating this
reference, I agonized for a time over the
possibility of including an ITEM_DECLARATION with each "ITEM" that could be declared
(OBJECT_IDENTIFER, COLOR_MAP_IDENTIFIER,
etc.).  The original documentation does this.  Instead I assumed that the reader could
find Identifier Declaration in the
contents for any identifier and figure it out.

Robert Chaffe
http://www.donovansweb.com/~chaffe/

Post a reply to this message

On Wed, 13 Mar 2002 21:20:19 -0600, "Robert Chaffe"
<rob### [at] earthlinknet> wrote:
> The RVALUE item is part of the ARRAY_INITIALIZER and ARRAY_ELEMENT_ASSIGNMENT items.
 In testing possible assignments of
> RVALUEs to array elements, I could not get a user-defined function item to work.

try: #local A=array[1]{function{x+y+z}}
works fine for me with beta 12

>  So I left it out of the RVALUE list.  Was
> this a bug that has been corrected?

probably

> > 10.1.4.3  File Input/Output
> >
> >   Considering discussion about array entries and final "something can be
> >   declared but not assigned" I suggest to change:
>
> I am not sure what you mean here.  Outside of arrays, I don't think there is such a
thing as an unassigned identifier.  And
> even for the arrays, it would be an unassigned element, would it not?  I cannot use
#read to read a value directly into an
> array element.  Please correct me with an example!

Try this twice - first time as is, second time with uncommented line with
array redeclaration:

  #local A=array[2]{1,2};
  #fopen File "test.txt" write
  #write(File,A[1])
  #fclose File
  //#local A=array[2];#local A[0]=1;
  #fopen File "test.txt" read
  #read(File,A[1])
  #fclose File

At first run script reads into declared (becouse symbol A[1] is known and has
memory reference) and assigned (with value 2) entry. At second run (with
uncommented line) script reads into declared but not assigned entry. Now try
this the same way:

  #local A=array[1]{1};
  #fopen File "test.txt" write
  #write(File,A[0])
  #fclose File
  // #local A=array[1];
  #fopen File "test.txt" read
  #read(File,A[0])
  #fclose File

In second run (with uncommented line) it returns parse error becouse A[0] is
not declared. It is not declared becouse it wasn't specified with first
assigment which could define type of entries in array.

> > 10.1.4.3  File Input/Output
> >
> >   I suggest to add to File Input/Output quick ref section about EOF detecting.
>
> "It does not provide definitions for the numerous keywords nor explain their usage!"

Since there are parts of possible file operations: open, read, write, close I
just found EOF detecting as another possible IO-operation. It could be
explanation of usage if it would be used in #ifdef section. But using it in
File Input/Output section is more like using #declare assigment explanation in
User Defined Functions section.

> > 10.1.4.8  Macro
>
> I am avoiding TOKENS because that includes punctuation.  Can we have a macro that
returns just a plus sign or a parenthesis?

Of course:

  #macro Plus() + #end
  #macro Open_Parenthesis() ( #end
  #macro Close_Parenthesis() ) #end
  #local C=
    Open_Parenthesis()
       2 * Open_Parenthesis() version Plus() pi Close_Parenthesis() Plus() 1
    Close_Parenthesis() ^ pi;
  #warning str(C,0,-1)

> Now that I look at this though, is it possible to have more than one RVALUE?

afaik not

ABX

Post a reply to this message

>
> 10.1.4.2 Identifier Declaration
>
> try: #local A=array[1]{function{x+y+z}}
> works fine for me with beta 12

I added USER_FUNCTION to the RVALUE list.  I removed USER_FUNCTION from the
ACTUAL_PARAM item for a macro (section 10.1.4.8)
since it would now be redundant.


> > > 10.1.4.3  File Input/Output
> > >
> Try this twice - first time as is, second time with uncommented line with
> array redeclaration:
>
>  [snip]
> At first run script reads into declared (becouse symbol A[1] is known and has
> memory reference) and assigned (with value 2) entry. At second run (with
> uncommented line) script reads into declared but not assigned entry. Now try
> this the same way:
>
>  [snip]
> In second run (with uncommented line) it returns parse error becouse A[0] is
> not declared. It is not declared becouse it wasn't specified with first
> assigment which could define type of entries in array.

I added ARRAY_REFERENCE to the DATA_IDENTIFIER list.  I also added an item note: "May
read a value into an array reference if
the array element's type has already been established."


> > > 10.1.4.3  File Input/Output
> > >
> > >   I suggest to add to File Input/Output quick ref section about EOF detecting.
> >
> > "It does not provide definitions for the numerous keywords nor explain their
usage!"
>
> Since there are parts of possible file operations: open, read, write, close I
> just found EOF detecting as another possible IO-operation. It could be
> explanation of usage if it would be used in #ifdef section. But using it in
> File Input/Output section is more like using #declare assigment explanation in
> User Defined Functions section.

I added an item note:  "Use defined(FILE_HANDLE_IDENTIFIER) to detect end-of-file
after a read."


> > > 10.1.4.8  Macro
> >
> > I am avoiding TOKENS because that includes punctuation.  Can we have a macro that
returns just a plus sign or a
parenthesis?
>
> Of course:
>  [snip]

I replaced MACRO_ITEM with TOKENS and removed the MACRO_ITEM definition.


Robert Chaffe
http://www.donovansweb.com/~chaffe/

Post a reply to this message