FreeBASIC Namespace Project

For other topics related to the FreeBASIC project or its community.
angros47
Posts: 1424
Joined: Jun 21, 2005 19:04

Re: FreeBASIC Namespace Project

Postby angros47 » Jan 09, 2018 15:13

Imortis wrote:Also, the only reason you are asking for this is so you can have a "default" namespace, which kind of defeats the purpose of putting the keywords into namespaces in the first place.


I didn't mean really a "default" namespace, but a namespace "enabled by default", that can be disabled in case someone needs to have the symbols available.

Just from this what is said here, I still don't see what's the problem in dividing fb into 2 branches as stated by sancho3, one with the compatibility, and the other with the reshape.


The reason is that FreeBasic has already 3 sub-languages, adding more of them would make things worse, not better. And branching (or, even worse, forking) the compiler would not be an evolution, would just create a different compiler (since the new compiler would not accept the old code, and the new code would not work any more on the old compiler): to keep the ability to self-compile, the compiler would need some changes, and this would end in creating a new, different language, not an evolution of FreeBasic
Munair
Posts: 828
Joined: Oct 19, 2017 15:00
Location: 't Zand, NL
Contact:

Re: FreeBASIC Namespace Project

Postby Munair » Jan 09, 2018 16:17

There is always the possibility of a migration tool to make the transition to new incompatible concepts easier. Change is inevitable. Trying to hold on to 10+ years old concepts won't benefit the compiler and the language in general. More possibilities and new powerful features should always be considered. Those who do not want change can alsways use the exisiting compiler for several years to come.
angros47
Posts: 1424
Joined: Jun 21, 2005 19:04

Re: FreeBASIC Namespace Project

Postby angros47 » Jan 09, 2018 16:40

Please... C++ is more than 30 years old, and is still retro-compatible. This kind of discussion happened dozens of times, here, and never lead to anything good.
marcov
Posts: 2691
Joined: Jun 16, 2005 9:45
Location: Eindhoven, NL
Contact:

Re: FreeBASIC Namespace Project

Postby marcov » Jan 09, 2018 16:46

angros47 wrote:Please... C++ is more than 30 years old, and is still retro-compatible. This kind of discussion happened dozens of times, here, and never lead to anything good.


But they were *very* minimalistic about what is in the default space, so that is not a good comparison. On the contrary, it is more a reason to continue with the namespace idea :-)
angros47
Posts: 1424
Joined: Jun 21, 2005 19:04

Re: FreeBASIC Namespace Project

Postby angros47 » Jan 09, 2018 17:01

The namespace idea itself is good, but it has not to break retro compatibility. At least, in my opinion.
dbickin
Posts: 39
Joined: Aug 03, 2005 16:40

Re: FreeBASIC Namespace Project

Postby dbickin » Jan 09, 2018 17:35

Can I ask a stupid noob question; while I think I understand what a "namespace" entails, am I right that if we put the basic parts of the language in a namespace, if I wanted to print something, I would either:

Code: Select all

fb.std.print "Hello World"

or

Code: Select all

using fb.std
print "Hello World"


Is that right? or can someone point me to something I can read that can get me up to speed on what is being discussed?

My gut tells me that the first is ugly and should avoided, but the second is not so bad, though I understand that that interferes with things already using namespaces.

So long as a solution is found that allows namespaces, but where I almost never have to type fb.std.print, I think I would be happy.

Mind you I learned Basic back in the gosub line_number days when everything was global, so even variable scoping is something I have to think "hard" about.

David
Imortis
Moderator
Posts: 1605
Joined: Jun 02, 2005 15:10
Location: USA
Contact:

Re: FreeBASIC Namespace Project

Postby Imortis » Jan 09, 2018 17:48

You are correct. A Namespace is just a wrapper around identifiers to separate them from other identifiers.

And Using can be used with multiple namespaces, it seems.
MrSwiss
Posts: 2934
Joined: Jun 02, 2013 9:27
Location: Switzerland

Re: FreeBASIC Namespace Project

Postby MrSwiss » Jan 09, 2018 17:54

angros47 wrote:The reason is that FreeBasic has already 3 sub-languages, adding more of them would make things worse, not better.
My suggestion, taking the whole issue one step further:

Fork the Compiler (32/64 bit) to, let's call it: GepardFB (mean/lean/fast), by:
  • getting rid of 'backwards compatible languages', aka: -lang FB exclusive
    (thus, getting rid of all 'dialect specific' current issues)
  • above allowes then for far quicker fixes to remaining compiler issues (only -lang FB to consider)
  • implementation of the 'namespace' idea
All people requiring the 'deprecated' language(s), can stick to ver. 1.05.0 (and, maintain that themselves!).
Developers ressources, thus greatly concentrated on advancing FB, instead of on: maintaining 'backwards compatibility'!
Last edited by MrSwiss on Jan 09, 2018 18:05, edited 1 time in total.
marcov
Posts: 2691
Joined: Jun 16, 2005 9:45
Location: Eindhoven, NL
Contact:

Re: FreeBASIC Namespace Project

Postby marcov » Jan 09, 2018 18:04

angros47 wrote:The namespace idea itself is good, but it has not to break retro compatibility. At least, in my opinion.


What do you mean with compatability? Compiling the old sources, or compiling the old sources without adding parameters etc ?

Since a simple parameter to add namespaces to the default startup state would fix the first, but not the second.

IMHO the first is reasonable, the second is counterproductive. If you want so much compatibility without thinking, just keep using old versions.

Changing the default (library-) namespace is a kind of library equivalent to dialect switches, and is quite normal. FPC auto-adds certain namespaces (units) to the default (system) namespace, but also has a parameter to add additional ones. And the last namespace added overrides.

That is sometimes very handy to keep code in some old dialect running (chose the nearest dialect mode, and create an unit with addition/overrides for cases where the libraries differ).
Tourist Trap
Posts: 2626
Joined: Jun 02, 2015 16:24

Re: FreeBASIC Namespace Project

Postby Tourist Trap » Jan 09, 2018 18:58

marcov wrote:IMHO the first is reasonable, the second is counterproductive. If you want so much compatibility without thinking, just keep using old versions.

Why not? I mean, would someone be happy if C vanished from earth and left the whole space for C++? It's a little extreme ok, dont take this for anything but an example, but we all like to know that one thing won't change, it's C, and that no fear there, it will be kept maintained and pass the time sticking to a considerable amount of backward compatibility.

What I try to say is that my feeling is that freebasic is by nature a language that has in its ADN a kind of nostalgia, combined with power and modernity in the case of freebasic. It's , I would say, a key feature here, not a side effect.

About namespaces, I will never be against them in principle. I love this feature. My concern is about the fact that the way it works today, this will lead to a kind of shadowing of instructions of fb code that would be working fine without, and won't anymore with (again if I understand well). If this is true, then I'm sure that, my opinion here, I wouldn't like the things to go this way. For the sake of what I think is a real key feature, yet misapreciated maybe (or it s me that is just errent) , I mean compatibility with our code.

Just sharing anyway, I don't really know if multiple simultaneous namespaces couldn't be implemented or whatever workaround compatible with the improvement. Why not (true question) ?
St_W
Posts: 1460
Joined: Feb 11, 2009 14:24
Location: Austria
Contact:

Re: FreeBASIC Namespace Project

Postby St_W » Jan 09, 2018 19:10

I'll just quote myself from 2015 :-)
viewtopic.php?f=17&t=23484&p=207246&hilit=namespace#p207246
St_W wrote:I agree that we should update the FreeBasic language as it still contains quite a lot of legacy stuff. Of course this would break compatibility, so maybe it should be really a new -lang option, although there are already several (which adds complexity to the compiler and may confuse users). For example there are these integrated commands with a custom syntax like LINE. I would also consider moving all fbgfx stuff or better all integrated functionality into an own namespace as these names clutter the global namespace. Of course there should be still some option to import the names into the current namespace with some "using" or "import" clause.

However, changing the FreeBasic language in a way so that no backwards compatibility is given could also be a risk. Take Python 2.7.x vs. Python 3.x as example. There weren't that many changes (for example: print "Hello World" has to be written as print("Hello World") in 3.x) but still many users refused to switch to Python 3.x and kept using 2.7.x. The situation got better over time, but it needed several years. This could especially be a problem for BASIC, as there are many elder people using it, who are often more skeptical regarding changes of well-known things / introducing new things - compared to young people.

I'd just use "fb" and "fbgfx" instead of "fb.std" and "fb.gfx", but otherwise I agree to your proposal. Regarding backwards compatibility I'd either add a new dialect or a compiler parameter (or both) to restore the old behavior somehow.

In practice it will just be necessary to add the lines below, because most code I've seen only uses a single BAS file and #includes the rest (instead of having multiple compilation units linked together, like it is the case for better structured projects like the FreeBasic compiler itself; in that case the lines need to be added to many files, but I don't see a problem with that either as the new code would compile just fine with a current version of FreeBasic).

Code: Select all

using fb
using fbgfx
Because of the little changes I'd enable the new dialect by default and provide a compatibility option to go back to the old behavior (and not the other way round).
marcov
Posts: 2691
Joined: Jun 16, 2005 9:45
Location: Eindhoven, NL
Contact:

Re: FreeBASIC Namespace Project

Postby marcov » Jan 09, 2018 20:02

Tourist Trap wrote:
marcov wrote:IMHO the first is reasonable, the second is counterproductive. If you want so much compatibility without thinking, just keep using old versions.

Why not?


Any project is a balance between conservatism and progressive forces. If you don't want to compromise, branch now, and be conservative forever.

I mean, would someone be happy if C vanished from earth and left the whole space for C++?


Conservatism is fine, but it should not be gratuitous. What do the conservative forces plan to contribute to keep their codebases in FreeBasic working?

It's a little extreme ok, dont take this for anything but an example, but we all like to know that one thing won't change, it's C, and that no fear there, it will be kept maintained and pass the time sticking to a considerable amount of backward compatibility.


IMHO it is a bad example because C and C++ don't come from the same source. It is a doubleplus bad example (excuse my newspeak) because usercommunities spent vast amounts of resources in standardization efforts to ensure a reasonably acceptable upgrade path from e.g. K&R to ISO C, and to keep the procedural subset of C++ compatible to C.

What I try to say is that my feeling is that freebasic is by nature a language that has in its ADN a kind of nostalgia, combined with power and modernity in the case of freebasic. It's , I would say, a key feature here, not a side effect.


You can't freeze a project like that and at the same time talk about its modernity. Unless you are talking about the modernity as it was in the year 2000(or not even that).

About namespaces, I will never be against them in principle. I love this feature. My concern is about the fact that the way it works today, this will lead to a kind of shadowing of instructions of fb code that would be working fine without, and won't anymore with (again if I understand well). If this is true, then I'm sure that, my opinion here, I wouldn't like the things to go this way. For the sake of what I think is a real key feature, yet misapreciated maybe (or it s me that is just errent) , I mean compatibility with our code.


Any new development is a potential risk to compatibility. Intentional or not. If you are that concerned about it, and don't want to invest in it, keep using old versions. They are 100% compatible!

Just sharing anyway, I don't really know if multiple simultaneous namespaces couldn't be implemented or whatever workaround compatible with the improvement. Why not (true question) ?


My point is that starting out disallowing even the smallest incompatibility is not constructive. Compatibility is fine, but it doesn't have to be effortless. And worse, if there are only takers for compatibility (as in users), and no givers (as in contributing users or developers) it is dead in the water.
Last edited by marcov on Jan 09, 2018 21:48, edited 1 time in total.
angros47
Posts: 1424
Joined: Jun 21, 2005 19:04

Re: FreeBASIC Namespace Project

Postby angros47 » Jan 09, 2018 20:04

MrSwiss wrote:Fork the Compiler (32/64 bit) to, let's call it: GepardFB (mean/lean/fast), by:
  • getting rid of 'backwards compatible languages', aka: -lang FB exclusive
    (thus, getting rid of all 'dialect specific' current issues)
  • above allowes then for far quicker fixes to remaining compiler issues (only -lang FB to consider)
  • implementation of the 'namespace' idea
All people requiring the 'deprecated' language(s), can stick to ver. 1.05.0 (and, maintain that themselves!).
Developers ressources, thus greatly concentrated on advancing FB, instead of on: maintaining 'backwards compatibility'!


I hope it is a joke. A fork means dividing the community, and one of the issues of FreeBasic is that the community is already small. Causing a division would be a very bad idea.

marcov wrote:What do you mean with compatability? Compiling the old sources, or compiling the old sources without adding parameters etc ?

Since a simple parameter to add namespaces to the default startup state would fix the first, but not the second.


Indeed I suggested something similar. I am unsure if you are talking about a command to include in the source code, or about a command line switch (or both, if it is implemented like the "LANG" parameter). Anyway, my suggestion is to keep the old behaviour by default, and having to explicitly require the new behaviour for the programs that need it.
Tourist Trap
Posts: 2626
Joined: Jun 02, 2015 16:24

Re: FreeBASIC Namespace Project

Postby Tourist Trap » Jan 09, 2018 20:54

marcov wrote:
You can't freeze a project like that and at the same time talk about its modernity. Unless you are talking about the modernity as it was in the year 2000(or not even that).

I can't do anything, and won't. But just for the fun to show you that you don't get it about what I try to express, I will return you the argument. You can't stop the projects of the users just for the sake of modernity.

Don't take it bad, just a little joke. I know you work at IT stuff so confrontation with simple hobbyists wishes can't lead to an easy convergence of views. However, compatibility still is at my eyes the grail I would try not to throw too fast to garbage here.

It had been stated better by other than me. And once again, I'm not against upgrade (even with some amount of change), I just wanted it at a pace that leaves me adapt and keep most of my habits. As a temporary conclusion from my side, I agree with everyone really so I would vote for a new Lang option that would leave away the interference from the good old stuff, making if possible the change as transparent as it can be made so.

Can one be wrong to wish the best of the 2 worlds :) ?
speedfixer
Posts: 287
Joined: Nov 28, 2012 1:27
Location: California

Re: FreeBASIC Namespace Project

Postby speedfixer » Jan 09, 2018 21:23

First, I have to say I love the intent of the Imortis project.
It will make the total so much more accessible to programmers who ONLY use FB that it will help it live greatly.

Now:

AT THE MOMENT, Imortis is the largest contributor to HIS project, yet still getting more help on actual code than dkl ever received. I could be wrong; I don't think so.

This suggests to me that MANY feel it is a time for change, and this is embraced by many.

Personally, I agree with the *sentiment* of the namespace change. However, one fact is clear everywhere:

the more new keystrokes required, the more likely the failure.

Requiring many mulitple edits to make existing examples of code work will make it all fail, in my opinion.
If every example published must have 'using fb.std' - it begs the question why ANY program has it.

My thought:
A simple switch - top of file or compiler, or both - would be the best answer FOR NOW.

Imortis choice: start with changes - start without changes.

But I don't think the active EXPRESSIVE community would embrace the new compiler without this choice.
Not that many 'busy' FB programmers keep alternate functional copies of FB around except for different OS versions.

Just my opinion.


david

I also very much like the idea of:

trashing compatibilty with -lite and -qb:
1.05 will be here a long time without major changes - that's the way it is TODAY
THAT is what is the 'official' distribution --- until the new version is mature and accepted.

splitting the rt core into its smaller functional parts as a possibility:
I want to write some kick-ass processors without needing to link in so much 'window-dressing' BASIC with it.
FB can be powerful. I like it, I want it. This would make the core scripts so much more complex though.

I still want it to be BASIC:
simple, intuitive, low-count keywords, simple non-cryptic syntax - but with modern functionality added
SIMPLE TO LEARN THE BASICS OF PROGRAMMING
EVERY EXAMPLE DOES NOT NEED POINTERS
EXAMPLES SHOULD HAVE THE **LEAST** COUNT OF KEYWORDS POSSIBLE TO DISPLAY THE FUNCTION

People still look to any BASIC to learn. Don't take that away. More initial setup (always include 'using fb.std' is too much like c, c++) will drive newbies away.

Return to “Community Discussion”

Who is online

Users browsing this forum: No registered users and 2 guests