FreeBASIC Namespace Project

For other topics related to the FreeBASIC project or its community.
BasicCoder2
Posts: 3349
Joined: Jan 01, 2009 7:03

Re: FreeBASIC Namespace Project

Postby BasicCoder2 » Jan 10, 2018 20:23

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: 5755
Joined: Jan 10, 2006 20:30
Location: Scotland

Re: FreeBASIC Namespace Project

Postby dodicat » Jan 10, 2018 20:59

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
Posts: 913
Joined: Jul 25, 2017 17:22
Location: Argentina

Re: FreeBASIC Namespace Project

Postby paul doe » Jan 10, 2018 23:52

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: 1614
Joined: Jun 02, 2005 15:10
Location: USA
Contact:

Re: FreeBASIC Namespace Project

Postby Imortis » Jan 23, 2018 19:48

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: 5755
Joined: Jan 10, 2006 20:30
Location: Scotland

Re: FreeBASIC Namespace Project

Postby dodicat » Jan 23, 2018 20:41

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: 1614
Joined: Jun 02, 2005 15:10
Location: USA
Contact:

Re: FreeBASIC Namespace Project

Postby Imortis » Jan 23, 2018 21:45

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: 1614
Joined: Jun 02, 2005 15:10
Location: USA
Contact:

Re: FreeBASIC Namespace Project

Postby Imortis » Jan 25, 2018 15:32

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: 1445
Joined: Jun 21, 2005 19:04

Re: FreeBASIC Namespace Project

Postby angros47 » Jan 26, 2018 22:19

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: 2750
Joined: Jun 16, 2005 9:45
Location: Eindhoven, NL
Contact:

Re: FreeBASIC Namespace Project

Postby marcov » Jan 26, 2018 22:41

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: 2750
Joined: Jun 16, 2005 9:45
Location: Eindhoven, NL
Contact:

Re: FreeBASIC Namespace Project

Postby marcov » Jan 26, 2018 22:52

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: 1445
Joined: Jun 21, 2005 19:04

Re: FreeBASIC Namespace Project

Postby angros47 » Jan 26, 2018 23:19

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: 326
Joined: Nov 28, 2012 1:27
Location: California

Re: FreeBASIC Namespace Project

Postby speedfixer » Jan 29, 2018 0:26

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: 2869
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: FreeBASIC Namespace Project

Postby coderJeff » Feb 04, 2018 17:51

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: 1614
Joined: Jun 02, 2005 15:10
Location: USA
Contact:

Re: FreeBASIC Namespace Project

Postby Imortis » Feb 04, 2018 18:04

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.

Return to “Community Discussion”

Who is online

Users browsing this forum: No registered users and 4 guests