FreeBASIC Namespace Project

For other topics related to the FreeBASIC project or its community.
marcov
Posts: 2748
Joined: Jun 16, 2005 9:45
Location: Eindhoven, NL
Contact:

Re: FreeBASIC Namespace Project

Postby marcov » Jan 09, 2018 21:47

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: 1443
Joined: Jun 21, 2005 19:04

Re: FreeBASIC Namespace Project

Postby angros47 » Jan 09, 2018 22:00

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: 322
Joined: Nov 28, 2012 1:27
Location: California

Re: FreeBASIC Namespace Project

Postby speedfixer » Jan 09, 2018 22:14

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

Re: FreeBASIC Namespace Project

Postby MrSwiss » Jan 09, 2018 23:13

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

Postby lizard » Jan 09, 2018 23:45

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

Re: FreeBASIC Namespace Project

Postby MrSwiss » Jan 09, 2018 23:59

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

Postby lizard » Jan 10, 2018 0:05

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: 5701
Joined: Jan 10, 2006 20:30
Location: Scotland

Re: FreeBASIC Namespace Project

Postby dodicat » Jan 10, 2018 0:11

<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
Posts: 912
Joined: Jul 25, 2017 17:22
Location: Argentina

Re: FreeBASIC Namespace Project

Postby paul doe » Jan 10, 2018 4:41

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

Postby sancho3 » Jan 10, 2018 4:58

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: 2748
Joined: Jun 16, 2005 9:45
Location: Eindhoven, NL
Contact:

Re: FreeBASIC Namespace Project

Postby marcov » Jan 10, 2018 7:03

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: 834
Joined: Oct 19, 2017 15:00
Location: 't Zand, NL
Contact:

Re: FreeBASIC Namespace Project

Postby Munair » Jan 10, 2018 9:33

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: 1612
Joined: Jun 02, 2005 15:10
Location: USA
Contact:

Re: FreeBASIC Namespace Project

Postby Imortis » Jan 10, 2018 15:12

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: 2756
Joined: Jun 02, 2015 16:24

Re: FreeBASIC Namespace Project

Postby Tourist Trap » Jan 10, 2018 17:13

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
Posts: 912
Joined: Jul 25, 2017 17:22
Location: Argentina

Re: FreeBASIC Namespace Project

Postby paul doe » Jan 10, 2018 20:02

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).

Return to “Community Discussion”

Who is online

Users browsing this forum: No registered users and 2 guests