The problem someone was having with some include file choking on
POV-Ray 3.5 because it used an identifier named 'size' which is a
reserved keyword in POV-Ray 3.5 got me thinking about one thing:

  Is there any good reason why reserved keywords should not be
allowed as identifier names?

  The only reason I can think of is that it makes the implementation
of the parser more complicated. Developers may well think this is good
enough to not to support (and I suppose this is justified), but if we
think about it from the user's and the SDL syntax point of view, would
there be any potential problem with that?

  If you think about it, is there any place where there could be
ambiguity whether a name is a keyword or an identifier (specially
when we know that if it's an identifier, what is its type)?

  For instance, suppose we have this:

#declare sphere = 5;

#declare Obj = sphere { 0, 1 };
#declare Val = sphere;

  The parser will have to look ahead and see that in the second #declare
if 'sphere' is taken as a float identifier it will result in a syntax
error, but if it's taken as the keyword for the sphere primitive, it
will work ok. Thus the parser chooses the meaning which does not cause
a syntax error. The same goes for the third #declare: As a keyword it
would produce a syntax error, but as a float identifier it won't, so
the parser would choose the meaning that does not produce the error.

  One could even write this:

#declare Obj = sphere { sphere, sphere };

  The parser would interpret 'sphere' as a primitive keyword where a
keyword is expected and as a float identifier where a float is expected.

  I can't think of any example where the parser could not unambiguously
decide which meaning to choose. And even if there would be, the parser
could simply issue an error in that case (something like "ambiguous use
of 'sphere'" or whatever).

  #macros are a special case in that the name of a macro could be any
reserved keyword except an internal function name (ie. sin, cos, etc).
This is naturally because calling an internal function has the same
syntax as calling a macro. However, there shouldn't be any problem in
having a #macro called 'sphere', for instance, because the syntax of
a macro call can't be confused with the creation of a sphere primitive.

  One could ask what would be the benefit from this. It only sounds as
an additional feature to make more obfuscated code.

  The benefit would be that if someone uses a certain name now, there
will be a bigger chance that his code will not break in future versions
of POV-Ray.

  I know, I know, someone will reply to this "just use identifier names
starting with a capital letter". The problem is that there are tens or
hundreds of thousands of people out there using POV-Ray and only a very
small percentage of them are reading this kind of good advice here.

  I'm not proposing that this should be implemented. I'm just thinking
out loud, sharing my random thoughts.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
>   Is there any good reason why reserved keywords should not be
> allowed as identifier names?

With a few exceptions, most programming languages does not allow that.
The exceptions are dynamic languages. I only can think of Lisp, but I'm sure
there's a lot of them. In these cases, the parser represents "keywords" as
function names which can be redefined. That way, you lose in optimization
of code.

>   If you think about it, is there any place where there could be
> ambiguity whether a name is a keyword or an identifier (specially
> when we know that if it's an identifier, what is its type)?

Yes:

#declare fresnel = 0;
#declare MyFinish = finish { reflection { 0.5 metallic fresnel } };

The parser wont know if it's supposed to be:
#declare MyFinish = finish { reflection { 0.5 metallic 0 } };
or
#declare MyFinish = finish { reflection { 0.5 metallic on fresnel on } };

because the boolean value could be omitted.

Of course this can be changed. But it's always complicated to guarantee that
the parser (or the programmer) wont be confused.


>   The parser will have to look ahead (...)

If I'm not mistaken, the current parser of POVRay SDL does not allow
lookaheads.
This would imply the total re-writing of the grammar to migrate to a parser
that supports lookahead.

>   I know, I know, someone will reply to this "just use identifier names
> starting with a capital letter". The problem is that there are tens or
> hundreds of thousands of people out there using POV-Ray and only a very
> small percentage of them are reading this kind of good advice here.

The doc's are out there to be read :P

I think a good keyword name never conflicts with good variable names.
For instance, a variable named "if" doesn't mean anything.
Of course, in POV-Ray some keywords do mean something (like the sphere
keyword). This is really a problem from the users point of view.

Maybe an alternative solution is to use some operator to refer to variables,
as $ in PHP.

Post a reply to this message

Leonardo <lmf### [at] megaistutlpt> wrote:
> #declare fresnel = 0;
> #declare MyFinish = finish { reflection { 0.5 metallic fresnel } };

> The parser wont know if it's supposed to be:
> #declare MyFinish = finish { reflection { 0.5 metallic 0 } };
> or
> #declare MyFinish = finish { reflection { 0.5 metallic on fresnel on } };

  The parser could use intelligent heuristics to decide which interpretation
is correct.
  The simplest heuristic would be: "This is the name of a keyword. If
I use it as a keyword in this place, will it cause a syntax error? If
yes, use it as a keyword, else use it as an identifier name." That is,
the name of a keyword is always used as a keyword if possible (ie. it
doesn't cause an error), and only if it won't work as a keyword it will
be tested as an identifier.

  Another possibility is to issue an error message about the ambiguous use
of the name in that place.

> If I'm not mistaken, the current parser of POVRay SDL does not allow
> lookaheads.
> This would imply the total re-writing of the grammar to migrate to a parser
> that supports lookahead.

  As I said, I didn't suggest this should be done. I was just thinking
aloud... :)

> I think a good keyword name never conflicts with good variable names.

  Sometimes this is not possible. For example "size" is a good variable
name and a good keyword name. The same applies to many other examples,
such as "radius", "location", "angle", etc.

> Maybe an alternative solution is to use some operator to refer to variables,
> as $ in PHP.

  This would make writing SDL more complicated. I'm not really sure I like
that.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

In article <40bb1df8@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>  The parser could use intelligent heuristics to decide which interpretation
> is correct.
>   The simplest heuristic would be: "This is the name of a keyword. If
> I use it as a keyword in this place, will it cause a syntax error? If

But can something like this always be determined in constant time?  If not,
and I think it cannot always be determined in constant time, it would make
parsing really slow.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> But can something like this always be determined in constant time?  If not,
> and I think it cannot always be determined in constant time, it would make
> parsing really slow.

  Can you give an example where it can't be solved in constant time?

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

In article <40bb476a@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

> Thorsten Froehlich <tho### [at] trfde> wrote:
>> But can something like this always be determined in constant time?  If not,
>> and I think it cannot always be determined in constant time, it would make
>> parsing really slow.
>
>   Can you give an example where it can't be solved in constant time?

This is a guess from the top of my head.  What would be the color of the
sphere sp1 and sp2?

    Thorsten

#declare sp1 = sphere
{
 z*10,1
 texture
 {
  pigment
  {
   color
   #declare blue = 0;
   blue
   #declare blue = 1;
   blue
   blue
   blue
   blue
  }
 }
}

#declare sp2 = sphere
{
 z*10,1
 texture
 {
  pigment
  {
   color
   #declare blue = 0;
   blue
   #declare blue = 1;
   blue
   blue
   blue
   blue
   blue
  }
 }
}

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <40bb852b$1@news.povray.org> , "Thorsten Froehlich" 
<tho### [at] trfde> wrote:

> This is a guess from the top of my head.

Wait, this example can be solved by just determining if there is an even or
odd number of "blue", but I was looking for an example that requires
counting (informal rationale: if counting is required, the language is not
context-free).  One needs to use a second color component specifier to
create the need for counting:

#declare sp1 = sphere
{
 z*10,1
 texture
 {
  pigment
  {
   color
   #declare blue = 0;
   blue
   #declare blue = 1;
   #declare red = 1;
   red
   red
   red
   blue
   red
   blue
   blue
   blue
   blue
   blue
  }
 }
}

#declare sp2 = sphere
{
 z*10,1
 texture
 {
  pigment
  {
   color
   #declare blue = 0;
   blue
   #declare blue = 1;
   #declare red = 1;
   blue
   red
   blue
   red
   red
   blue
   red
   red
   red
   blue
   blue
   blue
   blue
   red
  }
 }
}



____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

>   The parser could use intelligent heuristics to decide which interpretation
> is correct.
>   The simplest heuristic would be: "This is the name of a keyword. If
> I use it as a keyword in this place, will it cause a syntax error? If
> yes, use it as a keyword, else use it as an identifier name." That is,
> the name of a keyword is always used as a keyword if possible (ie. it
> doesn't cause an error), and only if it won't work as a keyword it will
> be tested as an identifier.

Those parser decisions can mislead the programmer to errors, because the
rules for an identifier to be upgraded to keyword depends on the context.
Context-sensitive grammars are not generally adopted in programming
languages.

>
>   Another possibility is to issue an error message about the ambiguous use
> of the name in that place.
That would be better.

>   Sometimes this is not possible. For example "size" is a good variable
> name and a good keyword name. The same applies to many other examples,
> such as "radius", "location", "angle", etc.
As I said this is a problem with POVRay's SDL

>   This would make writing SDL more complicated. I'm not really sure I like
> that.
Maybe... but this way, the language can be extended in the future without
conflicts. And maybe provide some plug-in API for anyone to add new
functionality. But thats is another topic... :)

Post a reply to this message

Sapphire supports this...or rather, did. I intend to completely remove 
it, checking and giving an error on uses of keywords as variable names. 
It just introduced too much complexity into the language, and let you do 
things that were completely useless...like declaring blocks named "for", 
"if", "while", etc that are uncallable. (block call syntax is similar to 
C function call syntax, which looks like loop and if statement syntax...)

A sufficiently flexible syntax would allow you to avoid having things 
like shape and texture parameters as part of the language. In this case, 
"size" would be a named parameter or method call, not a language 
keyword. This would also make the core parser code far simpler, the 
language more consistent and the language interface easier to code with, 
and probably cost a bit of parsing speed. Ideally, the language would be 
compiled once to bytecode and then interpreted, so the speed hit is a 
one-time thing...things like meshes could make use of hard-coded parsers 
for speed, perhaps some simplified file format...the description 
language seems like the wrong place to specify huge data sets, though 
it's certainly useful for generating them.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message