One step at a time

[Kyle Lahnakoski]

> The tool then must assume all the Tunes
> requirements.  To be self-extensible it must be
> self-defining.  Here I part with another of the
> Tunes "assumptions".  While agreeing that an HLL is
> a high level language I disagree that it is a high
> level (programming) language.  For me it is a high
> level (specification) language, a HLL language that
> is self-defining, self-extensible, and most
> importantly self-sufficient, i.e. never requiring
> the interceding of another language.

I agree with this statement here.  Any programming language should be a
subset of the HLL.  A programming language with all the complexities of
the HLL would be too dynamic or complex for humans to understand.  It is
better to see the HLL as a set of domain specific languages.


> This means that within its source form it can
> encompass all aspects of any hardware or software
> system.  As a specification language it means
> containing the specifications of any machine
> architecture for which we will execute software.
> Thus at the lowest levels of abstraction we will
> have the various target machine architectures with
> a selectable connectivity (a path) to any higher
> level abstraction (levels of abstraction).

I would assume that you mean the HLL will be able to describe the
specification for any hardware, and describe what the optimizations
measures are for the hardware.  Furthermore I believe you are saying
that a hardware specification language is a subset of HLL.  I have been
doing a little work on the high level description of low level
operations. 



> If you want to actually engage in "complete
> rethinking", I would suggest that you do so.  That
> means starting with as clean a set of assumptions
> as possible.  That applies to programs (as human
> productions), to objects, and to source forms.

I am an incremental fellow.  I believe a complete rethink is not needed;
any starting system can be evolved into Tunes, and like a caterpillar,
can shed its origins eventually.  I will admit that evolution is usually
slower than revolution, but at least there is a working system at all
stages.  Anyway, a Tunes revolution will never be realized, starting
from scratch will have as many code rewrites as an evolved system just
because Tunes has no formal specification.

I would like to hear Water's thoughts on this point.  His work on the
Arrow system should have given him the experience to comment on the work
required to do a complete rethink.  I would also like to hear from
others that have started from scratch and tell their stories.



> I would also suggest that you not belittle other
> systems, but have a clear understanding of what is
> right and what is not so right within them.  Then
> you can profitably engage in a culling process for
> the "right" and a corrective one for the "not so
> right".  Every one of them is a serious attempt by
> their author(s) and advocate(s) to do at least in
> part what we are attempting.  In that manner we can
> continue as part of a "common cause".

This last paragraph is what prompted me to reply.  I find the language
reviews to not be helpful at all.  They do not specifically show the
good and bad points of each language.  Such a discussion would go into
the semantics and syntax of the language and compare to others. 

I would like to rewrite the language reviews.  I would need everyone's
help here because I do not know most of these languages.  For example,
Haskell is one I am learning now, and the type system is quite a complex
unfamiliar beast.  But I wonder about how powerful static typing is, and
I doubt it would handle well in a system with dynamic types.

----------------------------------------------------------------------
Kyle Lahnakoski                                  Arcavia Software Ltd.
(416) 892-7784                                 http://www.arcavia.com