UDTs, tables, hashes...?

[Anonymous]

Hi all (and especially Markus),

I've recently come across X11, and it seems a great BASIC dialect -- both powerful and useful, and invoking memories of the good old days of GfA-BASIC on the Atari.

But one thing I'm missing are UDTs (User-defined data types) or tables (ie, arrays where the indices are strings), and any other more complex data types beyond the elementary ones.

Am I just too dumb to find information about such beasts, or are they really not implemented? (I know, GfA-BASIC didn't support them either.) Are there workarounds or equivalent mechanisms? Or is there a chance to get them implemented in a future release (nudge nudge wink wink)?

Cheers,

Elmar

[Markus Hoffmann]

Hi Elmar,

no, it is currently not planned to extend the language in that direction.
But if you need to use structs, you can pack values together into a string (with MKI$() etc.).

Array indicies with strings, Hm.... Maybe in future, but if one needs a database mechanism, I always recommend mysql. This can be accessed via X11-Basic and the sqlite3 binary.

Sorry.
But: Do you have a suggestion for the syntax of such an implementation?

[Anonymous]

Hi Markus,

Packing struct elements into a string -- I had thought about that, but of course that quickly escalates when you want to have arrays within a string, or nested structures.

String indices I don't see so much as a thing of database access, but rather for key-value pairs:

first_name$("smith")= "john"

seems to me to be a natural application. And from there one could go on to full UDTs.

As for the syntax, I fancy something similar to Lua:

With

x$= "smith"

all three following expressions would point to the same element:

first_name$.smith
first_name$("smith")
first_name$(x$)

I think it's implemented that way in smallBASIC (not the Microsoft one).

Maybe internally all members of the UDT could be stored in a string (since strings are already used in so many ways in X11/GfA-BASIC and cause no trouble in dynamic allocation), maybe in JSON notation: https://en.wikipedia.org/wiki/JSON (I think it's done that way in smallBASIC, but don't recall precisely.) So, with a C-library to write/extract elements in JSON format, you'd already almost be there with the implementation, once you allow for string indices in arrays. ;-)

(Even more dimly, I think I remember sdlBASIC (and gawk?) implemented the struct as a "flat" array structure. In other words, if you had a hierarchical structure with several levels, the interpreter would simply form a compound string from the indices of the individual levels. To wit
member$.children.first
would internally be translated to
member$("children.first")
But I think this made it difficult to access all sub-elements in one sweep, ie if you wanted to copy all children, then
member$(2).children= member$(1).children
wouldn't work out of the box.
I may be mistaken here though.)

I reckon these dynamically created UDTs (not really "types" in the sense of the word) make programming much easier and more powerful -- I'd be happy if you found the time to look into it. ;-)

Cheers,

Elmar

(P.S. -- I also think I used to have an account on sourceforge... must find access data...)

[Markus Hoffmann]

Hi Elmar,
Ok, maybe we can find a way to represent everything in Strings. At the moment this already works als for arrays (MKA$() CVA()) So all the memory allocation stuff is there. Just the syntay would be a major problem, because the parser and compiler etc. needed to be changed (a lot). As a first step, I would like to implement it "sort of" in native X11-basic functions, which is maybe slow, but would not need add-ons to the syntax.

Like
t$=@store_value("Tag","value")
val$=@get_value(t$,"Tag")

or so...

[Anonymous]

I had thought about writing a few functions for that, as a kind of "proof of concept."

The problem is, it's probably not only going to be slow, but cumbersome -- compare the approximate Lua version

villain.first_name$= anyperson.first_name$

with what it'd look like with "native" X11:

@set_json(villain, "first_name$", @get_json(anyperson, "first_name$"))

That's an awful lot of writing, and will be unwieldy for programmers.

And BTW if you decide to implement such a key/value scheme, the for command would need to be extended to something like foreach, because the program can't know ahead of time which childnodes the UDT is going to have:

jack.children.1.name$= "Jill"
jack.children.1.age= 16
...
print "This are Jack's children:"
foreach i in jack.children
    print i.name$, i.age
next i

I expect this could be difficult to implement, too.

But if I find the time, I might try my hands at a "native" version, just to see if it's wokable.

Cheers,

Elmar

[Markus Hoffmann]

Well, a well performing implementation would be very(!) difficult. All other implementation would slow down X11-Basic a lot, thats why I hesitate. In my opinion the usefullness of these data types is some how limited and more a matter of convinience. If your project really needs this, maybe python would be a better language.

[Anonymous]

What if you implemented a new variable type for the hashes and UDTs, with a separate suffix like "§" or such?

Wouldn't that make it possible to access "old" variables" in the regular way without slowing them down? Naturally UDTs will be processed more slowly in the new code to be written (by you), but in that case the user could chose between fast simple variables and slower more convenient ones. (I don't know how modular your codesbase for X11 is and how difficult it would be to introduce a separate channel for UDTs, so I may be off by a mile...)

IMHO UDTs open up completely new possibilities for programming and come in very handy in all but the smallest projects. I'd really love to see them in X11!

Cheers,

Elmar

[Anonymous]

I've been using binary search trees and full prefix tries for key/value lookup, stored in arrays extended by 10-25% or so as needed. Re-DIMing the arrays every time a new node needs to be added gets too slow too quickly. Since keys, left/right pointers, balancing data, and values may be of different data types, multiple arrays are needed for the binary tree data structure, as well as a separate count of active nodes. Alternatively, if deleting keys is to be allowed, add the new nodes to the free list immediately upon extending the arrays and the need to maintain a count goes away, at the cost of needing head/tail pointers for the free list and a head pointer for the tree since the root could be deleted. The procedure for a trie is similar.

[Yet Another Troll]

Since X11 BASIC was inspired by GFA in the first place, could going back to the original well and doubling down on that be the way forward? A quick search indicates GFA BASIC 3.x did eventually have UDT support of some sort, but documentation seems difficult to find.

[Markus Hoffmann]

No, I do not think so. Please be aware that the ATARI-ST version (which X11-Baisic want to be similar with) is different from the WINDOWS version (which was not at all pupular).