new features

[Stefano Antoniazzi]

This is a list of new possible key features that I think would enlarge the application area of EndBASIC and are especially important in my potential (industrial) scenarios, but not only:

1) a simple client interface to an external TCP server; it should be enough to:

 - open the session (given host/IP and port)

-  send a command (as string) and wait for a server reply (as string)

 - close the session

2) a way to create programs made of multiple source files; it could be an "include" mechanism or a "load without clear" variant; modularity/information hiding is not strictly required (to keep things simple)

3) some (even simple) way to step-debugging source code; maybe something like

   a break statement that leads to REPL mode and a continue command to go on from   the stopped point

Kind regards,

Stefano

[Julio Merino]

Hello Stefano,

On Sat, Jul 20, 2024, at 10:53, Stefano Antoniazzi wrote:

This is a list of new possible key features that I think would enlarge the application area of EndBASIC and are especially important in my potential (industrial) scenarios, but not only:

I'm curious: if you can elaborate, what scenarios are you targeting?

1) a simple client interface to an external TCP server; it should be enough to:

 - open the session (given host/IP and port)

-  send a command (as string) and wait for a server reply (as string)

 - close the session

This one is a matter of adding a new module with various new commands/functions. Something simple should be easy to do, but I'm afraid doing it "nicely" would require adding support for records (complex types) to the language which is not something I had thought about doing just yet.

2) a way to create programs made of multiple source files; it could be an "include" mechanism or a "load without clear" variant; modularity/information hiding is not strictly required (to keep things simple)

The big question on this is how to retrofit this into the REPL. As a language feature, it's not too complicated, but I haven't put any thought into how it would integrate with the interactive editor and the like while keeping the current CLI focus... Any ideas?

3) some (even simple) way to step-debugging source code; maybe something like

   a break statement that leads to REPL mode and a continue command to go on from   the stopped point

Yes, this is something I've been missing. Old BASIC has STOP and CONT for these purposes and something like that should be not too difficult to achieve.

Have you tried QB64 by the way? It is a much more complete BASIC interpreter than EndBASIC is and it already implements all of the above. Not saying that you should move away from EndBASIC, but I'm not sure when (if ever) I'll get to implementing these -- except for debugging, which is definitely something that should happen.

Thanks

[Stefano Antoniazzi]

Hi Julio,

below my further comments.

Thanks and regards,

Stefano

---

Da: Julio Merino <ju...@meroh.net>
Inviato: domenica 21 luglio 2024 16:17
A: endbasic <endb...@googlegroups.com>
Cc: Stefano Antoniazzi <s_ant...@hotmail.com>
Oggetto: Re: new features

 

Hello Stefano,

On Sat, Jul 20, 2024, at 10:53, Stefano Antoniazzi wrote:

This is a list of new possible key features that I think would enlarge the application area of EndBASIC and are especially important in my potential (industrial) scenarios, but not only:

I'm curious: if you can elaborate, what scenarios are you targeting?

STEFANO>>> besides experimenting EB as hobby language, I have one industrial scenario at hand 

that is related to specify control algorithms that needs to be

embedded as firmware on ASICs (to run on proprietary embedded cores). 

1) a simple client interface to an external TCP server; it should be enough to:

 - open the session (given host/IP and port)

-  send a command (as string) and wait for a server reply (as string)

 - close the session

This one is a matter of adding a new module with various new commands/functions. Something simple should be easy to do, but I'm afraid doing it "nicely" would require adding support for records (complex types) to the language which is not something I had thought about doing just yet.

STEFANO>>> a very general solution could maybe involve complex types. However, a simpler solution would already cover most practical use cases.

I proposed a way for EB to act as socket client since it's a flexible approach to extend it. EB could rely on external servers to do things not directly supported.

In my PC<->ASIC scenario, for instance, I'm already using multiple automation clients talking to custom hardware with the mediation of a server.

The simpler solution could be to add just the following EB built-in function (in Rust, inside your codebase):

<reply string> = SEND(<string message>)

This function would send the message string to the socket server and wait for a string reply (like a synchronous remote call).

The specific server to contact (address and port, assuming a TCP socket) could be defined at command line or in some other way.

The session could be automatically open at first SEND call and closed when the EB program terminates or the interpreter exits.

An alternative (or an additional) mechanism would be some kind of FFI. Yabasic, for instance, provides this (based on my suggestion to its author some years ago).

With FFI (but with dynamic linking of custom DLLs to the EB interpreter), one could make any extension in any language to EB, including

the socket interface. It would be totally open and flexible but there's lot more work on your side.

2) a way to create programs made of multiple source files; it could be an "include" mechanism or a "load without clear" variant; modularity/information hiding is not strictly required (to keep things simple)

The big question on this is how to retrofit this into the REPL. As a language feature, it's not too complicated, but I haven't put any thought into how it would integrate with the interactive editor and the like while keeping the current CLI focus... Any ideas?

STEFANO>>> of course we need more thinking about this; your integrated editor would need to select multiple files. Maybe there's a need for

an (optional)  concept of  "project" that is a list of .BAS file making a program (only if needed). The order of files could be also significant and

there's a need to understand what happens to top-level statements in each file.

3) some (even simple) way to step-debugging source code; maybe something like

   a break statement that leads to REPL mode and a continue command to go on from   the stopped point

Yes, this is something I've been missing. Old BASIC has STOP and CONT for these purposes and something like that should be not too difficult to achieve.

STEFANO>>> it will not be full stepping over lines but it would be a very helpful pass towards better debugging

Have you tried QB64 by the way? It is a much more complete BASIC interpreter than EndBASIC is and it already implements all of the above. Not saying that you should move away from EndBASIC, but I'm not sure when (if ever) I'll get to implementing these -- except for debugging, which is definitely something that should happen.

STEFANO>>> QB64 is too slow as development cycle for my taste, due to the hidden C++ compiler. 

Projects that are closer to EB are MMBasic (but no graphics in the Windows version) and Basic256 (but looks as abandonware).

What I like a lot in EndBASIC (and quite unique among BASIC-like solutions but also many other language families):

• 100% strong typing, with true booleans and without numeric promotions
• 32-bit integer type (very suitable for embedded/HW applications)
• interactivity and simple repl/edit/run all-in-one concept
• care for details

Thanks