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

Groups > comp.lang.forth > #46216 > unrolled thread

File extensions and Gforth on Openhub

Back to article view | Back to comp.lang.forth

Contents

  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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#46230

Julian Fondren <julian.fondren@gmail.com> writes:
>On Saturday, March 26, 2016 at 3:49:54 AM UTC-5, Anton Ertl wrote:
>.4 is an extension for *compiled* manpages.  Not something you'd
>find in a repo.

Looks to me like nroff source, so you might see this in a source
repository.

But the openhub case is just a symptom; detecting a file type by
extension is the easy and therefore common way to do it, and lots of
tools do it that way.  In some cases it is possible to extend the tool
to look at the content and decide based on that, but this requires
additional effort (who volunteers for that?), and it is not always
possible.

> I thought that F# was a pretty unimportant
>collision, since it's just O'Caml or SML or something dialect for
>.NET , but (with respect to .f) these are even less important.

I thought so, too, but apparently whoever wrote ohcount considered it
more significant than the usage of .fs for Forth.

>The last version of FoxPro was released in 1994.  Visual FoxPro was
>discontinued in 2007.  Theme files are not program source files.

And yet this use is listed in some file extension web sites and the
Forth usage is not.

>> So we decided that theforth.net uses .4th as default file extension
>> (essentially for package.4th).  Now the question is if we should not
>> move in that direction as a community in general.  I.e., add .4th as
>> extension to various tools we support, and use .4th as extension in
>> new projects, or maybe even in new files in old projects.
>> 
>
>*shrug*. github and openhub both have language identification
>libraries.  One already supports Forth and making the other support
>it seems like a more direct path to getting openhub to accurately
>identify Forth code.

Definitely, because it is unlikely that existing files will be
renamed, so Gforth will have 86k (and likely increasing) F# lines
forever unless the openhub way of counting lines is fixed.

>I guess the overall point is Forth advocacy, by way of increased
>visibility of Forth code.

No, that would be a nice side effect.  The overall point is that the
number of tools that use the file extension to decide what to do with
a file is increasing.

And the world is becoming more interconnected.  20 years ago, Gforth
did not work on Windows and MPE's and Forth, Inc.'s offerings did not
work on Unix, so there was little reason to worry about whether, say,
a SwiftForth editor setup would work for files originally written for
Gforth or vice versa.  These days we have SwiftForth and VFX for
Linux, and Gforth for Windows.

Having a common file extension has more synergistic effects now than
in the past, so maybe we should consider switching to a common file
extension for new files and in tool support, even if we all prefer our
existing file extensions.  The advantage of a common file extension
without conflicts is big enough IMO to be worth the cost of change and
the discomfort of using a non-favoured extension.

Of course, we need consensus in the community to reap these
benefits.

>That's a worthy goal, but, eh, '.4th' is
>an ugly extension.

That may be the case, and you give valid arguments, but I think that
the advantage of having no conflicts is more important.  A possible
political advantage is that it is not the favourite extension of any
of the big players, so it might be easier to get them to move there
than to the favourite extension of a big player.

- 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/

[toc] | [prev] | [next] | [standalone]

#46231

On 27/03/2016 09:01, Anton Ertl wrote:
> Having a common file extension has more synergistic effects now than
> in the past, so maybe we should consider switching to a common file
> extension for new files and in tool support, even if we all prefer our
> existing file extensions.  The advantage of a common file extension
> without conflicts is big enough IMO to be worth the cost of change and
> the discomfort of using a non-favoured extension.
>

File extensions are not of fixed length so why not use .forth as an 
extension.

-- 
Gerry

[toc] | [prev] | [next] | [standalone]

#46233

Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>On 27/03/2016 09:01, Anton Ertl wrote:
>> Having a common file extension has more synergistic effects now than
>> in the past, so maybe we should consider switching to a common file
>> extension for new files and in tool support, even if we all prefer our
>> existing file extensions.  The advantage of a common file extension
>> without conflicts is big enough IMO to be worth the cost of change and
>> the discomfort of using a non-favoured extension.
>>
>
>File extensions are not of fixed length so why not use .forth as an 
>extension.

Two more characters to type and read (there's a reason why we chose
.fs in Gforth and why Forth, Inc. chose .f), and there are still file
systems around like FAT and ISO9660 that limit the extensions to three
characters.  Admittedly, extensions that circumvent these limits like
VFAT and Rock Ridge (or, thanks to MicroSoft NIH syndrome, Joliet) are
usually available, but Microsoft uses VFAT patents as a club, so I
certainly don't want to bring Forth programmers in the position of
having to choose between following our recommendations and avoiding
patent trouble.

- 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/

[toc] | [prev] | [next] | [standalone]

#46277

On 27/03/2016 15:15, Anton Ertl wrote:
> Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>> On 27/03/2016 09:01, Anton Ertl wrote:
>>> Having a common file extension has more synergistic effects now than
>>> in the past, so maybe we should consider switching to a common file
>>> extension for new files and in tool support, even if we all prefer our
>>> existing file extensions.  The advantage of a common file extension
>>> without conflicts is big enough IMO to be worth the cost of change and
>>> the discomfort of using a non-favoured extension.
>>>
>>
>> File extensions are not of fixed length so why not use .forth as an
>> extension.
>
> Two more characters to type and read

Trivial objections, people read a word not individual characters, 
abbreviations have to be translated (evidently wrongly in the case of .frt)

.forth is explicit, meaningful and unlikely to be used for anything but 
Forth source files.

  (there's a reason why we chose
> .fs in Gforth and why Forth, Inc. chose .f), and there are still file
> systems around like FAT and ISO9660 that limit the extensions to three
> characters.  Admittedly, extensions that circumvent these limits like
> VFAT and Rock Ridge (or, thanks to MicroSoft NIH syndrome, Joliet) are
> usually available, but Microsoft uses VFAT patents as a club, so I
> certainly don't want to bring Forth programmers in the position of
> having to choose between following our recommendations and avoiding
> patent trouble.

In my ignorance I don't understand this. Can you give an example of a 
scenario in which Microsoft would sue someone for using .forth as an 
extension.

-- 
Gerry

[toc] | [prev] | [next] | [standalone]

#46278

Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
> In my ignorance I don't understand this. Can you give an example of a
> scenario in which Microsoft would sue someone for using .forth as an
> extension.

The issue is that traditional FAT filenames are limited to 3 character
extensions.  The workaround is VFAT, an overlay on FAT that is patented
by Microsoft.  FAT is used in many embedded systems.  Using .forth would
require people to also use VFAT and potentially get hassled over patents.

[toc] | [prev] | [next] | [standalone]

#46283

On Tue, 29 Mar 2016 00:15:06 -0700, Paul Rubin
<no.email@nospam.invalid> wrote:

>Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>> In my ignorance I don't understand this. Can you give an example of a
>> scenario in which Microsoft would sue someone for using .forth as an
>> extension.
>
>The issue is that traditional FAT filenames are limited to 3 character
>extensions.  The workaround is VFAT, an overlay on FAT that is patented
>by Microsoft.  FAT is used in many embedded systems.  Using .forth would
>require people to also use VFAT and potentially get hassled over patents.

Using .forth from a Windows box to a FAT filesystem without the
VFAT extension would simply mangle the extension. For every file
with a non-8.3 name there is a corresponding 8.3 name. For an
embedded system this is fine.

We have had very few requests to handle long file names in our
FAT file system. We will be interested if anyone has done it.

Stephen


-- 
Stephen Pelc, stephenXXX@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

[toc] | [prev] | [next] | [standalone]

#46282

Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>On 27/03/2016 15:15, Anton Ertl wrote:
>> Two more characters to type and read
>
>Trivial objections, people read a word not individual characters, 

If the characters of a word are on one line, yes.  However, if the
filename becomes so long that it does not fit in a line (including the
"bautiful" directory path that has long directory names for similar
reasons, the whole thing becomes very hard to read.  And that happens
in reality.  E.g., here are three lines from the output of "locate
Aufgabe1.java" on a system:

/nfs/a5/anton/pk/pk16s_uebungen/Aufgaben/Aufgabenblatt1/Aufgabenblatt1Studenten/Aufgabenblatt1/Aufgabe1/tasks/Aufgabe1.java
/nfs/a5/anton/pk/pk16s_uebungen/Aufgaben/Aufgabenblatt2/Aufgabenblatt1Studenten/Aufgabenblatt1/Aufgabe1/tasks/Aufgabe1.java
/nfs/a5/anton/pk/pk16s_uebungen/Aufgaben/Aufgabenblatt2/Aufgabenblatt2Studenten/Aufgabenblatt2/Aufgabe1/tasks/Aufgabe1.java

Do you find that easy to read?  On an 80-character-wide window?

Concise file names do not just make for easier reading, but also for
easier writing.

>  (there's a reason why we chose
>> .fs in Gforth and why Forth, Inc. chose .f), and there are still file
>> systems around like FAT and ISO9660 that limit the extensions to three
>> characters.  Admittedly, extensions that circumvent these limits like
>> VFAT and Rock Ridge (or, thanks to MicroSoft NIH syndrome, Joliet) are
>> usually available, but Microsoft uses VFAT patents as a club, so I
>> certainly don't want to bring Forth programmers in the position of
>> having to choose between following our recommendations and avoiding
>> patent trouble.
>
>In my ignorance I don't understand this. Can you give an example of a 
>scenario in which Microsoft would sue someone for using .forth as an 
>extension.

They probably won't sue a Forth programmer for using .forth, but they
might sue his employer for supporting VFAT in an embedded system.  So
the employer might chose not to support VFAT, and instead support
plain FAT.  Which would mean that the Forth programmer working for
this employer cannot use .forth, and he cannot use libraries that use
the .forth extension.

A library writer may find it more important to support such
programmers than to follow our hypothetical .forth recommendation.
Overall, while the sector of the Forth community that is directly
affected by this limitation may be small, it can have far more
wide-spread effects, because we are in a connected world.

The issue at hand is to improve interoperability, and ignoring
embedded systems for aesthetic reasons does not serve that purpose.

- 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/

[toc] | [prev] | [next] | [standalone]

#46285

On 29/03/2016 09:39, Anton Ertl wrote:
> Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>> On 27/03/2016 15:15, Anton Ertl wrote:
>>> Two more characters to type and read
>>
>> Trivial objections, people read a word not individual characters,
>
> If the characters of a word are on one line, yes.  However, if the
> filename becomes so long that it does not fit in a line (including the
> "bautiful" directory path that has long directory names for similar
> reasons, the whole thing becomes very hard to read.  And that happens
> in reality.  E.g., here are three lines from the output of "locate
> Aufgabe1.java" on a system:
>
> /nfs/a5/anton/pk/pk16s_uebungen/Aufgaben/Aufgabenblatt1/Aufgabenblatt1Studenten/Aufgabenblatt1/Aufgabe1/tasks/Aufgabe1.java
> /nfs/a5/anton/pk/pk16s_uebungen/Aufgaben/Aufgabenblatt2/Aufgabenblatt1Studenten/Aufgabenblatt1/Aufgabe1/tasks/Aufgabe1.java
> /nfs/a5/anton/pk/pk16s_uebungen/Aufgaben/Aufgabenblatt2/Aufgabenblatt2Studenten/Aufgabenblatt2/Aufgabe1/tasks/Aufgabe1.java
>
> Do you find that easy to read?  On an 80-character-wide window?

Of course not but the file extension doesn't contribute to the 
unreadability of those examples. My comment was just about the file 
extension, .java in your examples which is easy to read and locate in 
the overall name.

>
> Concise file names do not just make for easier reading, but also for
> easier writing.

So why did you use such long names in your examples?

>> In my ignorance I don't understand this. Can you give an example of a
>> scenario in which Microsoft would sue someone for using .forth as an
>> extension.
>
> They probably won't sue a Forth programmer for using .forth, but they
> might sue his employer for supporting VFAT in an embedded system.  So
> the employer might chose not to support VFAT, and instead support
> plain FAT.  Which would mean that the Forth programmer working for
> this employer cannot use .forth, and he cannot use libraries that use
> the .forth extension.
>
> A library writer may find it more important to support such
> programmers than to follow our hypothetical .forth recommendation.
> Overall, while the sector of the Forth community that is directly
> affected by this limitation may be small, it can have far more
> wide-spread effects, because we are in a connected world.
>
> The issue at hand is to improve interoperability, and ignoring
> embedded systems for aesthetic reasons does not serve that purpose.

It's a pity that limitations in one part of the community dictate what 
happens in the whole community. ISTM that the above is an argument for 
having two 'standard' extensions, one a 3 character extension for the 
embedded systems that use FAT, the other for the desktop systems etc 
that can use something like .forth.

-- 
Gerry

[toc] | [prev] | [next] | [standalone]

#46287

Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>On 29/03/2016 09:39, Anton Ertl wrote:
>> Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>>> On 27/03/2016 15:15, Anton Ertl wrote:
>>>> Two more characters to type and read
>>>
>>> Trivial objections, people read a word not individual characters,
>>
>> If the characters of a word are on one line, yes.  However, if the
>> filename becomes so long that it does not fit in a line (including the
>> "bautiful" directory path that has long directory names for similar
>> reasons, the whole thing becomes very hard to read.  And that happens
>> in reality.  E.g., here are three lines from the output of "locate
>> Aufgabe1.java" on a system:
>>
>> /nfs/a5/anton/pk/pk16s_uebungen/Aufgaben/Aufgabenblatt1/Aufgabenblatt1Studenten/Aufgabenblatt1/Aufgabe1/tasks/Aufgabe1.java
>> /nfs/a5/anton/pk/pk16s_uebungen/Aufgaben/Aufgabenblatt2/Aufgabenblatt1Studenten/Aufgabenblatt1/Aufgabe1/tasks/Aufgabe1.java
>> /nfs/a5/anton/pk/pk16s_uebungen/Aufgaben/Aufgabenblatt2/Aufgabenblatt2Studenten/Aufgabenblatt2/Aufgabe1/tasks/Aufgabe1.java
>>
>> Do you find that easy to read?  On an 80-character-wide window?
>
>Of course not but the file extension doesn't contribute to the 
>unreadability of those examples.

It's not the decisive factor here, but it certainly contributes.
There are also cases where the line is just a character or two too
long.

>> Concise file names do not just make for easier reading, but also for
>> easier writing.
>
>So why did you use such long names in your examples?

These are filenames occuring in reality.  I did not choose them (well,
I had a hand in the "/nfs/a5/anton/pk" part, but that's all).  The
person who chose them certainly had some reason for doing it, maybe he
even assumed it would help readability.

>> A library writer may find it more important to support such
>> programmers than to follow our hypothetical .forth recommendation.
>> Overall, while the sector of the Forth community that is directly
>> affected by this limitation may be small, it can have far more
>> wide-spread effects, because we are in a connected world.
>>
>> The issue at hand is to improve interoperability, and ignoring
>> embedded systems for aesthetic reasons does not serve that purpose.
>
>It's a pity that limitations in one part of the community dictate what 
>happens in the whole community.

That is life; a well-known example for this kind of principle is
<http://www.astrodigital.org/space/stshorse.html>.

>ISTM that the above is an argument for 
>having two 'standard' extensions, one a 3 character extension for the 
>embedded systems that use FAT, the other for the desktop systems etc 
>that can use something like .forth.

So what should a library writer use who writes a library that makes
sense for both embedded and desktop systems?

- 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/

[toc] | [prev] | [next] | [standalone]

#46292

On 29/03/2016 11:35, Anton Ertl wrote:
>>> A library writer may find it more important to support such
>>> >>programmers than to follow our hypothetical .forth recommendation.
>>> >>Overall, while the sector of the Forth community that is directly
>>> >>affected by this limitation may be small, it can have far more
>>> >>wide-spread effects, because we are in a connected world.
>>> >>
>>> >>The issue at hand is to improve interoperability, and ignoring
>>> >>embedded systems for aesthetic reasons does not serve that purpose.
>> >
>> >It's a pity that limitations in one part of the community dictate what
>> >happens in the whole community.
> That is life; a well-known example for this kind of principle is
> <http://www.astrodigital.org/space/stshorse.html>.

That didn't stop flat surface roads being invented that permitted 
different axle widths. The limitations of embedded systems tend to 
inhibit progress in the language.

>
>> >ISTM that the above is an argument for
>> >having two 'standard' extensions, one a 3 character extension for the
>> >embedded systems that use FAT, the other for the desktop systems etc
>> >that can use something like .forth.
> So what should a library writer use who writes a library that makes
> sense for both embedded and desktop systems?
>

There are several ways that I, and I'm sure you, can think of that are 
easier than handling directory paths in different systems.

-- 
Gerry

[toc] | [prev] | [next] | [standalone]

#46301

Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>The limitations of embedded systems tend to 
>inhibit progress in the language.

True, and we see an example of this in the cumbersome (to use, but
also to implement) interface we designed for SUBSTITUTE to avoid
having to ALLOCATE memory there.

But wether the common file extension is .4th or .forth is not a
question of progress.

>>> >ISTM that the above is an argument for
>>> >having two 'standard' extensions, one a 3 character extension for the
>>> >embedded systems that use FAT, the other for the desktop systems etc
>>> >that can use something like .forth.
>> So what should a library writer use who writes a library that makes
>> sense for both embedded and desktop systems?
>>
>
>There are several ways that I, and I'm sure you, can think of that are 
>easier than handling directory paths in different systems.

Please enlighten me about these ways.  I am not sure what directory
paths have to do with it.

- 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/

[toc] | [prev] | [next] | [standalone]

#46321

On 29/03/2016 17:47, Anton Ertl wrote:
>>>>> >>> >ISTM that the above is an argument for
>>>>> >>> >having two 'standard' extensions, one a 3 character extension for the
>>>>> >>> >embedded systems that use FAT, the other for the desktop systems etc
>>>>> >>> >that can use something like .forth.

>>> >>So what should a library writer use who writes a library that makes
>>> >>sense for both embedded and desktop systems?
>>> >>

>> >
>> >There are several ways that I, and I'm sure you, can think of that are
>> >easier than handling directory paths in different systems.

> Please enlighten me about these ways.

The simple way is to use the 3 letter extension as that will work on all 
systems. Other ways are to permit the user to change the file extension 
to suit; to provide 2 versions of the library with the different file 
extensions - the user selects the one to use; to provide a lib.forth 
file that includes the lib.fth containing the source code.

-- 
Gerry

[toc] | [prev] | [next] | [standalone]

#46322

On 2016-03-30, Gerry Jackson <gerry@jackson9000.fsnet.co.uk> wrote:
> On 29/03/2016 17:47, Anton Ertl wrote:
>>>>>> >>> >ISTM that the above is an argument for
>>>>>> >>> >having two 'standard' extensions, one a 3 character extension for the
>>>>>> >>> >embedded systems that use FAT, the other for the desktop systems etc
>>>>>> >>> >that can use something like .forth.
>
>>>> >>So what should a library writer use who writes a library that makes
>>>> >>sense for both embedded and desktop systems?
>>>> >>
>
>>> >
>>> >There are several ways that I, and I'm sure you, can think of that are
>>> >easier than handling directory paths in different systems.
>
>> Please enlighten me about these ways.
>
> The simple way is to use the 3 letter extension as that will work on all 
> systems.

That's going to be tough. Linux and UNIX don't use file extensions. There
are addons that have various extension awareness but the OS itself doesn't
care what you call a file.

Extensions are helpful for humans OTOH.

Bob

[toc] | [prev] | [next] | [standalone]

#46333

Bob Butler <bob@work.com> writes:
>On 2016-03-30, Gerry Jackson <gerry@jackson9000.fsnet.co.uk> wrote:
>> The simple way is to use the 3 letter extension as that will work on all 
>> systems.
>
>That's going to be tough. Linux and UNIX don't use file extensions. There
>are addons that have various extension awareness but the OS itself doesn't
>care what you call a file.

And that's why it's not at all tough to use a 3-letter extension on
Linux and Unix.

>Extensions are helpful for humans OTOH.

Microsoft seems to think otherwise: they hide the extension from
humans by default.

I think they are helpful for both humans and software for categorizing
files without looking inside, and for having a naming system for
related files.

- 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/

[toc] | [prev] | [next] | [standalone]

#46331

Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>On 29/03/2016 17:47, Anton Ertl wrote:
>>>>>> >>> >ISTM that the above is an argument for
>>>>>> >>> >having two 'standard' extensions, one a 3 character extension for the
>>>>>> >>> >embedded systems that use FAT, the other for the desktop systems etc
>>>>>> >>> >that can use something like .forth.
>
>>>> >>So what should a library writer use who writes a library that makes
>>>> >>sense for both embedded and desktop systems?
>>>> >>
>
>>> >
>>> >There are several ways that I, and I'm sure you, can think of that are
>>> >easier than handling directory paths in different systems.
>
>> Please enlighten me about these ways.
>
>The simple way is to use the 3 letter extension as that will work on all 
>systems.

That's a good solution, but why have the 5-letter extension for
desktop systems then?

>Other ways are to permit the user to change the file extension 
>to suit; to provide 2 versions of the library with the different file 
>extensions - the user selects the one to use; to provide a lib.forth 
>file that includes the lib.fth containing the source code.

And the benefits of .forth (instead of .4th) justify this cost?

- 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/

[toc] | [prev] | [next] | [standalone]

#46337

On 30/03/2016 15:00, Anton Ertl wrote:
> Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>> On 29/03/2016 17:47, Anton Ertl wrote:
>>>>>>>>>>> ISTM that the above is an argument for
>>>>>>>>>>> having two 'standard' extensions, one a 3 character extension for the
>>>>>>>>>>> embedded systems that use FAT, the other for the desktop systems etc
>>>>>>>>>>> that can use something like .forth.
>>
>>>>>>> So what should a library writer use who writes a library that makes
>>>>>>> sense for both embedded and desktop systems?
>>>>>>>
>>
>>>>>
>>>>> There are several ways that I, and I'm sure you, can think of that are
>>>>> easier than handling directory paths in different systems.
>>
>>> Please enlighten me about these ways.
>>
>> The simple way is to use the 3 letter extension as that will work on all
>> systems.
>
> That's a good solution, but why have the 5-letter extension for
> desktop systems then?
>

Well I thought that a unique extension to denote Forth source files was 
wanted that wouldn't be used by other languages, tools etc. This is 
unlikely with only 3 character extensions. I dislike .4th and .frt but 
apart from that I'm indifferent about the matter.

-- 
Gerry

[toc] | [prev] | [next] | [standalone]

#46338

Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
>Well I thought that a unique extension to denote Forth source files was 
>wanted that wouldn't be used by other languages, tools etc. This is 
>unlikely with only 3 character extensions.

I googled for "file extension .4th", and out of the first 10 hits 9
were file-extension websites, and they all only gave "Forth Source
Code Program" as the association for .4th; e.g.:
<http://fileinfo.com/extension/4th>.

The one other hit was this:
<http://stackoverflow.com/questions/18246756/what-is-the-most-common-filename-extension-of-a-forth-source-code-file>

This gives some statistics about the popularity of various extensions,
but it mainly shows that we are split rather than a community in this
area.

- 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/

[toc] | [prev] | [next] | [standalone]

#46298

On Tuesday, March 29, 2016 at 5:51:20 AM UTC-5, Anton Ertl wrote:
> Gerry Jackson <gerry@jackson9000.fsnet.co.uk> writes:
> >
> >It's a pity that limitations in one part of the community dictate what 
> >happens in the whole community.
> 
> That is life; a well-known example for this kind of principle is
> <http://www.astrodigital.org/space/stshorse.html>.
> 

That's amusing.  I've read it before, and recall that I drew from
it the lesson that it was very foolish for modern-day engineering
decisions to be affected by the Romans, who are all long dead.

It would have been wiser to design the most perfect imaginable SRB,
without regard such circumstances as having to transport them after
construction, and then to have used that.  Likewise each previous
generation should have done this, all the way back to the immediate
post-Romans who, having all of these good roads, should have torn
them up and reconstructed them to more precisely suit whatever
conveyance they could come up with at the time.

And of course, whenever you have just finished building some roads,
current-you should feel free to tear them right back up rather than
allow past-you have some kind of a say in any engineering that
concerns them.  Why be a slave to the past?


None of that's actually in the article, to its credit.


Nowadays I would just agree that this is a fine example of life.
Specifically, a fine example of living things.  Living things have
to function continuously.  They can't ever "not work" -- except to
then die.  There's a book, "Cat's Paws and Catapults", that
contrasts natural and man-made engineering.  Nature works with
flexible and wet materials; man works with dry and stiff materials,
and so on.  Nature's works must also function continuously, while
man can put his car on blocks, take his webserver down, disassemble
his shelves, to work on them and after a while put them back into
operation.  But men are natural, too.

Speaking of roads, suppose you built one from an existing town to
a newly discovered mine.  Then, later, you need to build a road
from the town to a second newly discovered mine.  Do you, without
regard for anything, come up with an optimal path between the town
and the new mine and then build that?  No - because you have this
other road already.  It may make sense to branch off of it after a
way, even if that's less ideal from the "there are no roads yet"
perspective.  After you've build the new extension of road, the
first mine may fail, leaving you with a senseless detour in what is
now one road from one town to one mine.

Someone may then come along, consider the single mine's location,
then the town's location, and then speculate that you - the road
builder - must be incapable of walking in a straight line without
firm assistance.  But at every step of the way you behaved
optimally.

"Continuously sensible road-building" is not the same thing as
"perfect road-building from the perspective of some later
observer".  Especially as otherwise written, "perfect road-building
according to a single, later, set of circumstances." Even with
foreknowledge, you couldn't avoid building the first road without
actively inconveniencing the town when the first mine was still
being worked.  If you'd betrayed their interests for some idea of
future perfection, they would've just called you a bad road
builder.


There are people who would eagerly betray the town, if they knew
for certain that some later passer-by would (seeing only the second
mine) conclude that the single road to it was well thought out.
This small reward is enough, weighed against the suffering and
drudgery of the townsmen having to cart ore right through a swamp,
or against their poverty for lack of the ore.  You can identify
these betrayers by showing them this story, "the Space Shuttle and
the Horse's Rear End", and then by proposing to them that the SRBs
were well designed because it made economic sense for them to be
transportable through a rail tunnel in the mountains.

"Economic sense," a betrayer will repeat, with scorn.


-- Julian

[toc] | [prev] | [next] | [standalone]

#46251

On Sun, 27 Mar 2016 15:00:32 +0100, Gerry Jackson
<gerry@jackson9000.fsnet.co.uk> wrote:

>On 27/03/2016 09:01, Anton Ertl wrote:
>> Having a common file extension has more synergistic effects now than
>> in the past, so maybe we should consider switching to a common file
>> extension for new files and in tool support, even if we all prefer our
>> existing file extensions.  The advantage of a common file extension
>> without conflicts is big enough IMO to be worth the cost of change and
>> the discomfort of using a non-favoured extension.
>>
>
>File extensions are not of fixed length so why not use .forth as an 
>extension.

MPE can live with .forth (and .frt) as a default extension for
Forth. We prefer .forth. After all FAT partitions are only there
to boot Linux and for embedded systems.

Stephen

-- 
Stephen Pelc, stephenXXX@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

[toc] | [prev] | [next] | [standalone]

#46253

stephen@mpeforth.com (Stephen Pelc) writes:
>MPE can live with .forth (and .frt) as a default extension for
>Forth. We prefer .forth.

The question at hand is if you can live with .4th, on which we decided
during the 2015 standards meeting, at which you were present.  If you
cannot live with that, why didn't you speak up then?

> After all FAT partitions are only there
>to boot Linux and for embedded systems.

Embeedded systems should be a good reason to make the standard file
extension FAT-compatible.  BTW, FAT partitions are not needed for
booting Linux.

- 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/

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.forth

csiph-web