 |
|
| Computers Forum Index » Computer Languages (Forth) » 4th RfD: Directories... |
|
Page 1 of 1 |
|
| Author |
Message |
| Bruce McFarling... |
 Posted: Thu Jan 21, 2010 4:37 am |
|
|
|
Guest
|
On Jan 20, 12:57 pm, an... at (no spam) mips.complang.tuwien.ac.at (Anton Ertl)
wrote:
Quote: Passing a relative filename to INCLUDED or REQUIRED uses the file name
as working-directory-relative file name. An ambiguous condition
exists if the file does not exist or is not accessible. [A typical
fallback then might be to search a path].
Passing a relative file name to REQUIRE or INCLUDE uses that file name
as source-directory-relative file name. An ambiguous condition
exists if that file does not exist or is not accessible.
Rendering non-standard any word that defined INCLUDE based on
INCLUDED. That is, given a word ParseFilename ( "filename" -- ca u )
respecting optional local quoting conventions,
: INCLUDE ( "filename" -- x*j ) ParseFilename INCLUDED ;
is under RfD 4 no longer a valid definition of INCLUDE, which is of
course absurd. |
|
|
| Back to top |
|
|
|
| Bruce McFarling... |
| Posted: Thu Jan 21, 2010 10:38 pm |
|
|
|
Guest
|
On Jan 21, 3:14 pm, J Thomas <jethom... at (no spam) gmail.com> wrote:
Quote: Provide a way for developers to specify absolute and relative directory paths
that will work on everybody's systems, when the developers already know
where to find the files they want.
Yes, have that.
Quote: Have one current path for commands like INCLUDED that provide source
code, and another path for commands like CREATE-FILE and OPEN-FILE
which work on data files.
This is even worse than Anton's proposal. He at least leaves a back
door open for generating an INCLUDE file then including it - even if
at the expense of specifying that INCLUDED is no longer the non-
parsing factor for INCLUDE. You seem to be proposing to put as many
obstacles in the way as you can conceive of. |
|
|
| Back to top |
|
|
|
| idknow... |
| Posted: Thu Jan 21, 2010 10:55 pm |
|
|
|
Guest
|
On Jan 21, 6:51 am, stephen... at (no spam) mpeforth.com (Stephen Pelc) wrote:
Quote: On Wed, 20 Jan 2010 17:57:50 GMT, an... at (no spam) mips.complang.tuwien.ac.at(Anton Ertl) wrote:
...
Leave INCLUDE alone and choose a new name.
Stephen
--
Stephen Pelc, stephen... at (no spam) mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web:http://www.mpeforth.com- free VFX Forth downloads
Hi folks; If I comprehend this thread correctly, then I'd like to
offer the word "use <path>" for consideration. |
|
|
| Back to top |
|
|
|
| J Thomas... |
| Posted: Fri Jan 22, 2010 12:52 am |
|
|
|
Guest
|
Bernd Paysan wrote:
Quote: I'm also not happy with the attitude "all good names are taken, please
use a bad one". As far as this proposal is concerned, MPE solves the
problem completely different, so has no common practice with what we
propose here. MPE uses the lose spec of file names to implement
something completely different (macros).
The usual way around this in previous standards was to supply a set of
construction words so that people could construct their favorite
implementation of e.g. VOCABULARY themselves, but nevertheless, they
all called it VOCABULARY  . So we might end up with having factors for
INCLUDE, which will be standardized, but what people actually *use* will
be called INCLUDE, nonetheless. And that use will break legacy code
that assumes a different semantics of INCLUDE.
Currently we don't have common practice, so people who do paticular things
(this time involving use of multiple directories) will find their code breaks
when it gets ported to foreign systems, unless somebody rewrites the code
in small ways.
If we change existing names to do new things, and all the important Forth
systems change, then new code will be portable, and legacy code which
depends on the old behavior will be broken on all systems except old
versions of the systems it was written for.
If we change existing names to do new things and some Forth systems are
not updated, then the situation will be pretty much unchanged except that we
get to point our fingers at the particular systems and say they are
nonstandard.
If we make new names for new functions then code which uses the new
names will port to the systems which provide the new names and new
functions. Legacy code will continue to be just as portable as it ever was.
People who keep using the old names will not get the benefit of the new
standard.
So, people who today use EXPECT instead of ACCEPT run into the minor
problems that ACCEPT was designed to fix. I don't notice that happening.
I find that I mostly use WORDLIST in place of VOCABULARY . It works OK.
I don't lose much. There are some words that would probably make it a
little easier, for example something to do
GET-ORDER wordlist SWAP 1+ SET-ORDER
etc with a single command. I haven't seen a proposal for names for those
words, and if we did get them standardised I would quit using what I use now
and I'd use the new names. I don't need VOCABULARY but if I wanted to use
it my code would be as portable as it ever was.
When there isn't common practice already and you make a standard, the
only people who get the benefit of the new standard are the people who
follow it. How could it be otherwise? In general there's a time to standardise
something, and that time is when there's beginning to be common practice.
If you try too early you're likely to get something that people won't use and
perhaps something that has flaws that haven't been discovered by
experience. If you try too late then either you're just putting a rubberstamp
on existing common practice or people will resist too much.
I like the idea of providing factored pieces of existing words, particularly
when the factors are likely to be useful in themselves.
And when vendors get into a deadlock where none of them want to
standardise the other guy's approach and give the other guy a competitive
advantage, then I like the idea of making the standard something that isn't
quite what any of them do, even if that makes it not particularly common
practice. Anything they all provide is portable for the people who choose
to use it, and if they can agree on that when they can't agree on something
else, then it's the way to go. |
|
|
| Back to top |
|
|
|
| J Thomas... |
| Posted: Fri Jan 22, 2010 1:14 am |
|
|
|
Guest
|
I think some of the criticism of the Directories proposal is that some of
us want it to tie into other innovations in addition to what it's currently
proposed to do.
Here's what I see it doing:
Provide a way for developers to specify absolute and relative directory paths
that will work on everybody's systems, when the developers already know
where to find the files they want. Have one current path for commands like
INCLUDED that provide source code, and another path for commands like
CREATE-FILE and OPEN-FILE which work on data files.
It looks to me like it will do this, and arguments about that are limited to
minor details.
Other things it might do:
1. Provide a format to allow macros. This would tie into a more general
macro proposal.
2. Provide a way for users to specify absolute or relative directory paths to
application installers and to applications, so that the applications can
reliably handle whatever the users give them. It might be useful for users to
be able to add files to a distribution and have the additions also be found on
everybody's systems. It might be useful to allow users to upload files to
foreign systems and have them be automatically stored in a correct place.
3. Maybe provide a way for applications to find packages that they need and
don't have, somehow searching foreign directory structures for the particular
versions of packages that they need? Without user intervention?
Is that it? Do we want ways for application developers and users both to
provide directory paths, and the developers provide paths that work
anywhere, and maybe applications should be able to search some default
structure for things that might be somewhere? Do any of these extended
goals require that something be done in the current proposal to
accomodate
them? |
|
|
| Back to top |
|
|
|
|
|
All times are GMT
The time now is Mon Mar 22, 2010 1:21 pm
|
|