POV-Ray : Newsgroups : povray.general : Pov 4.00 question Server Time
7 Aug 2024 01:19:55 EDT (-0400)
  Pov 4.00 question (Message 54 to 63 of 73)  
<<< Previous 10 Messages Goto Latest 10 Messages Next 10 Messages >>>
From: Thorsten Froehlich
Subject: Re: Possible POV Object Scheme (was Re: Pov 4.00 question)
Date: 3 Feb 2002 04:45:13
Message: <3c5d06a9@news.povray.org>
In article <3C5CB5DB.7970FB10@u.arizona.edu> , Kevin Wampler 
<wam### [at] uarizonaedu>  wrote:

> In the current scene I'm working on I have been using Icon extensively
> to generate Pov code.

Don't even get me started on Icon.  With its random (well, random to any sane
person) sequences of characters being operators, it can only appear a useful
language to those who designed it.  For everybody else its useless syntax gets
in the way all time.  Readability of a programming language is the most
important asset, and the designers of Icon did a good job.  Given L is a list,
who could tell "every i:=1 to *L/2 do L[i]:=:L[-i]" reverses it?  Not that is
is to be considered obfuscated code at all, no, this is how it is presented in
books that want to teach the language!

    Thorsten

____________________________________________________
Thorsten Froehlich
e-mail: fro### [at] iitedu


Post a reply to this message

From: Ron Parker
Subject: Re: Possible POV Object Scheme (was Re: Pov 4.00 question)
Date: 3 Feb 2002 10:36:38
Message: <slrna5qm88.91d.ron.parker@fwi.com>
On Sun, 03 Feb 2002 10:45:10 +0100, Thorsten Froehlich wrote:
> 
> Given L is a list,
> who could tell "every i:=1 to *L/2 do L[i]:=:L[-i]" reverses it?  

Hm, that would work in Perl, too, with very few modifications.  

Of course, @L = reverse @L would work, too...

-- 
#local R=<7084844682857967,0787982,826975826580>;#macro L(P)concat(#while(P)chr(
mod(P,100)),#local P=P/100;#end"")#end background{rgb 1}text{ttf L(R.x)L(R.y)0,0
translate<-.8,0,-1>}text{ttf L(R.x)L(R.z)0,0translate<-1.6,-.75,-1>}sphere{z/9e3
4/26/2001finish{reflection 1}}//ron.parker@povray.org My opinions, nobody else's


Post a reply to this message

From: Thorsten Froehlich
Subject: Re: Possible POV Object Scheme (was Re: Pov 4.00 question)
Date: 3 Feb 2002 10:59:10
Message: <3c5d5e4e@news.povray.org>
In article <slr### [at] fwicom> , Ron Parker 
<ron### [at] povrayorg>  wrote:

>> Given L is a list,
>> who could tell "every i:=1 to *L/2 do L[i]:=:L[-i]" reverses it?
>
> Hm, that would work in Perl, too, with very few modifications.
>
> Of course, @L = reverse @L would work, too...

I picked a short example.  Below is a scanner, also given as *educational*
example (from http://www.iit.edu/~tc/), in particular note sequences like
"||:= =", or the operators for connecting strings, because that is what the
"++" does.  Now guess what the "?" does!

Basically all operators are unqiue for each data type, which gives you a farm
of operators.  In order to implement those you end up with other interesting
character sequences like "~==="...

    Thorsten


procedure scan()
local t,c,b
static whiteSpace,initIdChars,idChars,hexdigits,commentDepth,commentLineNo
initial {
 /inputFile := &input
 inputLineNumber := 1
 inputColumn := 1
 inputLine := read(inputFile)
 eoiToken := &null
 whiteSpace := &ascii[1:34] #control ++ blank
 initIdChars := &letters
 hexdigits := &digits ++ 'ABCDEF'
 idChars := &letters ++ &digits ++ '$_'
 keywordSet := set([
  "DEF","VAL","while","bu"
 ])
}
if \eoiToken then return eoiToken
repeat inputLine ? {
 tab(inputColumn)
 tab(many(whiteSpace))
 c := &pos
 if b := (tab(any('+-'))|"") ||
   tab(many(&digits)) then {
  if b := b || fractionPart() ||
      scaleFactor() then {
   t := Token("signedFloat",b,
    inputLineNumber,c)
  } else if b ||:= fractionPart() then {
   t := Token("signedFloat",b,
    inputLineNumber,c)
  } else if b ||:= ="." || scaleFactor() then {
   t := Token("signedFloat",b,
    inputLineNumber,c)
  } else {
   t := Token("signedInt",b,
    inputLineNumber,c)
  }
  inputColumn := &pos
  return t
 } else
  if any(initIdChars) then {
  t := Token("ident",tab(many(idChars)),
   inputLineNumber,c)
  inputColumn := &pos
  if member(keywordSet,t.body) then
   t.type := t.body
  return t
 } else
  if b := =("~=" | ">=" | "<=" | "->") then {
  inputColumn := &pos
  return Token(b,b,inputLineNumber,c)
 } else
  if ="(*" then {
  inputColumn := &pos
  commentDepth := 1
  commentLineNo := inputLineNumber
  while commentDepth > 0 do {
   tab(upto('*(')|0)
   if pos(0) then {
       &pos := 1
       inputLineNumber +:= 1
       if not (&subject :=
     inputLine := read(inputFile))
       then {
    eoiToken := Token("EOI","EOI",
     inputLineNumber,1)
    write("end of input in comment beginning at ",
     commentLineNo)
    return eoiToken
       }
    } else if ="*)" then {
     commentDepth -:= 1
    } else if ="(*" then {
     commentDepth +:= 1
    } else {
     move(1)
    }
  }
  inputColumn := &pos
 } else
  if b := tab(any('\',=()[]<>+-*/@;:.')) then {
  inputColumn := &pos
  return Token(b,b,inputLineNumber,c)
 } else
  if pos(0) then {
  inputColumn := 1
  inputLineNumber +:= 1
  if not (inputLine := read(inputFile)) then {
   eoiToken := Token("EOI","EOI",
     inputLineNumber,1)

   return eoiToken
  }
 } else
  if ="\"" then {
  b := tab(find("\""))
  if not( = "\"" ) then {
   write("unterminated string at ",
    inputLineNumber," ",c)
  }
  t := Token("string",b,inputLineNumber,c)
  inputColumn := &pos
  return t
 } else
  {
  write("unexpected character: ",move(1),
   " at line ",inputLineNumber," column ",c)
  inputColumn := &pos
 }
}
end


Post a reply to this message

From: Hermann Voßeler
Subject: Re: Possible POV Object Scheme (was Re: Pov 4.00 question)
Date: 14 Feb 2002 06:56:03
Message: <3C6BA3F8.7010104@webcon.de>
Warp wrote:

> 
>   I don't understand why it would be "more powerful" and "cleaner" with
> no '{'s and '#'s.
>   Specially the lack of '{'s would make it uglier and harder to write and
> read.
>   (No, I *DON'T* want to start writing 'begin' and 'end' like in Pascal.)
> 
> 

may I throw in my $.02 on this?

do you know the haskell (funcitonal) programming language?


they use a indentation rule to figure out when a statement belongs to 
a block. As long as you indent new lines more than the line that 
started the block, the compiler knows you want to stay within that 
block. As soon as you indent lesser, it adds a implicit "}".
Works great.

For povray SDL this whould mean:

object sphere
   <0 0 1> 1.0
   texture
      pigment colour rgb(1, 1, 0)
      finish ambient 0.2
             diffuse 0.6
             metallic

camera location <0 0 0>
        look_at <0 0 1>




Post a reply to this message

From:
Subject: Re: Possible POV Object Scheme (was Re: Pov 4.00 question)
Date: 14 Feb 2002 07:12:43
Message: <7aan6uohose2fi918tja79tdn80kpvv7kt@4ax.com>

wrote:
> they use a indentation rule to figure out when a statement belongs to 
> a block

But in case of complicated mesh2 it could be horrible wasting of drive space.

ABX


Post a reply to this message

From: Nekar Xenos
Subject: Re: Possible POV Object Scheme (was Re: Pov 4.00 question)
Date: 14 Feb 2002 07:17:32
Message: <3c6baadc@news.povray.org>

news:3C6### [at] webconde...
> Warp wrote:
>
> >
> >   I don't understand why it would be "more powerful" and "cleaner" with
> > no '{'s and '#'s.
> >   Specially the lack of '{'s would make it uglier and harder to write and
> > read.
> >   (No, I *DON'T* want to start writing 'begin' and 'end' like in Pascal.)
> >
> >
>
> may I throw in my $.02 on this?
>
> do you know the haskell (funcitonal) programming language?
>
>
> they use a indentation rule to figure out when a statement belongs to
> a block. As long as you indent new lines more than the line that
> started the block, the compiler knows you want to stay within that
> block. As soon as you indent lesser, it adds a implicit "}".
> Works great.
>
> For povray SDL this whould mean:
>
> object sphere
>    <0 0 1> 1.0
>    texture
>       pigment colour rgb(1, 1, 0)
>       finish ambient 0.2
>              diffuse 0.6
>              metallic
>
> camera location <0 0 0>
>         look_at <0 0 1>
>

IMHO it's not all that practical. If you have lot's of nested loops and CSG you
could spend more time scrolling left and right than it would take to type in
'{'. It could get quite confusing. I would rather just do away with the #'s.

--
#local X=20*<-2,2,5>;#local K=2*z*X-X;#local R=seed(frame_number);blob{#while(K
.x>X.x)#local N=X+<rand(R)rand(R)1>/3;#local X=(vlength(N-K)<vlength(X-K)?N:2*X
-N);sphere{X,1,1rotate z*90}sphere{X,1,1}#end pigment{rgbt 1}interior{media{
emission<2,4,5>*5}}hollow scale.05}//   http://nekar_xenos.tripod.com/metanoia/
sphere_sweep{catmull_rom_spline 6<-8,-8>1<-8,-8>1<-8,8>1<8,-8>1<8,8>1<8,8>1
translate 20*z pigment{gradient z scale 3color_map{[0rgb<0,9,18>][1rgb 0]}}}


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.323 / Virus Database: 180 - Release Date: 2002/02/08


Post a reply to this message

From: Tom Melly
Subject: Re: Possible POV Object Scheme (was Re: Pov 4.00 question)
Date: 14 Feb 2002 07:19:46
Message: <3c6bab62$1@news.povray.org>

news:3C6### [at] webconde...

<snip>

Might be worth implementing if only to see Ken turning in his grave.... ("But
he's not dead", "No, but this will kill him")

I don't like it, although I can see the attraction. It strikes me as mixing up
style and content - which is exactly the confusion that got html/browsers in to
such trouble....


Post a reply to this message

From: Hermann Voßeler
Subject: Re: Possible POV Object Scheme (was Re: Pov 4.00 question)
Date: 14 Feb 2002 09:14:39
Message: <3C6BC474.1010002@webcon.de>
W^(3)odzimierz ABX Skiba wrote:


> wrote:
> 
>>they use a indentation rule to figure out when a statement belongs to 
>>a block
>>
> 
> But in case of complicated mesh2 it could be horrible wasting of drive space.
> 
> ABX
> 

I didn't mention that, but in haskell you are not bound to use
the layout-rule. You can as well go on and type as many {{{braces}}}
as you like. Only if you open a block without using a brace, the
compiler can figure out by indentation.


Post a reply to this message

From: Hermann Voßeler
Subject: Re: Possible POV Object Scheme (was Re: Pov 4.00 question)
Date: 14 Feb 2002 09:30:03
Message: <3C6BC80E.9030609@webcon.de>
Tom Melly wrote:


> news:3C6### [at] webconde...
> 
> <snip>
> 
> Might be worth implementing if only to see Ken turning in his grave.... ("But
> he's not dead", "No, but this will kill him")
> 
> I don't like it, although I can see the attraction. It strikes me as mixing up
> style and content - which is exactly the confusion that got html/browsers in to
> such trouble....
> 

the point is, it makes code much more readable, because it reduces
"syntactic noise".

Programmers usualy indent their code carefuly in order to make the
structure clear to the human reader. Only those dumb compilers don't
get right what everyone can see clearly :-;
You know, the "dangling else"-problem...

Thus, its not mixing up style and content.
With this rule, indentation is no longer a question of style but
caries valid information content, that can be exploited by the 
compiler to resolve ambiguities.


Post a reply to this message

From: Warp
Subject: Re: Possible POV Object Scheme (was Re: Pov 4.00 question)
Date: 14 Feb 2002 09:45:47
Message: <3c6bcd9b@news.povray.org>

: the point is, it makes code much more readable, because it reduces
: "syntactic noise".

: Programmers usualy indent their code carefuly in order to make the
: structure clear to the human reader. Only those dumb compilers don't
: get right what everyone can see clearly :-;
: You know, the "dangling else"-problem...

  The ability of making obfuscated POV-Ray signatures is a must. Any change
in the syntax which makes obfuscation or reducing a piece of code more
difficult is not good.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -


Post a reply to this message

<<< Previous 10 Messages Goto Latest 10 Messages Next 10 Messages >>>

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.