petercamilleri / foorth Goto Github PK

This will enable the insertion of raw ruby code into the code buffer. Sort of like an assembler level for fOOrth.

E codes should be used for all exceptions mapped from Ruby.

Classic FORTH uses a cooperative tasking model. This is much lighter weight than threads but more flexible than fibers (?) .

Is this a good idea?

The latest and the greatest!

What does it create?
Is it valid?
Does it need docs?
Does it need to be fixed?

Port a classic FORTH word.

Use the builtin Infinity instead? Need to investigate.

Also needed.

This would be the non-command version of )" xxxxxx "

The compiling methods (: !: .: and .::) do not nest correctly into control structures or inside a method being compiled. The following code demonstrates this issue:

true if : foo ."foo" ; then
F10: Invalid value for mode: :deferred not [:execute]

The above code should simply define the method foo but it produces an error instead.

Keeping up with the Matz's!

The fOOrth system already has some time based methods. Formal support for date and time data would seem to be a good idea.

Currently these switch out of execute mode to deferred mode.

Add this missing method.

What does this actually do/create?
Is it valid?
Does it merit its own docs?
Should it be fixed?

In the User Guide, create a section discussing the role of "self".

Go into deeper detail on this.

Right now, most of fOOrth is Ruby code. It need not be. fOOrth can be defined in fOOrth for the most part.

Convert these methods to NOS routing and move to Object.

Add a helper method .fmt_fields that defaults to self, also in Object

This change will allow for much greater versatility in formating non-traditional data.

Some background on this point would be useful.

Needed for multi-threaded apps.

This method is like call but also takes an object as an argument. This object is set to be the self with the called procedure. eg:

"Test 123" a_procedure .call_with

will call a_procedure with the "Test 123" string as self during execution.

Also missing

The fOOrth system already uses date/time data. Make it a part of the language!

The current method of defining NOS methods is sloppy, confusing, and highly error prone. This whole are really needs some serious attention and TLC.

The current way uses the method name. If the method created by the .: word does NOT start with a . or a ~, it defaults to be a NOS method... It is really easy to create them by accident when that was not my intent.

A better way is needed.

Add a section to the User Guide giving an overview of numeric data in fOOrth.

When not in execute mode, classes cannot be created. The following two interactive session traces show examples of this issue.

true if class: Fred then
F10: ?Fred?

true if Object .subclass: Fred then
F10: ?Fred?

Add an appendix to describe the git branch strategy to be used in the fOOrth project.

The fOOrth User Guide needs a lot of additional work. Sections needing further work:

Exceptions, FalseClass class, Hash class, InStream class, Integer class, MaxNumeric class, MinNumeric class, NilClass class, Numeric class, Object class, OutStream class, Procedure class, Queue class, Stack class, String class, Thread class, and VirtualMachine class.

It is supposed to be the proper:

E15: divide by zero

Get the message text the correct way!

e.foorth_message

Time to get back on the upgrade treadmill!

Currently methods like .new{ ... } can only be created in Ruby. Allow them to be defined in fOOrth.

Use issue tracking in git to record areas in fOOrth needing further work and the progress made in completing that work.
Eventually, it is expected that issues will reflect... issues (how novel) encountered by users and developers working on and with fOOrth.

Right now, proxies can only be defined in Ruby. Language elements to define this in fOOrth are needed.

This is not done in a consistent manner.

The integration test suite is again hanging under Ruby 2.1.5 when running the rake integration task. This seems to be related to the length of the command line being shelled out to Ruby.

A temporary bodge is to shorten the names of the integration tests by replacing the word library with lib.

A better fix is needed as this will eventually break again when more files are added.

So that [ 1 2 3 ] . displays [ 1 2 3 ] and not [1, 2, 3]

and

{ "a" 3 -> } . displays { "a" 3 -> } and not {"a"=>3}

Describe the role of context and the methods available for exploring it.

The spec error is really a syntax error. Remap from F11 to F10,01 and lose the obscure message. Simple use the standard ?wordname? of FORTH.

This could be done with the .new_value method for a single value and the .new{ method to specify a default value block.

There seems to be a need for a nested mode that does not enter a deferred or compiled mode. It seems that the current mode control is rather ad-hoc and not at all well thought out. There is a lot of room for improvement here. Further, in its current state, the mode system will be very difficult to port to fOOrth.

Also: There is also a need for modes to be properly documented. Currently they are only hinted at.

This works with floats and rationals

0.01 pi .rationalize_to yields: 22/7
0.01 1234/55 .rationalize_to yields: 157/7

Allow rounding to a specified number of digits. For example:

2 pi .round_to produces 3.14

1.3 .to_r should result in 13/10 and not 5854679515581645/4503599627370496 !!!

Fork > Fix > Push ;-)

Currently stubs can only be created in Ruby.

These methods would be useful

1 2 3 3 .join [ 1 2 3]
[ 1 2 3 ] .split 1 2 3

These methods should be changed (added) to extract the specified string region before comparison. The existing .mid? could be renamed to .has? or .exists?

Add a section to the User Guide giving an overview of Boolean data.

Add this classic FORTH method too.