I believe Charles Montgomery first suggested he would like to see this change,
in a previous email to me. I'd like to reintroduce this idea here in c.l.f. for
input from other users of the FSL. Are there any potential pitfalls?

Reorganize the FSL auxiliary files by moving the following words from dynmem.x
to fsl-util.x:

malloc-fail?
cell_size
}malloc
}free
}}malloc
}}free

Then, dynmem.x will only contain ANS compatible definitions of ALLOCATE and
FREE, and associated data structures to support these definitions.

The auxiliary file fsl-util.x should correspondingly be modified to perform a
conditional include of dynmem.x, based on the value of the constant
HAS-MEMORY-WORDS?. Thus, the fsl-util.x file will have the following

HAS-MEMORY-WORDS? [IF] include dynmem.x [THEN]

\ or

HAS-MEMORY-WORDS? [IF] s" dynmem.x" included [THEN]

Krishna Myneni bellsouth.net> writes Re: FSL auxiliary files: proposed reorganization of words
[..]

AFAIK, (and I checked this recently), SwiftForth, VFX and iForth have always
done it like this.

Wouldn't that be

HAS-MEMORY-WORDS? 0= [IF] S" dynmem.x" INCLUDED [THEN]

Marcel Hendrix wrote:

If I may, I'll join this thread in a less than polite way, by not quoting
specifically from the useful things said in the previous posts, but
making a few comments, some directly related and some indirectly.

1. Moving the dynamic allocation words into fsl-util.whatever makes a lot
of sense. I would even be willing to go through all the library routines
to see whether any would require changes if this were done. But if I,
and VFX, and SwiftForth, and iForth, and most other users of the Library
have already done it, it's not clear that the effort would be justified.

2. There would be a similar benefit, IMHO, in removing the
structure-related words from the general utility files. They are not
needed for many of the library routines, and a separate file could
provide support for routines needing them. This would require more
reworking of more files, though. Since the Forth200x project is taking
up standard structure words, my inclination is to wait for the outcome
there, which might then be incorporated in FSL usage.

C. G. Montgomery wrote:

The fsl-util.x files for F-PC, ThisForth, PFE, and GFORTH, which are given at
the FSL website, do not have the proposed integration of the dynamic memory
words. They rely on dynmem.x to provide "}malloc" etc.

The fsl-util.x file for Win32Forth, from the FSL website, does integrate
"}malloc" etc. (but I notice there is still a bug in this particular file's
definition of "}}free").

Krishna Myneni krishnamyneni@bellsouth.net wrote:

On Mar 11, 11:44 pm, Krishna Myneni bellsouth.net>
wrote:

You mean, as a standard of the FSL itself, as split stacks are a
standard of the FSL?

No, certainly not.

Rather, it is highly desirable to fix this particular specification of
the result produced by invoking an array name, document it, provide a
standard name for that specification and if you want provide a
tutorial on how to manipulate the result returned by array name words
that follow that particular specification.

Then that standard name for that implementation of the semantics can
appear as a TRUE constant with the same scope as }} and }.

If another wordlist is available that uses a different specification,
in the scope of its definitions for }} and } it defines that standard
name as a FALSE constant.

Krishna Myneni krishnamyneni@bellsouth.net wrote:

Except that the different fsl-util files don't all provide the same
functionality. This is something I'm working on (but not my top
priority). Even which words are provided varies. At least some
improvement should be possible without too much trouble. But there is no
definitive list of which words are available to the coder of an
algorithm, let alone a specification of their behavior.

"C. G. Montgomery" physics.utoledo.edu> writes Re: FSL auxiliary files: proposed reorganization of words
[..]

a{{ ( -- id ) \ The meaning of id is implementation-defined.

Marcel Hendrix wrote:

How about the following specification for the result of invoking the
array/matrix name?

a{{ ( -- addr )

Return the address to the first array element for statically-defined
arrays/matrices and for dynamic arrays/matrices which have been allocated. For
dynamic arrays/matrices which have not been allocated, the value of addr is
ambiguous.