FreeBASIC Namespace Project

General discussion for topics related to the FreeBASIC project or its community.
BasicCoder2
Posts: 3906
Joined: Jan 01, 2009 7:03
Location: Australia

Re: FreeBASIC Namespace Project

Post by BasicCoder2 »

paul doe wrote:I could never understand, for example, why the 'Defenders of the True QB Faith' think that things like this:

Code: Select all

line( x1, y1 ) - ( x2, y2 ), color, b
are more un-BASIC than this:

Code: Select all

drawLine( x1, y1, x2, y2, color )
No problem. I just use my own functions

Code: Select all

drawLine(x1,y1,x2,y2,penSize,penColor)
drawRect(x1,y1,x2,y2,fgColor,bgColor,fill_flag)
drawEllipse(w,h,rotate,fgColor,bgColor,fill_flag)
and so on ...
I can't change FB but you can replace the funny syntax with the more standard way of doing it while adding extra features at the same time.
dodicat
Posts: 7976
Joined: Jan 10, 2006 20:30
Location: Scotland

Re: FreeBASIC Namespace Project

Post by dodicat »

line captured variadically

Code: Select all


#macro drawline(x1,y1,x2,y2,args...)
line( x1, y1 ) - ( x2, y2 ),args
#endmacro

screen 19

drawline(200,200,500,500,4,bf)
drawline(200,200,500,500,15,b)
drawline(200,200,500,500,0)
drawline(200,100,500,100,7,,&b0000000011110000 )
sleep 
paul doe
Moderator
Posts: 1730
Joined: Jul 25, 2017 17:22
Location: Argentina

Re: FreeBASIC Namespace Project

Post by paul doe »

BasicCoder2 wrote:No problem. I just use my own functions...
dodicat wrote:line captured variadically
Both examples are quite good, but the idea is doing this one level of abstraction lower (at the runtime library level). While dodicat's code stays at the same level, your code, BasicCoder2, goes one level of abstraction higher (think a framework like .NET). This adds overhead, as you can imagine.

The idea of Imortis is simple yet powerful, and has far reaching implications that need to be carefully considered.
Imortis
Moderator
Posts: 1923
Joined: Jun 02, 2005 15:10
Location: USA
Contact:

Re: FreeBASIC Namespace Project

Post by Imortis »

I walked away from this post for a few days to let the ideas settle in for everybody, myself included. My intent here is to do what is best for the language as a whole. It will not be best for me, as I have been using FB for many years and I have a lot of code that would be made non-functional by these changes.
I am not suggesting it because I like it or because it will be convenient for me, or any end user. I am suggesting it because one of the main things keeping new features from being added to the language is "too many keywords".

If we don't want to add new keywords to the global namespace, maybe we can add them to their own namespace and keep everything else as-is, but that introduces even more inconsistencies into the language, and it would be better to have as consistent a syntax as possible.
dodicat
Posts: 7976
Joined: Jan 10, 2006 20:30
Location: Scotland

Re: FreeBASIC Namespace Project

Post by dodicat »

Could you perhaps put your fb run time library functions inside a temporary namespace so they are easier to test.
This way many more members would be able follow your work.
We could create a lib .a from fb compiled .o files.
We could then declare the namespace, declare a function inside and use it.
print rtl.chr(49)
Or would this prove difficult to implement?
Imortis
Moderator
Posts: 1923
Joined: Jun 02, 2005 15:10
Location: USA
Contact:

Re: FreeBASIC Namespace Project

Post by Imortis »

dodicat wrote:Could you perhaps put your fb run time library functions inside a temporary namespace so they are easier to test.
This way many more members would be able follow your work.
We could create a lib .a from fb compiled .o files.
We could then declare the namespace, declare a function inside and use it.
print rtl.chr(49)
Or would this prove difficult to implement?
That is totally possible. Unfortunately because I don't have the whole thing finished yet, it would not work right. Once I have EVERY function ported, adding the namespace so it can be tested as a separate library is a great idea.
Imortis
Moderator
Posts: 1923
Joined: Jun 02, 2005 15:10
Location: USA
Contact:

Re: FreeBASIC Namespace Project

Post by Imortis »

dodicat wrote:Could you perhaps put your fb run time library functions inside a temporary namespace so they are easier to test.
This way many more members would be able follow your work.
We could create a lib .a from fb compiled .o files.
We could then declare the namespace, declare a function inside and use it.
print rtl.chr(49)
Or would this prove difficult to implement?
Upon further reflection, that is not quite as good an idea as I initially thought.

FBC does some magic that would be cumbersome/impossible to duplicate in a standalone library. For Example:
Print is not 1 function. It is not even 3 functions (print, print #, print using). It is actually many different functions (15-20 i think, could be more), each with different parameter types and names based what and how it is used, also:

Code: Select all

Print "Hello World"
Would not work as there is a ton of context that needs to be passed along that could not be easily be handled in a stand-alone library. And using ; to keep from printing the line-end and moving the cursor down would be impossible. There is no way to duplicate that syntax in a library.

Because of all the qb quirks, an awful lot of the RTLIB NEEDS to be passed through the compiler to maintain its usefulness.

Maybe in-order for the RTLIB itself to become more consistent (even with itself in some cases) it would need to be restructured quite a bit and quite a few quirks either standardized (used everywhere) or dropped (used nowhere). This has made me re-consider putting the rtlib in a namespace by default, at least for now. As it stands, it could make things MORE confusing rather than simplifying things, but I do think that other new features could stand to be added in new namespaces so as to keep the global namespace clean.
angros47
Posts: 2321
Joined: Jun 21, 2005 19:04

Re: FreeBASIC Namespace Project

Post by angros47 »

Imortis wrote:FBC does some magic that would be cumbersome/impossible to duplicate in a standalone library. For Example:
Print is not 1 function. It is not even 3 functions (print, print #, print using). It is actually many different functions (15-20 i think, could be more), each with different parameter types and names based what and how it is used

....

Because of all the qb quirks, an awful lot of the RTLIB NEEDS to be passed through the compiler to maintain its usefulness.
Actually, those quirks are what make Basic a simple language, and allow it to work using much less keywords than an equivalent C/C++ code. In C, a library that allows to do the same things as Basic would require many more symbols. Basic reduces the number of reserved symbols by using them more than once: LINE, for example, is both a graphic command, and a modifier for INPUT. GET and PUT are both file I/O and graphic commands. STEP affects both the FOR instruction, and graphic commands.

Maybe in-order for the RTLIB itself to become more consistent (even with itself in some cases) it would need to be restructured quite a bit and quite a few quirks either standardized (used everywhere) or dropped (used nowhere).
Adopting a generic C-style syntax would do the trick, but it would require the language to become a sort of dialect of C.
This has made me re-consider putting the rtlib in a namespace by default, at least for now. As it stands, it could make things MORE confusing rather than simplifying things, but I do think that other new features could stand to be added in new namespaces so as to keep the global namespace clean.
Are you suggesting, perhaps, to put the sound features under a specific namespace?
marcov
Posts: 3454
Joined: Jun 16, 2005 9:45
Location: Netherlands
Contact:

Re: FreeBASIC Namespace Project

Post by marcov »

Imortis wrote:
FBC does some magic that would be cumbersome/impossible to duplicate in a standalone library. For Example:
Print is not 1 function. It is not even 3 functions (print, print #, print using).

Because of all the qb quirks, an awful lot of the RTLIB NEEDS to be passed through the compiler to maintain its usefulness.
In a more advanced stage, you can still mix that. E.g. only enable certain intrinsics/built-ins after a dummy declaration with a special attribute in an header.
Maybe in-order for the RTLIB itself to become more consistent (even with itself in some cases) it would need to be restructured quite a bit and quite a few quirks either standardized (used everywhere) or dropped (used nowhere). This has made me re-consider putting the rtlib in a namespace by default, at least for now. As it stands, it could make things MORE confusing rather than simplifying things, but I do think that other new features could stand to be added in new namespaces so as to keep the global namespace clean.
I think a first step would be to do what you can do to modularize the RTL and the default namespace, and then enable some implicit namespace for the existing language modes so that the result remains transparent to the user.

It doesn't matter than that some things are built-in, and some things are purely a library invention, as long as they appear in the default namespace as the user expects.

Or maybe even better, distribute all functions in the RTLIB that are plain functions into groups. And find some way to combine them into the default namespace (e.g. by including several headers by default, or have a per dialect mode header that include the group headers).

Later you can worry on per dialect enabling/disabling of builtins using headers, or some other ways to enable/disable built-ins per dialect, but that will always require compiler work.
marcov
Posts: 3454
Joined: Jun 16, 2005 9:45
Location: Netherlands
Contact:

Re: FreeBASIC Namespace Project

Post by marcov »

angros47 wrote: Actually, those quirks are what make Basic a simple language, and allow it to work using much less keywords than an equivalent C/C++ code. In C, a library that allows to do the same things as Basic would require many more symbols. Basic reduces the number of reserved symbols by using them more than once: LINE, for example, is both a graphic command, and a modifier for INPUT. GET and PUT are both file I/O and graphic commands. STEP affects both the FOR instruction, and graphic commands.
I think it is simply legacy from an interpreter era where linking is different, and library routines (in the to be interpreted language) less useful, while interpreter buildins call native libraries internally and thus run at native speed.

Graphics and sound were only added in the eighties anyway, BASIC was already 30 years old by then, I think input line is older than line the graphics command. This is very visible in e.g. C=64 basic V2 that has no graphics or sound commands. Only the later (Micro Soft) Basic V4 had them.
angros47
Posts: 2321
Joined: Jun 21, 2005 19:04

Re: FreeBASIC Namespace Project

Post by angros47 »

Most interpreters (MBasic, the commodore Basic... and even BasicA and GWBasic, as far as I know) converted the commands into tokens as soon as the line were written: in that way, the program was stored in memory in compressed form (very important, considering that memory was scarce at the time), and it was easy to interpret. Since often tokens were represented with a single byte, no more than 256 symbols were allowed. But it was very easy to combine different tokens ("LINE" was a token... it could have been followed by a parenthesis, or by the token of "STEP", or by the token of "INPUT", allowing different syntaxes using only two bytes). Of course, those bytes could be used in a jump table, allowing to interpret the program at a decent speed even on slow processors (parsing the whole string each time would have been crippling slow)

BTW, I have used the Commodore Basic: either the V2, and the V7 (used in the Commodore 128). V7 featured graphic commands, but no LINE command: instead, the DRAW command had a similar syntax, and was used both for lines and for points. There was no graphic macro language (but there was a sound macro language, with a PLAY command similar to GWBasic)
speedfixer
Posts: 606
Joined: Nov 28, 2012 1:27
Location: CA, USA moving to WA, USA
Contact:

Re: FreeBASIC Namespace Project

Post by speedfixer »

At some point, if FB is to survive to any distant future, QB has to disappear.

Easiest to prepare for that would be to make everything much more modular. Many more seperated files for parts of 'large' functions.
It will take a lot longer to compile.

The advantage will be a much easier job of trimming the language down to a less-quirky core set of modules and more easily identifiable large module blocks so that core functionality can be maintained.
Then, adding the switches and command-line parameters to choose to NOT load function blocks would be much simpler.

For any of the desires of most people that have contributed to these threads (namepsace, pure runtime) - a more sane and simple package would have more core distrubutables than is true today, but the compiler and linker could more easily produce a smaller unburdened exe. The result will still be a slower total compile job for most people. Less for the power users would be my guess.

Testing would be so much more easy.
coderJeff
Site Admin
Posts: 4313
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: FreeBASIC Namespace Project

Post by coderJeff »

I've been following this topic for a month. Can someone show the code example of where fbc's keywords in the global namespace get in the way of their creativity/productivity?
Imortis
Moderator
Posts: 1923
Joined: Jun 02, 2005 15:10
Location: USA
Contact:

Re: FreeBASIC Namespace Project

Post by Imortis »

coderJeff wrote:I've been following this topic for a month. Can someone show the code example of where fbc's keywords in the global namespace get in the way of their creativity/productivity?
I don't have the problem. But it was mentioned in the community thread, and I have seen it multiple times over the years on the forum. EVERYONE who is against adding new keywords/features to the compiler will eventually say it is because we already have too many keywords cluttering up the namespace and thus should not add any more.
coderJeff
Site Admin
Posts: 4313
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: FreeBASIC Namespace Project

Post by coderJeff »

Imortis wrote:it was mentioned in the community thread, and I have seen it multiple times over the years on the forum. EVERYONE who is against adding new keywords/features to the compiler will eventually say it is because we already have too many keywords cluttering up the namespace and thus should not add any more.
Agreed.

marcov wrote:I think a first step would be to do what you can do to modularize the RTL and the default namespace, and then enable some implicit namespace for the existing language modes so that the result remains transparent to the user.
My thought as well. Key being that result is transparent to the user.

angros47 wrote:Are you suggesting, perhaps, to put the sound features under a specific namespace?
Yes.
Post Reply