Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.acorn.programmer > #1224 > unrolled thread

Re: Structures in BASIC

Back to article view | Back to comp.sys.acorn.programmer

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Structures in BASIC Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-12-24 20:25 +0100
    Re: Structures in BASIC Steve Drain <steve@kappa.me.uk> - 2011-12-24 20:17 +0000
    Re: Structures in BASIC Gavin Wraith <gavin@wra1th.plus.com> - 2011-12-25 12:33 +0000
      Re: Structures in BASIC Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-12-26 02:21 +0100
    Re: Structures in BASIC Gazza <usenet@garethlock.com> - 2011-12-31 12:51 -0800
      Re: Structures in BASIC Martin <News03@avisoft.f9.co.uk> - 2011-12-31 22:36 +0000
        Re: Structures in BASIC Gazza <usenet@garethlock.com> - 2011-12-31 17:41 -0800
      Re: Structures in BASIC druck <news@druck.org.uk> - 2012-01-02 10:36 +0000
        Re: Structures in BASIC Alan Adams <alan@adamshome.org.uk> - 2012-01-02 11:36 +0000
          Re: Structures in BASIC Steve Drain <steve@kappa.me.uk> - 2012-01-02 15:16 +0000

#1224 — Re: Structures in BASIC

On 24/12/2011 12:38, Steve Drain wrote:

> Ideas have been gestating for more than a decade

As languages develop, I reckon there are a lot of people with ideas for 
"if only we could...". Certainly, structure handling is one of the biggies.


> but neither of those would cope with window blocks.

Which would rather limit their usefulness.


> In addition, you might have noted that I think a regularly developing
> BASIC module is not likely to happen, because of the central position it
> has in RISC OS.

Cdertainly, things can't change as often as NoScript updates, but does 
this mean we're stuck with a BASIC that hasn't really been changed much 
since the mid '90s? [and even that was fairly minor changes for the 
extended graphics capabilities of the RiscPC]

It should change, if only one major overhaul to add new stuff (yet 
remain broadly compatible), like BASIC V built on earlier versions, yet 
added *loads* of things (CASE selectors, multi-line IF, SWI/Arthur 
support, ARM assembler instead of 6502, WHILE loops and so on).


> Hidden away in the library is just such magic, it it the quickest
> method, but in assembler it would just be a normal termination check.

It's a shame BASIC itself doesn't support \x0D *and* \x00 (while, 
obviously, preferring \x0D for its own strings).


> It is "overloading".

Overloads my brain, I'll tell you that! ;-)


> I'm afraid BASIC, and much more Basalt, do it with keywords.

There is a certain zany beauty in "TO"P.


> The syntax for structures in Basalt would be similar to what I used for
> the library:
> Prototype=DEF(definition list)
> structure=NEW(Prototype)
> \structure.variable=value
> value=\(structure.variable)

That's pretty clear, not bad at all. I can see definite similarities 
with VisualBasic (not delved into C++ much) - define, create, use...


> '\' is a keyword that can be read as "the value of".

How come the final line has the structure.variable in brackets? Is 
\structure.variable the same as \(structure.variable)?


> It has been available to some for a long time.

;-)


Best wishes,

Rick.

[toc] | [next] | [standalone]

#1225

On 24/12/2011 19:25, Rick Murray wrote:
> On 24/12/2011 12:38, Steve Drain wrote:
>> In addition, you might have noted that I think a regularly developing
>> BASIC module is not likely to happen, because of the central position it
>> has in RISC OS.
> Certainly, things can't change as often as NoScript updates, but does
> this mean we're stuck with a BASIC that hasn't really been changed much
> since the mid '90s? [and even that was fairly minor changes for the
> extended graphics capabilities of the RiscPC]

And also some additions for the Iyonix. But these were supplied with new 
machines, so everyone had them in rom. In the early days of RISC OS we 
coped quite well with regular updates to some modules, particularly the 
SharedCLib, by updating !System, but remember the fuss over the 32-bit 
SCL. I fear that there would be similar problems with BASIC.

> It should change, if only one major overhaul to add new stuff (yet
> remain broadly compatible), like BASIC V built on earlier versions, yet
> added *loads* of things (CASE selectors, multi-line IF, SWI/Arthur
> support, ARM assembler instead of 6502, WHILE loops and so on).

But that was effectively a new language and the versions could not run 
on the same machines. I think I am right to suggest that BB4W can have 
regular updates because it compiles the current runtime into the executable.

>> Hidden away in the library is just such magic, it it the quickest
>> method, but in assembler it would just be a normal termination check.
> It's a shame BASIC itself doesn't support \x0D *and* \x00 (while,
> obviously, preferring \x0D for its own strings).

I am sure the change would be minimal, but might break existing programs 
that have assumed that control characters can be in strings.

>> The syntax for structures in Basalt would be similar to what I used for
>> the library:
>> Prototype=DEF(definition list)
>> structure=NEW(Prototype)
>> \structure.variable=value
>> value=\(structure.variable)
>
> That's pretty clear, not bad at all. I can see definite similarities
> with VisualBasic (not delved into C++ much) - define, create, use...
>> '\' is a keyword that can be read as "the value of".
> How come the final line has the structure.variable in brackets? Is
> \structure.variable the same as \(structure.variable)?

It is to do with BASIC syntax and returning values from the way USR is 
employed; all Basalt functions have to have parameters in parenthesis. 
Come to think of it, because structure.variable is not actually a 
parameter here, I could probably do without. I did so originally with 
the Toolbox syntax in Basalt, which is very OOP and shares the format of 
structures, but I changed it in the later versions for consistency.
When the time comes ...

Seasons greetings

Steve

[toc] | [prev] | [next] | [standalone]

#1226

In message <4ef62744$0$2524$ba4acef3@reader.news.orange.fr>
          Rick Murray <heyrickmail-usenet@yahoo.co.uk> wrote:

> but does 
> this mean we're stuck with a BASIC that hasn't really been changed much 
> since the mid '90s? 

No, use RiscLua instead! Sorry to proselytize, but why pour new wine
into old bottles?


-- 
Gavin Wraith (gavin@wra1th.plus.com)
Home page: http://www.wra1th.plus.com/

[toc] | [prev] | [next] | [standalone]

#1227

On 25/12/2011 13:33, Gavin Wraith wrote:

> but why pour new wine into old bottles?

So it can be passed off as old wine?

Sorry, couldn't resist the obvious. :-)


Best wishes,

Rick.

[toc] | [prev] | [next] | [standalone]

#1238

I can't remember who mentioned it here, but why do we have to stick to
updating/replacing the ROM version. The other option would be to go
down a similar route to BASIC64. In other words, we run in RAM side by
side with the ROM version.

We take a copy of the source as it is, add the requested features and
compile a module that won't clash with the existing BASIC in ROM.
Anybody who needs the extra features, just RMEnsures this new  module
and loads it from !System as required. No hacks, no bricked machines
etc because it doesn't try and replace the existing ROM BASIC. This
RAM based backward compatible version of BASIC can then be updated and
added to as desired, without the problems we now have while trying to
override the ROM BASIC.

Why someone didn't think of this simple solution as soon as the
sources became public is anyone's guess.

[toc] | [prev] | [next] | [standalone]

#1239

On 31 Dec, in article
<610bd83f-6257-47fe-920c-d092297d67c2@i8g2000vbh.googlegroups.com>,
   Gazza <usenet@garethlock.com> wrote:
> I can't remember who mentioned it here, but why do we have to stick to
> updating/replacing the ROM version. The other option would be to go
> down a similar route to BASIC64. In other words, we run in RAM side by
> side with the ROM version.

> We take a copy of the source as it is, add the requested features and
> compile a module that won't clash with the existing BASIC in ROM.
> Anybody who needs the extra features, just RMEnsures this new  module
> and loads it from !System as required. No hacks, no bricked machines
> etc because it doesn't try and replace the existing ROM BASIC. This
> RAM based backward compatible version of BASIC can then be updated and
> added to as desired, without the problems we now have while trying to
> override the ROM BASIC.

> Why someone didn't think of this simple solution as soon as the
> sources became public is anyone's guess.

That all sounds perfectly reasonable for testing ... EXCEPT that all the
effort you went into adding the extra facilities are ONLY available to
you. Worse, any BASIC you write may be unusable by anyone else! If they
are useful facilities, perhaps it would be better to subject them to
public scruting and acceptance so they might be added to the official ROM
module. Then your work would be appreciated by all, and other developers
could make use of the extra facilities.

Just for my information, after soft-loading your module, if you type
BASIC at a command prompt, which version starts? ROM or RAM?

I think that it would be useful to make ROOL BASIC so attractive that it
could/would become the standard on ALL RO machines, which would remove
one frustration of developers in trying to make sure a program works with
forked versions of BASIC.

IMHO
Martin

-- 
Martin Avison 
Note that unfortunately this email address will become invalid
without notice if (when) any spam is received. 

[toc] | [prev] | [next] | [standalone]

#1240

On Dec 31 2011, 10:36 pm, Martin <New...@avisoft.f9.co.uk> wrote:
> On 31 Dec, in article
> <610bd83f-6257-47fe-920c-d092297d6...@i8g2000vbh.googlegroups.com>,
>    Gazza <use...@garethlock.com> wrote:
>
> > I can't remember who mentioned it here, but why do we have to stick to
> > updating/replacing the ROM version. The other option would be to go
> > down a similar route to BASIC64. In other words, we run in RAM side by
> > side with the ROM version.
> > We take a copy of the source as it is, add the requested features and
> > compile a module that won't clash with the existing BASIC in ROM.
> > Anybody who needs the extra features, just RMEnsures this new  module
> > and loads it from !System as required. No hacks, no bricked machines
> > etc because it doesn't try and replace the existing ROM BASIC. This
> > RAM based backward compatible version of BASIC can then be updated and
> > added to as desired, without the problems we now have while trying to
> > override the ROM BASIC.
> > Why someone didn't think of this simple solution as soon as the
> > sources became public is anyone's guess.
>
> That all sounds perfectly reasonable for testing ... EXCEPT that all the
> effort you went into adding the extra facilities are ONLY available to
> you. Worse, any BASIC you write may be unusable by anyone else! If they
> are useful facilities, perhaps it would be better to subject them to
> public scruting and acceptance so they might be added to the official ROM
> module. Then your work would be appreciated by all, and other developers
> could make use of the extra facilities.
>
> Just for my information, after soft-loading your module, if you type
> BASIC at a command prompt, which version starts? ROM or RAM?
>
> I think that it would be useful to make ROOL BASIC so attractive that it
> could/would become the standard on ALL RO machines, which would remove
> one frustration of developers in trying to make sure a program works with
> forked versions of BASIC.
>
> IMHO
> Martin
>
> --
> Martin Avison
> Note that unfortunately this email address will become invalid
> without notice if (when) any spam is received.

You wouldn't use BASIC at the command prompt. BASIC64 used BASIC64 at
the command prompt... We'd invoke our BASIC in a similar way. Say
BASIC6 for arguments sake. As far as getting it out there, the idea
would be to distribute it on ROOL, just like the current versions of
BASIC and BASIC64. All you'd do would be to download it and use !
SysMerge, or the sysmerge utility in configure (for RISC OS v4 and
later) to get it in !System. Then just RMEnsure it as required. After
all, what happens if we don't have a module installed currently. You
have to use sysmerge. Not that hard.

[toc] | [prev] | [next] | [standalone]

#1241

On 31/12/2011 20:51, Gazza wrote:
> I can't remember who mentioned it here, but why do we have to stick to
> updating/replacing the ROM version. The other option would be to go
> down a similar route to BASIC64. In other words, we run in RAM side by
> side with the ROM version.

BASIC 64 is not BASIC it's different language as far as the computer is 
concerned, and using it requires you to invoke a different star command 
on the BASIC file.

> We take a copy of the source as it is, add the requested features and
> compile a module that won't clash with the existing BASIC in ROM.
> Anybody who needs the extra features, just RMEnsures this new  module
> and loads it from !System as required. No hacks, no bricked machines
> etc because it doesn't try and replace the existing ROM BASIC. This
> RAM based backward compatible version of BASIC can then be updated and
> added to as desired, without the problems we now have while trying to
> override the ROM BASIC.

The problem there similar to that of the SharedCLibrary. There is one in 
ROM, which is always used by the C ROM applications regardless of what 
happens. You can softload a later SCL which newly loaded C applications 
will use, but exactly ONCE. Another program comes along and wants a 
later softloaded SCL, and it wont run. The solution being to always load 
the latest SCL at boot time.

The only way one softloaded module can be replaced with another when 
there are already client applications using it, is if it is completely 
stateless, or there is a defined way of passing state from version X to 
version Y.

> Why someone didn't think of this simple solution as soon as the
> sources became public is anyone's guess.

Because it's never as simple as you may think!

---druck

[toc] | [prev] | [next] | [standalone]

#1242

In message <jds1c5$avh$1@dont-email.me>
          druck <news@druck.org.uk> wrote:

> On 31/12/2011 20:51, Gazza wrote:
>> I can't remember who mentioned it here, but why do we have to stick to
>> updating/replacing the ROM version. The other option would be to go
>> down a similar route to BASIC64. In other words, we run in RAM side by
>> side with the ROM version.

> BASIC 64 is not BASIC it's different language as far as the computer is
> concerned, and using it requires you to invoke a different star command
> on the BASIC file.

>> We take a copy of the source as it is, add the requested features and
>> compile a module that won't clash with the existing BASIC in ROM.
>> Anybody who needs the extra features, just RMEnsures this new  module
>> and loads it from !System as required. No hacks, no bricked machines
>> etc because it doesn't try and replace the existing ROM BASIC. This
>> RAM based backward compatible version of BASIC can then be updated and
>> added to as desired, without the problems we now have while trying to
>> override the ROM BASIC.

> The problem there similar to that of the SharedCLibrary. There is one in
> ROM, which is always used by the C ROM applications regardless of what
> happens. You can softload a later SCL which newly loaded C applications
> will use, but exactly ONCE. Another program comes along and wants a
> later softloaded SCL, and it wont run. The solution being to always load
> the latest SCL at boot time.

> The only way one softloaded module can be replaced with another when
> there are already client applications using it, is if it is completely
> stateless, or there is a defined way of passing state from version X to
> version Y.

>> Why someone didn't think of this simple solution as soon as the
>> sources became public is anyone's guess.

> Because it's never as simple as you may think!

> ---druck

Maybe we should be looking at adding the requested features to 
BASIC64. Then anyone who needed them could do so in the same way as 
they already would to use the extended Floating point format for 
example.

Replacing BASIC64 wouldn't be as difficult as BASIC, would it?

Alan


-- 
Alan Adams, from Northamptonshire
alan@adamshome.org.uk
http://www.nckc.org.uk/

[toc] | [prev] | [next] | [standalone]

#1246

On 02/01/2012 11:36, Alan Adams wrote:
> druck<news@druck.org.uk>  wrote:
>> On 31/12/2011 20:51, Gazza wrote:
>>> Why someone didn't think of this simple solution as soon as the
>>> sources became public is anyone's guess.
>> Because it's never as simple as you may think!
> Maybe we should be looking at adding the requested features to
> BASIC64. Then anyone who needed them could do so in the same way as
> they already would to use the extended Floating point format for
> example.

There is a good case for a new standard of using BASIC VI for 
applications rather than BASIC V, and they could coexist without 
problem. You can also make new versions of the BASIC module with 
different names that can coexist, as BasPlus has done experimentally, 
but then you start to lose the point of a common language module used by 
all.

> Replacing BASIC64 wouldn't be as difficult as BASIC, would it?

Yes. Once one copy has been loaded and an application is using it the 
module cannot be replaced, eg: by a later version that is required by 
another application. The only reason that there can be a new softloaded 
version of BASIC V is that the addresses in the ROM version do not 
become invalid for programs already using it.

The practical answer is that suggested by Martin, produce a new BASIC 
that has applications written with it that are so good *everyone* will 
take the trouble to install it in System.

I must add that this problem was apparent to me a long time ago. 
Although Basalt is not an ideal answer, because it is a bolt-on to 
BASIC, it has been designed so that the module can be replaced while it 
is in use. Without looking deeper into this [1], I think the technique I 
use could also be used by a new version of BASIC to allow its own 
replacement, but that would be a complete break from current versions.

Steve

[1] I assume here that the only critical address is the 'environment 
pointer'.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.sys.acorn.programmer

csiph-web