Compiler -- One more Pass

BackupUser · Post by **BackupUser** » Mon Feb 03, 2003 11:50 am

Restored from previous forum. Originally posted by geoff.

At the top of my code I include a long list of DECLARE statements
for all of the procedures included subsequently. If I don't do
this the compiler is confused by the use of a procedure name before
the procedure is included. Since procedures call procedures this
problem is difficult to avoid.

However, I haven't had this inconvenience with other languages.

Would it be better for the compiler to make an additional first pass
through the code to find the procedure names before the current
"first pass"? Then I wouldn't need the Declare statements.
Surely this wouldn't slow the compiler appreciably?

BackupUser · Post by **BackupUser** » Mon Feb 03, 2003 2:43 pm

Restored from previous forum. Originally posted by fred.

I will probably add this, but it would slowdown a lot the compiler for sure. I'm thinking to a smart way to do it.

Fred - AlphaSND

BackupUser · Post by **BackupUser** » Mon Feb 03, 2003 3:06 pm

Restored from previous forum. Originally posted by PB.

> I will probably add this, but it would slowdown a lot the compiler
> for sure. I'm thinking to a smart way to do it.

Put the source filename in the title bar, and third-party apps can
process the sources before/after compilation...

BackupUser · Post by **BackupUser** » Mon Feb 03, 2003 3:17 pm

Restored from previous forum. Originally posted by blueb.

Geoff,

I know PowerBasic is a single pass compiler, and operates
exactly like PureBasic, so it's not that uncommon.

To avoid writing declare statements ahead of time (so the
compiler doesn't complain) all you have to do is place your
Subs and Functions in another file and call it with the
IncludeFile statement and place this at the top of your code.

PureBasic reads this file first, then the statements in your main file.

Regards,
blueb

BackupUser · Post by **BackupUser** » Mon Feb 03, 2003 3:47 pm

Restored from previous forum. Originally posted by freak.

There could also be an Editor-Feature (optional of course) that checks the source before compilation, and adds the Declare Statements at the top.

QuickBasic used to to it that way, and I must say, it was very handy.

Just a thought...

Timo

BackupUser · Post by **BackupUser** » Mon Feb 03, 2003 4:11 pm

Restored from previous forum. Originally posted by geoff.

Thanks for the advice blueb, but what about functions that call
functions? You would need some sort of hierarchy of functions
with the lowest level ones uppermost.

Does it matter if this slows the compiler? It will make programming
easier and the compiled code will be just as fast.

BackupUser · Post by **BackupUser** » Mon Feb 03, 2003 7:55 pm

Restored from previous forum. Originally posted by GPI.

Originally posted by fred

I will probably add this, but it would slowdown a lot the compiler for sure. I'm thinking to a smart way to do it.

What about a optional feature. So everone can decide, if they want to use it.

Also the editor search for all procedure for the procedure-browser (btw: it would be nice, if the parameters shown there too). So it can be used to put the declares in the top of the sources by the editor.

The editor can create a file with same name, but other extensions. for Example ".declare.pbi".

so the editor must only add in the first line a
include ".declare.pbi", when he saves every file.

the advanced of this method is, that the compiler must not search the prozedures and that the editor don't declare a prozedure more than one time. Also the sourecode don't explode in the length.

GPI

sorry for my bad english.

BackupUser · Post by **BackupUser** » Tue Feb 04, 2003 1:51 am

Restored from previous forum. Originally posted by blueb.

Geoff,

Thanks for the advice blueb, but what about functions that call functions?

Doesn't matter. The compiler 'reads' each sub/function into it's memory and uses this information when needed by your code.

The only downside to using Include files is that you could end up having 150 'utility' functions in one file, while your program only needs 2 or 3 of these. This would make your compiled program larger than necessary.

We've talked about this before and what's really needed is a small program that 'gleans' the needed routines from your include file and creates a temporary include file that the compiler uses to compile your program.

Then you'd get the best of both worlds... you'll be able to have many pre-written routines in an include file that you could use with any of your programs and PB would still compile it to a small EXE.

Regards,
blueb

BackupUser · Post by **BackupUser** » Tue Feb 04, 2003 3:32 am

Restored from previous forum. Originally posted by TheBeck.

Anyone remember Blitz Basic on the Commodore 128 or 64? I am so not worried about compiler speed on the PC. Even if it were 1000 times slower it would still be faster than the Commodore 128.

BackupUser · Post by **BackupUser** » Tue Feb 04, 2003 10:59 am

Restored from previous forum. Originally posted by PB.

> Anyone remember Blitz Basic on the Commodore 128 or 64?

I own an app for the C64 called "Blitz! Compiler" -- is that the
same thing, or was there an actual "Blitz Basic" for the C64 too?

BackupUser · Post by **BackupUser** » Tue Feb 04, 2003 11:56 am

Restored from previous forum. Originally posted by geoff.

Blueb,

Doesn't matter. The compiler 'reads' each sub/function into it's memory and uses this information when needed by your code.

I don't think this is right, try this example:

Contents of file GRAPHIC.PB:

Code: Select all

Procedure SomeGraphics()
  StartDrawing(WindowOutput())
  draw_circle(); this procedure is declared later
  Locate(10, 10)
  BackColor(255,255,255)
  FrontColor(0,0,0) 
  DrawText("Hello, this is a test")
  StopDrawing()
EndProcedure

Procedure draw_circle()
  Circle(100,100,50,RGB(0,0,255))
EndProcedure

Main Program:

Code: Select all

IncludeFile "graphic.pb"

If OpenWindow(0,100,100,300,200,#PB_Window_SystemMenu,"Test")
  Repeat
    Repeat
      EventID.l = WaitWindowEvent()
    Until EventID  0
    If EventID = #PB_EventRepaint
      SomeGraphics()
    EndIf
  Until EventID = #PB_EventCloseWindow 
EndIf
End

When run you get:

Line 7 : Error in the included file "graphic.pb"
Line 4 : draw_circle() is not a function, an array, or a linked list

This is because there is a call to the second procedure of the include
file in the first procedure. As I said, you would have to arrange
procedures in a strict hierarchy to prevent this error.

Isn't the whole point of a high level language compiler to automate
as much as possible to make the task of the programmer as easy as
possible? Why even consider alternative solutions?

BackupUser · Post by **BackupUser** » Tue Feb 04, 2003 12:14 pm

Restored from previous forum. Originally posted by TheBeck.

>I own an app for the C64 called "Blitz! Compiler" -- is that the
>same thing, or was there an actual "Blitz Basic" for the C64 too?

Actually it was "Basic 128" by Abacus that I was thinking of, my mistake. I also remember a Blitz compiler for basic but I don't know who made it.

BackupUser · Post by **BackupUser** » Tue Feb 04, 2003 3:03 pm

Restored from previous forum. Originally posted by blueb.

Geoff,

Absolutely right!

I tried this on PB and another language, so it's not unique to PB.
My utility fuctions must be in the correct sequence, because I
haven't had a problem compiling before. Thanks for trying this.
Back to the drawing board.

For now...when I get a message that says it can't find a required
routine, I'll just put a declaration in the include file for that
particular routine... but it's not pretty. Is it?

Oh well, time to work on that 'gleaning routine' and put all of my
routines in one file.

Regards,
blueb

BackupUser · Post by **BackupUser** » Fri Feb 07, 2003 9:28 am

Restored from previous forum. Originally posted by koehler.

Wow, this 'gleaning' was exactly the solution I wanted so bad, back when I programmed more actively. Always thought it was rather stupid that we have tons of library's and includes, and you couldn't just have the compiler pull only what was actually used in your program at compilation time.

This is definately a 'bright idea' that needs doing...

--
1980 Applesoft Basic, '81 6502 Assembler, '82 Pascal, '96 C, '00 Blitz Basic
2003 Pure Basic - History does repeat itself.

BackupUser · Post by **BackupUser** » Fri Feb 07, 2003 5:30 pm

Restored from previous forum. Originally posted by Franco.

Hi guys,
that's why I like to have the possibility to create Purebasic libraries with PureBasic itself (and ask for over a year now for it...)

When the PureBasic Editor starts he searches the PureLibrary/UserLibrary directories for libraries and he creates a file with all the available commands.
When he is finished the compile function is active.

If I could make PureBasic Libraries out of my PureBasic Include files, I could use every Procedure function as a library call - no declaration no hierarchy of the Procedures necessary.

The only thing is, that the user has to test this 'Library Module' first and make it bug free. (well a good coder does it anyway, or not?)
Supposedly this would increase the stability of the application anyway.

A nice thing as a side effect would be, that if the user creates intelligent procedure calls (with all needed parameters for it) after a while he would have a complete system of 'Library Modules' and he doesn't need to cut and past the procedures from an older project to a new project and adapt it for the new project's code and parameter flow.
(I suppose this is the way most programmers work today - why do I talk to a dead horse anyway...

)

I like to think ahead and don't reinvent the weel twice.
That's why I started month ago to write such a collection of Procedures for myself (I called it PureGoodies) and made sure every Procedure Function gets all data needed at his call - so every Procedure can be used as a Module in every project of mine.

If I could use the missed function IncludeFile -> PureLIB/PureModule it would decrease the Declare statements in top of my code...
This would be awesome

Have a nice day...

Franco