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

<h.v### [at] webconde>  wrote:

> do you know the haskell (funcitonal) programming language?

Why do people always have to mention these "strange" languages? :-)

If I hadn't had to try Haskell, maybe I would be more favorable of its (I have
to admit not too bad) implementation of some old ideas.  Nevertheless, like
all these odd languages, it is not even close to the smooth* learning curve of
the traditional programming languages (which have proven they are capable of
more than a few hundred lines of nice examples how compact they can solve a
problem, which seems to be the common reason to invent a new language) or some
even more high-level languages specifically designed for end user programming.

After all, for someone with no programming experience the elegance an expert
can find in a language hardly matters.  What is far more important is a close
to zero learning curve and very good feedback (and i.e. the common Haskell
error messages are more than cryptic IMHO, even compared to POV-Ray).

    Thorsten

* For various reasons, one being that for "popular" languages there are
usually very good books, while for less popular languages there are no or very
few mostly useless books.

Post a reply to this message

In article <chr### [at] netplexaussieorg> , Christopher
James Huff <chr### [at] maccom>  wrote:

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

And even worse, these languages are just as open to language feature abuse as
the languages they try to improve on.

I am sure the below gets screwed up by posting here (because of wrapping
lines), but I think it gives everybody an idea of a pointless use of a
language.  Before anybody looks at the code, I should point out that I only
had about 1.5 hours and zero motivation to do the below as a homework
assignment.  I did not read the manual, I simply took some examples and cooked
something out of what I had with minimal effort.  This is why my tree insert
function is the most brain-dead and least efficient possible implementation,
thus providing a perfect example how to abuse this supposedly elegant language
... not to mention, even in C the code would not only be shorter but IMO also
more understandable when just looking at it.  Not to mention C++ and the STL,
which would reduce the code below to next to zero work!  And I can think of
much shorter Lisp implementations of such a trivial thing as well.

-- Set 2

-- Binary Tree Data Structure

data Mtree middle = Null | Leaf middle | Fork (Mtree middle) middle (Mtree
middle)
                    deriving (Show)

-- Utility Functions

-- Function:    list2tree
-- Parameters:  tree, list
-- Theory of operation:
--   Given an empty tree and an ordered list, this function will build
--   a valid tree out it.  The tree has only right nodes in exactly the
--   same order as they appear in the list.  Note that because the tree
--   is constructed recursively the list has to be reversed in order to
--   get a valid binary tree.  Of course, this tree is the worst of all
--   possible trees, but there is no question it is valid.

list2tree Null [] = Null
list2tree (Leaf middle) [] = (Leaf middle)
list2tree (Fork left middle right) [] = (Fork left middle right)
list2tree Null (x:xs) = list2tree (Leaf x) (reverse xs)
list2tree (Leaf middle) (x:xs) = list2tree (Fork Null middle (Leaf x)) xs
list2tree (Fork ignore middle right) (x:xs) = list2tree (Fork Null middle
(Fork Null x right)) xs


-- Function:    ordlistinsert
-- Parameters:  element, list
-- Theory of operation:
--   Given an element and an ordered list, this function will insert the
--   at the appropriate position based on the order defined by the less
--   than comparison operator.

ordlistinsert element [] = []
ordlistinsert element (x:xs) | x < element = [x] ++ (listinsert element xs)
                             | otherwise = [element] ++ [x] ++ xs


-- Assignment Set 2

-- Set 2.1

-- Function:    tflatten
-- Parameters:  Mtree
-- Theory of operation:
--   Given a tree, this function constructs a list containing the nodes
--   inorder as they appear in the tree from left to right, depthest node
--   first.

tflatten Null = []
tflatten (Leaf middle) = [middle]
tflatten (Fork left middle right) = tflatten (left ++ [middle] ++ tflatten)
right


-- Set 2.2

-- Function:    depth
-- Parameters:  Mtree
-- Theory of operation:
--   Walks through the whole tree recursivly and always returns the
--   greatest depth of a subtree.

depth Null = 0
depth (Leaf ignore) = 0
depth (Fork left ignore right) | (depth left) >= (depth right) = (depth left)
+ 1
                               | otherwise = (depth right) + 1


-- Set 2.3

-- Function:    insert
-- Parameters:  Mtree, element
-- Theory of operation:
--   This is the simplest possible implementation based on the previously
--   defined functions.  It uses the tflatten, list2tree and ordlistinsert
--   functions to get a list of the tree nodes, then inserts the given
--   element and turns the list back into a tree.  Since a recursive tree
--   insert function (provided as function betterinsert) does not create
--   a perfectly balanced tree, a banaced tree is obviously not part of the
--   assignment and the given tree is valid because the assignment required
--   only that the "mathematical ordering for integers and the lexiographical
--   order for strings".  This function does exactly that, and based on it
--   it is easy to write a function to return a balanced tree.

insert Null x = Leaf x
insert (Leaf middle) x | x < middle = Fork (Leaf x) middle Null
                       | otherwise = Fork Null middle (Leaf x)
insert (Fork left middle right) x = list2tree Null (ordlistinsert x ((tflatten
left) ++ [middle] ++ (tflatten right)))


-- Function:    betterinsert
-- Parameters:  Mtree, element
-- Theory of operation:
--   Recursive version of insert that keeps the tree in shape.  The new
--   node is inserted and the rest of the tree is moved to a leaf, either
--   the left or the right one, depending on the node compared to the
--   element to insert.

betterinsert Null x = (Leaf x)
betterinsert (Leaf middle) x | x < middle = Fork (Leaf x) middle (Null)
                             | otherwise = Fork (Null) middle (Leaf x)
betterinsert (Fork left middle right) x | x < middle = Fork (betterinsert left
x) middle right
                                        | otherwise = Fork left middle
(betterinsert right x)


-- Set 2.4

-- Function:    remove
-- Parameters:  Mtree, element
-- Theory of operation:
--   The function works analog to insert.  Since this function satisfies
--   requirements set by the assignment, I will not waste my time with the
--   recursive implementation of this function.

remove Null x = Null
remove (Leaf middle) x | middle == x = Null
                       | otherwise = (Leaf middle)
remove (Fork left middle right) x | middle == x = list2tree Null (dropWhile (x
==) ((tflatten left) ++ (tflatten right)))
                                  | otherwise = list2tree Null (dropWhile (x
==) ((tflatten left) ++ [middle] ++ (tflatten right)))

Post a reply to this message

: ...if macros are defined strictly as mere copy-and-paste
: operations

  But they aren't.

  This:

#macro A()
  #local Val = 2;
#end

#local Val = 1;
A()
// Val is 1 at this point

is *not* what a copy-and-paste macro scheme would do:

#local Val = 1;
#local Val = 2;
// Val is 2 at this point

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