I can't get my head around the concept of DOES>. I thought I try to use 
it to mix commands with input.

I had a go with something like this:
create strlen
create str 256 allot
: payee DOES> s 256 accept strlen ! ;

The plan is that I could then type in something like
payee mark carter
and inspect the results with something like
str strlen @ type

Now, why would I want to do it this way, I hear you ask? Well, the point 
is that it's convenient if I make a mistake in the input, so that I can 
just up-arrow and correct the bits that are wrong. Also, I prefer it 
over typing something like
s" mark carter" payee

Or is it just a bad idea?

Mark Carter wrote:
> I can't get my head around the concept of DOES>. I thought I try to use 
> it to mix commands with input.
> 
> I had a go with something like this:
> create strlen
> create str 256 allot
> : payee DOES> s 256 accept strlen ! ;
Rats. I meant
: payee DOES> str 256 accept strlen ! ;
               ^^^

"Mark Carter" <me@privacy.net> wrote in message 
news:438e2904$0$15794$14726298@news.sunsite.dk...
>I can't get my head around the concept of DOES>. I thought I try to use it 
>to mix commands with input.

Well, that isn't what DOES> is for.  It allows you to construct a defining 
word (CREATE, VARIABLE, : , CONSTANT, etc. are all defining words) with both 
a defining behavior and an instance behavior (that is, shared behavior of 
words defined by this defining word) that you specify.

> I had a go with something like this:
> create strlen
> create str 256 allot
> : payee DOES> s 256 accept strlen ! ;
>
> The plan is that I could then type in something like
> payee mark carter
> and inspect the results with something like
> str strlen @ type

This will not at all do what you want.  To begin with, ACCEPT is a 
'blocking' word, that will wait for you to type something.  It won't read 
forward in the input stream like your usage example.

A simple way to do this might be:

CREATE 'PAYEE   0 C, 256 ALLOT
: PAYEE ( -- )   0 WORD  DUP C@  1+  'PAYEE SWAP MOVE ;

Now, if you say PAYEE Mark Carter {cr}
....you can then say 'PAYEE COUNT TYPE  to display it.

Here's an example of proper use of DOES> to make a custom class of data 
objects.  I'm going to make a new defining word called ARRAY which will 
construct a buffer of a specified size; when you reference a buffer defined 
by ARRAY, you give it an index into the array and you'll get back the 
indexed item.  Items are each one cell wide.

: ARRAY ( size -- )   CREATE  CELLS ALLOT
   DOES> ( index -- addr)   SWAP  CELLS + ;

10 ARRAY STUFF
: SHOW ( -- )   10 0 DO  I STUFF @ . LOOP ;

Note that to make ARRAY a defining word, you use CREATE in the defining 
portion (before the DOES> ).  The code following DOES> will be executed when 
you execute a word defined by ARRAY (STUFF in this example).  When this code 
begins executing, the address of the data space for the instance is 
automatically pushed on the stack on top of any external parameter (index in 
the example).  It's recommended to show separate stack arguments for the 
defining and instance portions, as I have done here.  And it's also 
recommended not to include the instance address in the instance behavior 
stack comment, since the main purpose of the stack comment is to indicate 
how the word is to be used, and it isn't the user's responsibility to 
provide that address.

This topic is explored much more thoroughly in my book, Forth Application 
Techniques, available on our web site, www.forth.com

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310-491-3356
5155 W. Rosecrans Ave. #1018  Fax: +1 310-978-9454
Hawthorne, CA 90250
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
================================================== 

Elizabeth D Rather wrote:
> "Mark Carter" <me@privacy.net> wrote in message 

> A simple way to do this might be:
> 
> CREATE 'PAYEE   0 C, 256 ALLOT
> : PAYEE ( -- )   0 WORD  DUP C@  1+  'PAYEE SWAP MOVE ;
> 
> Now, if you say PAYEE Mark Carter {cr}
> ...you can then say 'PAYEE COUNT TYPE  to display it.

Wow - many thanks. I'm pretty sure I've digested what's going on.


Words like WORD C, and C@ are new to me, so I hadn't guessed their 
existence.

So I was thinking about how I might make Forth into a little accounting 
package. Let's say something along the lines of having a number of 
transactions (records), with each tansaction having a number of fields 
(let's say payee, amount, account number).

Would it be Forth'ish to, say, create an array consisting of records, 
having predecided the max num of records that are likely to be held in 
the "database". Each record would have the fixed-width fields 
"concatenated" together. This array could be loaded as a binary file 
when the app starts, and saved when the app finishes.

I guess my worries are: if you specify the number of records in advance, 
then can't you end up making whoppingly-big files? What happens if you 
find out later that your record-size wasn't big enough, and you find 
that you need more? I guess it's a design dilema of creating something 
very simply, but running the risk that your design was wrong, as against 
designing something more generic, but thereby complicating the design 
process.


> Here's an example of proper use of DOES> to make a custom class of data 

Thanks. It's going to take me a while to digest this information.

Mark Carter wrote:
> Elizabeth D Rather wrote:
> 
>> "Mark Carter" <me@privacy.net> wrote in message 

> I guess my worries are: if you specify the number of records in advance, 

Or, perhaps another way, is to use the blocks mechanism (when I figure 
it out!). So the user could edit the blocks however they like, and put 
in stuff like:
PAYEE mark carter
AMOUNT 1000 00 cr
ACCOUNT 11
ADD-TRANSACTION

The user could then "execute" the block, and it would do the right thing.

If there are only 64 screens in a block, that doesn't give room for many 
transactions - assuming you could get 2 transactions per screen, that's 
only 128 transactions. Hmmm, decisions, decisions.

It seems that with something like Forth one has to make a lot of ones 
design decisions very carefully, because once you've started to enter 
data in a particular way, it becomes problematical to change the decision.

If I was doing this in, say Lisp, I might have a data file that looked 
something like:
(add-transaction 'mark carter' 1000 11)
....
I would be less fightened of any bad design choice, because Lisp does a 
lot of the parsing for me, and I'm not hedged in by assumptions about 
what the fields widths are, for instance.

"Mark Carter" <me@privacy.net> wrote in message 
news:438ef87a$0$15783$14726298@news.sunsite.dk...
> Elizabeth D Rather wrote:
>...
> Words like WORD C, and C@ are new to me, so I hadn't guessed their 
> existence.

Before you go any farther, you need to invest some time in learning Forth 
basics.  You need a system to use, and a tutorial of some sort.  My web site 
has books, and our free evaluation version of SwiftForth also includes a pdf 
of a very extensive book on Forth.  But there are others as well.  gforth is 
a good system for Unix-like platforms, and comes with a tutorial and online 
docs.

> So I was thinking about how I might make Forth into a little accounting 
> package. Let's say something along the lines of having a number of 
> transactions (records), with each tansaction having a number of fields 
> (let's say payee, amount, account number).
>
> Would it be Forth'ish to, say, create an array consisting of records, 
> having predecided the max num of records that are likely to be held in the 
> "database". Each record would have the fixed-width fields "concatenated" 
> together. This array could be loaded as a binary file when the app starts, 
> and saved when the app finishes.
>
> I guess my worries are: if you specify the number of records in advance, 
> then can't you end up making whoppingly-big files? What happens if you 
> find out later that your record-size wasn't big enough, and you find that 
> you need more? I guess it's a design dilema of creating something very 
> simply, but running the risk that your design was wrong, as against 
> designing something more generic, but thereby complicating the design 
> process.

All of this is quite reasonable, but requires more experience with Forth 
than you have right now.  See my advice above.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310-491-3356
5155 W. Rosecrans Ave. #1018  Fax: +1 310-978-9454
Hawthorne, CA 90250
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
================================================== 

"Mark Carter" <me@privacy.net> wrote in message 
news:438efcf3$0$15787$14726298@news.sunsite.dk...
> Mark Carter wrote:
>> Elizabeth D Rather wrote:
>>
>>> "Mark Carter" <me@privacy.net> wrote in message
>
>> I guess my worries are: if you specify the number of records in advance,
>
> Or, perhaps another way, is to use the blocks mechanism (when I figure it 
> out!). So the user could edit the blocks however they like, and put in 
> stuff like:
> PAYEE mark carter
> AMOUNT 1000 00 cr
> ACCOUNT 11
> ADD-TRANSACTION
>
> The user could then "execute" the block, and it would do the right thing.

You can certainly put stuff in a file or a block that the system can 
interpret, just as though it was text in the keyboard input stream.

But you should be aware that blocks are a holdover from the 80's, when many 
Forths were native (not under any OS) and needed a simple, non-file-oriented 
way of accessing disk.  There are still some block-oriented Forths around, 
but most modern Forths run under an OS such as Windows or a varient of Unix 
and use files for both program source and data.

> If there are only 64 screens in a block, that doesn't give room for many 
> transactions - assuming you could get 2 transactions per screen, that's 
> only 128 transactions. Hmmm, decisions, decisions.

A 'block' is 1024 bytes on disk.  A 'screen' is nothing but a block used for 
source and commonly displayed as 16 lines of 64 characters each.

> It seems that with something like Forth one has to make a lot of ones 
> design decisions very carefully, because once you've started to enter data 
> in a particular way, it becomes problematical to change the decision.

I think that in any language once you've set up a database with a particular 
structure it's tricky to change the structure.  In general, Forth is at 
least as flexible as any other language, and its interactive nature makes 
things very easy to change, particularly in early stages before you have a 
lot of data in your database.

> If I was doing this in, say Lisp, I might have a data file that looked 
> something like:
> (add-transaction 'mark carter' 1000 11)
> ...
> I would be less fightened of any bad design choice, because Lisp does a 
> lot of the parsing for me, and I'm not hedged in by assumptions about what 
> the fields widths are, for instance.

It is certainly possible to build in a lot of flexibility.  There are pros 
and cons concerning fixed-width fields in a database.  In a sense they are 
less flexible, but they are also more reliable, because most schemes for 
handling variable-length fields involve pointers that can get damaged with 
dire consequences to your ability to access data.  This is, again, less a 
property of the language than a property of your design of your application.

Forth is not as widely used for database applications as some other 
languages (it was originally designed for embedded systems), and so doesn't 
have many high-level database tools.  On the one hand, that means you have 
the freedom to develop tools to your taste.  On the other, it means you have 
to do it!

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310-491-3356
5155 W. Rosecrans Ave. #1018  Fax: +1 310-978-9454
Hawthorne, CA 90250
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
================================================== 

In article <438e2904$0$15794$14726298@news.sunsite.dk>,
Mark Carter  <me@privacy.net> wrote:
>I can't get my head around the concept of DOES>. I thought I try to use
>it to mix commands with input.
>
>I had a go with something like this:
>create strlen
>create str 256 allot
>: payee DOES> s 256 accept strlen ! ;
>
>The plan is that I could then type in something like
>payee mark carter
>and inspect the results with something like
>str strlen @ type
>
>Now, why would I want to do it this way, I hear you ask? Well, the point
>is that it's convenient if I make a mistake in the input, so that I can
>just up-arrow and correct the bits that are wrong. Also, I prefer it
>over typing something like
>s" mark carter" payee
>
>Or is it just a bad idea?

You probably want more thingies like payee, like payant.

So this would be more like it
: string 0 C, 256 ALLOT DOES>  ;

string payee
string payant
payee mark ANDRE
payant mark wILLEM
payee COUNT TYPE

ISO standard words in upper case
Not tested, but to give the idea.

mark is left as an exercise for the reader.

--
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- like all pyramid schemes -- ultimately falters.
albert@spenarnc.xs4all.nl http://home.hccnet.nl/a.w.m.van.der.horst

"Mark Carter" <me@privacy.net> wrote in message
news:438efcf3$0$15787$14726298@news.sunsite.dk...
> I would be less fightened of any bad design choice, because Lisp does a
> lot of the parsing for me, and I'm not hedged in by assumptions about
> what the fields widths are, for instance.

But even still with the Lisp way, it is a design choice, it's just one that
happens to be cheap to make because Lisp provides it for free.

There is nothing stopping you from creating a simple reader to read in your
transactions that offers the same flexibility as what the Lisp reader does.
Even as far as storing the rows in a Comma Seperated Value format can handle
many ills.

But even with the Lisp reader, should you add a field, all of your
previously stored data would still need to be converted and updated.

Storing records in Forth (or any other language for that matter) is really
quite straightforward. You can either store the data in string format, or
binary format, fixed length fields, or variable length fields, delimited or
calculated field offsets.

Typically, for fixed records sizes, you would read a record into a buffer in
memory, and then access the fields using offsets. Nowadays, much of this is
a black art simply because SQL databases are ubiquitous and solve this
problem handily, but many record based storage systems have been done in
Forth in the past.

If you add a field, or change the length of a field, it's a simple matter of
copying the old records, reformat them, and store them in a new space. By
the second or third time you do this, you'll no doubt have a routine to make
this a reasonably simple task.

The other, more difficult, aspect of storing records in the problem of
indexing them for quick access. B+Trees have been the standard means of
dealing with those for a generation. The algorithm is mildy sophisticated,
but not unwieldly, and is well documented all over the place. It would not
surprise me if someone has some published words in Forth to do this.

Modern, sophisticated database servers jump through a myriad of hoops to
manage multiple users, locking, buffer management, disk layout, etc. etc.,
all looking for fast performance. But truth be told, most of the speed of a
database is from something as simple as the DBASE format. For most small
systems, it is more than adequate. Look it up on the web, it is well
documented. In fact, there may well be Forth code to manage the DBASE file
format.

Writing record management function is not trivial, but it's reasonably
straightforward. Most folks simply punt and let something like MySQL handle
the chores, but if you're looking for a mid-level project, writing one from
scratch would be very instructive.

Regards,

Will Hartung
(redrocks@sbcglobal.net)