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

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

BASIC and uppercase

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

Contents

  BASIC and uppercase Ron <beeb@woosh.co.nz> - 2011-10-30 14:34 +1300
    Re: BASIC and uppercase Matthew Phillips <spam2011m@yahoo.co.uk> - 2011-10-30 07:57 +0000
      Re: BASIC and uppercase Ron <beeb@woosh.co.nz> - 2011-10-30 21:35 +1300
        Re: BASIC and uppercase Ron <beeb@woosh.co.nz> - 2011-10-30 22:57 +1300
          Re: BASIC and uppercase "John Williams (News)" <UCEbin@tiscali.co.uk> - 2011-10-30 11:38 +0100
          Re: BASIC and uppercase Matthew Phillips <spam2011m@yahoo.co.uk> - 2011-10-30 16:50 +0000
            Re: BASIC and uppercase Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-10-31 01:02 +0100
              Re: BASIC and uppercase Steve Drain <steve@kappa.me.uk> - 2011-10-31 15:47 +0000
                Re: BASIC and uppercase Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-10-31 20:06 +0100
          Re: BASIC and uppercase Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-10-31 00:28 +0100
            Re: BASIC and uppercase Ron <beeb@woosh.co.nz> - 2011-10-31 17:04 +1300
              Re: BASIC and uppercase Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-10-31 16:12 +0100
                Re: BASIC and uppercase jgharston <jgh@arcade.demon.co.uk> - 2011-11-01 04:51 -0700
      Re: BASIC and uppercase "Ste (news)" <steve@revi11.plus.com> - 2011-10-31 01:03 +0000
        Re: BASIC and uppercase Steve Drain <steve@kappa.me.uk> - 2011-10-31 19:48 +0000
          Re: BASIC and uppercase Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-11-01 21:11 +0100
            Re: BASIC and uppercase Steve Drain <steve@kappa.me.uk> - 2011-11-02 14:26 +0000
      Re: BASIC and uppercase Steve Drain <steve@kappa.me.uk> - 2011-10-31 11:10 +0000
    Re: BASIC and uppercase Chris Johnson <chrisjohnson+news@spamcop.net> - 2011-10-30 08:44 +0000
      Re: BASIC and uppercase Ron <beeb@woosh.co.nz> - 2011-10-30 22:52 +1300
    Re: BASIC and uppercase Alan Adams <alan@adamshome.org.uk> - 2011-10-30 15:16 +0000
      Re: BASIC and uppercase Ron <beeb@woosh.co.nz> - 2011-10-31 14:37 +1300
        Re: BASIC and uppercase Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-10-31 16:15 +0100
          Re: BASIC and uppercase Ron <beeb@woosh.co.nz> - 2011-11-01 11:39 +1300
            Re: BASIC and uppercase Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-11-01 21:21 +0100

Page 1 of 2  [1] 2  Next page →

#945 — BASIC and uppercase

I have been working with !Confix and have found that the
example uses a function to convert variable names to
uppercase before they are used in a CASE OF structure.

DEFFNupcase(input$)
   LOCAL pos%
   $par% = input$
   FOR pos%=0 TO LEN(input$)-1
      char% = ?(par%+pos%)
      IF char%>64 THEN
         ?(par%+pos%) = char% AND NOT 32
      ENDIF
   NEXT
=$par%

With the example,  
DIM par% 255 is needed but not included.

Two questions.
I am using the WHEN variables in mixed case, ie.

WHEN "Foo"  : Bar% = VAL(val$)
 
and no problems on my Iyonix.
Do earlier BASIC's need uppercase or is it some sort of
optimisation for BASIC to use uppercase?

WHEN "FOO"  : Bar% = VAL(val$) 

Secondly, for another purpose, the $ indirection is 
limited to 256 chars.
Would Martin's longstring library change this limit?

Thanks,  Ron M.    

[toc] | [next] | [standalone]

#946

In message <cfae0b2a52.beeb@ron1954.woosh.co.nz>
 on 30 Oct 2011 Ron  wrote:

> I have been working with !Confix and have found that the
> example uses a function to convert variable names to
> uppercase before they are used in a CASE OF structure.
> 
> DEFFNupcase(input$)
>    LOCAL pos%
>    $par% = input$
>    FOR pos%=0 TO LEN(input$)-1
>       char% = ?(par%+pos%)
>       IF char%>64 THEN
>          ?(par%+pos%) = char% AND NOT 32
>       ENDIF
>    NEXT
> =$par%
> 
> With the example,  
> DIM par% 255 is needed but not included.

This example function is not going to convert "variable names" to upper case:
it will convert a string value, which may or may not be held in a variable:

PRINT FNupcase("This")
--> THIS

> I am using the WHEN variables in mixed case, ie.
> 
> WHEN "Foo"  : Bar% = VAL(val$)
>  
> and no problems on my Iyonix.
> Do earlier BASIC's need uppercase or is it some sort of
> optimisation for BASIC to use uppercase?
> 
> WHEN "FOO"  : Bar% = VAL(val$) 

You've missed out the CASE statement, which makes it harder to see what is
going on.  I'm guessing it was something like:

CASE upcase(a$) OF

It's just that the author of Confix wanted the code for "FOO" to be executed
when a$ was FOO, FOo, FoO, Foo, fOO, fOo, foO or foo without having to write
them all out.

It all depends on your application.  Can you rely on the capitalisation of
the terms being as you expect?  If you can, no need to bother with
upper-casing it all.  But if you're accepting user input or reading from a
user-editable configuration file or something like that, it is friendlier to
allow for a mixed case input.

And be careful about copying that example for converting a string to upper
case: it's not desperately well-written for general use as it also affects
various punctuation marks and does not handle accented characters properly.

You could try:

DEFFNupcase(input$)
  LOCAL pos%
  LOCAL table%
  IF input$="" THEN =""
  SYS"Territory_UpperCaseTable",-1 TO table%
  FOR pos%=1 TO LEN(input$)
    MID$(input$,pos%,1) = CHR$( table% ? ASC(MID$(input$,pos%,1)) )
  NEXT
  = input$

This uses the Territory module to find the upper case conversion table, so
should work whatever alphabet the machine is using (apart from UTF-8 and
things like that).

Note the use of assigning to MID$ which avoids having to have a separate
buffer to build the string in.

-- 
Matthew Phillips
Durham

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

#947

In message <63bc2e2a52.Matthew@sinenomine.freeserve.co.uk>
          Matthew Phillips <spam2011m@yahoo.co.uk> wrote:

> In message <cfae0b2a52.beeb@ron1954.woosh.co.nz>
>  on 30 Oct 2011 Ron  wrote:
> 
<snip>
> 
> This example function is not going to convert "variable names" to upper case:
> it will convert a string value, which may or may not be held in a variable:
> 
> PRINT FNupcase("This")
> --> THIS
> 
Sorry, yes they are not variables, but are expected strings that
are obtained from the front end. 
They are fixed once set in the _config file, so I dont need to
uppercase them if there is no other good reason to.

<snip>

> 
> And be careful about copying that example for converting a string to upper
> case: it's not desperately well-written for general use as it also affects
> various punctuation marks and does not handle accented characters properly.
> 
> You could try:
> 
> DEFFNupcase(input$)
>   LOCAL pos%
>   LOCAL table%
>   IF input$="" THEN =""
>   SYS"Territory_UpperCaseTable",-1 TO table%
>   FOR pos%=1 TO LEN(input$)
>     MID$(input$,pos%,1) = CHR$( table% ? ASC(MID$(input$,pos%,1)) )
>   NEXT
>   = input$
> 
> This uses the Territory module to find the upper case conversion table, so
> should work whatever alphabet the machine is using (apart from UTF-8 and
> things like that).
> 
> Note the use of assigning to MID$ which avoids having to have a separate
> buffer to build the string in.
> 
Thanks, the THEN ="" is new to me.
As is the CHR$( table% ?   but I'll try this out and observe.

Ron M.

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

#950

In message <4539322a52.beeb@ron1954.woosh.co.nz>
          Ron <beeb@woosh.co.nz> wrote:
> > 
> > You could try:
> > 
> > DEFFNupcase(input$)
> >   LOCAL pos%
> >   LOCAL table%
> >   IF input$="" THEN =""
> >   SYS"Territory_UpperCaseTable",-1 TO table%
> >   FOR pos%=1 TO LEN(input$)
> >     MID$(input$,pos%,1) = CHR$( table% ? ASC(MID$(input$,pos%,1)) )
> >   NEXT
> >   = input$
> > 
> > This uses the Territory module to find the upper case conversion table, so
> > should work whatever alphabet the machine is using (apart from UTF-8 and
> > things like that).
> > 
> > Note the use of assigning to MID$ which avoids having to have a separate
> > buffer to build the string in.
> > 
> Thanks, the THEN ="" is new to me.
> As is the CHR$( table% ?   but I'll try this out and observe.
> 
Checked it out, and there seems to be no difference if I REM
IF input$="" THEN =""
and have a input$ of ""

I got the above function working with
MID$(input$,pos%,1) = CHR$(?(table%+ASC(MID$(input$,pos%,1))))

Cheers Ron M.

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

#951

In article <c1b3392a52.beeb@ron1954.woosh.co.nz>, Ron <beeb@woosh.co.nz>
wrote:

> Checked it out, and there seems to be no difference if I REM IF input$=""
> THEN ="" and have a input$ of ""

It's just a 'quick exit', saving a few clock cycles.

John

-- 
John Williams, Brittany, Northern France - no attachments to these addresses!
Non-RISC OS posters change user to johnrwilliams or put 'risc' in subject!
Who is John Williams? http://petit.four.free.fr/picindex/author/

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

#954

In message <c1b3392a52.beeb@ron1954.woosh.co.nz>
 on 30 Oct 2011 Ron  wrote:

> In message <4539322a52.beeb@ron1954.woosh.co.nz>
>           Ron <beeb@woosh.co.nz> wrote:
> > > 
> > > You could try:
> > > 
> > > DEFFNupcase(input$)
> > >   LOCAL pos%
> > >   LOCAL table%
> > >   IF input$="" THEN =""
> > >   SYS"Territory_UpperCaseTable",-1 TO table%
> > >   FOR pos%=1 TO LEN(input$)
> > >     MID$(input$,pos%,1) = CHR$( table% ? ASC(MID$(input$,pos%,1)) )
> > >   NEXT
> > >   = input$
> > > 
> > > This uses the Territory module to find the upper case conversion table, so
> > > should work whatever alphabet the machine is using (apart from UTF-8 and
> > > things like that).
> > > 
> > > Note the use of assigning to MID$ which avoids having to have a separate
> > > buffer to build the string in.
> > > 
> > Thanks, the THEN ="" is new to me.

IF <condition> THEN <commands>

is the way some flavours of BASIC require it to be written.  BBC BASIC can
possibly cope with

IF input$="" =""

(I've not tested) but it looks so horrible it's clearer with THEN even if
it's not syntactically necessary.

The ="" is simply returning a blank string from the function: ENDPROC or =
can return from anywhere within a PROC or FN repectively, not just from the
last line of it.  It's sometimes considered bad form to do this as some
people expect functions and procedures only to have one point of exit, but
personally I think it's simpler than vast long nested conditional clauses.

> > As is the CHR$( table% ?   but I'll try this out and observe.
> > 
> Checked it out, and there seems to be no difference if I REM
> IF input$="" THEN =""
> and have a input$ of ""

BBC BASIC (unlike Locomotive BASIC which I cut my teeth on) always executes a
FOR NEXT loop a minimum of one time, even if the end value of the loop range
is less than the beginning value.  So "FOR pos%=1 TO 0" executes once, and so
does "FOR pos%=1 TO 1".  You might expect the former to execute one fewer
time (i.e. not at all).  This feature seems to me very odd, and it can cause
difficulties if you're not aware of it.

My inclusion of the line saying

IF input$="" THEN =""

is an example of defensive programming.  I wouldn't like to say that
assigning to

MID$(a$,1,1)

where a$ is an empty string would be OK in all flavours of BASIC, and if you
try

PRINT ASC(MID$("",1,1))

you will get -1 and you certainly have no guarantee that the memory at
table%-1 is available for reading a byte from: it's conceivable (without
knowing more information about the inner workings of the operating system)
that that logical address is unmapped and reading from it could result in an
address exception.

(As it happens, it works fine on my machine this afternoon, but I don't like
relying on it.)

> I got the above function working with
> MID$(input$,pos%,1) = CHR$(?(table%+ASC(MID$(input$,pos%,1))))

Yes,

?(a%+b%)

is equivalent to

a%?b%

The latter is just another way of writing it.  It's available with the !
operator as well, but not with $ as far as I remember.

-- 
Matthew Phillips
Durham

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

#956

On 30/10/2011 17:50, Matthew Phillips wrote:

> BBC BASIC (unlike Locomotive BASIC which I cut my teeth on) always executes a
> FOR NEXT loop a minimum of one time,
[...]
> This feature seems to me very odd, and it can cause difficulties if you're not
> aware of it.

This is a case of Know Your Language.

Try WHILE...ENDWHILE (not WEND!) loops if you want the ability to run a 
clause zero times.


> I wouldn't like to say that assigning to
> MID$(a$,1,1)
> where a$ is an empty string would be OK in all flavours of BASIC, and if you
> try
> PRINT ASC(MID$("",1,1))

Actually, either MID$ is bugged, or it is remarkably lackadaisical.

   A$ = ""
   PRINT MID$(A$,39034909,-90349)

Will work without generating an error, despite being utter gibberish.

It seems to be 'safe' in reverse, too. I've poked around with:
   *Memory 8F00
which is the start of the string table, and I can see no side effects to 
writing to invalid MID$ offsets.

It seems LEFT$ and RIGHT$ are similarly afflicted, and won't error in 
similar cases.


Best wishes,

Rick.

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

#970

On 31/10/2011 00:02, Rick Murray wrote:
> On 30/10/2011 17:50, Matthew Phillips wrote:
>
>> BBC BASIC (unlike Locomotive BASIC which I cut my teeth on) always
>> executes a
>> FOR NEXT loop a minimum of one time,
> [...]
>> This feature seems to me very odd, and it can cause difficulties if
>> you're not
>> aware of it.
>
> This is a case of Know Your Language.
>
> Try WHILE...ENDWHILE (not WEND!) loops if you want the ability to run a
> clause zero times.

The problem is that a FOR...NEXT loop is faster with a control variable 
than WHILE...ENDHILE. Another solution is to enclose the FOR...NEXT in 
an IF...ENDIF:

   IF first%<=last% THEN
    FOR i%=first% TO last%
     ...
    NEXT i%
   ENDIF

>> I wouldn't like to say that assigning to
>> MID$(a$,1,1)
>> where a$ is an empty string would be OK in all flavours of BASIC, and
>> if you
>> try
>> PRINT ASC(MID$("",1,1))
>
> Actually, either MID$ is bugged, or it is remarkably lackadaisical.
>
> A$ = ""
> PRINT MID$(A$,39034909,-90349)
>
> Will work without generating an error, despite being utter gibberish.

It is lackadaisical, isn't it? Or is that 'flexible' ?

> It seems to be 'safe' in reverse, too. I've poked around with:
> *Memory 8F00
> which is the start of the string table, and I can see no side effects to
> writing to invalid MID$ offsets.

Indeed, the parameters default to sensible values when those given are 
out of range. I have taken note of it for an update to my SH BASIC manual.

> It seems LEFT$ and RIGHT$ are similarly afflicted, and won't error in
> similar cases.

LEFT$ and RIGHT$ use the same code as MID$.

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

#971

On 31/10/2011 16:47, Steve Drain wrote:

>> PRINT MID$(A$,39034909,-90349)
>> Will work without generating an error, despite being utter gibberish.
> It is lackadaisical, isn't it? Or is that 'flexible' ?

I'd be inclined to say the example above should definitely throw an 
error. This isn't PHP, strings are no-way-no-how going to be those sorts 
of sizes. And negative indices not faulting!?

> I have taken note of it for an update to my SH BASIC manual.

Drop me a line when it is ready, please.


Best wishes,

Rick.

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

#955

On 30/10/2011 10:57, Ron wrote:

> Checked it out, and there seems to be no difference if I REM
> IF input$="" THEN =""
> and have a input$ of ""

Yeah, but the ="" is saying to exit the function with a blank response, 
*not* to assign an empty string to input$.


VisualBasic makes this a little clearer with:

   Private MyFunction() As String
     MyFunction = ""
   Exit Function

In other words, you explicitly write the result "to" the function, and 
then you explicitly exit the function.

That said, ="" is a lot less typing. Being used to Acorn BASIC 
(=variable) and C (return blah;), it seems weird to assign a value to 
something that isn't a variable, but there you go...


I absolutely definitely do NOT subscribe to the rule that a function 
should only have one entry and one exit point. People that think that 
probably cut their teeth on Pascal... Instead, if sanity checking needs 
to be applied, do so beginning with the most likely clause first, 
dropping out of the function if the test fails.


Consider the one-exit rule, which could lead to code like:
   DEFFNReadDiscLabel
     LOCAL DiscLabel$
     DiscLabel$ = ""
     IF FNDrive_Is_Present = TRUE THEN
       IF FNDisc_Is_Present = TRUE THEN
         IF FNDisc_Format_Okay = TRUE THEN
           DiscLabel$ = FNGetLabelFromBootSector
         ENDIF
       ENDIF
     ENDIF
   =DiscLabel$

With the quick-exit version:

   DEFFNReadDiscLabel
     IF NOT FNDrive_Is_Present: =""
     IF NOT FNDisc_Is_Present: =""
     IF NOT FNDisc_Format_Okay: =""
   =FNGetLabelFromBootSector

Not so much difference here, however imagine it through a much larger 
and more complicated function.


> I got the above function working with
> MID$(input$,pos%,1) = CHR$(?(table%+ASC(MID$(input$,pos%,1))))

You are saying:

   byte from table plus offset   -> ?table+(offset)

The other is saying:

   table with offset is byte     >  table?offset

Essentially it is the same thing, however the table? form lends itself 
to a smaller necessity for brackets.


Best wishes,

Rick.

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

#959

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

> On 30/10/2011 10:57, Ron wrote:
> 
> > Checked it out, and there seems to be no difference if I REM
> > IF input$="" THEN =""
> > and have a input$ of ""
> 
> Yeah, but the ="" is saying to exit the function with a blank response, 
> *not* to assign an empty string to input$.
> 
THEN = END Looks like it behaves and does the same thing.
John has mentioned less clock cycles, maybe the reason.
It is OK to exit a FN early then? I can remember being
told not to exit a PROC early. ie two possible ENDPROC's.  
> 
> VisualBasic makes this a little clearer with:
> 
>    Private MyFunction() As String
>      MyFunction = ""
>    Exit Function
> 
> In other words, you explicitly write the result "to" the function, and 
> then you explicitly exit the function.
> 
> That said, ="" is a lot less typing. Being used to Acorn BASIC 
> (=variable) and C (return blah;), it seems weird to assign a value to 
> something that isn't a variable, but there you go...
> 
> 
> I absolutely definitely do NOT subscribe to the rule that a function 
> should only have one entry and one exit point. People that think that 
> probably cut their teeth on Pascal... Instead, if sanity checking needs 
> to be applied, do so beginning with the most likely clause first, 
> dropping out of the function if the test fails.
> 
> 
> Consider the one-exit rule, which could lead to code like:
>    DEFFNReadDiscLabel
>      LOCAL DiscLabel$
>      DiscLabel$ = ""
>      IF FNDrive_Is_Present = TRUE THEN
>        IF FNDisc_Is_Present = TRUE THEN
>          IF FNDisc_Format_Okay = TRUE THEN
>            DiscLabel$ = FNGetLabelFromBootSector
>          ENDIF
>        ENDIF
>      ENDIF
>    =DiscLabel$
> 
> With the quick-exit version:
> 
>    DEFFNReadDiscLabel
>      IF NOT FNDrive_Is_Present: =""
>      IF NOT FNDisc_Is_Present: =""
>      IF NOT FNDisc_Format_Okay: =""
>    =FNGetLabelFromBootSector
> 
> Not so much difference here, however imagine it through a much larger 
> and more complicated function.
> 
Four possible endpoints to the function, I guess that it /is/ OK then.
 
> > I got the above function working with
> > MID$(input$,pos%,1) = CHR$(?(table%+ASC(MID$(input$,pos%,1))))
> 
> You are saying:
> 
>    byte from table plus offset   -> ?table+(offset)
> 
> The other is saying:
> 
>    table with offset is byte     >  table?offset
> 
> Essentially it is the same thing, however the table? form lends itself 
> to a smaller necessity for brackets.

I wasn't on to it, it was the space between table% and ? that was 
stopping it. 

Ron M.
 

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

#968

On 31/10/2011 05:04, Ron wrote:

> It is OK to exit a FN early then? I can remember being
> told not to exit a PROC early. ie two possible ENDPROC's.

In verification functions (consider, for instance, checking input data 
is valid), the code runs through the various checks, and as soon as a 
problem is found, it drops out. Only if all checks complete, does it get 
to returning TRUE.

You can ENDPROC wherever you like, but in general you should only do so 
when it makes sense in the context of what the procedure is actually 
doing. It helps alleviate the need for a spaghetti-mess of artificial 
constructs required to perform testing that may depend upon earlier code 
evaluating TRUE within the wholly artificial constraint of "only one 
exit point".


> Four possible endpoints to the function, I guess that it /is/ OK then.

:-)


> I wasn't on to it, it was the space between table% and ? that was
> stopping it.

Ah, yes. A little lonely space can change everything.


Best wishes,

Rick.

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

#974

Rick Murray wrote:
> Ron wrote:
> > It is OK to exit a FN early then? I can remember being
> > told not to exit a PROC early. ie two possible ENDPROC's.
>
> In verification functions (consider, for instance, checking input data
> is valid), the code runs through the various checks, and as soon as a
> problem is found, it drops out. Only if all checks complete, does it get
> to returning TRUE.
>
> You can ENDPROC wherever you like, but in general you should only do so
> when it makes sense in the context of what the procedure is actually
> doing.

A real-world example from some of my code is tidying up mangled date
strings:

DEFPROCfixdatestring
IF mangled_format_1 THEN fix it:ENDPROC
IF mangled_format_2 THEN fix it:ENDPROC
IF mangled_format_3 THEN convert to mangled_format_4
IF mangled_format_4 THEN fix it:ENDPROC
attempt to fix remaining mangled format
ENDPROC

JGH

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

#957

In article <63bc2e2a52.Matthew@sinenomine.freeserve.co.uk>,
   Matthew Phillips <spam2011m@yahoo.co.uk> wrote:
> DEFFNupcase(input$)
>   LOCAL pos%
>   LOCAL table%
>   IF input$="" THEN =""
>   SYS"Territory_UpperCaseTable",-1 TO table%
>   FOR pos%=1 TO LEN(input$)
>     MID$(input$,pos%,1) = CHR$( table% ? ASC(MID$(input$,pos%,1)) )
>   NEXT
>   = input$

Agreed. The Territory module is the way to go. On the related subject of
performing a case-insensitive comparison of two strings, can I suggest
people look up the PRM documentation for:

  SYS "Territory_Collate"

:)

Steve

-- 
Steve Revill @ Home
Note: All opinions expressed herein are my own.

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

#972

On 31/10/2011 01:03, Ste (news) wrote:
> Agreed. The Territory module is the way to go.

Lots of good things there. It is only a pity that so few modules 
actually exist.

> On the related subject of
> performing a case-insensitive comparison of two strings, can I suggest
> people look up the PRM documentation for:
>
>    SYS "Territory_Collate"

I just threw together TWIN(string1$,string2$ [,flags%]), a Basalt 
function to exploit that SWI. Is TWIN ok, or does it really need a new 
keyword? Suggestions?

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

#975

On 31/10/2011 20:48, Steve Drain wrote:

> I just threw together TWIN(string1$,string2$ [,flags%]), a Basalt
> function to exploit that SWI. Is TWIN ok, or does it really need a new
> keyword? Suggestions?

Isn't TWIN a command to invoke a mostly-forgotten editor?

I'm not sure case conversions and TWIN makes a lot of sense. How about 
STRCASE ? (to save overloading CASE)


Best wishes,

Rick.

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

#983

On 01/11/2011 20:11, Rick Murray wrote:
> On 31/10/2011 20:48, Steve Drain wrote:
>
>> I just threw together TWIN(string1$,string2$ [,flags%]), a Basalt
>> function to exploit that SWI. Is TWIN ok, or does it really need a new
>> keyword? Suggestions?
>
> Isn't TWIN a command to invoke a mostly-forgotten editor?

It is, but this is a case of overloading an existing keyword rather than 
inventing another. There is a marginal gain in efficiency by doing so.

> I'm not sure case conversions and TWIN makes a lot of sense. How about
> STRCASE ? (to save overloading CASE)

It is not really a case conversion; that is the keyword SWAP, which does 
several other conversions as well. It is compare with the possibility of 
ignoring case - the SWI uses 'collate', so that might be an obvious choice.

My dubious logic for using TWIN goes: comparing two strings is a bit 
like testing if they are twins.

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

#966

On 30/10/2011 07:57, Matthew Phillips wrote:
> You could try:
>
> DEFFNupcase(input$)
>    LOCAL pos%
>    LOCAL table%
>    IF input$="" THEN =""
>    SYS"Territory_UpperCaseTable",-1 TO table%
>    FOR pos%=1 TO LEN(input$)
>      MID$(input$,pos%,1) = CHR$( table% ? ASC(MID$(input$,pos%,1)) )
>    NEXT
>    = input$
> This uses the Territory module to find the upper case conversion table, so
> should work whatever alphabet the machine is using (apart from UTF-8 and
> things like that).
>
> Note the use of assigning to MID$ which avoids having to have a separate
> buffer to build the string in.

Which is an excellent thing. With my quibble hat on, the third parameter 
in each MID$ is strictly redundant as are some of the parentheses, but 
they do improve readability and the reduction in speed is minimal.

On another hand, this, from 'you-know-what', is 8 times faster:

   =SWAP$(input$,2)

;-)

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

#948

In article <cfae0b2a52.beeb@ron1954.woosh.co.nz>,
   Ron <beeb@woosh.co.nz> wrote:
> Do earlier BASIC's need uppercase or is it some sort of
> optimisation for BASIC to use uppercase?

No. I think this FN is probably used to make the compare/test case
insensitive, otherwise you could possibly need e.g.
 WHEN "YES":
 WHEN "Yes":
 WHEN "YEs":
 WHEN "yEs":
 etc, etc
to cover all eventualities.

-- 
Chris Johnson

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

#949

In message <522a33103cchrisjohnson+news@spamcop.net>
          Chris Johnson <chrisjohnson+news@spamcop.net> wrote:

> In article <cfae0b2a52.beeb@ron1954.woosh.co.nz>,
>    Ron <beeb@woosh.co.nz> wrote:
> > Do earlier BASIC's need uppercase or is it some sort of
> > optimisation for BASIC to use uppercase?
> 
> No. I think this FN is probably used to make the compare/test case
> insensitive, otherwise you could possibly need e.g.
>  WHEN "YES":
>  WHEN "Yes":
>  WHEN "YEs":
>  WHEN "yEs":
>  etc, etc
> to cover all eventualities.
> 
I can see the point if it was a user input like the above, and
maybe that is where the function hails from.
But in this particular confix useage, the WHEN "string" is a fixed
group name assigned in the _config file.

Thanks, Ron M.

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web