Re: Forth 200X and the Hayes tester

anton@xxxxxxxxxxxxxxxxxxxxxxxxxx (Anton Ertl) wrote:
Jonah Thomas <j2thomas@xxxxxxxxxx> writes:
When we are agreed about behaviors but we argue about what names to
give them -- doesn't that seem somehow trivial? Suppose we had two
solutions:

1. Let the compiler switch around the names' actions as needed. So
compilation can work with minimal changes to source code.
2. Let the text editor modify names as needed. So source code can
look the way you expect and still function correctly.

Then it becomes much less important that we choose one name when
common practice diverges.

Sounds like the Algol 60 approach. Not really an example to follow
(certainly not in this regard, and none of Algol 60s many successful
descendents have done so).

Among other things this would reduce the desired programmer
portability.

In the present case, there is actually no name clash (the locals use
of { is for the compilation semantics, and Forth Inc. could add {
comments as interpretation semantics in their implementation), only
the assumption that programmers could be confused.

I'm seeing this as a repetitive problem. So long as we think about
standards we will have name clashes where different systems use the same
name for different things, and different names for the same thing, and
we argue about which name to use where. In some fraction of cases both
uses for one name or both names for one function will be in enough use
to be painful for the losers to switch. Each time this happens it hurts
the standard and it hurts the Forth community.

If we have methods to easily change names it can only be an improvement.


Wordlists are a good start. To import somebody else's code, set up a
wordlist that defines his special names his way. Add it to the search
order before you import and remove it when you're done.

SYNONYM is a good start. Change the names as you need them.

I'm not sure what coding practices make it easy to change names in
source code. It's moderately bad to have names like TO that are common
in the documentation, since a global replace can corrupt the comments.
(But with literate programming that's easy to prevent, provided the name
isn't used in the documentation. ;) ) It's moderately bad to make
strings that must fit into indepently-fixed-size buffers, since a longer
new name might lead to the string getting truncated. Similarly it's a
little risky to make the new name longer than the old one.

When you change a name you need to change it in all the files you use
which use that name. And of course you need to carefully document the
change in case you miss a file you aren't using now, that you might use
after you've forgotten what the old name did.

I don't know what else.

Sure, programmers are less portable when they have to deal with
different names for the same thing and the same name for different
things than they would be if that never happened. Since it does happen,
and since standardising on one name may not always be the solution, and
since somebody has to deal with legacy code with the old names
regardless, it might make sense to have routine approaches (and perhaps
standard names for some routines) to handle it.
.

Relevant Pages

  • Standards question regarding intrinsics with complex arguments
    ... these arguments) is not permitted by the Fortran 95 standard. ... 1501-510 Compilation successful for file test_cmplx.f90. ... I believe the code in question is standard Fortran95 and that the compiler is ... A kind type parameter ...
    (comp.lang.fortran)
  • Re: C# -- Good or Bad?
    ... ECMA standard. ... These implementations use JIT compilation, ... > need languages which allow to work close to the hardware, ... Finally, I'd note that in some cases, interpretation can actually ...
    (comp.lang.cpp)
  • Re: Inconsistent Program Results
    ... including one of them might trivially slow down compilation, ... I wrote the above (starting with "The standard headers"). ... return void, but there's no advantage in using that. ... You're cheating yourself by ignoring warning messages. ...
    (comp.lang.c)
  • Re: Linux X demo
    ... Compilation can involve up to four stages: preprocessing, ... C source code which should not be preprocessed. ... library to make an Objective-C program work. ...
    (alt.lang.asm)
  • Re: GNU Public Licences Revisited (again)
    ... The source code isn't what most programmers are paid for, ... >> secrets' that allow companies to protect their ... Find 100 artists, get 100 ...
    (comp.programming)