Re: language design for handling library-complexity/learnability

["Henning von Rosen" <address@hidden>]

> One way to avoid a huge list of names is to have higher
> order functions.  Instead of both member-if and
> member-if-not, remove-if and remove-if-not, have just
> whatever-if and complement.

Is there a principal reason why not the if-combinations could be
constructable as well?

> In Arc we may make let people express operations on
> functions implicitly by doing things to their names.  For
> example, we may make foobar work as a way of expressing
> (fn (a . args) (apply foo (bar a) args))), so e.g.
> (eqcar x 5) would be a legal way to say (eq (car x) 5).

I like the principle! (must think about it). How do you resolve
namecollisions? Or does atomic names have precedence? In natural langs the
parts making up a word may belong to various classes. Thus helping to handle
complicated namingschemes and making possible one-word shortcuts as well as
multiple higher-order combinates... Sorry if I misunderstood.

/Henning

> We'll see how it works.
>
> --pg
>
> --- Henning von Rosen <henning@ikso.net> wrote:
> > this quote is from the former Caltech "Parallel Computing Works"
> > http://www.npac.syr.edu/copywrite/pcw/node405.html
> >
> > "Our claim is that the good ``in large'' computer language design
> > should
> > contain a nontrivial ``common English'' part, useful by itself for a
> > broad
> > set of generic tasks, and it should offer a graded, multiscale
> > extensibility model towards specialized expert dialects. Indeed, we
> > program
> > by building reusable associations between software entities and
> > names. Each
> > ``in large'' programming model unavoidably contains a large number of
> > names.
> > The disciplined and structured process of naming software entities is
> > crucial for successful complexity control. In languages such as C or
> > Fortran, the ``common English'' part is reduced to arithmetic and
> > simple
> > control structures such as if, for, switch, and so on. All other
> > names are
> > simply mapped on a huge and ever-growing linear chain of library
> > functions.
> > The original language syntax, based on mathematics notation,
> > degenerates
> > towards a poorly organized functional programming style. ``In large''
> > programming in such languages becomes very complex. "
> >
> > The text is a decade old. Questions:
> >
> > How relevant is the problem description to you?
> >
> > What languages by your opinion meets the demands presented in the
> > quote
> > best?
> >
> > If you are a language designer; how did you design in order to avoid
> > the
> > "All other names are simply mapped on a huge and ever-growing linear
> > chain
> > of library functions"-problem from above?
> >
> > thanks for any comments!
> >
> > amike via Henning
> >
> >
>
>
> __________________________________________________
> Do You Yahoo!?
> Send FREE video emails in Yahoo! Mail!
> http://promo.yahoo.com/videomail/