AFAICT, Peter Honeyman invented this concept decades ago: a command that
tells the current time in English rounded to the nearest five minutes,
like "Five til three" for 2:54. He wrote a version in C and used it
all the time. I later also wrote one in C and used it for a while.
Here it is in Gforth (set file to executable and run it):
\ ----------------------------------------------------------------
#! /usr/bin/gforth
: str-array ( n -- ) create 2 cells * allot
does> ( n -- a ) swap 2 cells * + ;

12 str-array hours
12 str-array minutes

variable a \ "address register"
: 2!a+ ( n n -- ) a @ 2! 2 cells a +! ;
: aa 2!a+ ; \ easier to type

0 hours a !
s" twelve" aa s" one" aa s" two" aa s" three" aa
s" four" aa s" five" aa s" six" aa s" seven" aa
s" eight" aa s" nine" aa s" ten" aa s" eleven" aa

0 minutes a !
s" o'clock" aa s" five after" aa
s" ten after" aa s" quarter past" aa
s" twenty after" aa s" twenty-five after" aa
s" half past" aa s" twenty-five til" aa
s" twenty til" aa s" quarter til" aa
s" ten til" aa s" five til" aa

: capitalize-letter ( c -- C ) \ precondition: c is a letter
$20 invert and ;

: capitalize-and-type ( a u -- ) \ precondition: u > 0
\ take string like "foo" and type it out as "Foo"
swap dup c@ capitalize-letter emit 1+ swap 1- type ;

: hms-time.1 ( seconds minutes hours day month year -- hours minutes seconds )
drop drop drop -rot swap ;
: hms-time ( -- hours minutes seconds ) time&date hms-time.1 ;

: rounded-time.1 ( hours minutes seconds -- hours minutes )
\ round to nearest 5 minutes by adding 2.5 minutes (150 seconds )
\ this is funky because time&date factor is currently not exposed
\ now requested at: https://savannah.gnu.org/bugs/index.php?61212
150 + 60 / + ( h mm ) dup 5 mod -
60 /mod swap >r + 12 mod r> ;
: rounded-time hms-time rounded-time.1 ;

: tshow.1 ( hours minutes -- )
5 / dup if
dup minutes 2@ capitalize-and-type bl emit
6 > if 1+ then hours 2@ type
else
swap hours 2@ capitalize-and-type bl emit
minutes 2@ type
then cr ;

: tshow ( -- ) rounded-time tshow.1 ;

tshow bye
\ ----------------------------------------------------------------

Oops, I forgot an adjustment at close to 12 o'clock. Fixed version:

----------------------------------------------------------------
#! /usr/bin/gforth
: str-array ( n -- ) create 2 cells * allot
does> ( n -- a ) swap 2 cells * + ;

12 str-array hours
12 str-array minutes

variable a \ "address register"
: 2!a+ ( n n -- ) a @ 2! 2 cells a +! ;
: aa 2!a+ ; \ easier to type

0 hours a !
s" twelve" aa s" one" aa s" two" aa s" three" aa
s" four" aa s" five" aa s" six" aa s" seven" aa
s" eight" aa s" nine" aa s" ten" aa s" eleven" aa

0 minutes a !
s" o'clock" aa s" five after" aa
s" ten after" aa s" quarter past" aa
s" twenty after" aa s" twenty-five after" aa
s" half past" aa s" twenty-five til" aa
s" twenty til" aa s" quarter til" aa
s" ten til" aa s" five til" aa

: capitalize-letter ( c -- C ) \ precondition: c is a letter
$20 invert and ;

: capitalize-and-type ( a u -- ) \ precondition: u > 0
\ take string like "foo" and type it out as "Foo"
swap dup c@ capitalize-letter emit 1+ swap 1- type ;

: hms-time.1 ( seconds minutes hours day month year -- hours minutes seconds )
drop drop drop -rot swap ;
: hms-time ( -- hours minutes seconds ) time&date hms-time.1 ;

: rounded-time.1 ( hours minutes seconds -- hours minutes )
\ round to nearest 5 minutes by adding 2.5 minutes (150 seconds )
\ this is funky because time&date factor is currently not exposed
\ now requested at: https://savannah.gnu.org/bugs/index.php?61212
150 + 60 / + ( h mm ) dup 5 mod -
60 /mod swap >r + 12 mod r> ;
: rounded-time hms-time rounded-time.1 ;

: tshow.1 ( hours minutes -- )
5 / dup if
dup minutes 2@ capitalize-and-type bl emit
6 > if 1+ then 12 mod hours 2@ type
else
swap 12 mod hours 2@ capitalize-and-type bl emit
minutes 2@ type
then cr ;

: tshow ( -- ) rounded-time tshow.1 ;

tshow bye

On 24/09/2021 08:15, Paul Rubin wrote:
> Oops, I forgot an adjustment at close to 12 o'clock. Fixed version:

'Look Ma, no locals'

The program seems to depend on multiple interpretive S" strings that
persist. Usually the strings would be compiled.

dxforth <dxforth@gmail.com> writes:
> The program seems to depend on multiple interpretive S" strings that
> persist. Usually the strings would be compiled.

Oh hmm, I didn't realize they didn't automatically persist. I had
already resisted doing something like:

s" One" s" Two" .... s" Twelve"
CREATE HOURS 2, 2, 2, 2, ...

Ok, here is new version, with a little bit of unrelated additional
refactoring:

----------------------------------------------------------------

#! /usr/bin/gforth
: str-array ( n -- ) create 2 cells * allot
does> ( n -- a ) swap 2 cells * + ;

12 str-array hours
12 str-array minutes

variable a \ "address register"
: 2!a+ ( n n -- ) a @ 2! 2 cells a +! ;
: aa 2!a+ ; \ easier to type

: make-hours.1 ( -- )
0 hours a !
s" twelve" aa s" one" aa s" two" aa s" three" aa
s" four" aa s" five" aa s" six" aa s" seven" aa
s" eight" aa s" nine" aa s" ten" aa s" eleven" aa ;

make-hours.1

: make-minutes.1 ( -- )
0 minutes a !
s" o'clock" aa s" five after" aa
s" ten after" aa s" quarter past" aa
s" twenty after" aa s" twenty-five after" aa
s" half past" aa s" twenty-five til" aa
s" twenty til" aa s" quarter til" aa
s" ten til" aa s" five til" aa ;

make-minutes.1

: capitalize-letter ( c -- C ) \ precondition: c is a letter
$20 invert and ;

: capitalize-and-type ( a u -- ) \ precondition: u > 0
\ take string like "foo" and type it out as "Foo"
swap dup c@ capitalize-letter emit 1+ swap 1- type ;

: seconds.1 ( seconds minutes hours day month year -- seconds )
drop drop drop 60 * swap + 60 * + 86400 mod ;

: rounded-time.1 ( seconds minutes hours day month year -- seconds )
\ round to nearest 5 minutes
seconds.1 150 + dup 300 mod - ;

: s>hms ( seconds -- hours minutes seconds )
60 /mod 60 /mod 12 mod ( s m h ) -rot swap ;

: rounded-time ( -- seconds )
time&date ( seconds minutes hours day month year )
rounded-time.1 ( seconds ) ;
: rounded-hm ( -- hours minutes ) rounded-time s>hms drop ;

: tshow.1 ( hours minutes -- )
5 / dup if
dup minutes 2@ capitalize-and-type space
6 > if 1+ then 12 mod hours 2@ type
else
swap 12 mod hours 2@ capitalize-and-type space
minutes 2@ type
then cr ;

: tshow ( -- ) rounded-hm tshow.1 ;

tshow bye

On 24/09/2021 13:24, Paul Rubin wrote:
>
> Ok, here is new version, with a little bit of unrelated additional
> refactoring:
>
> ----------------------------------------------------------------
>
> #! /usr/bin/gforth
> : str-array ( n -- ) create 2 cells * allot
> does> ( n -- a ) swap 2 cells * + ;
>
> 12 str-array hours
> 12 str-array minutes
>
> variable a \ "address register"
> : 2!a+ ( n n -- ) a @ 2! 2 cells a +! ;
> : aa 2!a+ ; \ easier to type
>
> : make-hours.1 ( -- )
> 0 hours a !
> s" twelve" aa s" one" aa s" two" aa s" three" aa
> s" four" aa s" five" aa s" six" aa s" seven" aa
> s" eight" aa s" nine" aa s" ten" aa s" eleven" aa ;
>
> make-hours.1

That's an approach I hadn't considered. Somewhat more traditionally...

: str-array ( n -- ) create cells allot
does> ( n -- a ) swap cells + ;

12 str-array hours
12 str-array minutes

: @minutes ( a -- adr len ) minutes @ count ;
: @hours ( a -- adr len ) hours @ count ;

: ," ( a "ccc<quote>" -- a' )
[char] " parse 2>r here r@ 1+ chars allot
( a here ) 2dup swap ! 2r> rot place ( a) cell+ ;

0 hours ( a)
," twelve" ," one" ," two" ," three"
," four" ," five" ," six" ," seven"
," eight" ," nine" ," ten" ," eleven"
drop

0 minutes ( a)
," o'clock" ," five after"
," ten after" ," quarter past"
," twenty after" ," twenty-five after"
," half past" ," twenty-five til"
," twenty til" ," quarter til"
," ten til" ," five til"
drop

....

: tshow.1 ( hours minutes -- )
5 / dup if
dup @minutes capitalize-and-type bl emit
6 > if 1+ then 12 mod @hours type
else
swap 12 mod @hours capitalize-and-type bl emit
@minutes type
then cr ;

Paul Rubin <no.email@nospam.invalid> writes:
>dxforth <dxforth@gmail.com> writes:
>> The program seems to depend on multiple interpretive S" strings that
>> persist. Usually the strings would be compiled.
>
>Oh hmm, I didn't realize they didn't automatically persist.

In Gforth they persist until the end of the session, but your new
version will also work when saved in an image.

You could upload it to theforth.net.

- 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 2021: https://euro.theforth.net/2021

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> In Gforth they persist until the end of the session, but your new
> version will also work when saved in an image.

Interesting. It looked from the docs that putting the s" ..." into a
colon definition would compile the string into the dictionary, but I
wasn't sure of that, so have been intending to study dxforth's version
too. Compiling into the dictionary would also generate a jump over the
string(?), which seems slightly clumsy.

The program also uses time&date which is gforth-specific, so it might
have been ok to leave the strings alone. I don't know whether there are
any other gforth-isms in there.

> You could upload it to theforth.net.

Hmm, I hadn't looked at that site much before. I managed to make an
account after a few tries at solving the rather annoying captcha. The
upload procedure looks a bit complicated so I'll wait til tomorrow or so
before trying to figure it out, as it is getting late here now.

It might make an interesting task for Rosetta Code as well.

On 24/09/2021 17:01, Paul Rubin wrote:
> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> In Gforth they persist until the end of the session, but your new
>> version will also work when saved in an image.
>
> Interesting. It looked from the docs that putting the s" ..." into a
> colon definition would compile the string into the dictionary, but I
> wasn't sure of that, so have been intending to study dxforth's version
> too. Compiling into the dictionary would also generate a jump over the
> string(?), which seems slightly clumsy.

s" inside a colon definition only requires the string be compiled - where
that is in relation to executable code is implementation-dependent.

The code I posted still contained a lot of redundancy.

\ parse & compile as counted string
: ," ( "ccc<quote>" )
[char] " parse here over 1+ chars allot place ;

\ define array action
: does does> swap 0 ?do count + loop count ;

create @hours does ( n -- adr len )
," twelve" ," one" ," two" ," three"
," four" ," five" ," six" ," seven"
," eight" ," nine" ," ten" ," eleven"

create @minutes does ( n -- adr len )
," o'clock" ," five after"
," ten after" ," quarter past"
," twenty after" ," twenty-five after"
," half past" ," twenty-five til"
," twenty til" ," quarter til"
," ten til" ," five til"

Paul Rubin <no.email@nospam.invalid> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> In Gforth they persist until the end of the session, but your new
>> version will also work when saved in an image.
>
>Interesting. It looked from the docs that putting the s" ..." into a
>colon definition would compile the string into the dictionary

It does. By contrast, interpretive S" in Gforth ALLOCATEs the string,
and Gforth does not preserve ALLOCATEd data in images.

>Compiling into the dictionary would also generate a jump over the
>string(?),

Not in recent snapshots:

: foo s" flip" s" flop" ;
simple-see foo \ output:
$7F7F70532630 lit
$7F7F70532638 $7F7F702ABCB8
$7F7F70532640 lit
$7F7F70532648 #4
$7F7F70532650 lit
$7F7F70532658 $7F7F702ABCC0
$7F7F70532660 lit
$7F7F70532668 #4
$7F7F70532670 ;s ok

>The program also uses time&date which is gforth-specific

TIME&DATE has been standardized since 1994:

https://forth-standard.org/standard/facility/TIMEandDATE

- 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 2021: https://euro.theforth.net/2021

On 24/09/2021 17:41, Anton Ertl wrote:
> Paul Rubin <no.email@nospam.invalid> writes:
>>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>> In Gforth they persist until the end of the session, but your new
>>> version will also work when saved in an image.
>>
>>Interesting. It looked from the docs that putting the s" ..." into a
>>colon definition would compile the string into the dictionary
>
> It does. By contrast, interpretive S" in Gforth ALLOCATEs the string,
> and Gforth does not preserve ALLOCATEd data in images.
>
>>Compiling into the dictionary would also generate a jump over the
>>string(?),
>
> Not in recent snapshots:
>
> : foo s" flip" s" flop" ;
> simple-see foo \ output:
> $7F7F70532630 lit
> $7F7F70532638 $7F7F702ABCB8
> $7F7F70532640 lit
> $7F7F70532648 #4
> $7F7F70532650 lit
> $7F7F70532658 $7F7F702ABCC0
> $7F7F70532660 lit
> $7F7F70532668 #4
> $7F7F70532670 ;s ok

Even less need for S, ," to explicitly ALIGN

On 2021-09-24 3:01 AM, Paul Rubin wrote:
> Compiling into the dictionary would also generate a jump over the
> string(?), which seems slightly clumsy.
>

GForth's allocated string solution is rather posh. ;-)

Why when I was a boy, we put our strings in the dictionary
like real men and we jumped over them. :-)

In case you are curious here was one way to do it in ITC systems.
( Camel99 Forth )

: S, ( c-addr u -- ) HERE OVER 1+ ALLOT PLACE ALIGN ;

: (S") ( -- c-addr u) R> COUNT 2DUP + ALIGNED >R ;

: S" ( -- c-addr u) [CHAR] " PARSE COMPILE (S") S, ;

The clever bit IMHO is pulling the IP of the string from the
return stack to perform COUNT, computing the jump over the string
and then pushing the new IP back onto the return stack.

Jump accomplished.

Brian Fox <brian.fox@rogers.com> writes:
>GForth's allocated string solution is rather posh. ;-)
>
>Why when I was a boy, we put our strings in the dictionary
>like real men and we jumped over them. :-)

Gforth's compiled strings are in the dictionary, and have always been.

In the beginning we used return-address manipulation like your (S").
When I did experiments with native-code generation (~2004), I
eliminated that (it would not work in gforth-native) and replaced it
with an explicit branch around the string. Recently we put the
strings in a different section of the dictionary, so we no longer need
to branch around the string in any way.

- 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 2021: https://euro.theforth.net/2021

On Thursday, September 23, 2021 at 5:07:58 PM UTC-5, Paul Rubin wrote:
> AFAICT, Peter Honeyman invented this concept decades ago: a command that
> tells the current time in English rounded to the nearest five minutes,

Long ago I made a Forth version of the classic Eliza program. Then I
modified it to make a human command/response interface one that just
looked for key words nothing sophisticated. It worked better than I
had imagined. Since only key words mattered a request could be worded
different ways and still result in the wanted action:
get my file foo
get a file named foo
get the foo file
and it would respond something like:
You want the file name foo?
at which point the user would enter "yes" or "no".

If the program failed to understand what the user requested, it assumed
there was something wrong with the user and would go into the
Eliza psychoanalysis mode.
--
me

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> Not in recent snapshots:
> : foo s" flip" s" flop" ;

Hmm, what happens with longer strings? In 0.7.3 (not so recent),
I see a branch.

Paul Rubin <no.email@nospam.invalid> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> Not in recent snapshots:
>> : foo s" flip" s" flop" ;
>
>Hmm, what happens with longer strings? In 0.7.3 (not so recent),
>I see a branch.

With recent, I mean, a few months ago or more recent. Anyway:

: foo
s" What happens with longer strings?"
s" The same happens with longer strings."
s" Compare the addresses of the strings with the addresses of the threaded code"
;

simple-see foo
$7F0C2D9F0630 lit
$7F0C2D9F0638 $7F0C2D769CB8
$7F0C2D9F0640 lit
$7F0C2D9F0648 #33
$7F0C2D9F0650 lit
$7F0C2D9F0658 $7F0C2D769CE0
$7F0C2D9F0660 lit
$7F0C2D9F0668 #37
$7F0C2D9F0670 lit
$7F0C2D9F0678 $7F0C2D769D08
$7F0C2D9F0680 lit
$7F0C2D9F0688 #76
$7F0C2D9F0690 ;s ok

The strings are in a different section than the threaded code.

- 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 2021: https://euro.theforth.net/2021

On 2021-09-24 11:15 AM, Anton Ertl wrote:
>
> In the beginning we used return-address manipulation like your (S").
> When I did experiments with native-code generation (~2004), I
> eliminated that (it would not work in gforth-native) and replaced it
> with an explicit branch around the string. Recently we put the
> strings in a different section of the dictionary, so we no longer need
> to branch around the string in any way.
>
> - anton
>

Thank you. That's good to know. I am playing with a native code
generator now for my own amusement.
I was wondering how best to handle S".

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> The strings are in a different section than the threaded code.

Does that mean you now have a post-compilation assembly or linking phase
to fix up the addresses of the different sections? Did you have that
before? Do you reserve a chunk of memory for the strings and hope it's
big enough, or what?

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> TIME&DATE has been standardized since 1994:
> https://forth-standard.org/standard/facility/TIMEandDATE

Hmm, the online gforth manual says it's a gforth word. Maybe you want
to update that.

On 24/09/2021 23:43, Brian Fox wrote:
> On 2021-09-24 3:01 AM, Paul Rubin wrote:
>> Compiling into the dictionary would also generate a jump over the
>> string(?), which seems slightly clumsy.
>>
>
> GForth's allocated string solution is rather posh. ;-)
>
> Why when I was a boy, we put our strings in the dictionary
> like real men and we jumped over them. :-)
>
> In case you are curious here was one way to do it in ITC systems.
> ( Camel99 Forth )
>
> : S, ( c-addr u -- ) HERE OVER 1+ ALLOT PLACE ALIGN ;
>
> : (S") ( -- c-addr u) R> COUNT 2DUP + ALIGNED >R ;
>
> : S" ( -- c-addr u) [CHAR] " PARSE COMPILE (S") S, ;
>
> The clever bit IMHO is pulling the IP of the string from the
> return stack to perform COUNT, computing the jump over the string
> and then pushing the new IP back onto the return stack.
>
> Jump accomplished.
>

Even VFX appears to do that. I was expecting something more posh :)
OTOH one doesn't normally place significant/frequently referenced
data in a colon definition.

The bigger annoyance is code alignment which some implementations
put into ," etc instead of handling it separately. ," is a really
handy function for compiling string constant data; but with
implementations that variously align, null-terminate and others
that don't, standardization becomes impossible.

Paul Rubin <no.email@nospam.invalid> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> The strings are in a different section than the threaded code.
>
>Does that mean you now have a post-compilation assembly or linking phase
>to fix up the addresses of the different sections?

No. The string is put into the next section, and its address is then
compiled with LITERAL:

: SLiteral ( Compilation c-addr1 u ; run-time -- c-addr2 u ) \ string
\G Compilation: compile the string specified by @i{c-addr1},
\G @i{u} into the current definition. Run-time: return
\G @i{c-addr2 u} describing the address and length of the
\G string.
tuck 2>r next-section here 2r> chars mem, align >r previous-section
r> postpone literal postpone literal ; immediate restrict

>Did you have that
>before?

Sections have been there for a few years, but we have only made use of
them in SLITERAL a few months ago.

>Do you reserve a chunk of memory for the strings and hope it's
>big enough, or what?

Just like the dictionary, section sizes are fixed at startup, so I
guess the answer to your question is yes.

- 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 2021: https://euro.theforth.net/2021

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> You could upload it to theforth.net.

I tried to do this but the upload failed with a gateway timeout. Oh
well. I appreciate the sentiment behind the site, but I miss Forth Freaks.

On 2021-09-25, Paul Rubin <no.email@nospam.invalid> wrote:
> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> You could upload it to theforth.net.
>
> I tried to do this but the upload failed with a gateway timeout. Oh
> well. I appreciate the sentiment behind the site, but I miss Forth Freaks.

Learned Forth with Fig Forth on ZX Spectrum.

--
7-77-777
Evil Sinner!

Paul Rubin <no.email@nospam.invalid> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> TIME&DATE has been standardized since 1994:
>> https://forth-standard.org/standard/facility/TIMEandDATE
>
>Hmm, the online gforth manual says it's a gforth word. Maybe you want
>to update that.

Thanks for the report. Interestingly, this had been fixed since 0.7
(what the online manual documents), just become broken again, and
checking your report resulted in me fixing that:-).

- 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 2021: https://euro.theforth.net/2021

dxforth <dxforth@gmail.com> writes:
>On 24/09/2021 23:43, Brian Fox wrote:
>> : (S") ( -- c-addr u) R> COUNT 2DUP + ALIGNED >R ;
....
>Even VFX appears to do that.

Yes, surprisingly much return-address manipulation words with native
code, too. It did not work with gforth-native, because the string
would land in data space, and the code in code space.

However, this technique incurs a branch misprediction (~20 cycles) on
return from (S"), so I don't recommend it for native-code 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 2021: https://euro.theforth.net/2021

Brian Fox <brian.fox@rogers.com> writes:
> : (S") ( -- c-addr u) R> COUNT 2DUP + ALIGNED >R ;

This is both awesome and terrifying.