Simplify CallUserFunction
Aleksej Saushev
Foreign function interface (FFI) is rather clumsy.
CallUserFunction is declared as returning cell value, which is ignored.
At this moment it accepts 3 parameters with values calculated from bit
fields in a cell, two those parameters denote arity and presense of
return value.
The problem is that in many cases external functions accept arguments of
types other than Forth cell type, thus one need to write wrapper function.
But then it is more useful to use simplified dispatching, when all
functions accept no arguments and return no values, operating on stack
directly. This has also positive side that all stack operations are
explicit and stack effect is visible.
Of course, one can do the same with current CallUserFunction implementation,
just declare all function as having zero arity and not returning result.
But then decoding work done for CallUserFunction is useless.
Another problem is that bit layout of CallUserFunction parameters is
defined and used in two different source files, which forces programmer
to modify two files, if he wants slightly different and possibly more
effective implementation. With single-argument CallUserFunction,
it is possible to define bit layout in single source file, or use other
ways to dispatch external functions.
I propose to change CallUserFunction to have signature
void CallUserFunction(cell_t func);
thus making "func" opaque for dispatch loop and in all the rest source
except pf_cglue.c, and correspondingly make CallUserFunction unpack bit
fields itself rather than relying on instruction dispatch code.
Phil Burk
> Foreign function interface (FFI) is rather clumsy.
Ouch.
> CallUserFunction is declared as returning cell value, which is
> ignored.
It may be unnecessary but I do not think this is harmful. The result of
the user function is pushed on the stack if requested. That is the
important thing.
> I propose to change CallUserFunction to have signature void
> CallUserFunction(cell_t func);
You have some fine ideas here. But please do not change any existing
APIs in pForth. We must not break existing user code.
> Of course, one can do the same with current CallUserFunction
> implementation, just declare all function as having zero arity and
> not returning result.
Right. You can still do what you want in the custom code.
> But then decoding work done for CallUserFunction is useless.
Not useless. It's convenient for the more common cases. It's already
written and it works. If you remove that functionality then you will
break lots of code that is happily using that feature.
> Another problem is that bit layout of CallUserFunction parameters is
> defined and used in two different source files, which forces
> programmer to modify two files, if he wants slightly different and
> possibly more
To add custom functions you only have to replace one file, pfcustom.c.
I am not interested in tinkering with pForth. The only things that I
think worth doing at this point are:
1) fixing obvious bugs
2) improving documentation
3) making it easier to build (Thanks Aleksej for your Makefile mods!)
4) supporting more platforms (Thanks also for your 64-bit mods!)
You have great ideas for creating a more perfect Forth. I strongly
encourage you to create a new Forth with all these great ideas. Then you
won't have to convince me to turn pForth into something else. You can
start with pForth. It is public domain. Just change the name and
refactor the code so it looks different and so it won't be confused with
pForth moving forward.
Thank you,
Phil Burk
Aleksej Saushev
> You have great ideas for creating a more perfect Forth. I strongly
> encourage you to create a new Forth with all these great ideas. Then you
> won't have to convince me to turn pForth into something else.
> You can start with pForth. It is public domain. Just change the
> name and refactor the code so it looks different and so it won't
> be confused with pForth moving forward.
Alright. Is it really public domain or is it copyrighted and licensed under MIT?
If it is public domain, why do files carry copyright notices?
Could you modify them so that the legal status is clear?
Does that apply to previous pForth versions?
--
HE CE3OH...
Phil Burk
> licensed under MIT?
The Google project was listed as MIT. That was the closest I could find.
They do not have "public domain" as an option. I just changed it to
"Other open source".
> If it is public domain, why do files carry copyright notices?
The pForth kernel was written at 3DO. We added some copyrighted works
with permission from Larry Polansky and David Rosenboom. 3DO agreed to
relinquish their rights if we made it all public domain. Everyone agreed
and we placed these copywritten works into the public domain. The 3DO
lawyers wrote the license paragraph.
The public domain license in each file describes how this copywritten
work may be used. I don't think there is a contradiction here. We could
not place it in the public domain if we did not own the copyrights.
> Does that apply to previous pForth versions?
Yes. The original pForth was released as public domain.
If you do this then I would encourage you to do a major rewrite. You
have many good ideas. If you have the energy then I think you could
produce and maintain a very good Forth.
Phil Burk