I am the egg man. They are the egg men. I am the walrus. Goo goo g'joob!!

[The Beez]

Hi 4tH-ers!

Although I actually DETEST the language, I keep my eyes on Python. Simply because it contains lots of controversial - but original - design decisions. 

If you know that I am Dutch and Guido van Rossum is Dutch, you might get the idea where all these weird concepts come from. ;-)

Anyway, Guido threw in the towel over the idea of a "walrus operator". I get the idea - it's a way to make Python more "C like". Which IMHO is as a bad idea as to make Forth more "C like". It feels like something ugly that is bolted on just to cut some corners.

I know there is a bit of controversy on the new words I added, especially UNLESS and EXPECT - which have NO counterpart in the Forth world. However, these words are mainly there to unclutter the code. They carry NO new functionality whatsoever.

And in essence - neither does CASE..ENDCASE, since it directly translates into a bunch of IF..ELSE..THEN statements. If you don't like 'em, simply use the old constructs. It will compile to the very same words.

But I added a line to uBasic today:

  

putback ctoken> [char] : = ctoken> [char] = = and if string> swap ! ;then

So what does this do? It creates a NEW assignment operator. One that is SLOWER (5-10%) than "=", but more intelligent.

So what does it do? Well, you can assign ANYTHING with it. Strings, quotes string, values, expressions, you name it. But it DOES have that 5-10% performance hit associated with it.

The ordinary "=" still works, but NOT with quoted strings. The good thing is, it hasn''t slowed a bit. Because it's still as dumb as always, it's fast.

So the whole thing boils down to three choices:

- Either you maintain the status quo - and give your users no choice. They might find their code a bit ugly and harder to understand;

- You make every assignment a bit slower - and give your users no choice;

- You give your users the choice between speed and readability and put the burden of consistency onto them.

I wished there were easy choices all the time. But it doesn't always work out that way. So, since I don't believe the paradigm "there should always be one single obvious way to do things", I chose the latter.

Your programs don't need a single change. They will continue to work. Their speed will not be affected in the least (I tested). But if you want a bit more intuitive way to declare your strings in uBasic, you can. Choose:

a = 15

a = DUP(" Hello world")

a = 16+(34/a)

b = JOIN(a, "!!")

Or:

a := 15

a := " Hello world"

a := 16+(34/a)

b := JOIN(a, "!!")

Or (if you insist):

a = 15

a := " Hello world"

b = JOIN(a, "!!")

Now you choose..

Hans Bezemer

[The Beez]

Hi 4tH-ers!

We all agree a "walrus operator' in 4tH would be completely out of place. Simply DUP the result before you assign it - big deal. However, could it be done in uBasic?

This didn't take me a minute to figure out. The confusing part in Python is that is an OPERATOR, which turns an assignment into a function. In Python, you can't get away with this:

y := 5

However, you can get away with this:

(y:=5)

Because that obvious flags it to be a function. So why not make it a function - and avoid all the confusion? I present you: SET(). Let's take a look at an example:

PRINT SET(a, 5+7), a

It will print "12" two times. The first time as a result of the assignment of 5+7 to "a", the second time as the contents of "a". If you "forget" a keyword, it simply wont work - like any function. There is absolutely *NO* confusion here. 

And that made me wonder. What if Guido van Rossum had proposed my solution - simply add another function. Would that have cause all that upheaval?

Note this solution is functionally equivalent. I've added it to an example where a file is opened and the file pointer evaluated in the same statement:

if set(a, open ("ustates.csv", "r")) < 0 then

  print "Cannot open \qustates.csv\q"  ' open file a for reading

  end                                  ' abort on file opening errors

endif

I'd be interesting to hear your thoughts on that.. ;-)

Hans Bezemer

[Ron K. Jeffries]

I am curious why you say you "detest" Python. I hope you start a new email with new subject line😁

I am indifferent, just very puzzled by your position.

As always, please keep on with your impressive body of work. Anyone who supports a BASIC can't be all bad. Just kidding.

Ron K Jeffries

--
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 on the web visit https://groups.google.com/d/msgid/4th-compiler/8b24d335-1a9a-466f-952f-dc569a3b66dfn%40googlegroups.com.

[The Beez]

Hi Ron!

My dislike of Python is roughly threefold:

- The architecture;

- The "duck-typing";

- The syntax.

(1) The architecture

If you install Python, it's splattered all around the disk. Adding new modules requires some murky import command. Making a byte code image requires a PhD. Hence, distributing a plain Python application is a pain in the neck.

Although Python has a VM as well (like 4tH) IT IS INCREDIBLY SLOW.

There is a reason 4tH is a single file application. I didn't want a complex installation. You want to run (basic) 4tH, you got ONE executable. You want to run a 4tH application? 

(1) Distribute the executable with a bytecode image;

(2) Distribute the executable with a preprocessed source;

(3) Make a true, native executable.

The latter one is even doable IMHO if you don't know C at all.

(2) Duck typing

Duck typing requires a language to make decisions better left to the programmer. Duck typing is based on the assumption it makes life easier for the programmer - even beginners. I tend to disagree. In certain circumstances, the language is forced to make decisions which are incomprehensible to the ordinary user - and aren't even fixable without deep technical knowledge. As a programmer who've been in several fights with SQL "optimizers" I know what I'm talking about.

I personally think it's better to have a "dumb" language with commands that simply do what is written on the can than one that is overly "clever". Predictability is a bliss for beginners. I consider 4tH a perfect language for those beginning Forth. Not necessarily a good language for absolute beginners. uBasic would be a much better candidate for that. Especially since it's now almost full featured.

(3)

Don't start me on this one. 

- Yeah, it might seem neat to force a programmer to lay out his code properly. But it may also introduce hard to find bugs.

- If you need a trailing comma to distinguish a tuple from e.g. a string, you've not thought out your syntax properly;

- Printing something without a LF is already murky in Bash, but in Python it's just syntax horror pur sang;

- There is no proper way to make methods private. All it has is more and more and uglier and uglier kludges;

- Underscores and more underscores show the hideous way Python works under the hood. It's completely unreadable in a language that should be completely readable;

- The 'walrus' operator just shows how the creator himself doesn't understand his own language - and is willing to violate his most basic architecture and principles.

That's why I don't like Python.

Yes, and I still do like Basic. It was my first language and my primary language during the eighties. I did have a little love affair with Turbo Pascal - some of its features found their way into 4tH, but in the end it was just too limited and awkward for my taste. Turbo C v2 was a much longer lasting love-affair. Pascal on steroids! 4tH started there, actually. I did add some syntax changes to make it look a bit more like Pascal (using the preprocessor - I picked up that idea from Byte Magazine), but I abandoned that "EasyC" in the early 2000's. You should find that in the changelog of 4tH.

Hans Bezemer

[The Beez]

To continue this rant, I think BASIC is an underestimated language. I think it's creators made an architecture that is highly suited for the purpose it was created for - much more than Python ever was. Because of its dead simple concepts, it's easy to communicate how you can make it work for you. We're all professionals here and I don't have to tell anyone how to make a "Hello world" program in languages like Pascal, C or C++.

Basic, however is even more simple than Forth. In Forth, you have to explain the ." word before a valid program can be written. Compare that to Basic:

PRINT "Hello world"

No program declarations, procedure declarations or even parenthesis. Add a variable to that:

INPUT "Your age, please: ", a

PRINT "Your age is ";a;" years"

It's so self evident. Ok, line number are a relic of FORTRAN, but I think I've proven that you can easily turn a Classic Basic interpreter into a modern dialect:

DO

  INPUT "Your age, please: ", a

  PRINT "Your age is ";a;" years"

LOOP

And even expand the "old" IF THEN statement into a structured one without adding loads of code:

DO

  INPUT "Your age, please: ", a

  PRINT "Your age is ";a;" years"

  IF a>21 THEN

    PRINT "Give the man a beer!"

  ELSE

    PRINT "Give the kid a coke!"

  ENDIF

LOOP

It's all in the architecture. You don't have to switch "modes" in uBasic. And it's a breeze to translate this structured code to Pascal or C. Note that IMHO the most amazing part is that you don't need "code blocks" - as introduced by Algol. A block is delimited by its proper closing keyword.

The only vulnerability is exiting loops using GOTO or RETURN. But that could partially be fixed by REMOVING that GOTO keyword (as my Tiny Basic Raspi competitor actually did). Still, the worst thing that happens is that the return stack of uBasic overflows (which probably was an issue in many early Basic interpreters as well - except for ZX Spectrum BASIC, which stored the loop info along with a dedicated LOOP variable). But who cared? It was BASIC. Most important thing was the thing actually ran. There was lots of issues with BASIC interpreters.

In short, IMHO the most important feature of BASIC is, it's gets you up and running - and gives you a growth path all up to C, Pascal, Ada, etc. And yes, I don't say Forth, because Forth is quite a different beast. It's no accident that most Forth programmers have a background in assembly too. You simply need to have this "Sudoku" mind to appreciate Forth, IMHO. When it comes to adoption, that is also Forth's main weakness. The only thing I tried to do is make it doable. I mean, the hoops I had to jump through to get a certain level of proficiency.. Hundreds of dollars spent on books, which feature some kind of Forth dialect I wasn't actually using. Major changes between what simply should have been a growth path. The inability to do things like "port a simple program" or "make an executable (turnkey)". It was that I was trying to fix by making a simple compiler, compiling simple sources in a simple, familiar way. And providing the right documentation and libraries to enable a user to focus on the task at hand - not implement the zillionth string library, because "every application is different so roll your own one - good luck!".

Hans Bezemer

[Timur Aksenov]

My point is that C ++ is definitely more powerful than plain C.  However, some things work better when using Forth.  I have a task to make a simple vector graphics rasterizer, I looked at many solutions such as Cairo, Blend2D, Skia and they are all pretty heavy.  I began to study how rasterization of 2D vector graphics works in order to do something small and simple and found that the first attempts were made in the postscript language, which, with a little transformation, was reborn into pdf.  Well, they just use the analogue of the Forth language, there is a built-in language, thanks to this, complex graphic elements are built from simple ones.  Thus, small built-in and lightweight languages ​​work very well within complex systems.  Therefore, choosing 4th for me is the best solution, it is lightweight, architecture independent, integrates well, works quickly and does not have undefined behavior, which is often found in more complex languages.

Timur

Пн, 7 июня 2021 г. в 10:42, The Beez <the.bee...@gmail.com>:

To view this discussion on the web visit https://groups.google.com/d/msgid/4th-compiler/5403f3af-0d3b-4d67-ae6e-e065b911fdb0n%40googlegroups.com.