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

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

: 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

Nekar Xenos <jpr### [at] citywalkcoza> wrote:
: I would rather just do away with the #'s.

  It's true that getting rid of most #'s would do more good than harm.
The reason for the #-commands is that they initially worked like the
preprocessor commands in C, that is, they just #included something and
#declared some constants, like you can do in the C preprocessor.
  However, as time passed, the #-commands developed into a full scripting
language which no more resemble a preprocessor but are direct script commands.

  Thus it might be a good idea to keep the #'s in the commands which are
clearly "preprocessor" commands and remove them (or better make them optional)
in scripting language commands (control flow commands, variable assignments
and so on).

-- 
#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

In article <3C6### [at] webconde>,


> 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.

I've never liked the idea of a language that relied on indentation and 
white space as controlling elements. Some kind of visible block 
delimiter is much better, and "{}" are already used in many languages, 
so people are familiar with them. Explicit begin and end keywords are 
also used in some languages, these take more typing and make more 
cluttered code in my opinion, but are better than whitespace.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

In article <3C6### [at] webconde>,


> 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.

Aack! That would be worse than indentation-only...I can imagine files 
with a horrible mix of indentation and brackets, users being unsure of 
where they can put brackets, bugs because of accidental mixing of 
brackets and indentation, etc...it would also be harder to read.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

How would it handle something like this:

#if(Fast)
  box
    -1,1
#else
  superellipsoid
    <.1,1>
#end
    pigment
      rgb 1

-- 
#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

On 14 Feb 2002 11:57:01 -0500, Warp <war### [at] tagpovrayorg> wrote:

>  How would it handle something like this:

I wonder how it could handle this in intendation mode:

#macro o()object{#end
#macro b()box{#end
#macro f()function{#end
#macro p()pigment{color#end
#local C=f()pattern{o()b()1 2}}}}
#local B=b()C(1.5,1.5,1.5)2p()1}}
o()B}

:-)

ABX

Post a reply to this message

Christopher James Huff wrote:

 >
 > I've never liked the idea of a language that relied on indentation
 > and white space as controlling elements. Some kind of visible block
 > delimiter is much better, and "{}" are already used in many
 > languages, so people are familiar with them. Explicit begin and end
 > keywords are also used in some languages, these take more typing
 > and make more cluttered code in my opinion, but are better than
 > whitespace.
 >


Indeed, I also where rather sceptic, as I lerned haskell some years
ago. I didn't like the idea and thought it would cause problems all
the time. It was a big surprise how good it worked. Of course, the
braces are more of a problem in a functional language with all the
function-style-if-then-else, alternativ clauses and pattern matching
definitions.

Maybee, one reason it works so well there is, that haskell has a
rather elaborated type system and thus the compiler can generate very
specific and precise error messages. Morover the layout rule is an
optional feature and activated on a per-statement-base, when the
opening brace is missing. This, btw, makes implementing the parser
rather a tough job, because there has to be a sort of "talkback"
channel between parser and tokenizer.

Post a reply to this message

...if macros are defined strictly as mere copy-and-paste
operations, then there will be no problem as long as the
compiler sees valid code after macro expansion. (One of
the haskell compilers indeed uses the c preprocessor to
do such things)

Warp wrote:

 >   How would it handle something like this:
 >
 > #if(Fast)
 >   box
 >     -1,1
 > #else
 >   superellipsoid
 >     <.1,1>
 > #end
 >     pigment
 >       rgb 1
 >



> I wonder how it could handle this in intendation mode:
> #macro o()object{#end
> #macro b()box{#end
> #macro f()function{#end
> #macro p()pigment{color#end
> #local C=f()pattern{o()b()1 2}}}}
> #local B=b()C(1.5,1.5,1.5)2p()1}}
> o()B}
> 
> :-)
> 
> ABX
>

Post a reply to this message