FreeBASIC Namespace Project

General discussion for topics related to the FreeBASIC project or its community.
marcov
Posts: 3462
Joined: Jun 16, 2005 9:45
Location: Netherlands
Contact:

Re: FreeBASIC Namespace Project

Post by marcov »

angros47 wrote: 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.
With FPC we do both. Commandline + pragma's.

One of the reasons for that is that we have people dual compiling with other compilers (Delphi , ISO Pascal) to contend with, and they rather not modify sources (since that will create potential problems with the other compilers, some of which also parse the non taken branches of IFDEFs).

However people that don't have that situation rather do everything in source (and not maintain potentially IDE specific project files)
Last edited by marcov on Jan 23, 2018 20:33, edited 1 time in total.
angros47
Posts: 2324
Joined: Jun 21, 2005 19:04

Re: FreeBASIC Namespace Project

Post by angros47 »

I just want to remind, for anyone who thinks to ditch -lang QB and -lang FBLITE, that these modes aren't just for compatibility for older languages: they are also for compatibility with the ISO standard https://en.wikipedia.org/wiki/BASIC#Standards. Dropping support for the standards would mean dropping the right to call FreeBasic a BASIC compiler, since a BASIC compiler is expected to be able to compile a standard-compliant BASIC code.
speedfixer
Posts: 606
Joined: Nov 28, 2012 1:27
Location: CA, USA moving to WA, USA
Contact:

Re: FreeBASIC Namespace Project

Post by speedfixer »

Valuable knowlege.
MrSwiss
Posts: 3910
Joined: Jun 02, 2013 9:27
Location: Switzerland

Re: FreeBASIC Namespace Project

Post by MrSwiss »

angros47 wrote:I hope it is a joke.
On the contrary, this is meant: deadly serious! (I wouldn't want to spend a single Second, on QB (anything)!)
angros47 wrote:... dropping the right to call FreeBasic a BASIC compiler, since a BASIC compiler is *expected to be able to compile a standard-compliant BASIC code.
*clearly NOT mandatory, therefore, nonsense! (I think, just a simple excuse, to maintain Status Quo!)
lizard
Posts: 440
Joined: Oct 17, 2017 11:35
Location: Germany

Re: FreeBASIC Namespace Project

Post by lizard »

Who should decide this internationally, for all countries, who is allowed to call his language "Basic"?
MrSwiss
Posts: 3910
Joined: Jun 02, 2013 9:27
Location: Switzerland

Re: FreeBASIC Namespace Project

Post by MrSwiss »

lizard wrote:Who should decide this internationally, for all countries, who is allowed to call his language "Basic"?
Well, it's about BASIC (all upper case) because, it is a acronym for: "Beginner's All-purpose Symbolic Instruction Code".
As long as nobody explicitly states: compliant to Standard "xXXXXXx", anybody is free to do anything (FB syntax is clearly BASIC, anyway).
Last edited by MrSwiss on Jan 10, 2018 0:11, edited 1 time in total.
lizard
Posts: 440
Joined: Oct 17, 2017 11:35
Location: Germany

Re: FreeBASIC Namespace Project

Post by lizard »

MrSwiss wrote:As long as nobody explicitly states: compliant to Standard "xXXXXXx", anybody is free to do anything (the syntax is clearly BASIC, anyway).
I would vote for you.
dodicat
Posts: 7983
Joined: Jan 10, 2006 20:30
Location: Scotland

Re: FreeBASIC Namespace Project

Post by dodicat »

<With a light heart>
Personally I think it is a fly by night idea.
Stationary in it's track.
A boulevard of broken dreams (somebody said somewhere)
A road to nowhere.
A lonely place.
using namespace.std
No, that means loading everything, which is not wanted.

Code: Select all


#define gfx
#define std

sub bird
dim as integer xres,yres
gfx.screeninfo xres,yres
dim as double PLOT_grade=2000
dim as double temp1,temp2
#macro sketch(_function,minx,maxx,miny,maxy)
For x As Double=minx To maxx  Step (maxx-minx)/PLOT_GRADE
    dim as double x1=(xres)*(x-minx)/(maxx-minx)
    dim as double y1=(yres)*(_function-maxy)/(miny-maxy)
    gfx.Pset(x1,y1),rgb(0,0,10)
    if abs(x)<1e-3 then
        temp1=x1:temp2=y1
        end if
Next x
gfx.circle (temp1,temp2),50,rgb(0,200,0),,,,f
gfx.circle (temp1-20,temp2-20),10,rgb(200,200,200),,,,f
gfx.circle (temp1+20,temp2-20),10,rgb(200,200,200),,,,f

gfx.circle (temp1-20-5*z,temp2-20),3,rgb(00,00,200),,,,f
gfx.circle (temp1+20-5*z,temp2-20),3,rgb(00,00,200),,,,f

gfx.circle (temp1,temp2),30,rgb(0,0,0),4,5.5
gfx.circle (temp1,temp2-2),30,rgb(0,0,0),4-k/3,5.5+k/3
gfx.circle (temp1,temp2),51,rgb(0,0,10)
#endmacro

static k as integer=1
static z as double
dim pi as double=4*std.atn(1)
     z=z+.02*k
sketch (-std.sin(z*x+z),-(pi),pi,-2,2)
sketch (std.sin(z*x-z),-(pi),pi,-2,2)
gfx.paint (.25*xres,.5*yres),rgb(0,50,120),rgb(0,0,10)
gfx.paint (.75*xres,.5*yres),rgb(0,50,120),rgb(0,0,10)
if z>1.1 then k=-k
if z<-1.1 then k=-k
if z>2*pi then z=0
gfx.window screen (0,0)-(xres,yres)
end sub

Sub Tree(x1 As Single,y1 As Single,size As Single,angle As Single,depth As Single,colb As ulong=0,colL As ulong=0,im as any ptr=0)
    Dim  As Single spread,scale,x2,y2
    spread=25
    scale=.76
    #define incircle(cx,cy,radius,x,y) (cx-x)*(cx-x) +(cy-y)*(cy-y)<= radius*radius
    x2=x1-.25*size*std.Cos(angle*.01745329)
    y2=y1-.25*size*std.Sin(angle*.01745329)
    Static As long count,fx,fy,sz,z
    If count=0 Then  fx=x1:fy=y1:sz=size:z=2^(depth+1)-1
    gfx.Line im,(x1,y1)-(x2,y2),colb
    If count=0 Then  fx=x2:fy=y2:sz=size
    count=count+1
    If count>z Then count=0
    If incircle(fx,fy,(.45*sz),x2,y2)=0 Then gfx.Circle im,(x2,y2),.01*sz,colL 
    If depth>0 Then
        Tree(x2, y2, size * Scale, angle - Spread, depth - 1,colB,colL,im)
        Tree(x2, y2, size * Scale, angle + Spread, depth - 1,colB,colL,im)
    End If
End Sub

Function Regulate(Byval MyFps As long,Byref fps As long=0) As long
        Static As Double timervalue,lastsleeptime,t3,frames
        Var t=std.Timer
        frames+=1
        If (t-t3)>=1 Then t3=t:fps=frames:frames=0
        Var sleeptime=lastsleeptime+((1/myfps)-T+timervalue)*1000
        If sleeptime<1 Then sleeptime=1
        lastsleeptime=sleeptime
        timervalue=T
        Return sleeptime
    End Function

gfx.screenres 1024,768,32
gfx.color , rgb(0,0,20)
dim as any ptr i=gfx.imagecreate(1024,768)

gfx.paint i,(0,0),rgb(0,0,35)
gfx.line i,(0,500)-(1024,768),rgb(0,30,0),bf
for n as long=1 to 200
    gfx.pset i,(rnd*1024,rnd*500)
    next
gfx.line i,(200,768)-(800,500),rgb(30,30,30)
gfx.line i,(850,500)-(900,768),rgb(30,30,30)
gfx.line i,(800,500)-(850,500),rgb(30,30,30)
gfx.paint i,(250,750),rgb(30,30,30),rgb(30,30,30)
var L=std.sqr((825-550)^2 + (768-500)^2)
var dx=(825-550)/L,dy=(768-500)/L
var x=0,y=0
gfx.pset(550,768)
dim as ulong clr
dim as single k=10,g=20
for n as long=1 to 50
    if n and 1 then clr=rgb(100,100,100) else clr=rgb(30,39,30)
    var x=550+dx*g*n,y=768-dy*g*n
    gfx.line i,-(x+dx*k,y-dy*k),clr
    g=.98*g
next 

for n as long=1 to 8
 Tree(-50+std.sqr(9-n)*280,500+n*20,n*40+std.rnd*20,90+(std.rnd*10-std.rnd*20),12,rgb(100,std.rnd*155,0),rgb(0,100,0),i)
next
 
 do
     gfx.screenlock
     gfx.cls
     gfx.put(0,0),i,trans
     bird
     gfx.screenunlock
     std.sleep regulate(50),1
     loop until std.len(std.inkey)

 std.sleep
 gfx.imagedestroy(i) 
paul doe
Moderator
Posts: 1733
Joined: Jul 25, 2017 17:22
Location: Argentina

Re: FreeBASIC Namespace Project

Post by paul doe »

angros47 wrote:The namespace idea itself is good, but it has not to break retro compatibility. At least, in my opinion.
MrSwiss wrote: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'!
I think that both postures are totally achievable. Retro compatibility should, at this time, not be a priority. FreeBasic needs to evolve sooner or later, and let go of its QB legacy that's quickly becoming a burden.

One possible solution to both issues would be to let the standard namespace as it is, with all those QB quirks, and evolve the namespaces instead. At first, the new namespaces would contain just syntactic-sugar wrappers for the old functions, but far more easy to maintain and develop. Then, only the new functions/namespaces would get updates and fixes, the rest can be left as-is. That way, the language can be developed and the compiler streamlined in a more homogeneous way, without stirring old crap.

Two quick examples of how the code might look like. Don't mind the boilerplate code, or the verbosity (this can be worked out later). Also, .NETisms need not apply (I used them only as an example):

Code: Select all

namespace fb
	namespace datatypes
		enum stringCompareMode
			scAny
			scLiteral
		end enum
		
		type atomic_string as string
	
		type stringEx extends object
			public:
				
				declare constructor()
				declare constructor( byref rhs as const string )
				
				declare operator let( byref rhs as const string )
				declare operator cast() as string
				declare operator []( byval index as uinteger ) as uinteger
				
				declare function inString _
					( _
						byref s as const string, _
						byval compareMode as fb.datatypes.stringCompareMode = scLiteral _
					) as integer
				
				declare function char( byval index as uinteger ) as string
				 
			private:
				as string m_string
		end type
		
		constructor stringEx()
			m_string = ""
		end constructor
		
		constructor stringEx( byref rhs as const string )
			m_string = rhs
		end constructor
				
		operator stringEx.let( byref rhs as const string )
			m_string = rhs
		end operator
		
		operator stringEx.cast() as string
			return( m_string )
		end operator
		
		operator stringEx.[]( byval index as uinteger ) as uinteger
			return( m_string[ index ] )
		end operator

		function stringEx.inString _
			( _
				byref s as const string, _
				byval compareMode as fb.datatypes.stringCompareMode = scLiteral _
			) as integer
		
			select case as const compareMode
				case scAny
					return( instr( m_string, any s ) )
				
				case scLiteral
					return( instr( m_string, s ) )
				
				case else
					'' defaults to literal as FB does
					return( instr( m_string, s ) )
			end select			
		end function
	
		function stringEx.char( byval index as uinteger ) as string
			return( chr( m_string[ index ] ) )
		end function
	end namespace '' datatypes
end namespace '' fb

sub showString( byref s as const string )
	? s
end sub

using fb
using fb.datatypes

dim as string someString = "This is a test"
dim as stringEx myString = someString

showString( someString )
showString( myString )

? instr( someString, "test" )
? instr( someString, any "test" )

? myString.inString( "test" )
? myString.inString( "test", stringCompareMode.scAny )

? chr( someString[ 2 ] )
? chr( myString[ 2 ] )
'' or, more Basic-like:
? myString.char( 2 )

sleep()

Code: Select all

#undef width
#undef screen

namespace fb
	namespace datatypes
		type atomic_integer as integer
		
		type integerEx extends object
			public:
				declare constructor()
				declare constructor( byref rhs as fb.datatypes.atomic_integer )
				
				declare operator let( byref rhs as fb.datatypes.atomic_integer )
				declare operator cast() as fb.datatypes.atomic_integer
				
				declare static function random _
					( _
						byval minValue as fb.datatypes.atomic_integer, _
						byval maxValue as fb.datatypes.atomic_integer _
					) as fb.datatypes.atomic_integer
			
			private:
				as fb.datatypes.atomic_integer m_integer = any
		end type
		
		constructor integerEx()
			m_integer = 0
		end constructor
		
		constructor integerEx( byref rhs as fb.datatypes.atomic_integer )
			m_integer = rhs
		end constructor
		
		operator integerEx.let( byref rhs as fb.datatypes.atomic_integer )
			m_integer = rhs
		end operator
		
		operator integerEx.cast() as fb.datatypes.atomic_integer
			return( m_integer )
		end operator
		
		static function integerEx.random _
		( _
			byval minValue as fb.datatypes.atomic_integer, _
			byval maxValue as fb.datatypes.atomic_integer _
		) as fb.datatypes.atomic_integer
		
			return( int( rnd() * ( maxValue + 1 - minValue ) + minValue ) )
		end function
		
	end namespace '' datatypes
end namespace '' fb

namespace fb
	namespace graphics
		namespace screen
			dim as integer width
			dim as integer height
		end namespace
		
		enum graphicModes
			fb8bit	= 8
			fb16bit	= 16
			fb32bit	= 32
		end enum
				
		sub setScreenResolution _
			( _
				byval w as integer, _
				byval h as integer, _
				byval d as fb.graphics.graphicModes = fb.graphics.graphicModes.fb32bit _
			)
			screenRes( w, h, d )
			
			screen.width = w
			screen.height = h
		end sub
		
		sub drawFilledRectangle _
		( _
			byval x as integer, _
			byval y as integer, _
			byval w as integer, _
			byval h as integer, _
			byval c as ulong _
		)
		
			line( x, y ) - ( x + w - 1, y + h - 1 ), c, bf
		end sub
		
		sub drawFilledCircle _
		( _
			byval x as integer, _
			byval y as integer, _
			byval r as integer, _
			byval c as ulong _
		)
			
			circle( x, y ), r, c, , , , f
		end sub
	end namespace '' graphics
end namespace '' fb

using fb
using fb.datatypes

graphics.setScreenResolution( 800, 600, graphics.graphicModes.fb32bit )
'' screenRes( 800, 600, 32 )
dim as integer scrW, scrH
screenInfo( scrW, scrH )

dim as integer choice

for i as integer = 0 to 1000
	choice = integerEx.random( 0, 1 )
	
	select case as const( choice )
		case 0	
			graphics.drawFilledCircle( _
				integerEx.random( 0, graphics.screen.width - 1 ), _ '' x
				integerEx.random( 0, graphics.screen.height - 1 ), _ '' y
				integerEx.random( 5, 25 ), _ '' radius
				rgb( _ '' color
					integerEx.random( 0, 255 ), _
					integerEx.random( 0, 255 ), _
					integerEx.random( 0, 255 ) ) )
			
			'circle( rnd() * scrW - 1, rnd() * scrH - 1 ), rnd() * 20 + 5, rgb( rnd() * 255, rnd() * 255, rnd() * 255 ), , , , f
		case 1
			graphics.drawFilledRectangle( _
				integerEx.random( 0, graphics.screen.width - 1 ), _ '' x
				integerEx.random( 0, graphics.screen.height - 1 ), _ '' y
				integerEx.random( 100, 300 ), _ '' width
				integerEx.random( 100, 300 ), _ '' height
				rgb( _ '' color
					integerEx.random( 0, 255 ), _
					integerEx.random( 0, 255 ), _
					integerEx.random( 0, 255 ) ) )
			
			'dim as integer x = rnd() * scrW
			'dim as integer y = rnd() * scrH
			'
			'line( x, y ) - ( x + ( rnd() * 200 + 100 ) - 1, y + ( rnd() * 200 + 100 ) - 1 ), rgb( rnd() * 255, rnd() * 255, rnd() * 255 ), bf
	end select
next

sleep()
It should be noted that I'm not advocating a pure-OO interface, just a more streamlined one. I think this is the intention of Imortis, too, but I may be mistaken. This could also bring other benefits, like a simpler grammar (which is also easier on the parser/compiler side of things, too).
Last edited by paul doe on Jan 10, 2018 16:25, edited 1 time in total.
sancho3
Posts: 358
Joined: Sep 30, 2017 3:22

Re: FreeBASIC Namespace Project

Post by sancho3 »

angros47 wrote: would mean dropping the right to call FreeBasic a BASIC compiler, since a BASIC compiler is expected to be able to compile a standard-compliant BASIC code.

How do you mean? For example both VB6 and VB Net can''t compile QB code.
marcov
Posts: 3462
Joined: Jun 16, 2005 9:45
Location: Netherlands
Contact:

Re: FreeBASIC Namespace Project

Post by marcov »

sancho3 wrote:
angros47 wrote: would mean dropping the right to call FreeBasic a BASIC compiler, since a BASIC compiler is expected to be able to compile a standard-compliant BASIC code.

How do you mean? For example both VB6 and VB Net can''t compile QB code.
And who said QB was standard compliant to begin with ?
Munair
Posts: 1286
Joined: Oct 19, 2017 15:00
Location: Netherlands
Contact:

Re: FreeBASIC Namespace Project

Post by Munair »

marcov wrote:And who said QB was standard compliant to begin with ?
You'd have to go to TrueBASIC for that if I'm not mistaken. Victor just liked QB very much, as did many others at the time, including me. FreePascal came about in the same way, while TP was also not standard or ISO Pascal compliant.
Imortis
Moderator
Posts: 1924
Joined: Jun 02, 2005 15:10
Location: USA
Contact:

Re: FreeBASIC Namespace Project

Post by Imortis »

paul doe wrote:...It should be noted that I'm not advocating a pure-OO interface, just a more streamlined one. I think this is the intention of Imortis, too, but I may be mistaken. This could also bring other benefits, like a simpler grammar (which is also easier on the parser/compiler side of things, too).
Correct. I want to make development on the language itself as simple as possible. This will mean more people will be able to work on it. This means more bug fixes, more progress.
Tourist Trap
Posts: 2958
Joined: Jun 02, 2015 16:24

Re: FreeBASIC Namespace Project

Post by Tourist Trap »

paul doe wrote:
One possible solution to both issues would be to let the standard namespace as it is, with all those QB quirks, and evolve the namespaces instead. At first, the new namespaces would contain just syntactic-sugar wrappers for the old functions, but far more easy to maintain and develop. Then, only the new functions/namespaces would get updates and fixes, the rest can be left as-is. That way, the language can be developed and the compiler streamlined in a more homogeneous way
Unless someone came here to declare that the way fb works today from the user side (left appart the need of the IDE...) is not in its opinion very satisfying, that is what should be done. I doubt that such an user can be sighted around sincerely ( note that I say user, I know that this is only one half of the affair but I'm in this side ;) ) Other way may work or may not, this way can only be successful.
paul doe
Moderator
Posts: 1733
Joined: Jul 25, 2017 17:22
Location: Argentina

Re: FreeBASIC Namespace Project

Post by paul doe »

Tourist Trap wrote:Unless someone came here to declare that the way fb works today from the user side (left appart the need of the IDE...) is not in its opinion very satisfying, that is what should be done. I doubt that such an user can be sighted around sincerely ( note that I say user, I know that this is only one half of the affair but I'm in this side ;) ) Other way may work or may not, this way can only be successful.
The problem is not FB, it's QB. FB syntax and behavior was modeled to be compatible with that of QB, and it's not that QB was such a great language to begin with. So, it had to be expanded without breaking compatibility with the crummy syntax of QB. The namespace project could offer both sides what they want: the ones that like the QB way of doing things can use it as always, the rest can move on. Neither of them bothers the other, and if/when people decide to migrate to the new way of doing things, they could do so more or less seamlessly.

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 )
By the way, the first one draws a rectangle, not a line. See what the whole point is about? If all funtions/subs follow the same signature, adding new functionality/exposing other is simply a matter of code the function, expose the prototype, and that's it. Only one simple parsing function could be used to parse almost all the code (sans control statements and other small quirks, of course), instead of needing a function for each QB keyword in existence. There is much to be gained, and little to lose. Other additional bonus:
Imortis wrote:Correct. I want to make development on the language itself as simple as possible. This will mean more people will be able to work on it. This means more bug fixes, more progress.
Which can be translated both to development of the compiler itself (the fbc program) and the language (the Basic dialect).
Post Reply