Hi,

: ...Well, So much for programmer's supporting new ideas! Please tell
: me that the innovation has not left the industry. Are we all so
: complacent now that we do not explore new ideas?
:
To be honest, I had no idea this board existed. Guess I can't use that excuse now. I'm currently a computer science undergrad at Cambridge (UK), and programming langauge design, compilers and virtual machine are areas I'm interested in. Knowledgable or competent is another matter, mind. Anyway, you've managed to capture my curiosity.

It seems to me that you're saying "we have these different natively compiled files (which may be executables or DLLs, or just a format of your own?) and will provide some kind of standardised, OO-shaped interface to allow connectivity between them". Let me run thorugh some examples of what I think the possibilities are and see if I get the idea.

1) You've written a module that converts a wave file to an MP3. Alone, it provides some mechanism (via a loader?) that allows people to use it out of the box solely for that. I'm implementing something that synthesises some sound and stores it in wave format. I can instantiate your module in my program and use it to convert my wave file to an MP3 using it. Nothing we can't do with a DLL so far, but the nice OO interface of the module being exported is going to make life easier for me.

2) You've written a module that takes a load of text and break it down into sentences. I like this, but I have my text that I want to use stored in HTML documents (sorry, these examples suck...). I inherit from your program, over-riding certain methods so that I can strip out the HTML before invoking the method on the super-module with the text.

The right kind of idea? Interesting, if so. In a way, we kinda went there with UNIX, where we had loads of little programs that we joined together with pipes. E.G. to find the number of lines containing the word monkey in a text file we'd do:-
cat textfile | grep monkey | wc -l
What you suggest almost seems to be an object oriented and more flexible extension of this.

Here's some questions.

1) What's the language going to look like? I suspect C and C++ style syntax, from your posts. But I'm hoping some lessons are learnt from elsewhere too...

2) Is this language going to be garbage collected? Do we get references rather than pointers (e.g. will there be free pointer arithmetic)? Are we getting bounds checking on arrays (buffers)?

3) Are you going down the native code route, or interpretation (so you win better cross-platform support)?

Warning: time isn't something I have in great supply. But I probably have time enough to bounce some ideas around.

Hope some of this makes sense...it was a long day at the lab today, and my brain is kinda mushy.

Jonathan

###
for(74,117,115,116){$::a.=chr};(($_.='qwertyui')&&
(tr/yuiqwert/her anot/))for($::b);for($::c){$_.=$^X;
/(p.{2}l)/;$_=$1}$::b=~/(..)$/;print("$::a$::b $::c hack$1.");