[clean-list] Wish list, part 3

[John W. Small]

1.  I wish that the command line option "-con" were settable
from within an application so that the application can decide
whether or not to request that the user hit any key to continue.

2. I wish we had something I call aggressive evaluation.
Suppose we have something like:

    add x y = x + y

    inc y = add 1 y

If we could instead have:

    inc = add 1 _

then "add 1 _" could under go aggressive evaluation instead of being
a mere functional closure.  The "_" in this case doesn't mean don't care
but instead means don't know yet.  Thus after aggressive evaluation, i.e.
logical rewrite at compile time reducing everything except what we don't
know yet, we would end up with essentially

    inc = \y -> 1 + y

Once dynamics are fully implemented it would seem this would be
plausible albeit painful to implement.

Now suppose we have

    sum x y z = x + y + z

    foo = sum 1 _

which would reduce to

    foo = \ y z -> 1 + y + z

It would even be possible to write

    foobar = sum 1 _ 2

which would reduce to

    foobar = \ y -> 1 + y + 2

Or course this is essentially a functional closure but with one
important distinction, i.e. any optimizing rewrites have been
taken advantage of  at compile time.

I think aggressive evaluation is similar to multistage programming
in a way.  Reasoning about types would become fascinating as
well especially when aggressive evaluation is thought to bridge
embedded domain languages and their implicit types.  Perhaps
dynamic types could then be thought of in terms of transforms
between languages which could than be fed back to reason about
"implicit types."

John

----- Original Message ----- 
From: "Marco Kesseler" <m.wittebrood@mailbox.kun.nl>
To: <clean-list@cs.kun.nl>
Sent: Saturday, April 06, 2002 1:40 PM
Subject: [clean-list] Wish list, part 3


> 
> things are a bit quiet here on the Clean list, so here are a few more 
> items for my wish-list. If anyone has wish-list items too, or has 
> reasons why something should NOT be on this wish-list, please post it 
> to this mailing list. Expressing support for a particular item is 
> also welcome. I think that a generally accepted wish-list is a good 
> starting point for getting some work organised (eventually). I am not 
> pretending that I know what is good for everybody, so discussions are 
> welcome. 
> 
> That does not mean that I actually know who is going to do the 
> implementation work..., that's another matter. 
> 
> Some time ago, there was talk of organising an implementer/user 
> meeting (in Nijmegen). Any news on that?
> 
> --------------------
> 
> onto the wish list.
> 
> already present:
> - better interfacing with imperative (object-oriented) languages (at 
> least
>   allowing Clean to be called from these languages).
> - support for exceptions
> 
> Wish 3:
> 
> compile-time evaluation of constant expressions. This is important 
> for efficiency and readablility.
> 
> I can remember two (similar) cases where this would have been useful 
> in my code:
> - fixed-point numbers: it is easy to write a macro/function FIX that 
> transforms floating point numbers into the corresponding fixed-point 
> representation, but using it is currently very inneficient, because 
> it does not get evaluated at compile-time.
> - Unicode: one can define a function Unicode that transforms an 
> ordinary ASCII string to its Unicode equivalent, but currently, this 
> does not get transformed into a Unicode literal.
> 
> Wish 4:
> 
> conditional compilation. Clean is not as platform independent as one 
> would like. This is not so much due to the language, as to the 
> (un)availability of libraries for various platforms. Apart from this, 
> I usually have a hard (i.e. boring) time enabling/disabling all kinds 
> of debugging/testing code.
> 
> Wish 5:
> 
> This falls in the category that dutch people call 'klein leed' 
> (little sorrow). I think that 'symbolic simplicity, convenience and 
> consistency' kind of sums it up, or:
> 
> what's in a symbol, that its name...
> 
> I know that getting this one right can be hard, but I feel things 
> have gotten a bit out of hand in Clean. The same complex syntactical 
> interactions that make this difficult to solve, also make things 
> difficult for programmers to grasp. What am I talking about?
> 
> - the list of cryptic keywords is growing steadily, and sometimes in 
> seemingly ad-hoc ways. Take for example the recently added support 
> for strict lists. This feature is important, but it comes with a new 
> set of denotations, which does not make things simpler. One would 
> think that the overloading mechanism should be able to avoid many of 
> this (more about overloading in a later message). Isn't it possible 
> to just stick with <- in list comprehensions, instead of <-, <-: and 
> <|-. Why do I have to write [!, [# or [| if the type of my function 
> already specifies what kind of list it is dealing with? These things 
> make it hard to change from ordinary lists to strict ones.
> 
> - I know there are good implementation reasons to distinguish tuples 
> from records and arrays from lists. From the same implementation view 
> one may argue that records and arrays are similar. Well, the Clean 
> syntax supports the implementers view, but it does not support the 
> programmers view for whom tuples and records are conceptually the 
> same, and lists and arrays are at least related.
> 
> - Related to the previous: ASCII symbols are a scarce resource. It is 
> a pity that square brackets have been devoted to lists, which are 
> just an algebraic type, and thus do not need any special notation, 
> except for their own constructor. The result of this choice is 
> apparently that square brackets cannot be used to identify array 
> types anymore, which is what some well-known languages use. And note 
> that Clean itself uses square brackets for array selection as well.
> 
> - The clean rules for identifiers are such that they can either 
> consist of ordinary characters, or of some special characters, but 
> not both. Otherwise the compiler has trouble interpreting things like 
> 'n+1'. In my opinion this is a pity, because:
> a) I have no trouble writing 'n + 1' (i.e. with spaces, which I often 
> do anyway)
> b) I prefer a simple rule that all symbols are separated by 
> whitespace (and brackets)
> c) I would very much like to markup my symbols like >add<,  >sub< for 
> dyadic operators, or symbol+, symbol*, symbol? for parsing functions, 
> or @node for labels, or <elem> and </elem> for constructors. 
> d) I don't believe that things like (<?@) make your code any more 
> readable (taken from parser combinator stuff).
> 
> regards,
> Marco
> 
> _______________________________________________
> clean-list mailing list
> clean-list@cs.kun.nl
> http://www.cs.kun.nl/mailman/listinfo/clean-list
>