[ColorForth] Code sharing

[Dirk Harms-Merbitz <dirk@xxxxxxxxx>]

One convenient way to do code sharing would be to map high
numbered blocks to the network. Read-only for library space?

Chuck's network support is almost complete so writing a block
server would be trivial. As would be writing replicating caches
for the local network.

On Mon, Aug 20, 2001 at 12:58:49PM -0400, Martin wrote:
> Hello Chuck.
> 
> 
> > I agree with the concept of a compact OS to which capabilities are
> > added as
> > necessary.
> > 
> > But I take exception to vocabularies, as I interpret the reference.
> > Multiple
> > vocabularies suggest multiple applications coexisting in the
> > dictionary,
> > distinguished by the search mechanism.
> > 
> > colorForth compiles applications on demand. The dictionary holds only
> > current words, and has minimum size and search time. No confusion about
> > multiply-defined words. And no need for clumsy prefixes to distinguish
> > them.
> 
> My mistake...no, I didn`t mean that.
> 
> As an aside...(I think someone (volunteers please apply) needs to start a 
> documentation project CDP (ColorForth Documentation Project).  Primarily 
> a single document with an intro and philosophy, the basics of how to 
> start and use ColorForth and then various chapters running through 
> ColorForth stacks, numbers strings etc.)   
> 
> My Forth is superficial and runs from FIGForth 6502, Apple ][, GForth, 
> Pygmy Forth to JForth.  I only ever had time to brush the surface due to 
> other committements.
> We do need clear docs on what is good and what is bad with conventional 
> Forths so we can re-adjust and re-focus.
> 
> I assume ColorForth only uses screens.
> 
> Is ColorForth case sensitive ?
> 
> 
> What I was trying to say, albeit poorly, is that...well, let`s take an 
> example.
> 
> Let`s suppose a bunch of people work together and produce code that does 
> internet stuff.  That is basic tcp/ip (udp/tcp), dns, smtp, pop, nntp.
> It gets worked over, factorised repeatedly, refined to become the 
> fastest, smallest code possible.
> 
> If you wanted to use internet code in an application you were writing you 
> could include it (load from relevent screens or whatever). the end result 
> is the same. It`s added to the vocabularly whilst you build your 
> application.  
> 
> But perhaps you only want to use 10% of that internet code. That means 
> 90% is baggage a.k.a. bloat.
> 
> Mike Haas and Phil Burk of JForth fame in the eighties produced a 
> programme called CLONE for JForth. It would read your programme and strip 
> away all the unused words producing a tight executable.  For example a 
> large demo originally 160K reduced to 28K.
> 
> I assume this would be irrelevent for ColorForth as we should be writing 
> very small screens and just load in the appropriate ones.
> 
> It that correct Chuck ?
> 
> Conversely, if there were a thousand small screens and we had to track 
> and decide which individual ones we wanted to use, wouldn`t having a 
> single internet file/block that we could load and strip away the unused 
> portions be easier to handle ?
> 
> This is a code reuse and manageability issue that we need some guidance 
> on and needs to be in a clean, coherent ColorForth document so newbies 
> and old hands can get clear, understandable explanations of how and why 
> things are being done in the ColorForth environment.
> 
> Food for thought.
> 
> Regards...Martin
> 
> ------------------------
> 
> To Unsubscribe from this list, send mail to Mdaemon@xxxxxxxxxxxxxxxxxx with:
> unsubscribe ColorForth
> as the first and only line within the message body
> Problems   -   List-Admin@xxxxxxxxxxxxxxxxxx
> Main ColorForth site   -   http://www.colorforth.com
> 
------------------------

To Unsubscribe from this list, send mail to Mdaemon@xxxxxxxxxxxxxxxxxx with:
unsubscribe ColorForth
as the first and only line within the message body
Problems   -   List-Admin@xxxxxxxxxxxxxxxxxx
Main ColorForth site   -   http://www.colorforth.com