<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