Purebasic wishlist from a Powerbasic User

[newtheogott]

As many know, Powerbasic does actually not yet support 64 bit, but Purebasic does.
So having something to do which must be "x64" i reminded my Purebasic Licence which i had since long years time and started over.

From the standpoint of a Powerbasic User, the Editor from Purebasic is a Enlightenment. There are no wishes left, it just looks like the final stage in Editor developement, campared to the actual Powerbasic-Editor. Even if I would include the new Powerbasic-Forms Editor which however must be bough separately (and in Purebasic all is included).

Saying this, away from the IDE, looking at the Compiler, there are some basic differences and shortcomings which I would want to be put on the Purebasic wishlist for future versions.

These are not new libraies with this or that function. Not new 3D gaming stuff. Basic things to improve the system.
Things that i am used to from Powerbasic or would like to have. These are:

1. Why do i need to declare PROCEDURES or use them in order? This looks to me outdated 2009.
The compiler should make a second PASS and collect all this stuff. Especially Global Variables, PROCEDURES, MACROS etc.
I doubt this will be a big deal to implement. If compiling takes a second longer ... no problem.

2. Labels should be possibly Procedure Local. I do not see any sense of having labels with a global scope.
This could easily be implemented, if the compiler (internally) just adds the Procudurename to the Label and maybe a UID it generates dynamically when
registering procedures. This way the Labels would be de-facto LOcal, while internally beeing accessible for the assembler at any point.

3. The same applies to Labels and VAriables inside MACROS. The usability of MACROS could be greatly enahnced if there would be a chance to declare lables and Variables inside the MACRO as "#MACROTEMP". Under the Hood the compiler wilol just count how often the MACRO was called and would add (as long as he's i nthe MACRO) a number to the name. This way MACROS could be called more often then once in a PROCEDURE if they contain such local things.

4. This is more of a Library thing. Purebasic has done a really good Job in supporting x64 Executables now!
The next big Trend with x64 is Multithreading. While there is actually support for several things, the Tranfer of Parameters in and out of Thread is not as easy as it can be. Internally this could be realized with a Global structure and giving the pointer to The calles procedure. For the End user I'd wish a very simple call to get Data in - and out of a "Multithreaded Procedure".

Thats all so far on my wishlist. Keep the good work going!

[srod]

1. Why do i need to declare PROCEDURES or use them in order? This looks to me outdated 2009.
The compiler should make a second PASS and collect all this stuff. Especially Global Variables, PROCEDURES, MACROS etc.
I doubt this will be a big deal to implement. If compiling takes a second longer ... no problem.

PB has always been a single pass compiler. Using declare is no big deal. The source I am working with now is over 50000 lines of code and it compiles within a couple of seconds which is perfect. A multiple pass compiler would impact on that for sure.

[JCV]

I wonder if it will have a big effect on the speed of the PB compiler if that feature is added.
FASM is also a multi pass assembler but its fast.

[freak]

1. Why do i need to declare PROCEDURES or use them in order? This looks to me outdated 2009.
The compiler should make a second PASS and collect all this stuff. Especially Global Variables, PROCEDURES, MACROS etc.
I doubt this will be a big deal to implement. If compiling takes a second longer ... no problem.

Its not that simple. PureBasic has the Defined() compiler function, which allows things like conditionally compiling code based on wether a procedure, constant etc is defined. Here, the order of things becomes very important.

Consider this example. Will C() be included in the compiled code or not ?

Code: Select all

CompilerIf Defined(B, #PB_Procedure)
  Procedure C()
  EndProcedure
CompilerEndIf

CompilerIf Defined(A, #PB_Procedure)
  Procedure B()
  EndProcedure
CompilerEndIf

Procedure A()
EndProcedure

With the current way things are simple:
You only end up with A() because A() and B() are not defined when the respective CompilerIf statements are compiled.

Now we want procedures to be known in the code before them:
1st pass: we find only A()
2nd pass: Defined(A, #PB_Procedure) is now true, which means we add B()
3rd pass: Defined(B, #PB_Procedure) is now true, which means we add C()

As you see, 2 passes are obviously not enough to determine the final "state" of the compiled program. This is what is called a fixpoint iteration. The compiler cannot stop after a predefined number of passes, it has to keep re-evaluating the entire code and compare it with the previous result until it no longer changes (the fixpoint is reached). Now take a large project like the PureBasic IDE with a lot of CompilerIf's inside and you can keep the compiler busy for quite some time.

Besides, if code would be compiled like that it would become very difficult for a human reader to determine when exactly such CompileIf statements become true or not, and that is a bad thing.

[Mistrel]

Why do i need to declare PROCEDURES or use them in order?

There is an easy solution to this problem. Write your own parser. I did it and I've also seen another example someone posted on this forum.

I assign the tool to a hotkey so that every time my procedures change in a file I hit one key to parse all of the code in the current file, format all function declarations, and put it to the clipboard. Then I just paste it at the top of my code.

Coming from other two-pass languages this was very frustrating at first but you will get used to it. It's just second nature now and something I don't even think about.

[gnozal]

There is an easy solution to this problem. Write your own parser...

Note : if you are a jaPBe user, simply check 'Create Declare files' in 'Project options'. jaPBe automatically creates a declare file out of the source code when saving.

[newtheogott]

DECLARES:
-------------
Of course there are sollutions. I know them all because i had to use them before Powerbasic 9.
Now after they changed the compilwr, I canload the include-libraries in any order - believe me its better.
Therefore i suggest this also for Purebasic.

@Freak, you construct things that may be interesting for very spacial cases.
I am suggesting a feature that will make programming easier for everybody.

Making constructions like you did in your example should be possible in another way also, using
Compiler-directives.

Please note that it did never say that i can not live without, or that there is no othr sollution.
We are here in the wishlist. So my wish is to step-by-step make the compiler competitive with what else is out there.
I don't know any other compiler out there left, using declares (while i do know most big compilers).

Let me go a bit into Philosophy here. Away from technic, what a compiler should do is, that it should as intuitive as possible generate what the user wants to get.
This will be a trend in times where the hardware becomes faster and faster.
Its not interesting if a second Pass will need a few seconds more or not. And for those who do not want it, it can be made switched off for example using
#SINGLEPASS.

Question:
Is it annoying to need Declares?
Ask the Purebasic Help File. In the german help file you can read:

Dies ist ärgerlich, da der Compiler dies mit 'Prozedur xxxx nicht gefunden' reklamiert

And "ärgerlich" means "annoying" . So i am not the only person who things this would be fine on the wishlist.

Today its hard to optimize the compiler output more and more because on the next CPU Generation all your opzimizations may be worthless or even contraproductive.
On the other side, the users side, it makes sense to put intelligence into the programm.

The Question is "what did the user want at this place?". If the compielr can fix it and make a working code he should just do that.
Because on the user side side there are not as much changes.

The only trends on that side are that the the average user-Computer Know How and the time a user is willing to use to learn will decrease.

Therefore a second pass, and any step into this direction of making a language system more intuitive will be a step forward for even bigger success of any system.

[blueznl]

To be honest, perhaps the compiler should have an option to declare such a Declare.

Does it bother me? Nope. But I can imagine it does some.

Let's hope 4.5 will bring a 'preparser' chain or option, where we can plug in one or more pre-parsers before code is passed on to the compiler. That would solve it.

I've been thinking about adding such an option to CodeCaddy, but to make it work properly I would have to preprocess all files including all includes, which is a pain in the proverbial but, as I would have to create copies of those files, preprocess them, etc. etc.

I'd rather not. I'd rather have the compiler taking care of that

[freak]

@Freak, you construct things that may be interesting for very spacial cases.
I am suggesting a feature that will make programming easier for everybody.

The compiler has to produce correct output for all correct input, not just the simple cases. I use this kind of construct very often btw. For a large project that runs on multiple platforms (like the IDE), conditional compilation is a must have.

I could give you more examples, but point is that if you have language constructs that depend on the order of things in the source code, removing the rule that things must be known before they are used not only makes the compiler more complex, it also makes programs harder to read/understand for the user.

Let me go a bit into Philosophy here. Away from technic, what a compiler should do is, that it should as intuitive as possible generate what the user wants to get.

I fully agree with you here. But what you are asking for actually does the opposite.

What you ask for is not about intuition or easier learning. The rule "everything has to be known before it is used" is not hard to understand after all. What you ask for is all about convenience/laziness, nothing else.

Now, if you think your suggestion through past your initial goal (to avoid Declare statements) to all aspects of the language, you get to things like the one above where things don't get simpler, they get more complicated. You may not want to use these aspects of the language but that does not change the fact that they are there and rules have to be defined for them. More rules means more learning for the users. And if you have counter-intuitive rules like the one i described above, you will also end up with counter-intuitive programs. And this is exactly what we try to avoid.

Your request is reasonable at its core. But we can't stop there. We have to take the entire language and its features into account.

[newtheogott]

@Freak. I am sure you know what you are talking about.
As I come from another corner of the "programming-galaxy" the chances are that I do not completely follow your ideas on this topic.

Maybe we can get a common position like this:
It would be nice to have, and for those who do not want it, there could be just a switch to turn it off.
#SINGLEPASS

[Trond]

1. Why do i need to declare PROCEDURES or use them in order? This looks to me outdated 2009. Especially Global Variables, PROCEDURES, MACROS etc.
I doubt this will be a big deal to implement.

First of all, I can assure you that this will be a very big deal to implement so that everything works properly.
Apart from that, there are many reasons:
1. Single pass compiling is much faster
2. A lot of core language feature would have to be redesigned
3. Using something before it is created is actually illogical. Fred has put effort into making PureBasic logical.
4. Using variables before they are defined means using variables before they are initialized, which can lead to crashes.

Some examples:

Code: Select all

; Pointer initialization:
Global C
C = *Ptr\l ; This currently gives a compilation error.
; If it was allowed, the program would crash when running.
Global B.l, D.l
Global *Ptr.long = @B
Global *Ptr.long = @D

You could argue that the initialization of *Ptr be put before everything else, but that would be disasterous if the initialization was a procedure call which would depend on the program state or have side effect. Moreover, PureBasic allows repeating the scope keyword. In this case, would C get the value of B or D?

This problem becomes especially prominent with arrays, which are allocated dynamically:

Code: Select all

a = Hooray(30) ; ?!?
Global Dim Hooray(10)
Global Dim Hooray(100)

2. Labels should be possibly Procedure Local.

If I remember correctly, this is planned.

3. The same applies to Labels and VAriables inside MACROS. The usability of MACROS could be greatly enahnced if there would be a chance to declare lables and Variables inside the MACRO as "#MACROTEMP". Under the Hood the compiler wilol just count how often the MACRO was called and would add (as long as he's i nthe MACRO) a number to the name. This way MACROS could be called more often then once in a PROCEDURE if they contain such local things.

It's a good idea.

4. This is more of a Library thing. Purebasic has done a really good Job in supporting x64 Executables now!
The next big Trend with x64 is Multithreading. While there is actually support for several things, the Tranfer of Parameters in and out of Thread is not as easy as it can be. Internally this could be realized with a Global structure and giving the pointer to The calles procedure. For the End user I'd wish a very simple call to get Data in - and out of a "Multithreaded Procedure".

No, it can't be done with a global structure. That's the nature of multithreadedness. The threads can't all use the same global structure.

[Seymour Clufley]

The same applies to Labels and VAriables inside MACROS. The usability of MACROS could be greatly enahnced if there would be a chance to declare lables and Variables inside the MACRO as "#MACROTEMP". Under the Hood the compiler wilol just count how often the MACRO was called and would add (as long as he's i nthe MACRO) a number to the name. This way MACROS could be called more often then once in a PROCEDURE if they contain such local things.

I've just run into a bug that would be solved if the above was implemented in PB. It's taken me ages to find the bug! Anyway, I think what NewTheoGott recommends here is a very good idea.

[swhite]

Hi

Coming from a dynamic language background where it never mattered what order the procedures were in I initially found it a nuisance to remember to put the procedures in order. However as mentioned here the rule is very simple and easy to remember and I have adjusted to it quickly so it is no longer an issues for me and I have only been programming in PB for a few months.

If I were to take feature from Power Basic I would take the ability to "Define Classes"

Simon

[Thorium]

If I were to take feature from Power Basic I would take the ability to "Define Classes"

PureBasic isnt OOP, so no classes.

[PMV]

You can declare all procedures with "declare" ... so there is no need to use the right order if you doesn't want.

MFG PMV