PluriBASIC 6.0 progress

[Brian Alvarez]

I was aproached regarding the status of PluriBASIC 5.0 and PluriBASIC 6.0. I thought i should as well post a reply here as a
precedent of what i am doing.

PluriBASIC 6.0 is a jewel. I will be able to use the binaries of PluriBASIC 5.0 to compile Android applications. In fact it already
works fine and much faster (Around 100 times faster for code generation!) which will translate into more speedy development.

However, at the moment i am not focusing on fixing the reported issues in version 5.0. There are not many, and most of the issues
are related to existing features not working on newer versions of the Android OS (issues that obviously where not there when
PluriBASIC 5,0 was released).

Please be patient to me, (hopefully) i will get there and you will be able to enjoy faster compilations compatible with newer Operating systems.

If i focus on fixing the issues on version 5.0 (issues that are mostly fixed in version 6.0), it will take longer to get version 6.0 released.

I dont know how many here are following the development of PluriBASIC 6.0, but i can tell you... it's a hit!.I hope there are no
problems for me releasing it.I already have some (unpaid) preorders (i dont want to charge anything yet), but there is still no release
date. I cant tell much about it but maybe you already know what it does.

Anyway, please be patient and stay tuned!

[Chris Boss]

Brian,

I have a new project which may interest you for PluriBasic 6.0:

Language independent Visual Designer/Code Generator.

By using the EZGUI 5.0 Pro visual designer as the basis for the project, the idea is to make the designer language independent by using a Template engine which would read external templates for different languages. This would be accomplished via plugins, which would be DLL's written in Powerbasic (or possibly other languages). The Designer would load in a plugin, which would be polled for info about the controls it supports. When it is time to generate code, the designer would call the plugin with info about the project and all its forms, sending each form one by one along with control info and the plugin would return source code for the specific language.

If I can accomplish what I plan, it might make a good addon for PluriBasic for visual design of forms.

Send me an email, if you want more info.

[Brian Alvarez]

Hello Chris, i dont know if i am understanding correctly, but that is somewhat PluriBASIC does.

However, compiling applications (no matter what platform) is not just a matter of converting code. Sometimes
external files must be created, like xml forms, manifests, resources, classes, and a long list of tasks that makes
conversion a challenge.

In the other hand (not trying to burst your bubble), I think language templates is too good to be true... however, go ahead,
maybe you will surprise me. You can start doing it for PowerBASIC, which is far more mature than PluriBASIC.
If it works for PowerBASIC, i might work for PluriBASIC.

[Brian Alvarez]

withdrawn.

[Rodney Hicks]

My .2 cents worth about this:

However, compiling applications (no matter what platform) is not just a matter of converting code. Sometimes
external files must be created, like xml forms, manifests, resources, classes, and a long list of tasks that makes
conversion a challenge.

In the other hand (not trying to burst your bubble), I think language templates is too good to be true... however, go ahead,
maybe you will surprise me. You can start doing it for PowerBASIC, which is far more mature than PluriBASIC.
If it works for PowerBASIC, i might work for PluriBASIC.

While it may seem an impossible dream, all of this is possible, and indeed inevitable. There already exists the scheme for a universal language, call it machine code, or whatever you will. It is the root of all computer technology. Adapting all other programming languages to it is the compiler writer's task, whatever programming language invoked. Then too, one must adapt all the native spoken/written languages to the mix.

It is an immense project, that can only become viable in much smaller sections at a time. Call it a bit at a time, for puns sake.

I think that the two of you have a good concepts, as both of you are approaching adaptability to other systems/languages which is on of the required features.

"...language templates is too good to be true..." may be true, but only for now. There are more and more software language translators as time goes by and what can be done for the spoken languages can be done for programming languages.

I have been looking into some of these requirements for some time, even though only two individuals from this forum knew that I had my eye on a different way of programming, and one of them has passed on.

Consolidation of the different aspects has to start some where, and I think that the PowerBASIC language can accommodate the steps along the way.

Keep up the good work, both of you!

[Kerry Farmer]

So guys......................

Not that I think I understand what you are saying...

But I would like to understand please

A compiler has three main steps

1 You write code in semi-human language - or at least in human coding methods
2 An editor interprets the code
3 The interpreted code than gets converted into machine code

I imagine that step two might have several substeps

Obviously you can have step 1 written in many many different computer programming languages - from Fortran to Basic to C to whatever

Step 2 then interprets those codes into what? - a semicompiled computer language at a high level

Step 3 then takes that semicompiled language and converts it into machine code.

There is no reason why step 3 cannot have more than one output - Intel based machine code or Android or what ever.

Those of us who code in machine code leave out the first two steps (yes I used to but no more! And it was not Intel code anyway)

Those of us who used to code in human language type coding which then was compiled into machine code on a one to one basis - or nearly on a one to one basis, could say that they were doing steps two and three (and yes, I could even do that but it was probably before you were born)

So tell me what we are talking about here please?

Step two could be universal - could it not? You would need some conventions and standards. You might need to add some functions as languages develop - but I am not sure about that.

Step three could be limited into whatever machine code systems that we have - what do we have beyond Intel and Android anyway?

I seem to remember that a computer only does very few things:

First of all it interprets instructions sequentially.

Then it:

• moves data from one spot to another
• adds numbers to each other
• subtracts numbers from each other
• displays or exports data onto different devices
• accepts data from different devices
• breaks the sequential processing based on certain conditions - bigger, smaller, equal fields (are there any other conditions?)
• exits

Is there any other function?

Enlighten me

[Brian Alvarez]

Hello Rodny and Kerry.

Kerry, it is not that simple, for example, "moving data from one spot to another" It is not just a matter of moving data,
it is a matter of organizing it exactly right. Even a missaligned byte could ruin the product or give wrong execution flow
resulting in lost or corruption of data.

[Kerry Farmer]

Hello Rodny and Kerry.

Kerry, it is not that simple, for example, "moving data from one spot to another" It is not just a matter of moving data,
it is a matter of organizing it exactly right. Even a missaligned byte could ruin the product or give wrong execution flow
resulting in lost or corruption of data.

Of course it must get it right - and in the right format. A misaligned bit can cause havoc!!

But do you agree with the overall thrust of the point? Are there any other steps we should add?

So my proposal is that:

Step one can be any 'human' oriented code that you want
Step two must be a standardized intermediary code
Step three will be into what ever machine code that is available.

Steps one and three more of less exist now. Step two is the one which has to be defined and coded.

So if you want to develop a new language, all you have to do is write step one - and maybe extend the capabilities of step two -but I am not even sure about that.

[Stuart McLachlan]

Of course it must get it right - and in the right format. A misaligned bit can cause havoc!!

But do you agree with the overall thrust of the point? Are there any other steps we should add?

So my proposal is that:

Step one can be any 'human' oriented code that you want
Step two must be a standardized intermediary code
Step three will be into what ever machine code that is available.

Steps one and three more of less exist now. Step two is the one which has to be defined and coded.

So if you want to develop a new language, all you have to do is write step one - and maybe extend the capabilities of step two -but I am not even sure about that.

You are overlooking two layers:
Operating System
Processor.

The actual instructions "machine code" just to display a dot on a screen is different for every combination of those two variables.

[Rodney Hicks]

The actual instructions "machine code" just to display a dot on a screen is different for every combination of those two variables.

Yes, but the consolidation I spoke of would include standardization as well. What with cloud computing and its silver linings, we're already heading to a universal computer.

[Brian Alvarez]

@Kerry, Im intrested to know what do you mean by "standardized intermediary code"?

@Rodney, im afraid a "universal computer" is like a holy grail. If right now a portion or the OS market attracts virus creators, imagine if the whole worlds used only one OS/CPU... it would be chaos. I agree having to focus on making one system invulnerable could be more successful though. A war between OS/hardware makers vs virus makers.

[Kerry Farmer]

Brian

I have never written a compiler. My only 'claim to fame' is that I have written ordinary programs in machine code - several different ones actually - but it was a long time ago.

I am quite interested in this discussion - but I did not fully understand the opening remarks.

And I do not yet agree with Stuart that there are two extra layers - I think they should be called something else, ie not layers - but I am still thinking.

So I am thinking this through from a position of some ignorance.

My basic proposition is that a compiler takes a human language set of instructions, then it analyses it into a set of machine language instructions and then produces machine code. Now I do know that step 2 - analysing into machine language instructions - has at least two substeps. They are 1 analysing the instructions and then 2 ensuring that branching and data location referrals are correctly set in relation to the actual locations.

Now it seems to me that if we define the exact steps that a compiler takes, then we can say 'but this step could be achieved differently'. In other words some steps might be the same.

If we could have a compiler which is a set of steps and the first step is what we would normally call the language - ie PB or Cobol or Fortran - and the last step is the translation into machine code - ie intel or android or whatever, and the middle steps are common no matter what - then we truly have a universal compiler.

So at any time we could develop another 'language' eg 'PB advanced' and just write the first step and the other steps would stay the same. Or we could have a compiler which delivers code for my PC, and we just change the last step and it produces code for my phone. Is that what you mean by a universal compiler?

First of all, I think these steps might be very complicated and take a lot of work! And I repeat that I am speaking with a degree of ignorance.

[PS just for the record there is a step zero - it is the editor which creates the 'human code' eg our IDE]

[PPS also for the record - the compiler has to operate in an environment. So this universal compiler of ours has to be written for a platform. Not the compiled program, but the compiler. We could have a compiler which works on my computer. We could have another version which works on my phone. This is not the universality which we are discussing - i do not think. And I think that this is where Stuart's comments fit it]

Clear as mud???

[Kerry Farmer]

Perhaps we should transfer this discussion to a new thread called 'universal compiler'

[Brian Alvarez]

Its been a while since i made a compiler, and it was very limited. But sure why not.

[Kerry Farmer]

Brian

What is your definition of a 'universal compiler'?

[Rodney Hicks]

Perhaps we should transfer this discussion to a new thread called 'universal compiler'

Done.

https://forum.powerbasic.com/forum/user-to-user-discussions/programming/782472-universal-compilers

[Brian Alvarez]

Its been a while since i made a compiler, and it was very limited. But sure why not.

Wow.. a bit hard... I would say a compiler that can target any OS. Not Necessarily a compiler, it is already too hard to make a
compiler for one single platform... for all platforms it would be nearly impossible. PluriBASIC uses the same syntax and uses
external compilers to target different platforms. For example It uses PowerBASIC for windows' destop applications.