[clean-list] Operator :=

[Antonio Eduardo Costa Pereira]

Could any one tell me what is going on? I typed the following
program:

module StringExample
import StdEnv

pMaiusculas :: String-> String
pMaiusculas xs= (loop xs 0, xs)
where
	sz= size xs-1
	loop s i | i > sz= s
	loop s i
	= loop (s := (i, toUpper s.[i])) (i+1)

Start= pMaiusculas s
where
	s= "Eduardo"

The intention was to convert a String to upper case. I thought
that the program would update s in place. It seems that this is
not what is going on. If the operator := is making a copy
of s at each iteration, why is it necessary in the language?
ZF operations should be enough.

Eduardo Costa

03/09/00 19:53:47, rinus plasmeijer <rinus@cs.kun.nl> wrote:

>Dear Panitz,
>
>> The other day I found an old clean manual on my book shelve:
>> 'concurrent clean language manual version 0.8.3 february 1993'.
>> In those days I was playing around with clean on a small
>> apple powerbook (with 4mb memory..)
>> 
>> Well that is some time ago! Nowadays I mainly use clean on my 
small
>> linux laptop or an old mac desktop.
>> 
>> I remember the fist time when Rinus Plasmijer presented clean 
1.0 on a
>> conference and how I was looking forward to that release.
>> Now we are waiting for the second mayor clean release: Clean 
2.0!
>> 
>> If I understand the information on the web site correctly this 
will
>> be a completely new dimension for clean and clean no longer 
looks
>> like a fast Haskell compiler with a little bit different syntax
>> and a good IO library, but a more powerful language with a lot 
of
>> additional features:
>
>> dynamics:
>> is this what I think? like in good old lisp days converting a 
string
>> into an epression? Wow! I could have used that in a program, 
where I now
>> wrote a parser for certain expressions.
>
>This is true. We now have the first examples running.
>One can dump any Clean expression in a dynamic on file (including
>closures), read it in another Clean
>program where the corresponding code is linked in dynamically.
>No parsers needed !
>
>> 
>> btw: those very long threads in comp.language.functional 'static 
vs dynamic
>> typing' will have a simple answer in the future: Clean! 
Especially I wonder
>> what the Erlang people will say. They insist that dynamic typing 
and linking
>> is needed in their area of application.
>
>I agree. With dynamics you have both static as well as dynamic 
typing.
>
>> 
>> Since the new Clean compiler is written mainly in clean, does 
that mean
>> that with dynamics we also get a Hugs like interpreter for 
clean?
>
>Maarten de Mol is working on the proof system for Clean.
>It has a great user-interface including a Clean interpreter which 
can do
>symbolic reduction as well.
>It might be a good idea to use the dynamic linker to include code
>dynamically such that one has an ideal mixture of interpreter and
>compiler.
>
>> 
>> And you are also planning to make the parts written in clean 
open source?
>
>All Clean source code will be put on the net.
>
>
>> Well who knows what will happen with that. Maybe someone who 
does not know
>> what to do with his/her spare time will write a Haskell 
frontend, so
>> that one can have mixed Haskell/Clean projects (and moving from
>> Haskell to Clean will be fairly easy, or using Haskell libraries 
will be
>> possible).
>
>As a matter of fact, I am looking for volunteers to make such a
>front-end.
>The idea to change the Clean parser to accept haskell code.
>It would be nice if Clean and Hassle modules could be combined 
into one
>application....
>
>> How difficult would it be to write such a Haskell frontend?
>
>Most of it will be very straightforward.
>The main problems I see will be caused by the different module 
structure
>of Clean and Haskell.
>
>> I guess the Clean compiler has some intermediate language,
>> so a Haskell parser and type  checker as well as a
>> transformer to that intermediate language would be needed.
>
>No, I think you only need to change the parser to accept Haskell 
syntax.
>Clean compiles to Core-Clean. One can also translate Haskell to
>Core-Clean.
>The main problem will be the module structure (Clean has dcl and 
icl
>modules which are much more convenient than the Haskell module
>structure).
>
>> And these things could be derived from the Clean parser and typ 
checker
>> or from some Haskell compiler written itself in Haskell (e.g. 
nhc and
>> then the 'n' of nhc could have a new meaning ...:-)).
>
>This would be one way to do it. I would prefer just to change the
>current Clean parser...
>
>> 
>> Well, I am looking forward to Clean 2.0, but I know, in order 
the get the
>> quality we are used from the team in Nijmegen, we simply have to 
wait
>> a bit more.
>
>Sorry about that. We could release the compiler today.
>But, we would get many bug reports.
>We rather test it until we believe the system is fine.
>
>
>By the way: we will release Clean 1.3.3 very soon. Next week. This 
week
>we are almost all joining IFL in Aachen.
>The 1.3.3 system contains some small improvements over 1.3.2 and
>contains some support for Clean 2.0.
>We have tested it for over a year.
>
>> 
>> Regards Sven Eric,
>> (who still could not convince his boss to make a project in
>> Clean and is therefore forced to make his living with Java 
hacking :-( )
>
>Life is hard..
>
>Greetings,
>
>Rinus
>
>