Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #46252

Re: File extensions and Gforth on Openhub

Show all headers | View raw

Bernd Paysan <bernd.paysan@gmx.de> writes:
>Am Sun, 27 Mar 2016 07:32:54 +0000 schrieb Anton Ertl:
>
>> Bernd Paysan <bernd.paysan@gmx.de> writes:
>>>Am Sat, 26 Mar 2016 08:15:04 +0000 schrieb Anton Ertl:
>>>As user, I would absolutely hate it when the next release of my Forth
>>>system would break all my programs which include some system library,
>>>just because the maintainer had changed all the extensions.
>> 
>> That's why I did not suggest changing existing files.
>
>But that's a bad idea: The existing files continue to have the problem, 
>e.g. being wrongly syntax-highlighted in the editor, because the editor 
>thinks it is a F# file.

If a project really has that problem (any occurences in the wild?),
they don't need me to suggest changing the extenson of the existing
file names.  They don't even need a consensus for a new extension in
that case.  So this issue is related to, but indepenent of what I was
suggesting.

>  Furthermore, inconsistent extensions are 
>annoying, too.  I want to load the string library, is it called string.fs 
>or is it a new library which would come under the name string.4th? And, 
>what could be worse: They both might exist, but actually be two different 
>string libraries, the first our "old, legacy" one, and the new string.4th 
>the "shiny new, much better one", which unfortunately is incompatible...

If the two files are related, that only occurs in the presense of
renaming, which I did not suggest; and I would hope that the project
members have enough sense to avoid that kind of confusion by also
making the basename different (e.g., string.fs and string2.4th).

If the two files are independent, we already have that problem now.
E.g., I find a string.fth coming with VFX, a string.f coming with
iForth (I would have expected SwiftForth), a string.4th coming with
PFE, and a string.fs coming with Gforth (actually, different versions
seem to include incompatible string.fs files; so much for project
members having sense; no matter, because they are all undocumented, so
anybody who uses that stuff is on their own).  And of course, if
someone wants to use two or more of these (e.g., because one library
uses one and another library uses another one), with the current lack
of directory support in the standard, the way to go is to put
everything in one directory.

Anyway, letting INCLUDE add or replace an extension would increase
that kind of confusion rather than reducing it.  E.g,, if there is

require string

which of the two should be included?

If there is

require string.fs

which of the two should be included?

>Don't.  If you change things like extensions, change them everywhere.  
>And before you do that, make sure the change will go smooth.

So your suggestion is to require various changes in Forth systems (to
make the file renamings go smooth), and that, when these changes are
implemented, everybody should switch all the files to the new common
extension?

That's quite a different, and somewhat complementary approach to what
I have suggested.  I believe that your suggestion has a very slim
chance of acceptance starting from where we are now.  My guess is that
people will see the costs of your suggestion higher than the benefits of 
having a common file extension.

OTOH, if my suggestion is accepted, and if you are right and it brings
about confusion and problems, then your suggestion has a better chance
of being accepted; of course smoothness is lost in this scenario.

However, I believe that there will not be much confusion and problems
if my suggestion is accepted.  Then maybe after some more years
passing, some existing projects may feel the desire to rename their
files to the new extension in order to benefit from better tool
support that will hopefully emerge.  We can add features to make that
transition smoother, and we can think about these features now, but
it's beyond what I am suggesting.

>>>So, in order to make a change of file extensions possible, we would
>>>first need to specify that INCLUDE works even when you don't specify the
>>>extension.
>> 
>> That would not help existing code that contains the file extension.
>
>A warning could be printed when the existing code still uses the file 
>extension, like "in <file>:<line>: explicit use of file extensions for 
>include is deprecated".

And that helps in which way?  Note that the topic is *legacy* code that
loads a new version of a library with changed extensions.

If I wanted to rename the files in a library (e.g., because my
editor becomes an F# editor for .fs files or something), what I would
do is to rename <file>.fs into <file>.4th, and also have a file
<file>.fs that contains just the following line:

require <file>.4th

(I think I can write that even in an F# editor).  No need for all
Forth systems to agree on an extension handling mechanism.  These stub
files are only needed for the load-files that were already used in the
old version (often only one file).

>> Of course, if we wanted to support changing the extension of existing
>> files, these words could try the filename with the new extension if the
>> file name with the old extension does not work.  But it is simpler not
>> to change existing files.
>
>If there weren't any drawbacks with the existing extension, we don't need 
>to change anything.

The question is if the drawbacks of renaming are not bigger than the
drawbacks of the existing extension.  I leave it to each project to
decide that for themselves.

>Still doesn't help with the drawbacks.  Funny that you are in the "we 
>don't have a problem" camp here.  If we don't have a problem with the 
>existing file extensions, we can stop the discussion right now.  If we 
>have a problem, it includes existing files, and they better get the new, 
>non-conflicting suffix.

We have a problem, but the questions are if 1) your suggested cure
(rename all existing code) is not worse than the disease and 2) you
can convince the whole community of that.

>On Linux, we haven't problems with .fs now, because nobody is using .net 
>on Linux, and for the Windows users, we don't give a shit ;-).  This may 
>change in the next years (the Linux use of .net, not that we don't give a 
>shit with Windows users problems; that won't change ;-).

I certainly do care for Windows users problems, and so do you, you
even make the Windows distributions.  As for .NET becoming more
relevant outside Windows, there was quite a lot of noise about Mono
maybe a decade ago, but I have not heard much about it in recent
years.  It seems to me that developers who drink the .NET Kool-Aid,
also use Windows-specific API calls, so .NET applications typically
work only on Windows.  Mono seems to be just a marketing effort by
Microsoft to make .NET seem more relevant than it is (e.g., to meet
token requirements for cross-platfrom-ness in some project bids), just
like the Windows POSIX support.

> Strictly speaking, I think the shipping of MINOS without an out-of-
>the-box setting to find the dependencies was a GPL violation, as the GPL 
>requires all build scripts ;-).

If there was a build script for that, the GPL requires you to include
it, but there is not, so there is no such requirement.

>>>So my proposal would be in that direction: Push that actual semantics
>>>out of the standard into a library, and just make sure the necessary
>>>plugin interface is standardized.  That would allow us to say "require
>>>some- packet" and the logic behind expanding filenames in require could
>>>say "ok,
>>>there's no file for that in the search path, but let's look in
>>>theforth.net package list, if we find one - and if so, download that,
>>>and include it", which would be part of the fget include.  You probably
>>>don't want to have this on open-file, though... so the plugin mechanism
>>>must be able to distinguish between these cases.
>> 
>> Interesting idea.  Now if two libraries use their own plug-ins, how to
>> combine that?  And how do you overcome the "we don't have this problem"
>> attitude?
>
>As usual with global settings and libraries: It is expected that the 
>library reverts the setting to the previous one, unless the library's 
>purpose is to change that setting.  It's the same issue as with BASE or 
>the search order, and recognizers.

Actually these cases are different:

BASE: there is no way you can combine BASEs, so you save it, change
it, and later restore it.  But even that is controversial, and is not
always done.  BASE seems to be a rather bad idea to me, and we are
slowly getting away from that, with number prefixes, and BASE-EXECUTE.

Search order: Here we typically add a new wordlist to the front of the
search order, and the others still remain in the search order
(possibly with some names shadowed).  Shadowing is relatively rare, so
that has not lead to big problems.

Recognizers: Again, we have a stack of recognizers to allow combining
them, with suggestions that we may want to add some to the end, and
maybe not remove them.  We don't have enough experience with
user-defined recognizers yet to see how that works out when combining
recognizers from different people; the potential for shadowing is
certainly higher.

Coming back to the issue at hand, defining a user-extendable mechanism
is a good idea if user extension is the primary goal, and even then
it's hard to get it right and easy to get it wrong, as evidenced by
BASE.

I don't think a user-extension mechanism is a good solution for the
problem of system implementors being unable to find consensus on a
standard mechanism for a problem.  Specifying a good user-defined
mechanism is harder (and more complex to specify and implement) than
specifying a common mechanism, so if we are too stupid to specify a
common mechanism, we are by far too stupid to specify a user-defined
mechanism.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2015: http://www.rigwit.co.uk/EuroForth2015/

Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

File extensions and Gforth on Openhub anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-26 08:15 +0000
  Re: File extensions and Gforth on Openhub Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-27 00:53 +0000
    Re: File extensions and Gforth on Openhub anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-27 07:32 +0000
      Re: File extensions and Gforth on Openhub Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-27 21:29 +0000
        Re: File extensions and Gforth on Openhub stephen@mpeforth.com (Stephen Pelc) - 2016-03-28 13:21 +0000
          relative file names and INCLUDED (was: File extensions ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-28 14:25 +0000
            Re: relative file names and INCLUDED (was: File extensions ...) stephen@mpeforth.com (Stephen Pelc) - 2016-03-28 15:35 +0000
              Re: relative file names and INCLUDED (was: File extensions ...) Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-28 19:58 +0000
              Re: relative file names and INCLUDED (was: File extensions ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-29 07:42 +0000
                Re: relative file names and INCLUDED (was: File extensions ...) stephen@mpeforth.com (Stephen Pelc) - 2016-03-29 11:33 +0000
                Re: relative file names and INCLUDED (was: File extensions ...) Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-29 15:34 +0000
                Re: relative file names and INCLUDED Doug Hoffman <glidedog@gmail.com> - 2016-03-29 12:31 -0400
                Re: relative file names and INCLUDED Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-30 14:21 +0000
                Re: relative file names and INCLUDED Doug Hoffman <glidedog@gmail.com> - 2016-03-30 10:35 -0400
                Re: relative file names and INCLUDED (was: File extensions ...) stephen@mpeforth.com (Stephen Pelc) - 2016-03-29 16:58 +0000
        Re: File extensions and Gforth on Openhub anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-28 12:29 +0000
          Re: File extensions and Gforth on Openhub Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-29 11:47 +0000
    Re: File extensions and Gforth on Openhub mhx@iae.nl - 2016-03-27 01:36 -0700
    Re: File extensions and Gforth on Openhub Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-27 15:19 +0000
  Re: File extensions and Gforth on Openhub Julian Fondren <julian.fondren@gmail.com> - 2016-03-26 19:51 -0700
    Re: File extensions and Gforth on Openhub anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-27 08:01 +0000
      Re: File extensions and Gforth on Openhub Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-03-27 15:00 +0100
        Re: File extensions and Gforth on Openhub anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-27 14:15 +0000
          Re: File extensions and Gforth on Openhub Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-03-29 08:13 +0100
            Re: File extensions and Gforth on Openhub Paul Rubin <no.email@nospam.invalid> - 2016-03-29 00:15 -0700
              Re: File extensions and Gforth on Openhub stephen@mpeforth.com (Stephen Pelc) - 2016-03-29 09:45 +0000
            Re: File extensions and Gforth on Openhub anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-29 08:39 +0000
              Re: File extensions and Gforth on Openhub Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-03-29 11:09 +0100
                Re: File extensions and Gforth on Openhub anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-29 10:35 +0000
                Re: File extensions and Gforth on Openhub Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-03-29 14:23 +0100
                Re: File extensions and Gforth on Openhub anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-29 16:47 +0000
                Re: File extensions and Gforth on Openhub Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-03-30 12:14 +0100
                Re: File extensions and Gforth on Openhub Bob Butler <bob@work.com> - 2016-03-30 11:11 +0000
                Re: File extensions and Gforth on Openhub anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-30 14:10 +0000
                Re: File extensions and Gforth on Openhub anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-30 14:00 +0000
                Re: File extensions and Gforth on Openhub Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-03-30 17:27 +0100
                Re: File extensions and Gforth on Openhub anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-30 16:47 +0000
                Re: File extensions and Gforth on Openhub Julian Fondren <julian.fondren@gmail.com> - 2016-03-29 09:41 -0700
        Re: File extensions and Gforth on Openhub stephen@mpeforth.com (Stephen Pelc) - 2016-03-28 13:34 +0000
          Re: File extensions and Gforth on Openhub anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-28 14:17 +0000
            Re: File extensions and Gforth on Openhub stephen@mpeforth.com (Stephen Pelc) - 2016-03-28 15:24 +0000
              Re: File extensions and Gforth on Openhub Paul Rubin <no.email@nospam.invalid> - 2016-03-28 10:51 -0700
                Re: File extensions and Gforth on Openhub foxaudioresearch@gmail.com - 2016-03-28 18:35 -0700
                Re: File extensions and Gforth on Openhub Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-03-29 08:05 +0100
              Re: File extensions and Gforth on Openhub anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-29 07:12 +0000
                Re: File extensions and Gforth on Openhub Paul Rubin <no.email@nospam.invalid> - 2016-03-29 00:42 -0700
                Re: File extensions and Gforth on Openhub stephen@mpeforth.com (Stephen Pelc) - 2016-03-29 09:55 +0000
                Re: File extensions and Gforth on Openhub anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-29 10:23 +0000
    Re: File extensions and Gforth on Openhub anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-27 14:09 +0000
    Re: File extensions and Gforth on Openhub Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-27 15:20 +0000
  Re: File extensions and Gforth on Openhub "Steve(spt)" <steven@jupiter-ace.co.uk> - 2016-03-28 06:44 -0700
  Re: File extensions and Gforth on Openhub Lars Brinkhoff <lars.spam@nocrew.org> - 2016-03-30 08:49 +0200

csiph-web