Re: Inline VALOF

["Barry Cook" <Barry@xxxxxxxxxxxx>]

All,

Perhaps we should be selective in applying Occam's razor - there are many 
things that are more 'complex' than they need to be but that 'complexity' 
introduces convenience which is of more value.

Examples:
- Differential calculus - we COULD stick with "the limit as x tends to zero"
- High-level programming languages - we COULD do it all with assembler
- occam (see above)

A real challenge is that each user probably has their own view of what is 
convenient - I certainly do and different projects demand different 
conveniences. A programming language that is easy to use for data-base 
access is unlikely to be the best for scientific calculations and neither 
very good for an embedded processor in a photocopier. There is never likely 
to be agreement that "Language X" is the best for everything and hence the 
observed lack of universal acclaim for occam, C, Java, FORTRAN, ... 
(although occam's razor would suggest it could all be done with 80x86 code). 
It is likely that the minimal offering suggested by Occam's razor may be 
'elegant' but probably considered of little practical use. This is the 
thinking behind my thinking-aloud on the subject of identifying the 
application that would see occam(-like) notation as valuable. (Summary of 
responses: where there is a powerful need for security or correctness 
guarantees.)

[Before anyone denies wanting their own notation I would point out that 
declaring a procedure to encapsulate things and give them a useful 
abbreviation IS adding to a language (in an application specific way) and 
clearly shows the desire, and value, of moving beyond the minimalist 
approach.]

   Barry (awaiting counter-arguments).

Dr Barry M. Cook, BSc, PhD, CEng, MBCS, CITP, MIEEE
CTO,
4Links Limited,
The Mansion,
Bletchley Park,
MK3 6ZP,
UK.
----- Original Message ----- 
From: "A.E.Lawrence" <A.E.Lawrence@xxxxxxxxxxx>
To: "Denis A Nicole" <dan@xxxxxxxxxxxxxxx>
Cc: <occam-com@xxxxxxxxxx>
Sent: Wednesday, December 13, 2006 1:02 PM
Subject: Re: Inline VALOF


> Denis A Nicole wrote:
> > On Tue, 12 Dec 2006, Adam Sampson wrote:
> >
> >
> > > Has anybody:
> > >
> > > - used inline VALOF in real code at all?
> > >
> > > - found interesting uses for inline VALOF (that can't be obtained as
> > >  elegantly using named FUNCTIONs)?
> >
> >
> > Won't taking VALOF out upset the BCPL community? I think we once 
> > supported
> > mixed occam1/BCPL on the Atari ST and maybe the Sinclair QL.
> >
> > More seriously, could occam-pi support something like the B ? E : E'
> > syntax of C and Java or the E if B else E' of Python 2.5? It might be an
> > appropriate replacement.
>
> Would this not violate the "razor"? Quite apart from my instinctive
> repugnance :-)
>
> Adrian