[OT] We need a language

[James Michael DuPont]

--- "Lynn H. Maxson" <lmaxson@pacbell.net> wrote:
> I didn't want to weigh in on this, somehow violating my lurker 
> (and "moron") status, but it's starting to sound too much like 
> an intelligent discussion.  I can't really speak to Scheme, Perl, 
> Python and the others individually, only generically.  Strong 
> versus weak typing simply indicates the dependence upon 
> implementation "convenience" imposing itself upon language 
> rules.

Well, The same applies to me. I am obviously not hyper intelligent,
and have not read all of the wiki. In fact, I cannot even program in
lisp! Anyway, I still think that the lessons learned from the gcc and
other compilers will be useful to the tunes project.

> 
> Arguing over language, primarily the matter of which form to 
> imposed on equivalent substance, ignores the implementation 
> as if one were independent of the other.  I would argue that 
> implementation restrictions, particularly three of them, offer 
> greater barriers to progress.
> 
> One, the use of source files instead of a source database 
> based upon data directory/repository. 

> Two, the requirement 
> that we limit a compilation to a single object module when we 
> could just as easily compile an unlimited number with an 
> equally unlimited number of object modules on output as a 
> single unit of work.

>  This would allow us to use the software 
> to do truly global checking as well as provide as single point 
> for the synchronization of source changes across modules.  

> Three, to allow the unordered input of program units, 
> statement groups as introduced in fourth generation 
> languages.

When there is a tunes language that I can output this information into,
then I will do so. I hope that some day we will have some type of
language specification that say, if you put your program in this
format, then future versions of tunes will be able to support it.

> 
> If we did this, then we would not use a compiler, which is 
> probably the biggest single handicap in software development.  

I agree. My approach with the introspector is to extract the
information from the compiler at the highest level that the compile can
capture the inforamation, and use that as input into a semantic
recovery system that allows for marking up and extraction of
information on many levels. The preprocessor, lexical, the parser, the
ast, the generated code. 


> Instead we would use an interpreter which allowed us to 
> process the entire source composing multiple modules, 
> including up to an entire operating system, coupled with 
> dynamic testing.

That will be possible, right now I am outputting each module and each
function as a database that can be re-interpreted at a higher level.

mike

=====
James Michael DuPont
http://introspector.sourceforge.net/

__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com