Author Topic: JadeLib  (Read 1132 times)

Offline Mike Lobanovsky

  • ON-HOLD
  • BASIC Developer
  • Posts: 261
Re: JadeLib
« Reply #30 on: January 08, 2019, 05:52:46 PM »
If the library supports anything that's close to the notion of BASIC "fixed length strings" then comparing the string lengths only isn't sufficient to make John's evaluation fool proof. An empty 3 byte long fixed length string is going to fail the TRUE/FALSE test.

Under similar conditions, the C-language strstr() equivalent returns a NULL pointer that evaluates to FALSE in Boolean logic (that's as far as "other languages" go...)
Mike
____________________________________________________________________
(3.6GHz Intel Core i5, 16GB RAM / nVidia GTX 1060Ti , 6GB VRAM / x64 Win7 Ult.)

Offline AIR

  • Moderator
  • Posts: 534
Re: JadeLib
« Reply #31 on: January 08, 2019, 07:17:03 PM »
The library uses std::string, which isn't fixed by default.

Mike, can you code me an example of what you mean as far as a "empty 3 byte long fixed length string"?  On the surface, it sound pretty esoteric and outside the norm.  Thanks.
« Last Edit: January 08, 2019, 07:23:41 PM by AIR »

Offline jack

  • Contributor
  • Posts: 7
Re: JadeLib
« Reply #32 on: January 09, 2019, 03:57:35 AM »
AIR, I must disagree with your design
Code: [Select]
#include "../include/jade.hpp"


MAIN
  STRING mystring = "This is a string.";
  if ( INSTR(mystring,"not")) THEN
PRINT ("yes, substring found");
PRINT (STR$(INSTR(mystring,"not")));
  END
  if ( INSTR(mystring,"is")) THEN
PRINT ("yes, substring found");
PRINT (STR$(INSTR(mystring,"is")));
  END
  if ( 0 ) THEN
PRINT ("no substring found");
PRINT (STR$(INSTR(mystring,"no")));
  END
  PRINT ();

ENDMAIN
obviously the last IF clause is not going to be executed, it's just for illustration of what the first clause should be
« Last Edit: January 09, 2019, 04:01:05 AM by jack »

Offline Mike Lobanovsky

  • ON-HOLD
  • BASIC Developer
  • Posts: 261
Re: JadeLib
« Reply #33 on: January 09, 2019, 05:16:35 AM »
Hi Armando,

A BASIC "fixed length" string is what you'd normally call a "char" or "byte buffer" in "other languages". It's a contiguous chunk (in fact, a one-dimensional array) of bytes allocated in "unmanaged" memory via malloc() or its equivalent outside the scope of C++ std::string. Depending on the platform bitness and Unicode awareness, BASIC would regard such a buffer as a pre-allocated string of CHARs or WCHARs pre-filled with zeros, and would include all operations with the buffer in the category of string functions. Further, depending on the completeness and compliance of its design and implementation, a particular BASIC dialect may also include utility functions to convert (cast) the buffer to other composite data types such as CHAR/WCHAR arrays, UDTs (structures), etc. to enable non-string functions to operate on the buffer natively as well. The advantage of "fixed length" strings over "ordinary" strings preallocated dynamically via the STR()/STRING() allocation functions is that the former normally accept CHR(0) as a valid filler character.

For speed reasons many BASIC dialects, especially interpretative ones, would not at all times rely on literal comparison of string bytes (in fact, CHARs or WCHARs) with zero or each other alone when determining the string lengths or comparing them for (in)equality. A BASIC var structure would normally include a dedicated field to store the string length as set forth/determined at the moment of its creation or assignment. A "fixed length" string would have the buffer capacity (in CHARs or WCHARs) stored precisely in this field of its var structure regardless of the actual CHAR/WCHAR values (possibly zeros) written in the string by allocation, initially, or assignment, thereafter.

Thus, again depending on a particular BASIC dialect implementation, DIM buffer AS STRING * 128: PRINT LEN(buffer) may very well yield 128 regardless of buffer having been filled with zeros initially at allocation time thus being of zero string length as ASCIIZ strings go. When comparing such buffers with "ordinary" strings for whatever purpose, measures should be taken transparently or explicitly by the language developer or the user to resolve possible data type ambiguity (e.g. dynamic string vs. fixed length string) and avoid related pitfalls as in John's example.

Examples of fixed length strings:

-- Visual Basic:        DIM buffer AS STRING  * 128            (128 zero bytes/CHARs)
-- ANSI FreeBASIC:      DIM buffer AS STRING  * 128            (ditto)
-- ANSI PowerBASIC:     DIM buffer AS STRING  * 128            (ditto)
-- Unicode FreeBASIC:   DIM buffer AS WSTRING * 128            (256 zero bytes/128 WCHARs)
-- Unicode PowerBASIC:  DIM buffer AS WSTRING * 128            (ditto)

etc.

I see nothing esoteric in this paradigm. And that's what a BASIC-er would rely upon from their experience, faced with a necessity or challenge to write some BASIC-like code for a language translator program or library. BASIC has no official standard these days and tradition is what we have to rely heavily instead in order to keep on using our favorite "toy" language.

Hopefully this helps to make Jade more predictable and BASIC compliant regardless of the notorious semicolon line endings. :)
« Last Edit: January 09, 2019, 05:20:40 AM by Mike Lobanovsky »
Mike
____________________________________________________________________
(3.6GHz Intel Core i5, 16GB RAM / nVidia GTX 1060Ti , 6GB VRAM / x64 Win7 Ult.)

Offline AIR

  • Moderator
  • Posts: 534
Re: JadeLib
« Reply #34 on: January 09, 2019, 08:39:53 AM »
AIR, I must disagree with your design
Code: [Select]
#
  STRING mystring = "This is a string.";
  if ( INSTR(mystring,"not")) THEN
PRINT ("yes, substring found");
PRINT (STR$(INSTR(mystring,"not")));
  END



Ah, NOW I see!  Thank You, Jack!

AIR.

Offline AIR

  • Moderator
  • Posts: 534
Re: JadeLib
« Reply #35 on: January 09, 2019, 09:55:15 AM »
Mike,

Thanks for the explanation.

I don't think this is applicable to std::string, though, which I think you alluded to towards the beginning of your post.

Since std::string doesn't rely on a terminating '\0' and also tracks it's size internally and will dynamically resize when needed I don't think the scenario you've put forth would be an issue.  I may be incorrect; if so please let me know.

The string functions I've thrown together don't take char* as parameters, so they shouldn't be susceptible to the scenario you've described.

Note to all:  There is no BASIC parser with Jade.  It's more of a "snake-oil salesman" approach, in that it's a thin veneer of sorts over CPP.  So, some things may not work as you may be accustomed to with a "proper" BASIC.  When that happens, you need to think more along the lines of how CPP would do something vs BASIC.

For example, Jack's INSTR example would have worked by checking if the return value was zero or greater.  I've addressed this in the latest update so that it works as BASIC-ers expect (1 based vs 0 based indexing - MID$ too) but FWIW it bugs me that I even had to do this, simple as it was to implement.

At any rate, please update and rebuild, and please continue finding areas that need looking at!!

Thanks,

AIR.

Offline Mike Lobanovsky

  • ON-HOLD
  • BASIC Developer
  • Posts: 261
Re: JadeLib
« Reply #36 on: January 09, 2019, 11:05:19 AM »
Note to all:  There is no BASIC parser with Jade.  It's more of a "snake-oil salesman" approach, in that it's a thin veneer of sorts over CPP.  So, some things may not work as you may be accustomed to with a "proper" BASIC.

I think this note is worth inscribing at the very top of git blurb. It states fairly enough that, unlike BCX or MBC or BC9, Jade is NEITHER BASIC NOR CPP and not even a subset of either of them.

Quote
... you need to think more along the lines of how CPP would do something vs BASIC.

If one knew exactly how CPP would work under particular circumstances, why would one ever need a translator from a non-compliant (i.e. heavily RTFM'ed) and relatively shallow BASIC-like syntax to the incongruously richer C/CPP paradigm in the first place?

However what I'm saying is in no way meant as mockery at your pet project. Have fun! FWIW it may be just a first step to yet another full-fledged BASIC-to-CPP translator on the market. :)
« Last Edit: January 09, 2019, 12:22:18 PM by Mike Lobanovsky »
Mike
____________________________________________________________________
(3.6GHz Intel Core i5, 16GB RAM / nVidia GTX 1060Ti , 6GB VRAM / x64 Win7 Ult.)

Offline John

  • Forum Support / SB Dev
  • Posts: 2413
    • ScriptBasic Open Source Project
Re: JadeLib
« Reply #37 on: January 09, 2019, 11:08:22 AM »
String support for C BASIC has been the primary hold up moving forward with it. My goal with C BASIC is to make building SB extension modules easier. It's not like JADE providing a C helper platform for BASIC programmers.

I plan on using SB's existing string engine / memory manager but making it easier to use.

« Last Edit: January 09, 2019, 11:12:33 AM by John »

Offline AIR

  • Moderator
  • Posts: 534
Re: JadeLib
« Reply #38 on: January 09, 2019, 11:50:20 AM »

Quote
... you need to think more along the lines of how CPP would do something vs BASIC.

If one new exactly how CPP would work under particular circumstances, why would one ever need a translator from a non-compliant (i.e. heavily RTFM'ed) and relatively shallow BASIC-like syntax to the incongruously richer C/CPP paradigm in the first place?

What would make the most sense for someone coming from a BASIC background?

Code: C++
  1. PRINT(LEFT$(mystring,4));
  2. std::cout << std::string(mystring,0,4) << std::endl;
  3. std::cout << mystring.substr(0,4) << std::endl;

All I'm doing is trying to make it more familiar.  And BTW, Jade IS CPP!!  It's just using defines and a library to somewhat mask things.  It's not translating a thing.

"BASIC-like" does NOT suggest compliance.  Since there is no "official standard", "compliance" is ultimately a subjective thing.  And that's not my goal, anyway.

In the end, what matters is if a given implementation allows you to produce the desired result with the least friction.  Admittedly, Jade has some friction, but that's what happens when you try transitioning from one implementation to another.  Note the non-use of the word "language" here.

Quote
However what I'm saying is in no way meant as mockery at your pet project. Have fun! FWIW it may be just a first step to yet another full-fledged BASIC-to-CPP translator on the market. :)

Most of the translators I've seen only do BASIC-to-C, making it a challenge to interface with CPP Libraries at times.  Even those that allow compiling as CPP usually throw warnings regarding some of the string functions.

Jade actually started as a re-write of MBC, I just thought I'd share what I've come up with towards that end.  Doesn't mean that you have to like or approve of the approach I've taken, you always have a choice!!  ;D

AIR.

Offline Mike Lobanovsky

  • ON-HOLD
  • BASIC Developer
  • Posts: 261
Re: JadeLib
« Reply #39 on: January 09, 2019, 12:47:53 PM »
What would make the most sense for someone coming from a BASIC background?

Code: C++
  1. PRINT(LEFT$(mystring,4));
  2. std::cout << std::string(mystring,0,4) << std::endl;
  3. std::cout << mystring.substr(0,4) << std::endl;

For someone that's made it into the 21st century together with mature BASICs (you know, pointers and OOP and COM and stuff) rather than died together with Dartmouth and Kemeny in mid-fifties of the last century, both notations are equally understandable if a little too inhuman for a BASIC-er. :)

Quote
"BASIC-like" does NOT suggest compliance.  Since there is no "official standard", "compliance" is ultimately a subjective thing.  And that's not my goal, anyway.

You know, my people say: "One can't possibly have all the women in the world. Still that's something worth striving for". Sounds a little chauvinistic yet true enough from my standpoint,  Freud-wise. ;)

Quote
In the end, what matters is if a given implementation allows you to produce the desired result with the least friction.

That's correct in most cases provided one knows exactly the limitations, incompatibilities and how to avoid them. Some learning curve is unavoidable even for such a relatively straight-forward implementation as Jade.

Quote
Jade actually started as a re-write of MBC, I just thought I'd share what I've come up with towards that end.

And we're thankful for that. :)
Mike
____________________________________________________________________
(3.6GHz Intel Core i5, 16GB RAM / nVidia GTX 1060Ti , 6GB VRAM / x64 Win7 Ult.)

Offline AIR

  • Moderator
  • Posts: 534
Re: JadeLib
« Reply #40 on: January 12, 2019, 08:37:31 PM »
Commit on 01/12/2019: [master 8db3035] Added BIN$, HEX$, and OCT$ functions

Code: C++
  1. #include <jade.hpp>
  2.  
  3. MAIN
  4.     VAR x = 131917119186620000;
  5.  
  6.     PRINT( x, " = ", HEX$(x));
  7.     PRINT( x, " = ", OCT$(x));
  8.     PRINT( x, " = ", BIN$(x));
  9. END
  10.  

$ ./test_dec_conv
131917119186620000 = 0x1d4a9ebc4e94e60
131917119186620000 = 07245236570472247140
131917119186620000 = 0000000111010100101010011110101111000100111010010100111001100000


AIR.

Offline John

  • Forum Support / SB Dev
  • Posts: 2413
    • ScriptBasic Open Source Project
Re: JadeLib
« Reply #41 on: January 12, 2019, 09:24:18 PM »
Looks great!

What did you come up with about the string starting reference?

Offline AIR

  • Moderator
  • Posts: 534
Re: JadeLib
« Reply #42 on: January 12, 2019, 10:13:42 PM »
I made the concession for INSTR and MID, but I'm not doing that across the board...

Offline John

  • Forum Support / SB Dev
  • Posts: 2413
    • ScriptBasic Open Source Project
Re: JadeLib
« Reply #43 on: January 12, 2019, 10:29:02 PM »
That's fair. We all must keep in mind that JADE isn't a language or a translator. It's a pre-processor include and pre-built function helper library to make C++ resemble BASIC.

Offline Mike Lobanovsky

  • ON-HOLD
  • BASIC Developer
  • Posts: 261
Re: JadeLib
« Reply #44 on: January 13, 2019, 10:25:54 AM »
My friend Patrice Terrier does the same with his CPP code, and with mine too when I submit my patches.

My eyes bleed. ;D
Mike
____________________________________________________________________
(3.6GHz Intel Core i5, 16GB RAM / nVidia GTX 1060Ti , 6GB VRAM / x64 Win7 Ult.)