YUKO YUnit KOnverter calculator

[David Meyer]

YUKO is a collection of words for converting between SI and US Customary
units that I first wrote many years ago as my first excercise in
learning Forth.

YUKO is designed to be used in Forth calculator mode, so adapting it to
4tH was a long-standing mystery to me. After completing a major rewrite
and improvement, I decided to use it as an opportunity to reacquaint
myself with 4tH.

Although the 4tH compiler itself has only a very limited interactive
calculator function, browsing 4tH's sample programs and library revealed
that the hard part of building a more powerful interactive environment
has already been done. Programs like dc.4th, fdc.4th, and opgcalc.4th
both create interactive calculator environments and show how to access
user-programmed words with the interprt and evaluate libraries.

So I am happy to announce the YUKO YUnit Konverter library and YDC YUKO
desktop calculator for 4tH:

https://papa.sdf.org/yuko/yuko.4th
https://papa.sdf.org/yuko/ydc.4th

Download both source files to the same directory, then run with:

$ 4th cx ydc.4th

idc.4th is an integer-based RPN calculator that I created by removing
floating-point and FORTRAN/BASIC notation from fdc.4th. I used idc.4th
as the basis for ydc.4th.

https://papa.sdf.org/yuko/idc.4th

There's a general introduction to YUKO here:

https://papa.sdf.org/yuko/


Happy hacking!

--
David Meyer
Takarazuka, Japan
pa...@sdf.org

[Phillip Kelly]

Thanks David

Yours Sincerely
Mr. Phillip Kelly
 

--
You received this message because you are subscribed to the Google Groups "4tH-compiler" group.
To unsubscribe from this group and stop receiving emails from it, send an email to 4th-compiler...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/4th-compiler/875x1ynt9p.fsf%40localhost.

[The Beez]

David,

I have to keep it short tonight, but I promise I'll give you a more elaborate answer later. First, I have to congratulate you with finishing this program. I had a quick look and it looks absolutely great.

I'll hope you'll consider my offer to make it part of the package!

See you later,

Hans Bezemer

[David Meyer]

The Beez <the.bee...@gmail.com> writes:

> First, I have to congratulate you with finishing this program. I had a quick
> look and it looks absolutely great.

Thank you! I take that as very high praise.

> I'll hope you'll consider my offer to make it part of the package!

It would be a great honor for you to include my programs in the 4tH
package. :)

[The Beez]

Hi David!

On Thursday, July 30, 2026 at 6:02:52 AM UTC+2  wrote:

The Beez  writes:

> First, I have to congratulate you with finishing this program. I had a quick
> look and it looks absolutely great.

Thank you! I take that as very high praise.

Well, you earned it. I think it's a very nice port.

> I'll hope you'll consider my offer to make it part of the package!

It would be a great honor for you to include my programs in the 4tH
package. :)

It is my honor. Really! You used the possibilities of the language wonderfully.

 

--
David Meyer
Takarazuka, Japan

Well, these were the things that caught my attention:

1. I don't see splitting off the internals of a program very often -- but actually, it works great in a well configured 4tH system! :-)
2. I've seen you dropped the unit-max table -- and I think that's the right choice for a 64-bit system (or even a 32-bit system). You don't need that complication.
3. I also saw you modified the unit-cstr table -- which is logical as well, since 4tH allows you to build string tables with ease. I guess I could get these things to work in 4tH, it'll be a nice exercise, but this solution is so much clearer and cleaner IMHO!
4. The need for CONVERT-FROM isn't exactly there for 4tH -- since you have to load the word CONVERT in 4tH. So, CONVERT would have been fine -- I checked! ;-) But I know where this is coming from, the Gforth version! But don't pay any attention to me -- just babbling;
5. I suspected the need for evaluate.4th was not there -- and interpret.4th would have sufficed. I tested -- and I was not wrong. Sure the thing works fine -- but you carry some dead code along. Unless at one time or another you want this thing to load code from a block and execute it -- because, that's what evaluate.4th allows you to do. It works, because evaluate.4th also loads interprt.4th.

In short -- I really like this thing!

Now, when I take your code in, it has to be updated if any compiler changes occur that prevent it from working or compiling properly. If that is the case, you wont hear from me -- because the alternative is a program that no longer compiles or works. Nowadays -- those changes are VERY rare. 

But it has happened before that I created a library, in this case a I18n library, that fitted perfectly on a program featuring multi language support. In that case I'll contact you before submitting those changes. In short, I respect your work -- and how you layout or comment your code.

Again, thank you very much for your contribution! It's a nice addition!

Hans Bezemer

[The Beez]

BTW, it reminds me of this 4tH related thingy: Old Russian measure of length

Hans Bezemer

[The Beez]

Now I know where you got "evaluate". It was FDC.4TH. But that one uses it to translate FTRAN expressions. Gotta dive a bit deeper here.

On Thursday, July 30, 2026 at 6:02:52 AM UTC+2 pa...@freeshell.org wrote:

[The Beez]

Okay, I figured it out. First, fdc.4th was not written by me, but by the author of the opgftran.4th library -- I suppose as an example. The calculator supports a "LET" command, which gives you access to the FTRAN library, which in turn allows you to enter infix expressions. Now, what happens is that it parses the TIB up to the semicolon at the end of the infix expression -- and sends that addr/count string to FTRAN. Than one rewrites the expression to postfix and stores it in its own buffer -- and returns that addr/count back to the _let routine.

Now -- and here is the thing: INTERPRET always reads from the TIB. So you have two options. Either copy from the FTRAN buffer to the TIB (very dirty - and dangerous) - or use EVALUATE, since that one takes an addr/count (the FTRAN buffer) as parameter. That is the sole reason it is in fdc.4th. Since you don't need EVALUATE (it's nowhere in your program) interprt.4th will do just fine.

Hans Bezemer

[David Meyer]

The Beez <the.bee...@gmail.com> writes:

> 1 I don't see splitting off the internals of a program very often --

> but actually, it works great in a well configured 4tH system! :-)

For YUKO, dividing the conversion words and the calculator environment
into separate files seemed like the obvious choice since the conversion
library part is all that was necessary for Forth environments with a
calculator mode REPL like Gforth, and the calculator part providing the
user interface was just a modified version of fdc.4th.

> 2 I've seen you dropped the unit-max table -- and I think that's the

> right choice for a 64-bit system (or even a 32-bit system). You don't
> need that complication.

I did the initial programming for this version of YUKO for fig-Forth on
VAX/VMS with 16-bit integer cells. Even using doubles for everything put
tight limits on some of the unit values, so I thought it was better to
put in maximum value checks than to give incorrect results when values
overflow. When I ported YUKO to Gforth and 4tH, 64-bit integers made me
feel like the maximum value checks weren't necessary.

> 3 I also saw you modified the unit-cstr table -- which is logical as

> well, since 4tH allows you to build string tables with ease. I guess I
> could get these things to work in 4tH, it'll be a nice exercise, but
> this solution is so much clearer and cleaner IMHO!

Working in fig-Forth, I decided it would be easier to identify
convert-to units by interpreting the first four bytes of the input
string as a double instead programming my own string comparison words.
I kept the same approach in the Gforth version. However, it looked like
it would take some effort to implement with 4tH's separate character and
integer segments so I replaced the unit code double table with the more
straight-forward string table.

> 5 I suspected the need for evaluate.4th was not there -- and

> interpret.4th would have sufficed. I tested -- and I was not
> wrong. Sure the thing works fine -- but you carry some dead code
> along. Unless at one time or another you want this thing to load code
> from a block and execute it -- because, that's what evaluate.4th
> allows you to do. It works, because evaluate.4th also loads
> interprt.4th.

I kept the dependency on evaluate.4th from fdc.4th. However, I've tried
replacing the reference to evaluate.4th with interprt.4th directly in
both ydc.4th and idc.4th and they both work fine. I've replaced the
source files on my web site:

https://papa.sdf.org/yuko/ydc.4th
https://papa.sdf.org/yuko/idc.4th


Regarding the underline words (": _+ + ; ...") in ydc.4th, I see that my
initial understanding that an underline word had to be defined for every
word accessible to INTERPRET was incorrect and that underline words are
only needed for 4tH build-in words and not for user-defined words like
the YUKO conversion words. I've also cleaned out the unnecessary
underline words from ydc.4th.

Thanks for your comments.

--
David Meyer
Takarazuka, Japan

pa...@sdf.org

[The Beez]

I uploaded your new version to the repository!

No, the DICTIONARY table is a table just like any other -- there are no special requirements here. BTW, fun fact: TABLE got in because Wil Baden suggested that -- a VERY, VERY long time ago! A century ;-)

Best strategy in 4tH is -- just do it. If it doesn't like it ("Wrong type" or "Name too long") it will probably complain.

BTW, was this your first program in 4tH? And if it was, was there anything special compared to ordinary Forths? I'm curious about your experience..

Hans Bezemer

[David Meyer]

The Beez <the.bee...@gmail.com> writes:

> BTW, fun fact: TABLE got in because Wil Baden suggested that -- a
> VERY, VERY long time ago! A century ;-)

fig-Forth has TABLE, too. It makes sense for defining a table of constants.

> BTW, was this your first program in 4tH? And if it was, was there
> anything special compared to ordinary Forths? I'm curious about your
> experience..

How soon they forget! YUKO is not my first 4tH program. I contributed
ROMANS2.4TH to the package back in 2019.

What's special about 4tH? One thing is the manual. In addition to
documenting the 4tH language, it includes a lot of tutorial material for
topics of interest to intermediate programmers, which is rare. I enjoy
the humor, too.

Another special thing about 4tH is YOU. Your active support and
improvement of 4tH, your adventures in programming and the amazing
things you do with 4tH are inspiring and made me want to know more about
the language.

[The Beez]

This must be the first post which made me ashamed and blushed at the same time ;-)

Cheers!