A few observations Re: Clean

Adrian Hey ahey@iee.org
Wed, 08 Apr 1998 22:37:58 +0100 (BST)


On Mon 06 Apr, rinus plasmeijer wrote:

> >Gripe 1 - List Expressions
> >--------------------------

>For easy porting you can define your own infix Cons operator and simply
>change every ':' to this operator.

Yes I did think of that, but didn't try it because it wouldn't sort out the
same problem with list patterns (unless the Clean compiler is a lot smarter
than I thought). In fact it would be even worse because syntax wouldn't
even be consistent within same module.

> >Perhaps to retain compatibility with current Clean a pragma could be
> >introduced to enable this feature for those who want it.
>
>Why not.

On reflection I think this probably isn't such a good idea because it would
mean Clean had 2 alternative syntax's, which would almost certainly cause
more confusion than it cured. Please forget I mentioned it. I guess aspiring
Clean programmers will just have to make the effort to get into Clean think
mode.


> >Gripe 2 - Memory Allocation
> >---------------------------
> >When compiling a program you have to specify how much heap space and
> >stack space to use separately. The problem with this is how can you
> >really know the best values. In most cases these will depend entirely
> >on what data the program gets. It would help if just 1 value
> >(total memory to use) was supplied and the run-time system made best
> >possible use of this memory using stack-heap collision detection.
> >(Or better still, if the OS allows, the application could just grab
> >memory as required at run time. I suspect MacOS won't let you do this
> >though, since even the latest versions of this supposedly wonderful OS
> >don't seem to be able to sort out memory fragmentation without a
> >shutdown.)
>
>This is indeed the problem.

Hmm.. You don't appear to be very confident regarding a solution.
I'm not really sure I understand what the problem is...
Is it a Clean implementation problem? If so it shouldn't be to hard to fix.
or...
Is it an OS problem? If so it must afflict applications programmers using
whatever language. I wonder what they do about it. The only OS I really
know much about is RiscOS and I know its easy for RiscOS apps to get more
memory from the OS if they need it (provided the OS has some free of course).

It seems to me that this is a pretty serious problem. You might be
able to live with it whilst developing 'experimental' software on your
own machine. But what if you were to use Clean for a commercial
application? You wouldn't know how much memory end users had, so you would
be wise to set the figures small. But somebody who had invested in 256Mb RAM
might get a bit annoyed if the application only used 8Mb and then stopped
complaining about lack of memory.
Have I missed something here?
Am I being stupid?

Also, I don't understand what the {Maximum Heap Size, Initial Heap Size,
Next Heap Size Factor} applications options in the IDE really do. HELP seems
a little vague on this subject. The fact that there are 'Initial' and
'Maximum' Heap sizes suggests to me that heap size isn't fixed, but I'm
probably wrong.

> >Gripe 3 - Arity in Function Types
> >---------------------------------
> >The Clean system requires that the types assigned to functions aggree
> >with the arity of the function definition. Why? I can't think of any
> >reason the programmer should need to know a functions arity.
>
>You are right. The reasons is that the compiler demands this (for reasons
>of efficiency) because it can't find it out when module boundaries are crossed.
>
> >I appreciate that at the machine level implementation it is necessary to
> >know how many arguments a 'graph-rewriting' routine actually requires,
> >but surely this information could be generated automatically by the
> >compiler and hidden away somewhere in the Clean System Files.
>
>That indeed would be a solution. But this would slow down the
>compilation process because the additional information has to be read in.
>For your information: I/O handling is one of the major botylenecks in
>the compilation process.
>
> >This may seem a minor point, but it causes me real grief when I use
> >synonyms for function types (as I often do). It would appear that
> >whoever wrote the parser combinators detailed in chapter II.5 of the
> >'Functional Programming in Clean' book had the same problem.
>
>I agree that it would be nice if we could solve this problem.
>It is small but annoying.

Believe it or not, I have no gripes about the speed of the compiler.
A compiler must be really slow if you spend a significant part of your
day waiting for it. If you want to see a really slow compiler I suggest
you try using ADA (yuk!) if you haven't already.

I think having a 'nice' language is more important than having an ultra fast
compiler. That's my own personal opinion, of course. Others may disagree.

Regards,
-- 
Adrian Hey