Under datatypes, you have currency, but not currencyx. Is that an intentional decision, an omission from the documentation, or a 'not implemented yet'?
CurrencyX
It will be available in PBXA64 from next versions. Most of it is already implemented (Check V8).
I used this to compare the Minimax M3 Model vs. the Deepseek V4-Flash.
And the result was: Minimax failed, Deepseek did it.
Will check what other tasks its good for in the next days.
Today used M3 to prepare implementation of all 108 HLIB-Containers into PBXB64.
This compiler is now mostly bugfree and will get all HLIB Datatypes as native Datatypes.
This means for example:
LOCAL a as LnStkor
Function ABC(byref g as SsArr, byref x as LnHash ...) as LnStk
Local re as LnStk
...
' return multiple results in a LnStk Datatype
FUNCTION=re
END FUNCTION
these are ~108 new native datatypes like Stk, Hash, Que, Tree usw.
If it works it will increase Power siginificantly.
DeepSeek is pretty mean. A modern array has a pointer to data type, count and capacity. When the array is full, typically, the allocation doubles when it needs to add a new value. With a procedure to free excess memory when needed.
DeepSeek built the whole thing from one prompt.
That's not the hardest part for writing a library, magnified for a compiler. The test code is the hardest part and drudgery. The test code needs to be far more complex than the code it's testing. Not only did DeepSeek build the code for the file, but it also built a complete test app, testing all possible edge cases, all from the same prompt.
I asked it to build a test app to test quick sort and binary search, testing speed and making sure everything is in proper order. It built it and gave a computer science analysis of the results.
The first array was a long long. With a very simple prompt, asking it to change the data logic and the procedure prefixes, I kept feeding the .h file and the test app back in, and in a few seconds, I had a different array container.
Then I asked it to build a string array with split and join.
On top of that, all arrays can be stored to/from file as a binary blob.
---
Forget about my hLib code. When the time comes, ask DeepSeek to build it.
---
The whole work is in building a proper prompt. I did use some local models to test the prompt for individual procedures. Slow, but you can watch the thinking process. If it struggled with the prompt, then I killed it and rewrote the prompt.
---
To write a translator, you'll have to spend a lot of time on the prompt. You can put the entire prompt as very detailed comment as to what's supposed to happen, fix it if it's not good enough. When you're done, you have fully documented code, another drudgery. And it serves as a good AI prompt as the code grows.
---
You have to tell DeepSeek what existing procedures to call to accomplish the task. If you build on your code, the more it gets tested and the smaller the results. Otherwise, it may build the entire code without calling any existing procedures.
---
You can start with sections. The absolute biggest thing is you can ask it to build a terminal test app to test all edge cases. It may take a wrong turn from what your design goals are. Just fix the prompt. If a great part of the prompt is in the comments, you're building documentation for future submissions and the end user.
---
Once you get the core component thoroughly tested, should be easier to build up.
Note: On the test apps, I have to tell it to put a getchar(); at the bottom, otherwise it just closes.
Of course your code is in PB and can not be included in a C-based x64 compiler.
But the system and naming like LnArr, SsStk, WsHash or SsTree will be used.
For example
' Return as Tree Object from a function
Function SDF () as WsTree
LOCAL Z as WsTree
Z.AddItem "abcd" ....
FUNCTION=Z
END FUNCTIONI did not test it but this is my idea.
And i think the heap based storage will be used by the implementation like in your code.
QuoteTo write a translator, you'll have to spend a lot of time on the prompt. You can put the entire prompt as very detailed comment as to what's supposed to happen, fix it if it's not good enough. When you're done, you have fully documented code, another drudgery. And it serves as a good AI prompt as the code grows.
My Prompt is (ok a bit simplified): ""Go to ....\HLIB3 folder. We will implement all these conatiners as native datatypes into the compiler ...".
There is a bit more details but this the way to go. The rest is API-Cost and waiting .. testing ..
Here i have used the Minimax M3 Model. Its surprisingly good with this.
However it will use a Ringbuffer foor the Que. Should we accept that?
I have just checked the Implementation.
So the new Datatypes can really be used in FUnctions at any place also as return parameters.
If you want to return 3 Extended Values from a Math functions you can use a
' CuX -> CurrencyX is now implemented.
FUNCTION ABC(BYREF IX as ExArr) as CuXArr
LOCAL Ar as CuXArr
Ar.AddItem IX.GetItem(1)+5.67
Ar.AddItem 5.14159 ...
Ar.AddItem 0.15679 ...
' Return 3 Items in one Strike from a Function
FUNCTION=Ar
END FUNCTION2026-06-12 05_33_52-Greenshot.png
This is the beauty of your datatypes.
Possibly they can also be used in UDT's.
Will need to check that after implementation.
Must also add that we can return UDT's in functions and UDT's can contain dynamic strings ij PBXA64 + PBXB64 Compilers. We did not copy PB-Limitations.
Like you say, it's a little early to focus on containers.
For one thing, they don't need to be a part of the compiler, they can be implemented later as include files. Building them into the compiler is going to make it more complicated.
The simplest way to implement them is as a UDT, thus can be stored in a UDT. The user must call a final procedure to free memory.
If you add doubly linked list, then you also have a very fast stack and a queue. There are faster ways to implement a stack and queue, but for most use, you couldn't tell the difference.
Using a handle to an allocated UDT has advantages at the expense of more complexity and a little slower execution.
Implemented as a COM object, it's just a UDT hosted in an object. Advantage, users don't have to free them. Can't be stored in UDT. At first glance, it is easier to use, but things can get very tricky and complicated. I wouldn't try that again.
My advice is to add them later as UDT include files. A user can put them in an object or use them as allocated pointers if they wish.