Loading ...
Sorry, an error occurred while loading the content.

Re: [TI-99/4A] Re: General FORTH question

Expand Messages
  • mark wills
    Just about every modern (PC or Mac based) Forth uses text files in favour of blocks these days. It s certainly true that back in the old days it did make
    Message 1 of 41 , May 1, 2011
    • 0 Attachment
      Just about every modern (PC or Mac based) Forth uses text files in favour of blocks these days.

      It's certainly true that back in the 'old days' it did make portability an issue. But it's not an issue for the TI. The blocks files are just DF128. You can email them to each other etc. No problems at all :-)

      From: "richgilbertson@..." <richgilbertson@...>
      To: ti99-4a@yahoogroups.com
      Sent: Saturday, 30 April 2011, 1:21
      Subject: Re: [TI-99/4A] Re: General FORTH question

      Blocks are exactly why Forth died, you are totally right. The fact that you can only see the Blocks in Forth and nothing
      else ensures the death of the any new Forth. If you can not have accessibility and transport to other OS then that
      system will die. I have Language history books and they all died for the same reason, only one environment to
      exist in and not accessible from anything else. Compatible with nothing but itself is sure death to any OS.
      Moving one set of programs to another OS means that you can see the other and traverse between the two. That
      means it is more easy the transfer and trasport, and  the better that language does long term, why C came out on top.

      Not that C is a better language, it is just more easy to transfer programs to.

      ----- Original Message -----
      From: "David Ormand" <dlormand@...>
      To: ti99-4a@yahoogroups.com
      Sent: Friday, April 29, 2011 8:02:09 AM
      Subject: [TI-99/4A] Re: General FORTH question

      Okay, I'm seeing the arguments FOR Blocks and AGAINST flat source text files.

      Just to say, I've had a lot of experience with graphical languages (HP Vee and NI LabView, notably) and their big shortcoming of being impossible to track changes or do diff reports to their source files.  I'm thinking this would be the same thing for Blocks, which, though they _are_ text, are a binary file format and thus suffer from the same lack of trackability, etc.

      That said, one of the things about "normal" languages (like C and Python) is LIBRARIES.  Does Forth have a library concept, or does everything in a program have to exist within the same source file?

    • mark wills
      I m enjoying reading all this Forth chat. I hope we re not clogging up the board with all this Forthy goodness! I think David asked if libraries were a
      Message 41 of 41 , May 1, 2011
      • 0 Attachment
        I'm enjoying reading all this Forth chat. I hope we're not clogging up the board with all this Forthy goodness!

        I think David asked if libraries were a possibility in Forth. Allow me to address that question if I may.

        The answer is yes. Definitely. However, it is just a concept in the "mind" of the user (for want of a better way of putting it).

        You see, loadable code lives on a block somewhere. There is actually nothing to distinguish it at all from a full-blown application. Only "you" know that it is a library.

        For example, I have a program call CPYBLK which allows me to copy blocks within the same block file (if I need to move blocks around), or indeed copy blocks between different blocks files. Here is the code (which could probably be improved, I wrote this around 6 months ago as the need arose):

        0 CONSTANT strtblk  0 CONSTANT endblk  0 CONSTANT dstblk
        : BLW 32 WORD ;
        BLW  SWAP srcfn ! srcfn 2+ ! BLW  NUMBER DROP TO dstblk
        BLW  SWAP dstfn ! dstfn 2+ ! CR endblk 1+ strtblk DO
        srcfn @ srcfn 2+ @ USE I BLOCK DROP I .
        dstfn @ dstfn 2+ @ USE 0 dstblkSETBLK 0 DIRTY FLUSH
        dstblk 1+ TO dstblk LOOP ." Copied. " CR
        srcfn @ srcfn 2+ @ USE ; .( CPYBLK loaded)

        Now, CPYBLK is 'program' in it's own right (it's just a small one ;-) - however, I often treat it as a loadable library. If the need arises to copy blocks around, I just do:

        80 LOAD

        And hey presto, I now have the ability to do it. We are used to attributing this 'optional load and use' paradigm to "libraries" - at least, that's what we call them on other systems. It's pretty much the same in Forth. If you need it, load it. However, what you load is just a bunch of words in the Forth dictionary. So, *you* can use the new functionality, and so can your programs. It's also possible to test to see if a particular word is loaded, and if not, go load it.

        Another important point about blocks: When you LOAD a block (with the LOAD command), as far as the Forth system is concerned, the contents of the block have (more or less) come from the keyboard! What I mean by that is, the data in the block takes the same route 'through' the interpreter/compiler as it would if it were typed via the keyboard.
        This gives you access to unprecedented power (for our little machines, anyway): It means that Forth is both a programming language, and a scripting language. What's more, it's both of these things *simultaneously*!

        Here is an example. Imagine the following in a block somewhere:

        : CLEVER-WORD ... ... ... ... ;
        .( CLEVER-WORD loaded)
        100 CELLS ALLOT

        Here, we defined a colon-definition called CLEVER-WORD - an executable word that is stored in the dictionary and can be executed later. However, the next two lines are NOT in a colon definition. Thus, they are executed immediately, as they are encountered, as if they were typed in (by fast, error-free typist!) from the keyboard. LOAD essentially spools the blocks' contents to the interpreter. Neat or what? Anything you can type at the command line, can be entered into a block. Thus, when you LOAD a block, it is like a super-fast replay of a keyboard input session! Name another language with this amount of flexibility!

        The incredible thing is, all this 'power' existed in the 70's. Unfortunately, when the home computer boom hit in the early 80's, the worlds manufacturers decided to install BASIC into their machines... The rest is history...


      Your message has been successfully submitted and would be delivered to recipients shortly.