Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #134774 > unrolled thread
| Started by | Krishna Myneni <krishna.myneni@ccreweb.org> |
|---|---|
| First post | 2026-03-24 08:51 -0500 |
| Last post | 2026-03-29 13:22 +0200 |
| Articles | 20 on this page of 98 — 11 participants |
Back to article view | Back to comp.lang.forth
Parsing a file name with spaces Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-03-24 08:51 -0500
Re: Parsing a file name with spaces peter <peter.noreply@tin.it> - 2026-03-24 15:24 +0100
Re: Parsing a file name with spaces dxf <dxforth@gmail.com> - 2026-03-25 01:28 +1100
Re: Parsing a file name with spaces dxf <dxforth@gmail.com> - 2026-03-25 21:24 +1100
Re: Parsing a file name with spaces albert@spenarnc.xs4all.nl - 2026-03-25 14:57 +0100
Re: Parsing a file name with spaces Stephen Pelc <stephen@vfxforth.com> - 2026-03-24 15:55 +0000
Re: Parsing a file name with spaces Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-03-25 10:05 -0500
Re: Parsing a file name with spaces anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-03-25 16:56 +0000
Re: Parsing a file name with spaces Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-03-25 15:22 -0500
Re: Parsing a file name with spaces dxf <dxforth@gmail.com> - 2026-03-28 12:02 +1100
Re: Parsing a file name with spaces albert@spenarnc.xs4all.nl - 2026-03-28 08:54 +0100
Re: Parsing a file name with spaces dxf <dxforth@gmail.com> - 2026-03-28 19:37 +1100
Re: Parsing a file name with spaces sjack@dontemail.me (sjack) - 2026-03-28 15:10 +0000
Re: Parsing a file name with spaces anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-03-28 18:59 +0000
Re: Parsing a file name with spaces dxf <dxforth@gmail.com> - 2026-03-29 11:11 +1100
Re: Parsing a file name with spaces anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-03-29 09:24 +0000
Re: Parsing a file name with spaces albert@spenarnc.xs4all.nl - 2026-03-29 13:03 +0200
Re: Parsing a file name with spaces dxf <dxforth@gmail.com> - 2026-03-29 22:07 +1100
Re: Parsing a file name with spaces anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-03-29 16:08 +0000
Re: Parsing a file name with spaces dxf <dxforth@gmail.com> - 2026-03-30 09:34 +1100
Re: Parsing a file name with spaces dxf <dxforth@gmail.com> - 2026-03-31 09:18 +1100
Re: Parsing a file name with spaces Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-03-30 20:41 -0500
Re: Parsing a file name with spaces dxf <dxforth@gmail.com> - 2026-03-31 14:14 +1100
Re: Parsing a file name with spaces anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-03-31 07:36 +0000
Re: Parsing a file name with spaces albert@spenarnc.xs4all.nl - 2026-03-31 14:03 +0200
Re: Parsing a file name with spaces dxf <dxforth@gmail.com> - 2026-04-01 12:22 +1100
Re: Parsing a file name with spaces anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-04-01 08:22 +0000
Re: Parsing a file name with spaces dxf <dxforth@gmail.com> - 2026-04-01 20:06 +1100
Re: Parsing a file name with spaces anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-04-02 06:05 +0000
Re: Parsing a file name with spaces dxf <dxforth@gmail.com> - 2026-04-02 18:09 +1100
Re: Parsing a file name with spaces albert@spenarnc.xs4all.nl - 2026-04-02 13:54 +0200
Re: Parsing a file name with spaces dxf <dxforth@gmail.com> - 2026-04-03 11:57 +1100
Re: Parsing a file name with spaces albert@spenarnc.xs4all.nl - 2026-04-03 11:44 +0200
Re: Parsing a file name with spaces dxf <dxforth@gmail.com> - 2026-04-04 00:23 +1100
Re: Parsing a file name with spaces dxf <dxforth@gmail.com> - 2026-04-05 10:55 +1000
Re: Parsing a file name with spaces dxf <dxforth@gmail.com> - 2026-04-05 11:50 +1000
Re: Parsing a file name with spaces albert@spenarnc.xs4all.nl - 2026-04-01 12:25 +0200
Re: Parsing a file name with spaces dxf <dxforth@gmail.com> - 2026-04-02 00:07 +1100
Re: Parsing a file name with spaces anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-03-31 07:54 +0000
Re: Parsing a file name with spaces Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-03-31 05:03 -0500
Re: Parsing a file name with spaces anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-03-31 10:32 +0000
Re: Parsing a file name with spaces Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-03-31 10:26 -0500
Re: Parsing a file name with spaces albert@spenarnc.xs4all.nl - 2026-04-01 00:19 +0200
Re: Parsing a file name with spaces Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-03-31 18:04 -0500
Re: Parsing a file name with spaces anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-04-01 07:54 +0000
Re: Parsing a file name with spaces Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-04-01 06:23 -0500
Re: Parsing a file name with spaces anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-04-02 08:34 +0000
Re: Parsing a file name with spaces Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-04-02 07:18 -0500
Re: Parsing a file name with spaces anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-04-02 14:43 +0000
Re: Parsing a file name with spaces Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-04-02 20:52 -0500
Re: Parsing a file name with spaces albert@spenarnc.xs4all.nl - 2026-04-03 11:40 +0200
Re: Parsing a file name with spaces sjack@dontemail.me (sjack) - 2026-04-04 06:21 +0000
Re: Parsing a file name with spaces Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-04-04 08:00 -0500
Re: Parsing a file name with spaces sjack@dontemail.me (sjack) - 2026-04-04 22:01 +0000
Re: Parsing a file name with spaces dxf <dxforth@gmail.com> - 2026-04-07 10:23 +1000
Re: Parsing a file name with spaces sjack@dontemail.me (sjack) - 2026-04-07 14:26 +0000
Re: Parsing a file name with spaces sjack@dontemail.me (sjack) - 2026-04-07 15:05 +0000
Re: Parsing a file name with spaces sjack@dontemail.me (sjack) - 2026-04-07 17:09 +0000
Re: Parsing a file name with spaces dxf <dxforth@gmail.com> - 2026-04-08 12:25 +1000
Re: Parsing a file name with spaces Stephen Pelc <stephen@vfxforth.com> - 2026-04-09 10:22 +0000
Re: Parsing a file name with spaces dxf <dxforth@gmail.com> - 2026-04-01 19:13 +1100
Re: Parsing a file name with spaces anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-04-02 05:55 +0000
Re: Parsing a file name with spaces dxf <dxforth@gmail.com> - 2026-04-02 17:44 +1100
Re: Parsing a file name with spaces albert@spenarnc.xs4all.nl - 2026-03-31 13:41 +0200
Re: Parsing a file name with spaces Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-03-31 10:18 -0500
Re: Parsing a file name with spaces dxf <dxforth@gmail.com> - 2026-04-01 11:28 +1100
Re: Parsing a file name with spaces anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-04-01 08:17 +0000
Re: Parsing a file name with spaces dxf <dxforth@gmail.com> - 2026-04-01 19:42 +1100
Re: Parsing a file name with spaces albert@spenarnc.xs4all.nl - 2026-04-01 12:13 +0200
Re: Parsing a file name with spaces Gerry Jackson <do-not-use@swldwa.uk> - 2026-04-01 19:43 +0100
Re: Parsing a file name with spaces dxf <dxforth@gmail.com> - 2026-04-02 12:18 +1100
Re: Parsing a file name with spaces dxf <dxforth@gmail.com> - 2026-04-02 12:43 +1100
Re: Parsing a file name with spaces anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-04-02 09:07 +0000
Re: Parsing a file name with spaces dxf <dxforth@gmail.com> - 2026-04-02 21:50 +1100
Re: Parsing a file name with spaces anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-04-02 09:11 +0000
Re: Parsing a file name with spaces Hans Bezemer <the.beez.speaks@gmail.com> - 2026-04-12 19:37 +0200
Re: Parsing a file name with spaces Hans Bezemer <the.beez.speaks@gmail.com> - 2026-04-12 19:44 +0200
Re: Parsing a file name with spaces dxf <dxforth@gmail.com> - 2026-04-13 11:05 +1000
Re: Parsing a file name with spaces Hans Bezemer <the.beez.speaks@gmail.com> - 2026-04-14 14:45 +0200
Re: Parsing a file name with spaces Hans Bezemer <the.beez.speaks@gmail.com> - 2026-04-15 15:51 +0200
Re: Parsing a file name with spaces anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-03-24 17:58 +0000
Re: Parsing a file name with spaces Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-03-24 13:41 -0500
Re: Parsing a file name with spaces anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-03-24 20:40 +0000
Re: Parsing a file name with spaces Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-03-24 20:26 -0500
Re: Parsing a file name with spaces albert@spenarnc.xs4all.nl - 2026-03-25 10:37 +0100
Re: Parsing a file name with spaces Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-03-25 05:13 -0500
Re: Parsing a file name with spaces Bigtreeman <treecolin@gmail.com> - 2026-03-26 09:16 +1000
Re: Parsing a file name with spaces Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-03-25 20:57 -0500
Re: Parsing a file name with spaces anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-03-28 19:14 +0000
Re: Parsing a file name with spaces Bigtreeman <treecolin@gmail.com> - 2026-03-29 12:22 +1000
Re: Parsing a file name with spaces Paul Rubin <no.email@nospam.invalid> - 2026-03-28 20:55 -0700
Re: Parsing a file name with spaces Bigtreeman <treecolin@gmail.com> - 2026-03-29 17:00 +1000
Re: Parsing a file name with spaces Paul Rubin <no.email@nospam.invalid> - 2026-03-29 19:05 -0700
Re: Parsing a file name with spaces Bigtreeman <treecolin@gmail.com> - 2026-03-30 21:58 +1000
Re: Parsing a file name with spaces anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-03-29 09:52 +0000
Re: Parsing a file name with spaces anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-03-29 09:32 +0000
Re: Parsing a file name with spaces Bigtreeman <treecolin@gmail.com> - 2026-03-30 22:10 +1000
Re: Parsing a file name with spaces Hans Bezemer <the.beez.speaks@gmail.com> - 2026-03-29 13:22 +0200
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
| From | dxf <dxforth@gmail.com> |
|---|---|
| Date | 2026-04-01 19:13 +1100 |
| Message-ID | <69ccd3a9$1@news.ausics.net> |
| In reply to | #134821 |
On 31/03/2026 9:03 pm, Krishna Myneni wrote: > On 3/31/26 2:54 AM, Anton Ertl wrote: >> Krishna Myneni <krishna.myneni@ccreweb.org> writes: >>> While changing the long-standing behavior of INCLUDE is not a good idea, >>> using a consistent method for parsing file names in use currently is >>> needed. It doesn't matter whether or not one thinks such names are >>> insane. Such names are a reality we have to address. >> >> File name with just spaces have been addressed by INCLUDED long before >> INCLUDE was standardized in Forth-2012. ... > > INCLUDED is not a parsing form, which is needed in some use cases. > ... FORTH-94 didn't have any words that parsed a filename so it was never an issue. That changed when 200x introduced REQUIRE and INCLUDE. The culprit in their stack comment was the continued use of the token <name>. Properly a new token representing filenames should have been defined and added to 2.2.3 'Parsed-text notation'. This would have covered what forth systems were using in real life.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-04-02 05:55 +0000 |
| Message-ID | <2026Apr2.075555@mips.complang.tuwien.ac.at> |
| In reply to | #134831 |
dxf <dxforth@gmail.com> writes:
>FORTH-94 didn't have any words that parsed a filename so it was never an issue.
>That changed when 200x introduced REQUIRE and INCLUDE. The culprit in their
>stack comment was the continued use of the token <name>. Properly a new token
>representing filenames should have been defined and added to 2.2.3 'Parsed-text
>notation'. This would have covered what forth systems were using in real life.
What Gforth has been using in real life is parsing
white-space-delimited file names, which goes back to the time that
Gforth first implemented INCLUDE and REQUIRE (they already were
present in Gforth-0.2 in 1996). There have been no complaints about
that behaviour in the last 3 decades, and I have no intention to
change 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: https://forth-standard.org/
EuroForth 2025 proceedings: http://www.euroforth.org/ef25/papers/
[toc] | [prev] | [next] | [standalone]
| From | dxf <dxforth@gmail.com> |
|---|---|
| Date | 2026-04-02 17:44 +1100 |
| Message-ID | <69ce1055$1@news.ausics.net> |
| In reply to | #134844 |
On 2/04/2026 4:55 pm, Anton Ertl wrote: > dxf <dxforth@gmail.com> writes: >> FORTH-94 didn't have any words that parsed a filename so it was never an issue. >> That changed when 200x introduced REQUIRE and INCLUDE. The culprit in their >> stack comment was the continued use of the token <name>. Properly a new token >> representing filenames should have been defined and added to 2.2.3 'Parsed-text >> notation'. This would have covered what forth systems were using in real life. > > What Gforth has been using in real life is parsing > white-space-delimited file names, which goes back to the time that > Gforth first implemented INCLUDE and REQUIRE (they already were > present in Gforth-0.2 in 1996). There have been no complaints about > that behaviour in the last 3 decades, and I have no intention to > change it. Standard forth has obligations to a wider audience.
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl |
|---|---|
| Date | 2026-03-31 13:41 +0200 |
| Message-ID | <nnd$05dd835d$3c36be15@184ee771a393832b> |
| In reply to | #134817 |
In article <10qf8nr$2vaat$1@dont-email.me>,
Krishna Myneni <krishna.myneni@ccreweb.org> wrote:
>On 3/30/26 5:18 PM, dxf wrote:
>> On 30/03/2026 9:34 am, dxf wrote:
>>> On 30/03/2026 3:08 am, Anton Ertl wrote:
>>>> dxf <dxforth@gmail.com> writes:
>>>>> On 29/03/2026 8:24 pm, Anton Ertl wrote:
>>>>>> I don't know and I don't care what GETFILENAME does. The
>>>>>> specification for INCLUDE is clear:
>>>>>>
>>>>>> |Skip leading white space and parse name delimited by a white space
>>>>>> |character.
>>>>>
>>>>> Are you saying Gforth's INCLUDE is limited to that?
>>>>
>>>> Gforth implements the standard INCLUDE
>>>
>>> Christians cite Leviticus 20. What's your point?
>>
>> LMAO. Woke up to discover Forth Inc has reverted to the standard's
>> INCLUDE of 2006. It's worth repeating what they said in late 2006:
>>
>> SwiftForth 3.0.5 (22-Nov-2006)
>>
>> Changed the FILENAME parsing used by INCLUDE. Instead of repeatedly
>> parsing for a space character and checking for file existence (which
>> causes problems with file/directory name ambiguity), INCLUDE now uses
>> the more standard technique of allowing optional double-quote delimited
>> path names. The quotes are only required when the path name contains a
>> space. In all other cases, this change has no impact.
>>
>> 30 years after the world was introduced to filenames with spaces, forth
>> does a taliban in favour of one that no longer exists.
>>
>
>INCLUDE per the Forth-2012 standard is inadequate for modern desktop
>systems, which was the starting point of this thread.
No. INCLUDED is the proper way, and once proper string denotation
is introduced by recognizers e.g. "foor bar.c" there is no reason
to use INCLUDE apart from an interactive convenience.
In the time of blocks, nobody had the idea of
LOAD 13
instead of
13 LOAD
>Krishna
>
Groetjes Albert
--
The Chinese government is satisfied with its military superiority over USA.
The next 5 year plan has as primary goal to advance life expectancy
over 80 years, like Western Europe.
[toc] | [prev] | [next] | [standalone]
| From | Krishna Myneni <krishna.myneni@ccreweb.org> |
|---|---|
| Date | 2026-03-31 10:18 -0500 |
| Message-ID | <10qgok7$3ejgv$1@dont-email.me> |
| In reply to | #134823 |
On 3/31/26 6:41 AM, albert@spenarnc.xs4all.nl wrote: > In article <10qf8nr$2vaat$1@dont-email.me>, ... there is no reason > to use INCLUDE apart from an interactive convenience. > And that was my point in my original post. It is still necessary to have a file name parsing word for some applications. Standard INCLUDE and INCLUDED are not sufficient for that purpose. -- KM
[toc] | [prev] | [next] | [standalone]
| From | dxf <dxforth@gmail.com> |
|---|---|
| Date | 2026-04-01 11:28 +1100 |
| Message-ID | <69cc66b6$1@news.ausics.net> |
| In reply to | #134823 |
On 31/03/2026 10:41 pm, albert@spenarnc.xs4all.nl wrote: > In article <10qf8nr$2vaat$1@dont-email.me>, > Krishna Myneni <krishna.myneni@ccreweb.org> wrote: >> ... >> INCLUDE per the Forth-2012 standard is inadequate for modern desktop >> systems, which was the starting point of this thread. > > No. INCLUDED is the proper way, and once proper string denotation > is introduced by recognizers e.g. "foor bar.c" there is no reason > to use INCLUDE apart from an interactive convenience. > > In the time of blocks, nobody had the idea of > LOAD 13 > instead of > 13 LOAD Given CHAR [CHAR] what reason is there for 'c' ? Some swear for it while others at it. For me it wasn't merely redundant, it required hacking the forth interpreter to implement. With INCLUDE which was added on the basis of 'common practice', it's at least based on INCLUDED and therefore relatively easy for a user to implement should it not be provided. What I object to are appeals to authority which apparently have caused otherwise sane people to do insane things. "A victory dependent upon authority is unreal and illusory." - Bertrand Russell
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-04-01 08:17 +0000 |
| Message-ID | <2026Apr1.101749@mips.complang.tuwien.ac.at> |
| In reply to | #134829 |
dxf <dxforth@gmail.com> writes:
>What I object to are appeals to authority
Look who's talking.
- 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: https://forth-standard.org/
EuroForth 2025 proceedings: http://www.euroforth.org/ef25/papers/
[toc] | [prev] | [next] | [standalone]
| From | dxf <dxforth@gmail.com> |
|---|---|
| Date | 2026-04-01 19:42 +1100 |
| Message-ID | <69ccda70$1@news.ausics.net> |
| In reply to | #134833 |
On 1/04/2026 7:17 pm, Anton Ertl wrote: > dxf <dxforth@gmail.com> writes: >> What I object to are appeals to authority > > Look who's talking. 200x creator, defender and goalkeeper?
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl |
|---|---|
| Date | 2026-04-01 12:13 +0200 |
| Message-ID | <nnd$1c9e451f$30b11d6b@d9f8fdc8543c3d83> |
| In reply to | #134829 |
In article <69cc66b6$1@news.ausics.net>, dxf <dxforth@gmail.com> wrote: >On 31/03/2026 10:41 pm, albert@spenarnc.xs4all.nl wrote: >> In article <10qf8nr$2vaat$1@dont-email.me>, >> Krishna Myneni <krishna.myneni@ccreweb.org> wrote: >>> ... >>> INCLUDE per the Forth-2012 standard is inadequate for modern desktop >>> systems, which was the starting point of this thread. >> >> No. INCLUDED is the proper way, and once proper string denotation >> is introduced by recognizers e.g. "foor bar.c" there is no reason >> to use INCLUDE apart from an interactive convenience. >> >> In the time of blocks, nobody had the idea of >> LOAD 13 >> instead of >> 13 LOAD > >Given CHAR [CHAR] what reason is there for 'c' ? Some swear for it >while others at it. For me it wasn't merely redundant, it required >hacking the forth interpreter to implement. In view of the ' character playing a special role in Forth it was a bad idea to copy this c-notation. Groetjes Albert -- The Chinese government is satisfied with its military superiority over USA. The next 5 year plan has as primary goal to advance life expectancy over 80 years, like Western Europe.
[toc] | [prev] | [next] | [standalone]
| From | Gerry Jackson <do-not-use@swldwa.uk> |
|---|---|
| Date | 2026-04-01 19:43 +0100 |
| Message-ID | <10qjp0t$fnek$1@dont-email.me> |
| In reply to | #134829 |
On 01/04/2026 01:28, dxf wrote: > On 31/03/2026 10:41 pm, albert@spenarnc.xs4all.nl wrote: >> In article <10qf8nr$2vaat$1@dont-email.me>, >> Krishna Myneni <krishna.myneni@ccreweb.org> wrote: >>> ... >>> INCLUDE per the Forth-2012 standard is inadequate for modern desktop >>> systems, which was the starting point of this thread. >> >> No. INCLUDED is the proper way, and once proper string denotation >> is introduced by recognizers e.g. "foor bar.c" there is no reason >> to use INCLUDE apart from an interactive convenience. >> >> In the time of blocks, nobody had the idea of >> LOAD 13 >> instead of >> 13 LOAD > > Given CHAR [CHAR] what reason is there for 'c' ? Some swear for it > while others at it. For me it wasn't merely redundant, it required > hacking the forth interpreter to implement. I'm curious - why did you implement it if redundant and you clearly hate it? -- Gerry
[toc] | [prev] | [next] | [standalone]
| From | dxf <dxforth@gmail.com> |
|---|---|
| Date | 2026-04-02 12:18 +1100 |
| Message-ID | <69cdc3e7$1@news.ausics.net> |
| In reply to | #134841 |
On 2/04/2026 5:43 am, Gerry Jackson wrote:
> On 01/04/2026 01:28, dxf wrote:
>> On 31/03/2026 10:41 pm, albert@spenarnc.xs4all.nl wrote:
>>> In article <10qf8nr$2vaat$1@dont-email.me>,
>>> Krishna Myneni <krishna.myneni@ccreweb.org> wrote:
>>>> ...
>>>> INCLUDE per the Forth-2012 standard is inadequate for modern desktop
>>>> systems, which was the starting point of this thread.
>>>
>>> No. INCLUDED is the proper way, and once proper string denotation
>>> is introduced by recognizers e.g. "foor bar.c" there is no reason
>>> to use INCLUDE apart from an interactive convenience.
>>>
>>> In the time of blocks, nobody had the idea of
>>> LOAD 13
>>> instead of
>>> 13 LOAD
>>
>> Given CHAR [CHAR] what reason is there for 'c' ? Some swear for it
>> while others at it. For me it wasn't merely redundant, it required
>> hacking the forth interpreter to implement.
>
> I'm curious - why did you implement it if redundant and you clearly hate it?
An undocumented feature disabled by default. I was curious enough to find
out what it would take. For me, it was 34 bytes better spent elsewhere.
: number ( c-addr -- n|d|r xt )
dup 2@ swap $FF00 and $27002703. d= if 2+ c@ postpone literal exit then
count ...
hdr x,'NUMBER',,1
numb: call docol
if 0 ; 200x char literal 'c'
dw dupp,tat
dw swap
dw lit,0ff00h
dw andd
dw tlit
dw 2700h,2703h
dw dequ
dw zbran,numb0
dw twop,cat
dw lit,liter
dw exit
numb0 = $
endif
dw count
...
[toc] | [prev] | [next] | [standalone]
| From | dxf <dxforth@gmail.com> |
|---|---|
| Date | 2026-04-02 12:43 +1100 |
| Message-ID | <69cdc9ac$1@news.ausics.net> |
| In reply to | #134842 |
On 2/04/2026 12:18 pm, dxf wrote: > ... > > : number ( c-addr -- n|d|r xt ) > dup 2@ swap $FF00 and $27002703. d= if 2+ c@ postpone literal exit then > count ... Let's try that again. Assumes a 16-bit forth. : number ( c-addr -- n|d|r xt ) dup 2@ swap $FF00 and $27002703. d= if 2+ c@ ['] literal exit then count ...
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-04-02 09:07 +0000 |
| Message-ID | <2026Apr2.110715@mips.complang.tuwien.ac.at> |
| In reply to | #134842 |
dxf <dxforth@gmail.com> writes:
>On 2/04/2026 5:43 am, Gerry Jackson wrote:
>> On 01/04/2026 01:28, dxf wrote:
>>> Given CHAR [CHAR] what reason is there for 'c' ?
...
>For me, it was 34 bytes better spent elsewhere.
How much do CHAR and [CHAR] cost in your system?
[I applied the correction from <69cdc9ac$1@news.ausics.net>]
>: number ( c-addr -- n|d|r xt )
> dup 2@ swap $FF00 and $27002703. d= if 2+ c@ ['] literal exit then
> count ...
Clever!
- 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: https://forth-standard.org/
EuroForth 2025 proceedings: http://www.euroforth.org/ef25/papers/
[toc] | [prev] | [next] | [standalone]
| From | dxf <dxforth@gmail.com> |
|---|---|
| Date | 2026-04-02 21:50 +1100 |
| Message-ID | <69ce4a13@news.ausics.net> |
| In reply to | #134849 |
On 2/04/2026 8:07 pm, Anton Ertl wrote: > dxf <dxforth@gmail.com> writes: >> On 2/04/2026 5:43 am, Gerry Jackson wrote: >>> On 01/04/2026 01:28, dxf wrote: >>>> Given CHAR [CHAR] what reason is there for 'c' ? > ... >> For me, it was 34 bytes better spent elsewhere. > > How much do CHAR and [CHAR] cost in your system? Everything in my system costs. It comes down to what can I afford to lose.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-04-02 09:11 +0000 |
| Message-ID | <2026Apr2.111128@mips.complang.tuwien.ac.at> |
| In reply to | #134829 |
dxf <dxforth@gmail.com> writes:
>Given CHAR [CHAR] what reason is there for 'c' ?
My reasons are:
1) Shorter source code
2) source code that can be copied and pasted from interpreted code to
compiled code and vice versa.
Looking at <http://www.forth200x.org/number-prefixes.html>, the
proposal does not give this reasons, but focuses on existing practice.
>For me it wasn't merely redundant, it required
>hacking the forth interpreter to implement.
Yes, like the Chuck Moore hacked the interpreter when he included a
number recognizer instead of adding parsing words for numbers. If he had
added, e.g.
single -single double -double
[single] [-single] [double] [-double]
instead, he would have spared himself and us all the complexity of
dealing with negative numbers and doubles in the number recognizer. I
am happy that he did not (admittedly, his double syntax is debatable).
- 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: https://forth-standard.org/
EuroForth 2025 proceedings: http://www.euroforth.org/ef25/papers/
[toc] | [prev] | [next] | [standalone]
| From | Hans Bezemer <the.beez.speaks@gmail.com> |
|---|---|
| Date | 2026-04-12 19:37 +0200 |
| Message-ID | <nnd$60fc60e8$79c3d3b2@5c4f08db57f94819> |
| In reply to | #134829 |
On 01-04-2026 02:28, dxf wrote: > What I object to are appeals > to authority which apparently have caused otherwise sane people to do > insane things. Agreed. Never outsource your ability to think, reason or decide. It were always the rebels that brought humanity forward, never the rulers. Hans Bezemer
[toc] | [prev] | [next] | [standalone]
| From | Hans Bezemer <the.beez.speaks@gmail.com> |
|---|---|
| Date | 2026-04-12 19:44 +0200 |
| Message-ID | <nnd$65376cb2$5c1809cf@5c4f08db57f94819> |
| In reply to | #134816 |
On 31-03-2026 00:18, dxf wrote: > LMAO. Woke up to discover Forth Inc has reverted to the standard's > INCLUDE of 2006. It's worth repeating what they said in late 2006: > > SwiftForth 3.0.5 (22-Nov-2006) > > Changed the FILENAME parsing used by INCLUDE. Instead of repeatedly > parsing for a space character and checking for file existence (which > causes problems with file/directory name ambiguity), INCLUDE now uses > the more standard technique of allowing optional double-quote delimited > path names. The quotes are only required when the path name contains a > space. In all other cases, this change has no impact. > > 30 years after the world was introduced to filenames with spaces, forth > does a taliban in favour of one that no longer exists. Was that the standard? Really? I'm already ashamed I must try to open an include file twice - because the $DIR4TH environment variable may be involved. ;-) No, the first space is the delimiter of the filename. Ik ben gekke Henkie niet.. Hans Bezemer
[toc] | [prev] | [next] | [standalone]
| From | dxf <dxforth@gmail.com> |
|---|---|
| Date | 2026-04-13 11:05 +1000 |
| Message-ID | <69dc413c$1@news.ausics.net> |
| In reply to | #134918 |
On 13/04/2026 3:44 am, Hans Bezemer wrote: > On 31-03-2026 00:18, dxf wrote: >> LMAO. Woke up to discover Forth Inc has reverted to the standard's >> INCLUDE of 2006. It's worth repeating what they said in late 2006: >> >> SwiftForth 3.0.5 (22-Nov-2006) >> >> Changed the FILENAME parsing used by INCLUDE. Instead of repeatedly >> parsing for a space character and checking for file existence (which >> causes problems with file/directory name ambiguity), INCLUDE now uses >> the more standard technique of allowing optional double-quote delimited >> path names. The quotes are only required when the path name contains a >> space. In all other cases, this change has no impact. >> >> 30 years after the world was introduced to filenames with spaces, forth >> does a taliban in favour of one that no longer exists. > > Was that the standard? Really? I'm already ashamed I must try to open an include file twice - because the $DIR4TH environment variable may be involved. ;-) > > No, the first space is the delimiter of the filename. Ik ben gekke Henkie niet.. I should mention that Forth Inc has back-flipped on their recent decision and restored what they had. User complaints?
[toc] | [prev] | [next] | [standalone]
| From | Hans Bezemer <the.beez.speaks@gmail.com> |
|---|---|
| Date | 2026-04-14 14:45 +0200 |
| Message-ID | <nnd$1a9b9f00$47f1a6a7@76c6a78c60944cb7> |
| In reply to | #134920 |
On 13-04-2026 03:05, dxf wrote: > On 13/04/2026 3:44 am, Hans Bezemer wrote: >> On 31-03-2026 00:18, dxf wrote: >>> LMAO. Woke up to discover Forth Inc has reverted to the standard's >>> INCLUDE of 2006. It's worth repeating what they said in late 2006: >>> >>> SwiftForth 3.0.5 (22-Nov-2006) >>> >>> Changed the FILENAME parsing used by INCLUDE. Instead of repeatedly >>> parsing for a space character and checking for file existence (which >>> causes problems with file/directory name ambiguity), INCLUDE now uses >>> the more standard technique of allowing optional double-quote delimited >>> path names. The quotes are only required when the path name contains a >>> space. In all other cases, this change has no impact. >>> >>> 30 years after the world was introduced to filenames with spaces, forth >>> does a taliban in favour of one that no longer exists. >> >> Was that the standard? Really? I'm already ashamed I must try to open an include file twice - because the $DIR4TH environment variable may be involved. ;-) >> >> No, the first space is the delimiter of the filename. Ik ben gekke Henkie niet.. > > I should mention that Forth Inc has back-flipped on their recent decision > and restored what they had. User complaints? > Probably. I mean - the problem with this "solution" is that you effectively need a SECOND delimiter - or blow up the compiler. Why, well look at this thingy: include lib/fp0.4tt include lib/zenfsqrt.4th Now - let's assume I specified the first filename incorrectly - so it won't load. Pull in "INCLUDE". No such luck. Pull in "lib/zenfsqrt.4th". Since it's "everything since "lib/fp0.4tt"" it won't load either. Etc. etc. Until EOF. Unless we artificially terminate this string at EOL. BTW, that's what I always hated about "\", but let's not go in there. The additional "terminator" Bernd introduced is an elegant kludge, but nonetheless - it breaks a lot of code. So - always did "INCLUDE" as it is specified: "Skip leading white space and parse name delimited by a white space character. Push the address and length of the name on the stack and perform the function of INCLUDED." .. except for the "INCLUDED" part, because 4tH doesn't have "INCLUDED" - not is inclusion done at runtime (but at compile time). Fallback is [NEEDS, which was even in 4tH *before* INCLUDE. Nowadays I'm an avid INCLUDE user. And that works for me because I don't like filenames with spaces. It makes my skin crawl. Most files are included through $DIR4TH - so even in Windows it doesn't bother me much. And I never got a report it bothered others. So...? Hans Bezemer
[toc] | [prev] | [next] | [standalone]
| From | Hans Bezemer <the.beez.speaks@gmail.com> |
|---|---|
| Date | 2026-04-15 15:51 +0200 |
| Message-ID | <nnd$041ad6b7$16c8f6f5@282bbf8c46aaa16d> |
| In reply to | #134923 |
On 14-04-2026 14:45, Hans Bezemer wrote: >> I should mention that Forth Inc has back-flipped on their recent decision >> and restored what they had. User complaints? > Probably. What I meant here is that "user complaints" were probably the reason they rolled it back. *NOT* that the rollback *CAUSED* user complaints. I thought I should clarify that. ;-) Hans Bezemer
[toc] | [prev] | [next] | [standalone]
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
Back to top | Article view | comp.lang.forth
csiph-web