OT: GCed Forth-like language, proof checking and machine code generation (was: migrating to mediawiki)

[Hendrik Boom]

On Fri, Oct 21, 2005 at 10:14:53PM +0200, Massimo Dentico wrote:
> First of all: my apologies to Hendrik Boom for giving him the
> wrong impression that people on this (zombie) project can be
> interested in his work. Only *I* am interested.
> 
> 
> Brian Rice wrote:
> 
> >...someone brings up their project to us thinking that they'll
> >gain volunteers or our "blessing" or something. In fact, that
> >seems to be the only thing that most people consider this list
> >worthwhile for.

Not looking for volunteers.  I have strong intentions what this project
is intended for, and, frankly, there's not enough of it present that
volunteers could be of much use.  My impression is that volunteers
are good when it's a case of filling in details in an existing
structure, or in rebuilding something that has already been done
before (perhaps to achieve a new license, or to accomodate a
new shared vision of basic implementation techniques), or to grow
systems by evolution and natural selection.  This is new creation,
I'm not sure where it's going, and a team of volunteers would
probably be a hindrance at this point.

I'm trying to see how low-level a statically strongly-typed language can be
and still be both useful and secure.  It's involved some innovation
in my understanding of what a type-system can be, to say the least.

> 
> Not fair and, frankly, ridiculous: he has found us, has written
> asking for information about the outcome of a past discussion and
> then I have replied with some information and ideas. Now, after
> months, he is just informing us about his progress.

Actually, I was under the impression that the end-product of my
work might be TUNES-related, if it evar got that far.  I was
answering a questipn whether there was any TIMES-related coding
work anuwhere.  I hesitated before replying.

> 
> He is not certainly waiting for volunteers nor he needs our
> "blessing".
> 
> Again, here is the thread readers can check:
> 
> http://lists.tunes.org/archives/tunes-lll/2005-April/thread.html
> 
> 
> And just that I'm here:
> 
> Brian Rice wrote:
> >>>Most TUNES members really do not follow what is
> >>>actually going on in the wide world of computer
> >>>science. That's worthless for this project, since
> >>>the point is to provide a common convergence goal.
> 
> Part (most?) of what is actually going on in the wide world
> of computer science is total crap. Digging into this garbage
> to find interesting things and occasionally a pearl is an
> ungrateful task.

I quite agree.  Things were different in the sixties, when
I first got involved with computers.  The use of computers
is expanding far faster than the knowledge how to use them
is spreading.  Crap is the natural result. 

> 
> 
> >We, as TUNES project members, should not endorse or pay any mind to  
> >projects which attempt to become new "metarecursive lumps" except via  
> >providing a migration path for existing software via multiple paths -  
> >we need software that ties things together, ...

I have some hopes in this direction.  My threaded-code system is
intended to be a possible target code for a variety of source
languages, but only run-time secure ones, where the programmer
cannot break the run-time structures.  I'm deliberately not
defining any official, human-adapted source-code syntax.

> 
> This is void of content: I remember to have asked you about the
> meta-translator subproject (without which this "software that ties
> things together" will be yet another "interoperability" and "back
> compatibility" idiocy). In your opinion, it was "too difficult for
> us right now" or something like that. How is it more attainable
> now?

Actually, I have a metarecursive translator on the shelf.  It has:
   * a top-down, recursive-descent parser with backtracking and a few
hacks of the kind that distinguish real-life parsing from theoretical
LL(1) stuff
   * a recursive-descent tree-transformation subsystem with support
for ejecting subtrees from deep down near the leaves of the tree to
collection points near the root (very useful for generation code in
language that want to see declarations at the beginning of a block,
or at the beginning of the program)
   * an excessively rudimentary unparsing sublanguage.

Its main deficiencies are:
   * It generates C code, and was bootstrapped from C.
   * It needs a garbage collector.  At present I just rely on my
gigabyte of RAM not running out.
   * It is not strongly statically typed.

It would take maybe a month or two for me to document this thing for
any kind of release, it anyone were interested.

In fact, it is he deficiencies of this system that have led me the
threaded-code stuff I am working on now.  I'm planning someday to
retarget this to threaded, garbage-collected code with some very
carefully designed threaded-code primitive operations.

> 
> 
> >... not a new pile of research legacy code.
> 
> He never said that. I understood it will be a new system.
> 
> 
> >Forth dialects definitely LOSE on this front.
> 
> For bootstrapping purpose and for formal manipulation,
> a Forth-inspired language is better than, say, using C
> as intermediate code: people first struggle with its
> syntax... when they come to its semantics they undertsand
> that the beast is not really so simple as someone imagine.

It took me a while to realise this.  I knew C had problems
in this regard, but I had no idea how much its deficiencies
would dominate my design.

> 
> 
> >I see more interesting stuff pass by on Lambda the Ultimate
> >in a week...

Well, I'll have to take a look at this, too.
> 
> I respect some LtU contributors, but I find depressing when
> they take seriously crap like XML/XPath/Xsomething or the worst
> parts of C++, just to name 2 examples.
> 
> 
> Regards.
> 
> --
> Massimo Dentico