Create or find examples for Float and File-Access words.

[SirWumpus]

From #46, some float and file-access examples would be nice.

[SirWumpus]

So in an effort to find a Floating Point example or something interesting I had a quick look at floating-point matrix multiplication and it fails out of the box.

GRRR. Its really disappointing that packages (modules nudge nudge) do not list or somehow communicate what additional optional word lists are required. Seems like everyone expects (assumes) that ALL the optional word sets will be implemented regardless, which begs the question WHY are they optional in the standard?!?

@ruv Is it worth implementing the Locals word set? Was reading the discussions about Locals in comp.lang.forth and for everyone's complaints about Locals, yet they still get occasional use.

Sidebar: I've tried a few packages (snprint, stringstack, matmul) and they each fail for some reason: missing word sets, Forth implementation specific words, dated and not maintained. I think when trying to make a package portable they need to confine themselves to documented standard words to start with.

(I really need to go for a walk and calm down. Maybe find a big tree and give it a hug.)

[ruv]

Its really disappointing that packages (modules nudge nudge) do not list or somehow communicate what additional optional word lists are required.

As for the program mentioned, the main file matmul.4th documents which words are used (grouped into word sets), but not all of them.

Seems like everyone expects (assumes) that ALL the optional word sets will be implemented regardless,

What makes you think so?

If a program needs some optional word, what the author should do? The standard says that it is enough to document this as "Requiring name(s) from the XXX word set" (see 5.2.2 Program labeling and other sections like N.5.2).

In some cases a program could check whether the word is provided by the system and implement it if it is not. But doing this in every program is too burdensome. In future we can have a portable module that implements missed standard words when possible.

which begs the question WHY are they optional in the standard?!?

Optionality is a language for describing different Forth systems, designed for different purposes and different niches.

Obviously, not all things are needed in every niche. For example, embedded systems might not provide the File word set and the Memory-Allocation word set. For example, most programs do not need the Floating-point word set at all.

---

Is it worth implementing the Locals word set?

Locals can be implemented in a portable way if the system provides the Recognizer API.

So, the Recognizer API is a more critical thing to implement, I think.

---

Sidebar: I've tried a few packages (snprint, stringstack, matmul) and they each fail for some reason: missing word sets, Forth implementation specific words, dated and not maintained. I think when trying to make a package portable they need to confine themselves to documented standard words to start with.

Yes. And that is why I'm developing a module system. A module can use only standard words and other modules. Modules have globally unique names, and they are downloaded/cached locally automatically by a package manager.

There will be no problems like a missing words. If the Forth system is capable, the program mast work. If the Forth system is not capable for the program, you (as the user of the program) can take another Forth system. Ideally, you don't have to deal with missing words or anything like that.

[SirWumpus]

Its really disappointing that packages (modules nudge nudge) do not list or somehow communicate what additional optional word lists are required.

As for the program mentioned, the main file matmul.4th documents which words are used (grouped into word sets), but not all of them.

While that is good, I like to find requirements in the README.md or maybe theforth.net could add an extra section under Dependencies and Dependents, like "Word Sets" to summarise what is needed at a glance.

Seems like everyone expects (assumes) that ALL the optional word sets will be implemented regardless,

What makes you think so?

Well seems like everyone expects Search-Order and Locals, despite the recent comp.lang.forth discussion about locals vs stack manipulation and the performance of Locals. I got the impression that Locals is unpopular yet used in a handful of cases where a word might have a large number of arguments to manage.

If a program needs some optional word, what the author should do? The standard says that it is enough to document this as "Requiring name(s) from the XXX word set" (see 5.2.2 Program labeling and other sections like N.5.2).

My feeling is test for the most common word in the word set, eg. SET-ORDER or (LOCAL) and if missing rather than supply a word set to include (one option), just write a message explaining requirements and terminate.

[undefined] (local) [if]
.( Locals word set is required. )
[else]
...
[then]

In some cases a program could check whether the word is provided by the system and implement it if it is not. But doing this in every program is too burdensome. In future we can have a portable module that implements missed standard words when possible.

which begs the question WHY are they optional in the standard?!?

Optionality is a language for describing different Forth systems, designed for different purposes and different niches.

Obviously, not all things are needed in every niche. For example, embedded systems might not provide the File word set and the Memory-Allocation word set. For example, most programs do not need the Floating-point word set at all.

I agree about Floating Point. Try make clobber; ./configure --disable-math; make and you save ~8KB on the code (ya, despite giga bytes of memory, I still think about code size, Small is beautiful.).

Is it worth implementing the Locals word set?

Locals can be implemented in a portable way if the system provides the Recognizer API.

So, the Recognizer API is a more critical thing to implement, I think.

While I think it might be good, I think its also something that needs some internal support to work well and for that I'd prefer a well baked proposal that has good support.

Sidebar: I've tried a few packages (snprint, stringstack, matmul) and they each fail for some reason: missing word sets, Forth implementation specific words, dated and not maintained. I think when trying to make a package portable they need to confine themselves to documented standard words to start with.

Yes. And that is why I'm developing a module system. A module can use only standard words and other modules. Modules have globally unique names, and they are downloaded/cached locally automatically by a package manager.

There will be no problems like a missing words. If the Forth system is capable, the program mast work. If the Forth system is not capable for the program, you (as the user of the program) can take another Forth system. Ideally, you don't have to deal with missing words or anything like that.

I look forward to seeing what this will finally look like. Sounds like a really good idea. Is it like GNU Autoconf for Forth packages? Or more like Npm, Rebar3, Cargo, Cpan language specific package/module systems?