Proposal for assigning an address to a structure

[RichardRussell]

One of the few things that irritates me about BBC BASIC is that there is no built-in way of assigning a memory address to a structure, something that you commonly want to do if (for example) you are using structures to implement a linked list. It wasn't too bad in the 32-bit-only days because one could write:

Code: Select all

      !(^struct{}+4) = address%

but with compatibility with 64-bits now being so important you typically end up using a procedure:

Code: Select all

      DEF PROC_setptr(RETURN d{},p%%)
      IF INKEY(-256)=&73 IF @platform% AND &40 ](^d{}+8)=p%% ELSE !(^d{}+4)=!^p%%
      ENDPROC

Whilst this is effective at hiding the ugliness, it's not fast or elegant. Therefore I'm wondering about implementing this extension to the language:

Code: Select all

      PTR(struct{}) = address%%

There are no significant compatibility implications (currently this syntax will result in a 'Missing #' error) and I don't think it would be too difficult to achieve, in BBCSDL at least (it could be considered for BB4W at a future date).

Thoughts?

[Edja]

4 points :

• this irritates you

• you don't think it would be too difficult to implement your proposed solution

• there are no significant compatibility implications

• even though I'm the type of programmer that always struggles with pointers and fiddling with memory locations, I clearly see that the way you would like to proceed is far more elegant

I see no technical or other arguments not to proceed with this and I'm always in favor of improvements, so I think you should go ahead!
Edja

[RichardRussell]

I clearly see that the way you would like to proceed is far more elegant

If it was "the way I would like to proceed" I would just go ahead and implement it without any consultation! There are several reasons why I am asking the question rather than simply doing that:

• It would undoubtedly slow BBC BASIC down (not least because it would make it bigger, resulting in less efficient cache usage).
  
  
• I may well have missed something which means it is a stupid idea (it wouldn't be the first time!).
  
  
• My competence at programming is currently very poor. I would even go so far as to say that based on recent experience there is a high likelihood that a change of this sort would result in me introducing a bug.
  
  
• The change would result in an avoidable incompatibility between BB4W and BBCSDL, something that is highly undesirable and could discourage writing cross-platform programs.

So by forcing me to think about the negatives you may well have persuaded me that it's not a good idea.

[Edja]

I don't think it would be too difficult to achieve, in BBCSDL at least (it could be considered for BB4W at a future date)

This led me to conclude that at a later date the same solution for BB4W would also be implemented. Admittedly, you didn't say that. My wrong interpretation. But this unavoidable incompatibility certainly reshuffles the cards.
I agree with you that introducing an incompatibility between BB4W and BBCSDL combined with a penalty in performance is not the preferred way.
With this in mind I would go for PROC_setptr(RETURN d{},p%%)

So by forcing me to think about the negatives you may well have persuaded me that it's not a good idea.

You're welcome!
Edja

[RichardRussell]

This led me to conclude that at a later date the same solution for BB4W would also be implemented. Admittedly, you didn't say that. My wrong interpretation.

It's not out of the question, but I only update BB4W (if at all) about once a year, and that's only if there is a pressing need. The balance of risk and benefit is clearly very different with such a mature and stable product. I think there's a reasonably high likelihood that when another update to BB4W is 'due' that I will have had to give up all coding.

Admittedly the recent discovery of the bug in the BB4W IDE does mean that there is a reason to consider updating BB4W independently of compatibility considerations, but the reaction I received to that being announced (none at all!) means it's not a high priority.

[Ivan]

Hi Richard,

I'm very sorry to see, that you have so little responce of maintaining BB4W, because although I have wishes for implementing different features, I don't know of any programming system, that is so friendly and fast to use.

I must admid I saw you had updated and I think other users also have and gladly updated to the last version.

Regards,

Ivan

[RichardRussell]

I'm very sorry to see, that you have so little responce of maintaining BB4W

I feel very strongly that maintaining a language does not necessarily mean extending it. I fear it is a sign of the times, that everything these days is expected to be transient; nobody seems to value stability any more.

The younger generation probably can't even imagine software being programmed into Read Only Memory chips, making it effectively impossible to upgrade. I wonder how today's programmers would cope with being told that they must write code with such care, and test it so thoroughly, that once deployed it can never be changed!

So basically there is a gulf between my approach to programming (based on about 47 years experience) and the desires of the typical user today, and it is only going to get deeper. In any case I do not expect to be able to continue writing code for much longer, as my 'cognitive impairment' worsens (I'm feeling it particularly badly today, as it happens; my brain is just a mush).

Fortunately if you want to continue to use BBC BASIC, but prefer a dynamic, constantly changing, leading edge version, you have the option of switching to Matrix Brandy. It's highly comparable with my versions (and much faster) and is gaining new features on an almost weekly basis. If you suggest an extension, and it's not too difficult, it is likely to be implemented within hours (in stark contrast to my ultra-cautious approach).

[Ivan]

I'm sorry to know about your ilness - i'll hope for the best for you!

Rather fewer and stable features than a lot you can't count on!

I had followed videos of "Uncle Bob" about Clean Code. He said that all programming languages can be boiled down to sequence, selection and iteration. In priciples nothing had chanced the 60 years. He had been a professional programmer for 50 years.

I told my stepsons the other day that I had a computer in the eighties that took about 1-2 seconds to boot. Had programs in chips and never used antivirus and had no whirring fans. He was stunned when I told him that almost all smartphones runs on a risc processor that was created then. A processor code that was born on a BBC micro!

[RichardRussell]

When the proposal to extend the functionality of the PTR() pseudo-variable was first made I was persuaded - admittedly somewhat reluctantly - to go further by supporting not only specifying a structure parameter but also an array. So currently, in BBCSDL and the Console editions, we have:

Code: Select all

      address = PTR(struct{})
      address = PTR(array())
      address = PTR(string$)
      PTR(struct{}) = address
      PTR(array()) = address
      PTR(string$) = address

It has recently occurred to me that it's somewhat inconsistent to support these options without also being able to do the same with a function or procedure:

Code: Select all

      address = PTR(FNmyfunc)
      PTR(PROCmyproc) = address

I don't suggest that this usage would be particularly valuable, but then nor are some of the other extended uses for PTR(), but it would be difficult to justify arbitrarily omitting it. So I propose to add this extension-to-the-extension in a future release, unless anybody has an objection (it adds a whole four bytes to the editions coded in assembler!):

This rather contrived test program shows one way in which it could be used:

Code: Select all

      PROC0
      PTR(PROC0) = PTR(PROC1)
      PROC0
      PTR(PROC0) = PTR(PROC2)
      PROC0
      END

      DEF PROC0
      ENDPROC

      DEF PROC1
      PRINT "One"
      ENDPROC

      DEF PROC2
      PRINT "Two"
      ENDPROC

which prints:

Code: Select all

One
Two