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

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

BBC BASIC, EVAL and PROC

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

Contents

  BBC BASIC, EVAL and PROC Michael <michaelremerton@gmail.com> - 2011-10-22 11:15 -0700
    Re: BBC BASIC, EVAL and PROC Steve Fryatt <news@stevefryatt.org.uk> - 2011-10-22 20:20 +0100
      Re: BBC BASIC, EVAL and PROC Michael <michaelremerton@gmail.com> - 2011-10-22 12:54 -0700
        Re: BBC BASIC, EVAL and PROC Steve Fryatt <news@stevefryatt.org.uk> - 2011-10-23 18:44 +0100
          Re: BBC BASIC, EVAL and PROC Michael <michaelremerton@gmail.com> - 2011-10-23 12:45 -0700
          Re: BBC BASIC, EVAL and PROC Gavin Wraith <gavin@wra1th.plus.com> - 2011-10-24 10:07 +0100
      Re: BBC BASIC, EVAL and PROC jgh@arcade.demon.co.uk (Jonathan Graham Harston) - 2011-10-23 19:13 +0100
        Re: BBC BASIC, EVAL and PROC Michael <michaelremerton@gmail.com> - 2011-10-23 12:50 -0700
        Re: BBC BASIC, EVAL and PROC Steve Fryatt <news@stevefryatt.org.uk> - 2011-10-23 22:00 +0100
        Re: BBC BASIC, EVAL and PROC Martin <News03@avisoft.f9.co.uk> - 2011-10-24 18:23 +0100
      Re: BBC BASIC, EVAL and PROC Steve Drain <steve@kappa.me.uk> - 2011-10-24 13:34 +0100
      Re: BBC BASIC, EVAL and PROC Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-10-25 07:34 +0200
        Re: BBC BASIC, EVAL and PROC Nick Roberts <tigger@orpheusinternet.co.uk> - 2011-10-25 18:14 +0100
          Re: BBC BASIC, EVAL and PROC Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-10-26 06:32 +0200
            Re: BBC BASIC, EVAL and PROC druck <news@druck.org.uk> - 2011-10-26 10:51 +0100
              Re: BBC BASIC, EVAL and PROC Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-10-26 19:15 +0200
          Re: BBC BASIC, EVAL and PROC "Ste (news)" <steve@revi11.plus.com> - 2011-10-26 15:09 +0100
            Re: BBC BASIC, EVAL and PROC "John Williams (News)" <UCEbin@tiscali.co.uk> - 2011-10-26 16:36 +0200
              Re: BBC BASIC, EVAL and PROC Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-10-26 19:18 +0200
            Re: BBC BASIC, EVAL and PROC Nick Roberts <tigger@orpheusinternet.co.uk> - 2011-10-26 17:26 +0100
              Re: BBC BASIC, EVAL and PROC "Ste (news)" <steve@revi11.plus.com> - 2011-10-26 21:07 +0100
    Re: BBC BASIC, EVAL and PROC Gerph <gerph@gerph.org> - 2011-10-25 03:28 -0700
      Re: BBC BASIC, EVAL and PROC Ron <beeb@woosh.co.nz> - 2011-10-27 11:52 +1300
        Re: BBC BASIC, EVAL and PROC Theo Markettos <theom+news@chiark.greenend.org.uk> - 2011-10-27 12:00 +0100
          Re: BBC BASIC, EVAL and PROC Ron <beeb@woosh.co.nz> - 2011-10-28 01:38 +1300
            Re: BBC BASIC, EVAL and PROC Theo Markettos <theom+news@chiark.greenend.org.uk> - 2011-10-27 14:02 +0100
          Re: BBC BASIC, EVAL and PROC Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-10-27 18:24 +0200
      Re: BBC BASIC, EVAL and PROC Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-10-27 07:42 +0200
      Re: BBC BASIC, EVAL and PROC Steve Drain <steve@kappa.me.uk> - 2011-11-03 13:57 +0000
        Re: BBC BASIC, EVAL and PROC Tony van der Hoff <news1106@vanderhoff.org> - 2011-11-03 15:28 +0100
          Re: BBC BASIC, EVAL and PROC Steve Drain <steve@kappa.me.uk> - 2011-11-03 16:00 +0000
        Re: BBC BASIC, EVAL and PROC Gerph <gerph@gerph.org> - 2011-11-04 16:22 -0700
          Re: BBC BASIC, EVAL and PROC Steve Drain <steve@kappa.me.uk> - 2011-11-05 14:51 +0000
            Re: BBC BASIC, EVAL and PROC Steve Drain <steve@kappa.me.uk> - 2011-11-06 13:25 +0000
              Re: BBC BASIC, EVAL and PROC Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-11-06 19:35 +0100
                Re: BBC BASIC, EVAL and PROC Alan Adams <alan@adamshome.org.uk> - 2011-11-06 18:53 +0000
              Re: BBC BASIC, EVAL and PROC Gavin Wraith <gavin@wra1th.plus.com> - 2011-11-07 14:09 +0000

Page 1 of 2  [1] 2  Next page →

#901 — BBC BASIC, EVAL and PROC

Hi,

RISC OS 5.17
BBC BASIC version 1.44

I am attempting to set-up a timer system.

I have an array / queue which has instructions to call.

When the time has expired, the instruction is supposed to be pulled from the beginning of the queue (0).

The instruction is the name of a PROC or FN held in a string.

This is to then be EVAL'd by the timer check code.

I have successfully used this method in other languages, and expected it to work under BBC BASIC, however after reading the manual, I now understand that it can only be used with an expression, or a Function.

How would I go about getting this to work without setting the PROCs to FNs, or maybe a much better way of doing this?

The idea is that I can setup the timer to do a number of tasks / 1 task n seconds away from when set.

Due to the nature of the programme, these instructions are not set in stone.

For now, I am setting up a CASE and passing integers, but this feels limiting to me.

Cheers
Michael

[toc] | [next] | [standalone]

#902

On 22 Oct, Michael wrote in message
    <2944631.819.1319307324460.JavaMail.geo-discussion-forums@yqbl36>:
 
> RISC OS 5.17 BBC BASIC version 1.44
> 
> I am attempting to set-up a timer system.
> 
> I have an array / queue which has instructions to call.
> 
> When the time has expired, the instruction is supposed to be pulled from
> the beginning of the queue (0).
> 
> The instruction is the name of a PROC or FN held in a string.
> 
> This is to then be EVAL'd by the timer check code.
> 
> I have successfully used this method in other languages, and expected it
> to work under BBC BASIC, however after reading the manual, I now
> understand that it can only be used with an expression, or a Function.
> 
> How would I go about getting this to work without setting the PROCs to
> FNs, or maybe a much better way of doing this?

You can't (unless you're using BB4W, before the usual suspect jumps in).

The standard trick is to use

  DEF FNmy_routine
  =0

instead of

  DEF PROCmy_routine
  ENDPROC

and then use

  next_function$ = "my_routine"
  result% = EVAL("FN" + next_function$)

Back in the days of the Beeb I've also seen a solution involving
self-modifying code, but that's *not* a recommendation for a modern program.

> The idea is that I can setup the timer to do a number of tasks / 1 task n
> seconds away from when set.
> 
> Due to the nature of the programme, these instructions are not set in
> stone.
> 
> For now, I am setting up a CASE and passing integers, but this feels
> limiting to me.

TBH, that's probably a fairly sane option in BBC BASIC: have a case
statement calling the different PROCs or FNs as required.

This is one of the things that makes other languages look more appealing.

-- 
Steve Fryatt - Leeds, England

http://www.stevefryatt.org.uk/

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

#903

> > I have an array / queue which has instructions to call.
> > 
> > When the time has expired, the instruction is supposed to be pulled from
> > the beginning of the queue (0).
> > 
> > The instruction is the name of a PROC or FN held in a string.
> > 
> > This is to then be EVAL'd by the timer check code.

> You can't (unless you're using BB4W, before the usual suspect jumps in).
> 
> The standard trick is to use
> 
>   DEF FNmy_routine
>   =0
> 
> instead of
> 
>   DEF PROCmy_routine
>   ENDPROC
> 
> and then use
> 
>   next_function$ = "my_routine"
>   result% = EVAL("FN" + next_function$)

I had guessed this was the case :@( 


> Back in the days of the Beeb I've also seen a solution involving
> self-modifying code, but that's *not* a recommendation for a modern program.
> 
> > The idea is that I can setup the timer to do a number of tasks / 1 task n
> > seconds away from when set.
> > 
> > Due to the nature of the programme, these instructions are not set in
> > stone.
> > 
> > For now, I am setting up a CASE and passing integers, but this feels
> > limiting to me.
> 
> TBH, that's probably a fairly sane option in BBC BASIC: have a case
> statement calling the different PROCs or FNs as required.

I had guessed this, but causes my code to be extended and rigid :@(

> 
> This is one of the things that makes other languages look more appealing.

Yep!

Cheers for re-clarifying this! 
:@)

Michael

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

#904

On 22 Oct, Michael wrote in message
    <32504122.1061.1319313269404.JavaMail.geo-discussion-forums@yqhp35>:

> > TBH, that's probably a fairly sane option in BBC BASIC: have a case
> > statement calling the different PROCs or FNs as required.
> 
> I had guessed this, but causes my code to be extended and rigid :@(

Does it?  I'd have thought that

  DEF PROCdispatch(code%)
  CASE code% OF
    WHEN 1 : PROCa
    WHEN 2 : PROCb
    WHEN 3 : PROCc
    OTHERWISE : PROCerror("BadRoutine")
  ENDCASE
  ENDPROC

was fairly concise.  You can't call procedures that don't exist, so you
might just as well add the necessary WHEN clause at the same time as you add
the DEF PROC.  And there's some structured error checking, which is more
than can be said for

  DEF PROCdispatch(code$)
  LOCAL result%
  result% = EVAL("FN" + code$)
  ENDPROC

OK, so the latter could be wrapped in ON ERROR LOCAL, but I think I'd prefer
the CASE ... ENDCASE approach.

Also, I /think/ that parameter passing would become a lot cleaner if you're
using the CASE ... ENDCASE structure, although I've not thought too hard
about that.

-- 
Steve Fryatt - Leeds, England

http://www.stevefryatt.org.uk/

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

#906

<snip>
> > > TBH, that's probably a fairly sane option in BBC BASIC: have a case
> > > statement calling the different PROCs or FNs as required.
> > 
> > I had guessed this, but causes my code to be extended and rigid :@(
> 
> Does it?  I'd have thought that
> 
>   DEF PROCdispatch(code%)
>   CASE code% OF
>     WHEN 1 : PROCa
>     WHEN 2 : PROCb
>     WHEN 3 : PROCc
>     OTHERWISE : PROCerror("BadRoutine")
>   ENDCASE
>   ENDPROC
> 
> was fairly concise.  You can't call procedures that don't exist
<snip>

Ah touché!

, so you
> might just as well add the necessary WHEN clause at the same time as you add
> the DEF PROC.  And there's some structured error checking, which is more
> than can be said for
> 
>   DEF PROCdispatch(code$)
>   LOCAL result%
>   result% = EVAL("FN" + code$)
>   ENDPROC
> 
> OK, so the latter could be wrapped in ON ERROR LOCAL, but I think I'd prefer
> the CASE ... ENDCASE approach.

I think that I have mis-stated what I was aiming for:

Something akin to JavaScript's setTimeout(code,millisec)

so basically I have 5 timers setup, and if I want something to happen in x seconds I simply set it up with the code to be called (PROC Usually)

So, to simply put the time on the screen:

REM Setup Timer
	MyTimer% = FN_Timer_GetFreeTimer
	PROC_Timer_Start(MyTimer%,"PROC_TimeDate_PrintTime",100)
	
	
REM Main Programme Loop
	REPEAT
		PROC_Timer_CheckTimer
	UNTIL Quit%
END

DEF PROC_Timer_Start(Timer%,Procedure$,Timeout%)
	REM Error
		IF Timer% = -1 THEN ERROR 1,"No Free Timers"
    Timers%(Timer%,0) = TIME + Timeout%
	Timers%(Timer%,1) = 1
	Timers$(Timer%) = Procedure$
ENDPROC

DEF PROC_Timer_Stop(Timer%)
	Timers%(Timer%,1) = 0
ENDPROC

DEF PROC_Timer_Renew(Timer%,Timeout%)
	Timers%(Timer%,0) = TIME + Timeout%
ENDPROC

DEF FN_Timer_GetFreeTimer
	LOCAL UnusedTimer%
	UnusedTimer% = -1
	FOR I = 0 TO 5
		IF UnusedTimer% = -1 THEN
			IF Timers%(Timer%,1) = 0 THEN
				UnusedTimer% = I
				Set% = 1
			END IF
		ENDIF
	NEXT I
= UnusedTimer%

DEF PROC_Timer_CheckTimer
	FOR I = 0 TO 5
		IF Timers%(I,1) = 1 THEN
			IF Timers%(I,0) < TIME THEN
				EVAL(Timers$(I))
			ENDIF
		ENDIF
	NEXT I
ENDPROC


Any errors (other than the EVAL) are due to typing under Notepad++ under Windows! :@D

So, I am sure there is a better way of doing this, and I think you may be able to see why case may be wrong here...

> Also, I /think/ that parameter passing would become a lot cleaner if you're
> using the CASE ... ENDCASE structure, although I've not thought too hard
> about that.

 Cheers for the advice so far :@)

Michael

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

#914

In message <mpro.ltj5ao09mmcog01il.news@stevefryatt.org.uk>
          Steve Fryatt <news@stevefryatt.org.uk> wrote:

>  You can't call procedures that don't exist, 

Excuse the peripheral relevance. RiscLua does not have a CASE statement
but you can fake one with

 CASE = \(list_of_procs,defaultproc) => \(code,...) 
        local action = list_of_procs[code]
        if action then
           => action(...)
        else
           => defaultproc(...)
        end end end

which copes nicely with procedures with indeterminate
numbers of parameters and undefined procedures. Thus, for example

 wimp_case = CASE (event_handlers, do_nothing)
 
 repeat
  reason_code = sys ("Wimp_Poll",mask,message_block)
  result = wimp_case (reason_code,message_block, user_parameters)
 until exit(result)

shows how the CASE structure can be lifted out of the polling
loop. Incidentally, the "..." is the Lua syntax for an indeterminate 
number of parameters, not metasyntax.

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

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

#905

stevefryatt wrote:
> Michael wrote:
> > I am attempting to set-up a timer system.
 
"set-up" is a noun. The verb you are looking for is "set up".
 
> > [ OP wants to do something like EVAL("PROC"+name$) ]
> > How would I go about getting this to work without setting the PROCs to
> > FNs, or maybe a much better way of doing this?
> 
> You can't (unless you're using BB4W, before the usual suspect jumps in).
 
or ARM BBC BASIC with BB4W extensions:
http://mdfs.net/bbcbasic/RISCOS/BasPlus.htm
but your application would have to specifically loaded.
 
You'd do something like:
 
    my_routine%=^PROCroutine_to_call
...
    PROC(my_routine%)
 
but as pointed out, a CASE structure will probably make for code
that is easier to read and maintain:
 
    CASE action% OF
      WHEN 1:PROCouch
      WHEN 2:PROCthing
      WHEN 3:PROCfobar
    ENDCASE
 
-- 
J.G.Harston - jgh@mdfs.net - mdfs.net/jgh
/* Real programmers don't use comments. */

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

#907

> > > I am attempting to set-up a timer system.
>  
> "set-up" is a noun. The verb you are looking for is "set up".

My bad!

>  
> > > [ OP wants to do something like EVAL("PROC"+name$) ]
> > > How would I go about getting this to work without setting the PROCs to
> > > FNs, or maybe a much better way of doing this?
> > 
> > You can't (unless you're using BB4W, before the usual suspect jumps in).
>  
> or ARM BBC BASIC with BB4W extensions:
> http://mdfs.net/bbcbasic/RISCOS/BasPlus.htm
> but your application would have to specifically loaded.

Looking into this now :@)

>  
> You'd do something like:
>  
>     my_routine%=^PROCroutine_to_call
> ...
>     PROC(my_routine%)
>  
> but as pointed out, a CASE structure will probably make for code
> that is easier to read and maintain:
>  
>     CASE action% OF
>       WHEN 1:PROCouch
>       WHEN 2:PROCthing
>       WHEN 3:PROCfobar
>     ENDCASE
>  
> -- 
> J.G.Harston - j...@mdfs.net - mdfs.net/jgh
> /* Real programmers don't use comments. */

Cheers! :@)

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

#910

On 23 Oct, Jonathan Graham Harston wrote in message
    <111023195504@arcade.demon.co.uk>:
  
> or ARM BBC BASIC with BB4W extensions:
> http://mdfs.net/bbcbasic/RISCOS/BasPlus.htm but your application would
> have to specifically loaded.
>  
> You'd do something like:
>  
>     my_routine%=^PROCroutine_to_call
> ...
>     PROC(my_routine%)

I hadn't realised that was one of the features that you'd implemented yet.
Thanks!

-- 
Steve Fryatt - Leeds, England

http://www.stevefryatt.org.uk/

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

#921

On 23 Oct, in article <111023195504@arcade.demon.co.uk>,
   Jonathan Graham Harston <jgh@arcade.demon.co.uk> wrote:

> ARM BBC BASIC with BB4W extensions:
> http://mdfs.net/bbcbasic/RISCOS/BasPlus.htm

Nice to hear you are still around. Is BasPlus still being developed? 

I had hopes that your changes would become accepted for inclusion in the
ROOL Basic, and become generally available to normal users.

What are your current plans?

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

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

#917

On 22/10/2011 20:20, Steve Fryatt wrote:
> On 22 Oct, Michael wrote:
>> How would I go about getting this to work without setting the PROCs to
>> FNs, or maybe a much better way of doing this?
> You can't (unless you're using BB4W, before the usual suspect jumps in).

The other usual suspect will step in instead. ;-)

Michael uses Basalt, so he can call a PROC by name:

   PROC(name$)

However, there is a bug in the published version that affects procedures 
with parameters, but it does work OK for simple calls.

> The standard trick is to use
>
>    DEF FNmy_routine
>    =0
>
> instead of
>
>    DEF PROCmy_routine
>    ENDPROC
>
> and then use
>
>    next_function$ = "my_routine"
>    result% = EVAL("FN" + next_function$)

With Basalt the simpler and faster equivalent is:

  void%=FN("my_routine")

This one is OK with parameters.

> Back in the days of the Beeb I've also seen a solution involving
> self-modifying code, but that's *not* a recommendation for a modern program.

Been there, done that, and it is not feasible for ARM BASIC. Basalt has 
to do quite a bit to get named PROCs to work, but it does not modify the 
program. It does named FNs in the machine code equivalent of the BASIC 
above.

>> For now, I am setting up a CASE and passing integers, but this feels
>> limiting to me.
> TBH, that's probably a fairly sane option in BBC BASIC: have a case
> statement calling the different PROCs or FNs as required.

I agree, but for speed I might put in a word for the ON PROC structure:

  ON index% PROCa,PROCb,,PROCd ELSE PROCnothing

Note that index%=3 is ignored and that there is a catch-all PROC, too.

> This is one of the things that makes other languages look more appealing.

Would an event-driven Wimp or Toolbox program in BASIC be appropriate? 
There is some undocumented code even in the published version of Basalt 
that does that for Toolbox programs. ;-)

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

#923

On 22/10/2011 21:20, Steve Fryatt wrote:

> TBH, that's probably a fairly sane option in BBC BASIC: have a case
> statement calling the different PROCs or FNs as required.

Nothing wrong with a CASE structure.


> This is one of the things that makes other languages look more appealing.

You mean stuff like this?

--8<--------
#include <stdio.h>

// functions
void one(int a);
void two(int a);

typedef void (*FunctionCall)(int);
FunctionCall Function[] = {&one, &two};

int main(void)
{
    int f = 0;
    scanf("%i", &f);

    if(i >= sizeof(Function))
       { printf("Bad function call: %i", f); return 1; }

    Function[f](f);
    return 0;
}

void one(int a) { printf("Function one(%i)\n", a); }

void two(int a) { printf("Function two(%i)\n", a); }
--8<--------

While that might seem useful, I've come across code that takes function 
pointers to the point of psychopathic abuse. The only time I've ever 
used function pointers is in atexit() - otherwise, a sane handler with 
switch() dispatch is a lot easier to read, if at the cost of a small 
amount of additional processing.


Best wishes,

Rick.

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

#928

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

> On 22/10/2011 21:20, Steve Fryatt wrote:
> 
> > TBH, that's probably a fairly sane option in BBC BASIC: have a case
> > statement calling the different PROCs or FNs as required.
> 
> Nothing wrong with a CASE structure.
> 
> 
> > This is one of the things that makes other languages look more
> > appealing.
> 
> You mean stuff like this?
> 
> --8<-------- #include <stdio.h>
> 
> // functions void one(int a); void two(int a);
> 
> typedef void (*FunctionCall)(int); FunctionCall Function[] = {&one,
> &two};
> 
> int main(void) {
>     int f = 0;
>     scanf("%i", &f);
> 
>     if(i >= sizeof(Function))
>        { printf("Bad function call: %i", f); return 1; }
> 
>     Function[f](f);
>     return 0;
> }
> 
> void one(int a) { printf("Function one(%i)\n", a); }
> 
> void two(int a) { printf("Function two(%i)\n", a); }
> --8<--------
> 
> While that might seem useful, I've come across code that takes
> function  pointers to the point of psychopathic abuse. The only time
> I've ever  used function pointers is in atexit() - otherwise, a sane
> handler with  switch() dispatch is a lot easier to read, if at the
> cost of a small  amount of additional processing.

I strongly disagree.

The abstraction provided by (say) eventlib enables me to write code
that says "on receipt of this type of event on this object, do this".
All of the handling for the object (say, a dialog box or a menu) can be
hidden away in its own package, and I only need to change that package
when the functionality of the object changes.

The alternative is a huge central switch, which leads to (at least) two
problems:

  1. If I change the functionality of one object, the switch (which
manages _all_ the objects) has to change. This means that I can
inadvertently introduce errors to a completely unconnected object. This
is bad.

  2. Because the package containing the switch has visibility over all
the other objects, any change to one of those objects means that the
switch package needs to be recompiled. This is also bad.

As an example of the badness of 2 - I used to be the principle
specifier of a large discrete event simulation written in Ada 83. The
Mk 1 implementation used a central despatcher very much in line with a
big case statement. By the time the developers had implemented about
thirty of the main sub-components, every time they updated one of the
sub-component specifications, the despatcher had to be recompiled,
which caused other modules to be recompiled, etc, etc. Rebuilding the
system after such a change took about 6 hours (on an AXP - about a day
on a VAX). As the complete system was intended to include approximately
120 sub-components, you may be able to see why we abandoned this
approach. When we re-implemented the despatcher using function
pointers[1], rebuilding the system after compiling one sub-component
took 15-20 minutes.

[1] Which is, of course, impossible in pure Ada 83, as it doesn't
support function pointers - we came up with an OS-specific mechanism.
One of the big changes between Ada 83 and Ada 95 was the introduction
of function pointers, so the people who spec'ed Ada 95 must have
thought they were pretty useful.

-- 
Nick Roberts           tigger @ orpheusinternet.co.uk           

Hanlon's Razor: Never attribute to malice that which
can be adequately explained by stupidity.

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

#929

On 25/10/2011 19:14, Nick Roberts wrote:

> I strongly disagree.

;-)


Having read that, I can see in certain circumstances function pointers 
may be beneficial. In the case of smaller programs, I do wonder if 
standard constructs (IF/ELSE, CASE, etc) wouldn't be perfectly capable. 
Perhaps I'm a little prejudiced thanks to having in the past deal with 
code that used them for pretty much everything possible. There was one 
chunk of code I simply rewrote myself because function pointers in an 
array with both '.' and '->' style indirection with a few asterisks 
thrown in for good measure [*]... t'was a nightmare trying to untangle 
what it thought it was doing.


Best wishes,

Rick.

* - It was a long since abandoned stock control system that ran on an
     old 8086, and when the company that owned it moved to Windows and a
     system under that, they suddenly realised that the old data wasn't
     going to drop into the new setup. Somebody had to get in, figure out
     the mostly undocumented code, with short variable names (I think the
     programmer grew up with GWBASIC and had an orgasm at all of C's
     weirder features, it's the first time I'd seen the comma operator in
     use outside of for constructs), and paste together a working export
     option. Thankfully their original box was such a piece of crap,
     Acorn's *software* emulator was better spec'd, so I spent a lot of
     late nights on that code. And to this day I shiver at the idea of
     function pointers. In fact, pointers in general. Pointers aren't a
     bad idea, but when it looks more like like:
       (void *)ng.df[**i->q.e[4]]++;   [emphasised for effect, just :-) ]
     then you panic. And cry.

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

#930

On 26/10/2011 05:32, Rick Murray wrote:
> Having read that, I can see in certain circumstances function pointers
> may be beneficial.

I find it rather amusing that proponents of a 1960s language (BASIC) are 
arguing against features of a new fangled 1970s language (C), as if the 
last 40 years of language development (from C++ though to Java and C#) 
has never happened. But on RISC OS, that's pretty much the case!

---druck

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

#935

On 26/10/2011 11:51, druck wrote:

> I find it rather amusing that proponents of a 1960s language (BASIC) are
> arguing against features of a new fangled 1970s language (C), as if the
> last 40 years of language development (from C++ though to Java and C#)
> has never happened.

I wonder what C++ offers that can't otherwise be done in C. But then, 
with a background of deconstructing it all to assembly code, I'm perhaps 
not the best person to ask. ;-)


Best wishes,

Rick.

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

#932

In article <2c8fce2752.tigger@bc63.orpheusinternet.co.uk>,
   Nick Roberts <tigger@orpheusinternet.co.uk> wrote:
> I strongly disagree.

Why can't you just use functions, which as has already been pointed out,
will work exactly as you want? The difference between using a PROC or a FN
in this case is purely asthetic.

Ta,

Steve

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

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

#933

In article <52284175a1steve@revi11.plus.com>,
   Ste (news) <steve@revi11.plus.com> wrote:

> in this case is purely asthetic.

or aesthetic as we older folks say - 

or even Æsthetic as even older folk used to say with the correct character
set in operation!

Anaesthesia just sends me to sleep!  Tant pis!

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]

#936

On 26/10/2011 16:36, John Williams (News) wrote:

> or aesthetic as we older folks say -
> or even Æsthetic as even older folk used to say with the correct character
> set in operation!

Or perhaps even æsthetic unless you want to be Germanic with Various 
capital Letters in the Middle of Sentences. ;-)


> Anaesthesia just sends me to sleep!

As does most UK telly output these days.


Best wishes,

Rick.

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

#934

In message <52284175a1steve@revi11.plus.com>
       "Ste (news)" <steve@revi11.plus.com> wrote:

> In article <2c8fce2752.tigger@bc63.orpheusinternet.co.uk>,
>    Nick Roberts <tigger@orpheusinternet.co.uk> wrote:
> > I strongly disagree.
> 
> Why can't you just use functions, which as has already been pointed
> out, will work exactly as you want? The difference between using a
> PROC or a FN in this case is purely asthetic.

Because (in the context in which my post was written) we weren't
discussing BASIC?

-- 
Nick Roberts           tigger @ orpheusinternet.co.uk           

Hanlon's Razor: Never attribute to malice that which
can be adequately explained by stupidity.

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web