Re: The Ulimate Editor

Jenny Brien wrote:
On Sun, 01 Jan 2006 17:13:07 -0000, Alex McDonald <alex_mcd@xxxxxxxxxxxxxxx> wrote:

In fact, the call statement is not required in the latest version; the word (apart from case sensitivity) is tickable etc, and looks just like an ordinary word.


That's the sort of thing that trips people up. I'd just about sorted out in my mind that any Forth code that didn't use Call had its parameters in the opposite order. :-( Quite frankly, I don't much care which convention is used so long as it's explicitly declared.

I'm sorry, I'm not that conversant with other Windows' based Forths. In W32F, the parameters to CALL have always been in the reverse order to a standard C call. It's omission (a new feature) doesn't change the order. Given

int funcname (int a, int b);

then the stack effect is ( b a -- retval ), and CALL funcname or funcname operate identically. W32F does not use the count of parameters to manipulate the stack before the call; that's what I mean by stack-natural.


My goal is to be able to read a properly documented Windows routine in any language with which I am conversant, and be able to easily translate it into any Windows Forth. That applies to translation between Forths too!

Given that limited objective, I propose:

WINCONSTANTS
    constantname  [ alias ] [ \ comment ]

I'm not sure I understand this, or the requirement for it. Windows constants are (in the main) mostly numeric constants.

    ...
WINLIBRARY  dllname
    n IMPORT procname  \ stack comment in C order
    ...

This need not be implemented, but should be included (as a comment if necessary) in published code.

It is assumed that all proc names are found in the declared library.

Which one? In your example, is procname bound to the immediately preceding WINLIBRARY dllname?


Procnames are case-sensitive. They take parameters in the declared
order. If preceded by Call, they take parameters in 'stack natural' order. So Call would be mandatory for a Win32 type Forth, defined as a
noop if need be. Since the number of parameters is declared in IMPORT, it should be possible, if required, to write a Call to allow a C-order Forth to read 'stack-natural' code.

The number of parameters is fixed in the Windows api for most calls, but that is not generally true of all DLLs that we have experience in using with W32F. There are several calling conventions in use; for example C, Pascal, or standard. The n IMPORT notation is inadequate for this.


Well, that's a start. What else is needed? Maybe some tool to examine a library and automatically create an IMPORT list as a text file.

These already exist; they are the C header files in the Windows case. SWIG can be used to generate XML output from the parse of these, something I have experimented with.


Basically, I'll agree to anything that allows me to treat the name of a function as a normal Forth word, without too much declaration fluff; preferably just the name of the library it lives in, as I can do right now in Win32Forth. It's much more flexible currently than I think you give it credit for.


You can still do that for your own private code. I'm concerned with standards for publication, not implementation.

I'm concerned with ensuring that W32F can interface with as wide a range of external libraries (DLL, COM objects etc) as possible. The restrictions of n IMPORT (or W32F's n PROC) are too limiting.

--
Regards
Alex McDonald
.

Relevant Pages

  • Re: Application benchmark suite available
    ... but using a system with an inliner like VFX ... This is a GCC-maintainer-like interpretation of the standard. ... Forth system provides a real return stack, ... We quibble about not having portable Forth libraries. ...
    (comp.lang.forth)
  • Re: C89, size_t, and long
    ... libraries which have useful stuff). ... So because others here can't think of a good reason to use long instead of size_t and you can't prove there is never such a reason, we must all assume there could be a good reason to not use the mechanisms provided by the standard to deal with a problem? ... If you are claiming there is a reason to avoid the mechanisms the standard provides to allow portability then it is up to *you* to prove your point, not up to others to disprove it. ... but you can hardly blame the consequences on the Standard headers. ...
    (comp.lang.c)
  • Re: C89, size_t, and long
    ... libraries which have useful stuff). ... So because others here can't think of a good reason to use long instead of size_t and you can't prove there is never such a reason, we must all assume there could be a good reason to not use the mechanisms provided by the standard to deal with a problem? ... want to have standard headers included in their own headers which ...
    (comp.lang.c)
  • Re: comparing doubles for equality
    ... AFAIK there is no ANSI/ISO standard for it. ... Fortran 95 seem to have some built-in operators but it's not clear ... LIA,GIA,ICE libraries for interval methods in C++ from Delisoft ... Actually I've been for quite some months proposing getting together ...
    (comp.programming)
  • Re: "Criticism of the C programming language ??????"
    ... "that's not in the standard, ... rewrites of the compiler. ... PH> They got all the compiler vendors to agree to a common ... or graphics libraries or threading libraries, ...
    (comp.lang.c)
Loading