Basic and ZeroPain

BASIC shouldn’t cause a crash like that.

Who knew how it did that apart from Sophie?

I am not sure if I have understood you, but it is inevitable from the nature of BASIC, which does not have true boolean types. AND is a bitwise operator, so it must have two parameters. Boolean behaviour is simulated by having numerical values for TRUE and FALSE, but that is inadequate in cases like this.

Zero page change is one of those under-the-bonnet changes that needs a matching under-the-bonnet fix such that the same BASIC code works on pre and post ZP change systems.

I agree that BASIC needs to be changed, but it will never work precisely the same. The best I see is that BASIC itself throws an informative error before the OS aborts.

[ANDLOG] sounds like LOGarithm

Yes, that is a problem of overloading existing keywords.

Why not LAND and LOR for logical versions of the existing bitwise AND and OR?

Those would require completely new keywords in a restricted namespace.

or perhaps ANDL and ORL

Those are alternatives I cogitated on, and would be equally fine. They have an advantage of the L standing for ‘logical’ or ‘lazy’. ;-)

I am not sure if I have understood you, but it is inevitable from the nature of BASIC, which does not have true boolean types.

I was referring to the fact that most people use the code without knowing (or really needing to know) where the object data being accessed resides. The system doesn’t complain about the code and it gives the result the author intended, or it used to. Now, without requiring a change in an unknown number of BASIC programs, what if anything can be done to fix it and not break something else?

As an aside:
Hypothetically, on an older system, if something else stored a value in that location and the BASIC code accessed it what happens? Unpredictable?
Cause of intermittent error / bug?

most people use the code without knowing […] where the object data being accessed resides.

They possibly use it in a boolean manner without considering how BASIC actually works. As in Martin’s WHILE example, until the first parameter returns FALSE the second is correctly expected to return a valid value – they do know where the object data resides.

A related problem is getting into the mindset of using any non-zero value to represent TRUE. Often this is a very useful shortcut, but in logical expressions it can cause quaos. ;-)

Cause of intermittent error / bug?

Inevitably. I imagine that many of the cases cropping up now are zero pointers and !0 held a non-zero value and returned ‘true’. In that case it would act like a lazy AND by accident.

Perhaps the policy most likely to keep programs running would be to return TRUE for all zero-page accesses, but I am sure that would store up troubles for the future.

They possibly use it in a boolean manner without considering how BASIC actually works.

Operate a switch to a fluorescent fitting – how many people know how it works?
It still illuminates the room.
Plug a computer into a network switch connected via an L3 router to another switch with a connected server – how many people know the method of communication? It still works.

Cause of intermittent error / bug?

Inevitably. I imagine that many of the cases cropping up now are zero pointers and !0 held a non-zero value and returned ‘true’.

I at least partially understand then.

Fixing ZeroPain to have some level of support for unaligned loads is still on my todo list

Thanks Jeffrey for fixing this in ZeroPain v0.04, which I have managed to download. Now A%=!8 and A%=!9 both work on the Iyonix, enabling applications to work again like pre-ZP, while now being logged by ZP, just as on an RPi.

(along with reporting the BASIC line number)

This would be nice, but not a priority.

If I recall correctly, the ( curiously both massively over and under rated ) Visual Basic uses AndAlso and OrElse for this purpose, which, suitably capitalised of course, would seem appropriate here

And for the benefit of people that have never touched VB in their life:

If Sub1 And Sub2 Then… will execute both Sub1 and Sub2.
If Sub1 AndAlso Sub2 Then… will execute Sub1, but will only execute Sub2 if Sub1 returned True.

I haven’t use OrElse but I assume that it works the same way.

And for the benefit of people that have never touched VB in their life:

And for the purists people who have touched VB, David and Chris are referring to VB.Net which is similar in name, if not in syntax¹ or spirit.

¹ I tried the freebie VB.Net with one of my programs. The migration tool failed on so many basic things it wasn’t funny. I might as well have been porting my application to another language, like C##. Plus if you think the VB runtime is a huge load of baggage, wait ’til you get a load of the .Net framework.

Ah! I haven’t used “classic” VB in more than a decade so I made an assumption that the same syntax applied.

.Net was a big jump but I do think that it was worth it.

.Net was a big jump but I do think that it was worth it.

An enormous jump in memory occupation, not convinced it was worth it.
Whether the bloated code out and about is just bad coding or a consequence or .Net bloat is probably a bigger debate.

Actually, C# is not a bad language. I’m aware it has an enormous run-time, but the executables that use it are not huge.

If it became available on RISC OS, I’d use it.

Whether the bloated code out and about is just bad coding or a consequence or .Net bloat is probably a bigger debate.

At the risk of digressing this thread even further, I’d go with “bad coding, sort of” – the majority of cases I’ve seen of huge .Net apps are when people add 20 external dependencies to their apps for no good reason. Some of the components at work are guilty of that (I think we have a 30-something kilobyte component that returns a single integer). On the other hand I wrote an app that does much more (calculates flood statistics based on readings from river flow sensors), and it’s about half that size.

If it became available on RISC OS, I’d use it.

As would I. At one point I was taking a look at making a very simple “interpreter” that line-by-line converts C# to native C, but it looks like it’ll quickly become fiendishly complicated.

Wasn’t there some activity to port Vala to RISC OS? Since the Vala compiler first translates Vala (which is similar to C#) to ANSI C, this seems like a workable long-term solution.

On the other hand, many people see C# as the whole thing including the .NET runtime, and of course Vala is only the language part, not the runtime part.