[Coco] noob question

[Mathieu Bouchard]

Le 2017-11-08 à 09:50:00, William Astle a écrit :

> On 2017-11-08 09:20 AM, Mathieu Bouchard wrote:
>> I doubt it... but as nearly all cases of using a GUI library, there's an 
>> infinite loop called a "runloop" that watches for incoming events and 
>> distributes them around. The problem with ColorBASIC in this case, is 
>> that there are no function pointers nor anything similar enough to that, 
>> the only thing that vaguely looks like it are ON ERR GOTO, ON BRK GOTO, 
>> and they are not extensible to user-defined events, so you couldn't 
>> write a ColorBASIC lib that takes registrations for keys or mouse and 
>> GOSUB at will. (IIRC, ColorBASIC doesn't support variable line numbers 
>> in ON GOSUB, does it ?)
>> 
>> Other languages might be different. With asm you can easily have some 
>> kind of function pointers and JSR to the contents of a register or RAM 
>> variable.
>
> No, Color Basic doesn't support line numbers in variables. It also turns 
> out that patching it to do so causes a lot of knock on effects.
>
> To do it right, you also need local variables (stack frames) for 
> functions. Color Basic also doesn't have that though you could 
> potentially fake it with some degree of success using an array as a 
> stack and a variable to serve as a stack pointer. But if you're going to 
> do that, you're probably better off going for ASM or another environment.

To do it right, you also need to ditch line numbers so that they never conflict, 
then also allow to use multiple source files at once, and change the rest of the 
language while we're at it. But really, we don't need local variables in order 
to support "true" event-driven programming, it just never has been done this 
way, and it would feel like a hack in ColorBASIC (supposing we could at least 
GOTO variable line numbers), but then, pretty much everything feels like a hack 
in ColorBASIC once you have tasted a modern language.

That said, in unpatched ColorBASIC, it's still possible to do event-based 
programming. Let's say you have a library for that starting at line number 10000 
that you MERGE into your own program (or LOAD the library and SAVE it as another 
name with your app in it). Let's say that library specifies a single callback 
consisting of a single GOSUB at a fixed line-number. Then you define that 
callback in your app whatever way you like, using ON n GOTO, ON n GOSUB, or IF 
n=42 THEN 400 ELSE IF n=53 THEN 500 ELSE ... ; the point being that sorting out 
the types of events would be up to you. Of course there are many things you 
can't do or can't do easily with this model, but hey, it's ColorBASIC, and hey, 
it's event-based programming already (though much unlike any recent example of 
it).


> UI type things are a very good fit for event driven architectures which 
> is why most GUI toolkits use some sort of event system. You are right 
> about the implementation in those toolkits, though. There is always a 
> "main loop" that waits for events to happen and then dispatches them in 
> some manner. Whether that's a non-blocking "process events" call that 
> needs a manual loop or a blocking event loop, there has to be one somewhere.
> It's actually pretty easy to implement such a main loop in ASM once you 
> wrap your head around the necessary concepts. It's also pretty easy in C 
> (and by extension, it should be pretty easy with CMOC assuming it 
> supports function pointers which I haven't checked into).

Now that I think of it, the X11 event API, still in use the Linux world (albeit 
almost always inside higher-level libraries), works in a very basic way. You 
can't register function pointers with it (e.g. per event type and per window or 
per widget), that's a layer that you'd have to implement on your own. Then it 
doesn't come with its own main-loop, you have to write your own (with XNextEvent 
if you're lucky, or big bad hacks if you aren't). IIRC, with some old GUI 
toolkits, you wouldn't have different callbacks per event-type, you typically 
had to use a big switch(event->type), which is basically an ON n GOTO.

Despite all of this, all GUI input to a X11 app went through what were called 
"events" already in 1987 (and in prior versions of X as well, several years 
before). So, it seems like "event-based programming" doesn't really have an 
exact feature set, it's just a way of working that evolved much over the years, 
with much higher expectations now than in the early days (though the so-called 
"modern features" pretty much all already existed in Smalltalk 1980 language, 
AFAIK).

  ______________________________________________________________________
| Mathieu BOUCHARD --- tél: 514.623.3801, 514.383.3801 --- Montréal, QC