Bob Hughes wrote:
> 
> "Possibly" sounds encouraging.
> I was thinking along the lines that if the two or more words could be
> done with spaces then somehow it would be seen *only* when all the group
> were present, like when part of a keyword is written into the CodeMax
> editor it shows that the keyword is not all there (also if written
> wrong) by not switching color. So if all the words were present in
> proper placement (and spelling) it would be recognized and only then.

I could live with the loss of underscores and abreviated key words
but have a feeling it would make the language a little too loose
by adding support for spaces. Personaly I see no advantage to it
anyway. If you want to do two things to reduce code size and ease
of entering then turn around and add spaces back in. Where are you
going with this ?

-- 
Ken Tyler

mailto://tylereng@pacbell.net

Post a reply to this message

Bob Hughes schrieb in Nachricht <36D32A3C.A7C6D824@aol.com>...
>'sor' is surface of revolution though. Of course I understand your
>sentiment, writing a word out is more obvious. Especially difficult to
>recall all the keywords if each and every were short versions. Except I
>still could see getting along with several at least. superellipsoid is
>one, especially; maybe 'sel'?. Ones like prism are fine.
>
>Got 98 cents for a dollar?

The size of the keyword can be larger, as long as it is not used very often.
In Delphi we have words like initialization, finalization or implementation
which are really a nuisance to type. But they appear only once in a file. I
think sor is a bit short. I first though it was some kind of boolean
operation (like or, and and not). Superellipsoid is ok for me. (Supertoroid
would be nice too.)

--
Rudy Velthuis

Post a reply to this message

Rudy Velthuis wrote:
> 
> Bob Hughes schrieb in Nachricht <36D32A3C.A7C6D824@aol.com>...
> >'sor' is surface of revolution though. Of course I understand your
> >sentiment, writing a word out is more obvious. Especially difficult to
> >recall all the keywords if each and every were short versions. Except I
> >still could see getting along with several at least. superellipsoid is
> >one, especially; maybe 'sel'?. Ones like prism are fine.
> >
> >Got 98 cents for a dollar?
> 
> The size of the keyword can be larger, as long as it is not used very often.
> In Delphi we have words like initialization, finalization or implementation
> which are really a nuisance to type. But they appear only once in a file. I
> think sor is a bit short. I first though it was some kind of boolean
> operation (like or, and and not). Superellipsoid is ok for me. (Supertoroid
> would be nice too.)
> 
> --
> Rudy Velthuis

I like "superlips". Has a nice ring to it.

-- 
Ken Tyler

mailto://tylereng@pacbell.net

Post a reply to this message

I bet there's some side effects that may not be immediately apparent
too. In Keith Rule's Graphic File Formats, he explains why the use of
commas between vector components were added.  If you have a vector 1.0 2
0.0, the parser might think you meant <1.02, 0.0, 0>.  Something like
that.  I bet a lack of underscores could lead to some keywords getting
mixed up.

-Mike

Ron Parker wrote:
> 
> On Tue, 23 Feb 1999 12:32:51 -0600, Bob Hughes <inv### [at] aolcom> wrote:
> >crss {}
> 
> I asked about that one because it's one of the longer new keywords
> in the superpatch.  Obviously, it's not one of mine.  I don't change
> other people's keywords for compatibility's sake, unless there's a
> conflict (the #macro stuff from the iso patch, for example.)
> 
> >Any idea about making spaces available between keywords? Plausible
> >(doable I don't know) to make a keyword recognisable (oops, my Canadian
> >sp.) which goes as a pair of words or more?
> 
> Possible but ugly, since the tokenizer splits things on spaces.  Even if
> you did make it work with the current tokenizer (and you could, I think)
> you'd get weird error messages if you said something like "max trace 10"
> instead of "max trace level 10"  All in all, probably not a good thing.

Post a reply to this message

On Wed, 24 Feb 1999 02:55:00 -0600, Mike <Ama### [at] aolcom> wrote:
>I bet there's some side effects that may not be immediately apparent
>too. In Keith Rule's Graphic File Formats, he explains why the use of
>commas between vector components were added.  If you have a vector 1.0 2
>0.0, the parser might think you meant <1.02, 0.0, 0>.  Something like
>that.  I bet a lack of underscores could lead to some keywords getting
>mixed up.

Actually, that one was due to the imparsability of <1 -2 3> as a vector.
is that <-1, 3, 0> or <1, -2, 3>?  I remember they documented the change
as such when they did it, anyway.

Post a reply to this message

Peter Popov <pet### [at] usanet> wrote:

  Now, here we have a person who definitively have been raytracing too
long... ;)

-- 
main(i){char*_="BdsyFBThhHFBThhHFRz]NFTITQF|DJIFHQhhF";while(i=
*_++)for(;i>1;printf("%s",i-70?i&1?"[]":" ":(i=0,"\n")),i/=2);} /*- Warp -*/

Post a reply to this message

Think you lost me more than I you.
Simply put, if you had 'light source' instead of 'light_source' and
there was a way the pvengine would only see it when written that way,
ie. *not* when typed in as 'source light' or 'light color' (parser would
say "What the...!? then), I would certainly like that way of things.


Ken wrote:
> 
> Bob Hughes wrote:
> >
> > "Possibly" sounds encouraging.
> > I was thinking along the lines that if the two or more words could be
> > done with spaces then somehow it would be seen *only* when all the group
> > were present, like when part of a keyword is written into the CodeMax
> > editor it shows that the keyword is not all there (also if written
> > wrong) by not switching color. So if all the words were present in
> > proper placement (and spelling) it would be recognized and only then.
> 
> I could live with the loss of underscores and abreviated key words
> but have a feeling it would make the language a little too loose
> by adding support for spaces. Personaly I see no advantage to it
> anyway. If you want to do two things to reduce code size and ease
> of entering then turn around and add spaces back in. Where are you
> going with this ?
> 
> --
> Ken Tyler
> 
> mailto://tylereng@pacbell.net

-- 
 omniVERSE: beyond the universe
  http://members.aol.com/inversez/POVring.htm
 mailto:inv### [at] aolcom?PoV

Post a reply to this message

That's what I was wondering though, unless it was implausible in the
coding of the program then obviously it wouldn't work anyway, but if it
was possible the why not as I said to one of Kens posts:
Simply put, if you had 'light source' instead of 'light_source' and
there was a way the pvengine would only see it when written that way,
ie. *not* when typed in as 'source light' or 'light color' (parser would
say "What the...!? then), I would certainly like that way of things.
A group of words from 2 to ? using spaces, as long as the program code
could discern in the afore-mentioned way, I would think it might be the
best alternative to underscoring.


Mike wrote:
> 
> I bet a lack of underscores could lead to some keywords getting
> mixed up.
> 
> -Mike
> 
> Ron Parker wrote:
> >
> > On Tue, 23 Feb 1999 12:32:51 -0600, Bob Hughes <inv### [at] aolcom> wrote:
> > >crss {}
> >
> > I asked about that one because it's one of the longer new keywords
> > in the superpatch.  Obviously, it's not one of mine.  I don't change
> > other people's keywords for compatibility's sake, unless there's a
> > conflict (the #macro stuff from the iso patch, for example.)
> >
> > >Any idea about making spaces available between keywords? Plausible
> > >(doable I don't know) to make a keyword recognisable (oops, my Canadian
> > >sp.) which goes as a pair of words or more?
> >
> > Possible but ugly, since the tokenizer splits things on spaces.  Even if
> > you did make it work with the current tokenizer (and you could, I think)
> > you'd get weird error messages if you said something like "max trace 10"
> > instead of "max trace level 10"  All in all, probably not a good thing.

-- 
 omniVERSE: beyond the universe
  http://members.aol.com/inversez/POVring.htm
 mailto:inv### [at] aolcom?PoV

Post a reply to this message

Well, I'm OOP in every-way... (I do JAVA as well :-)
But, I think POV animations and several other things would be easier o
acces with .<variable>
Perhaps only read-only (only an only to many?) but it would still be
nice.




Rudy Velthuis wrote:
> 
> Spider schrieb in Nachricht <36D2CD37.BED49543@bahnhof.se>...
> >While we're at it, when will someone do a OOP-POV ???
> >dot separated keywords and so on.
> >int photon.mapsize
> >int photon.level
> >vector camera.look_at
> >vector camera.postition
> 
> I've been thinking along the same lines last night. We can access a vector's
> x, y and what-not, but we can't access an object's elements like that. I
> would really have been glad to have something like camera1.position.x and
> camera1.look_at.y or for an Escher pic I was working on.
> 
> (Must be our Delphi background, I suppose <heh>.)

-- 
//Spider 
( spi### [at] bahnhofse ) [ http://www.bahnhof.se/~spider/ ]
#declare life = rand(seed(42))*sqrt(-1);

Post a reply to this message

Bob Hughes wrote:
> 
> That's what I was wondering though, unless it was implausible in the
> coding of the program then obviously it wouldn't work anyway, but if it
> was possible the why not as I said to one of Kens posts:
> Simply put, if you had 'light source' instead of 'light_source' and
> there was a way the pvengine would only see it when written that way,
> ie. *not* when typed in as 'source light' or 'light color' (parser would
> say "What the...!? then), I would certainly like that way of things.
> A group of words from 2 to ? using spaces, as long as the program code
> could discern in the afore-mentioned way, I would think it might be the
> best alternative to underscoring.

Why confuse thing by adding spaces ?  lightsource{}   I can read it.
Better yet would be light{}, cam{}, tex{}, pig{}, obj{}, tri{},
smthtri{}, sph{}, cyl{}, tor{}, sprlips{}, and I think you get the idea.

-- 
Ken Tyler

mailto://tylereng@pacbell.net

Post a reply to this message