Re: Extension by implementation instead of consensus Re: [] arrays, again

anton@xxxxxxxxxxxxxxxxxxxxxxxxxx (Anton Ertl) wrote:
jmdrake <johnmdrake@xxxxxxxxx> writes:

No. That's not what I mean. I've been very clear so I don't
no why you built that strawman. I'm talking about having a
small core and building up words on top of it based on
implementation instead of consensus. Maybe you don't think
XML is portable.

XML is an empty shell. The Forth equivalent would be standardizing
that word names do not contain white space and that words are
separated by white space. An XML file also specifies to which DTD it
belongs, which defines more syntax, but no semantics. The Forth
equivalent would be to indicate at the start a file containing the
names (only the names, no definitions) of the predefined words used by
the program.

XML does not specify semantics, and the DTDs don't do it, either.

I think there are valid arguments against his concept but this isn't one
of them. He's thinking in terms of starting lower on the tree than that.

As long as you can load new words
that build up on your core then your program is portable.
You're concerned (maybe) that two different people might build
up two different words with the same name on top of the same
core. Guess what? That's already a reality. One approach
is to ask everybody "How do you use DEFER"? Another is to
simply have different reference implementations built in
ANS that show how different people use DEFER. I can (or
should be able to) drop whichever one fits my fancy on top
of whatever compliant Forth I'm using and expect it to work.
It shouldn't matter how Forth from X vendor may be using
DEFER or @+ or whatever as long as I can download and use
an ANS compliant version that does what I want.

What does this have to do with name spaces?

That approach does not scale well: For scaling extensions need to use
other extensions. How do you deal with half of the extensions using
variant A of DEFER, a quarter using variant B, and another quuarter
variant C?

I believe he's talking about using wordlists for that. You have an A
wordlist, a B wordlist and a C wordlist. Each extension uses the DEFER
it needs. That gets harder if the extensions do EVALUATE etc at runtime,
then they have to do SET-ORDER at runtime and it looks real messy to me.

So OK, if your system already has variant A but not the others and you
go to the big repository in the sky to get a library and that library
needs variant C, you can either use that library or you can rewrite it
to use variant A and upload your version too. Then the next guy who
needs that library has a choice between variant A and variant C.

So OK, let's say there are 20 different commonly-used words that have 2
variants each. If we had enough Forth users and enough Forth libraries
we would eventually find ourselves with 2^20 versions of some library.
But there aren't that many Forth users....

In practice people would tend to use the same version of each word that
some important library did, and they'd tend to use the version of each
word that their own Forth system provides, so we'd get clusters of
variants that go together, based on which library or system people get
influenced by.

With traditional Forth name handling you can work this by including
each variant right before each module that uses it (i.e., multiple
times). And even then you have to hope that another extension you
also need does not overwrite your prefered DEFER with its own
preferred variant.

In theory we have that problem now with / which can be floored or
symmetric, and libraries that care about that can define / using FM/MOD
or SM/REM , over and over again. In practice it seems like the arguments
about floored versus symmetric division died down as soon as we stopped
having a standard that specified which we'd get. The problem doesn't
arise that often and it's often easier to work around it than to choose
which / to need.

Another alternative would be something more in the direction of
wordsets, but that has its own set of problems.

I thought that's what he was talking about, but I may have
misunderstood. (Maybe I misunderstand you.) Yes, it has its own
problems. He claims that the example of XML shows that those problems
can be dealt with adequately. I don't follow how that works in detail,
but XML does let you use whole different languages and get them to sort
of cooperate.

No. =A0A compliant Forth-94 program cannot EMIT non-ASCII
characters.

LOL. Now you're trying to tell me how my code works?

I am trying to tell you what Forth-94 guarantees about EMIT. From the
specifications of UTF-8 and Forth-94 it follows that you cannot
implement a complete UTF-8 XEMIT or equivalent with Forth-94 EMIT.

Yes, it would only work for the particular Forth systems that implement
EMIT so it can send 0-255 or something like that. Those are standard
systems, but the standard systems that allow EMIT only to work with
32-126 would fail. It could still be useful to have code like that,
provided it was clear which systems it would run on.

So we'd essentially wind up with a collection of overlapping standards,
and code that has environmental dependencies will only run on the
systems that provide what it needs. That is, it would be what we have
now but more explicitly.

Yes, if you have specified an interface, then you can do a
different> implementation of that. =A0But then you are back to
specifying> interfaces, which is what we do in the Forth200x effort.

*Sigh* You don't get it. When you give an implementation you already
get an interface.

Sure, you get an interface. The interface that you specify through an
implementation is usually overspecified, and does not leave a lot of
room for different implementations.

E.g., the reference implementation for DEFER uses DOES>. If there was
no other specification, that would mean that the user can use >BODY to
access the field containing the vector. The specification of
X:deferred does not give that guarantee, allowing a variety of other
implementations.

Yes. So code which doesn't use >BODY could use all the versions of DEFER
that meet its needs. Code which does use >BODY would be more limited.

It looks to me like you and jmdrake have two different visions of how it
could work.

With your vision, smart Forth users and implementors think out the
problems ahead of time and come up with a version of DEFER that works
portably. Then Forth programmers use that version and their code is
portable.

With his vision, smart Forth users and implementors think out ahead of
time how to handle diversity of code. Then Forth programmers do whatever
they want and we manage the resulting complexity.

My prediction is that Forth programmers will do whatever they want, but
they will have some tendency to do it your way once you present a good
rationale along with reference code. So your approach does some good.

I think jmdrake's ideas are intriguing, and to make them work well we
need a way to automate most of the drudgery. If somebody has to sit down
with each piece of code and decide what systems it will port to, it
mostly won't get done. If somebody has to build test code for each
library that will show whether it will run on a given system, that
mostly won't get done either.

Unless there's some way to mostly automate all that, the best we can
hope for is libraries that get affirmations from users. "26 users say
that this library worked for them on SwiftForth, 37 users say that this
library worked for them on VFX-Forth, 18 users say that this library
worked for them on gforth, 1 users say that this library failed on
eforth". But even that is almost too much to expect.

(Assuming the implementation is well documented
with stack effects).

Stack effects can be extracted from the code (with some work) pretty
unambiguously, so that's not the issue. The issue is about specifying
what words are supposed to do without overspecifying it.

An alternative might be to find some way to automate the process of
documenting what is required for each piece of code. That looks like a
big effort. But each other solution also looks like a big effort.

Instead of worrying about name clashes just use what you
need. If, for whatever reason, you needed to use both
version that's where namespaces come into play. Assume
"bf" for the bigForth namespace and "sf" for the SwiftForth
namespace. Same code as above.

( One version of @+ )
: sf.@+ ( a | a' n ) dup cell+ swap @ ; / Takes address. Leaves
incremented address and value on stack

( Another version of @+ )
: bf.@+ ( a | n a' ) dup @ swap cell + ; / Takes address. Leaves
value and incremented address on stack

I don't have to sit down and think of some new word for
"@+".

Right, you thought about two new names, but at least you have a scheme
for generating them without much thinking.

I wouldn't want to think about writing bf.@+ every time I use the word.
I'd consider letting an edit function change all my @+ to bf.@+ before
it goes into a library. I'd rather put bf or sf at the beginning of a
file, but then I imagine a Forth system that is supposed to run various
libraries, and it implicitly commits itself to supply the entire user
interface to bigforth and swiftforth both....

There's just no comprehensive site
(that I know of) where people can search for verified plug and
play ANS forth code to do X.

That's certainly something that many people would like to see, and
it> has been discussed many times here and elsewhere in the past,
often> called CFAN (after CPAN (Perl) and CTAN (TeX)). =A0Until now
nobody has> implemented it yet. =A0One difference from CPAN/CTAN is
that it probably> should cater for multiple implementations/standards
(whereas there is> only one dominating Perl or TeX).

Right. That's the problem the web was having until someone
realized the way forward was to take a step back and simplify
HTML to XML. Now new standards based on XML come out routinely.
Having a simplified core and defining new words and supplying
reference implementations based on that core is the best way
forward IMO.

If you manage such a site, and people put programs there according to
that scheme, more power to you. But I don't hold my breath.

Yes, who will bell that cat?

Perhaps
there's someone quibbling about vectored execution in Perl
or TEX, but as you pointed out that hasn't stopped CTAN or
CPAN. You said they could move forward because they have
"one implementation".

No, I said that we have an additional issue to deal with because of
that.

If I had to name just one thing that TeX has and that Forth has not
(and that we have been quibbling over) and that's important for
building an archive of reusable libraries, it's kpathsea(rch).

But I think that's a problem that would solve itself if there was such
an archive: Those systems with sane path handling would be easy to use
with code from the archive, and the others would be hard.

If someone started such a project, maybe some of the other problems
would fall out too. The things that worked would work, and the things
that don't work would have to be worked around.

At what point do you think you will reach
the level where you can build CFAN?

At any time when I get the time to do it myself or the money to pay
someone for it. But why do you think it's my job to build CFAN?

Forth is not known for big cooperative efforts. But neither is anything
else really, right? Usually there's one main implementor and a few minor
contributors. So if something gets specified which has the requirements
cut down to the point that it looks pretty easy, it's more likely to get
done. Then the same person or somebody else might get motivated to do
something a little more ambitious.

When I look at big problems I tend to envision big comprehensive
solutions that look like a tremendous amount of work and which aren't
useful until they are complete. This is not a recipe for success.

When I think better, I can imagine small solutions for some of the
smaller problems. Something like a peephole optimiser could handle a lot
of the little wordlist problems. Run source code through the system and
convert -ROT to ROT ROT or ROT ROT to -ROT , whichever you prefer. 0> to
0 > . 1+ to 1 + or vice versa. Lots of little incompatibilities could
just get smoothed out.

John Hayes wrote code to test Forth systems for ANS compatibility.
Something similar could test ANS Forth systems for various of the known
implementation dependencies. It looks much harder to test code for
environmental dependencies but maybe something could be done with that.
The more of that work which can be automated the easier it gets to tell
which code will port where. Doing the easy parts could have some value
even if the hard parts never get done.

.

Relevant Pages

  • Writing a library for .NET ?
    ... libraries... ... // You can specify all the values or you can default the Revision and Build ... // If the KeyFile and the KeyName values are both specified, ... // directory is the project directory. ...
    (alt.comp.lang.borland-delphi)
  • Re: Infopath - Submit Form to Parent Library
    ... When I set up a datasource, I have to specify exactly where I want it to be ... I am setting up some site templates, and one of the form libraries will use ... my Infopath form template as its template. ... I've seen some posts asking about and maybe even providing a solution ...
    (microsoft.public.sharepoint.portalserver.development)
  • Re: Infopath - Submit Form to Parent Library
    ... When I set up a datasource, I have to specify exactly where I want it to be ... I am setting up some site templates, and one of the form libraries will use ... my Infopath form template as its template. ... I've seen some posts asking about and maybe even providing a solution ...
    (microsoft.public.sharepoint.portalserver.development)
  • Re: Infopath - Submit Form to Parent Library
    ... When I set up a datasource, I have to specify exactly where I want it to be ... I am setting up some site templates, and one of the form libraries will use ... my Infopath form template as its template. ...
    (microsoft.public.sharepoint.portalserver.development)
  • Re: Setting based 1 Arrays
    ... .NET libraries that wrap C++ code, I do have a couple articles on my blog that ... Before I dropped dead this morning, I did finally got three WcServerAPI class libraries in VB.NET, C# and C++/CLR. ... The factVARIANT was removed in all the .NET languages it seems, ...
    (microsoft.public.dotnet.languages.vb)
Loading