fblite: -lang deprecated revival

The forum for all of your Freebasic needs!

Moderators: Pete, Mods

Post Reply
coderJeff
Coder
Posts: 16
Joined: Tue Jan 08, 2008 8:14 am

fblite: -lang deprecated revival

Post by coderJeff »

A while back I asked what it would take to get users up to date on FreeBASIC. Well, here is a plan for a dialect that the FB Dev-Team would be willing to support long term.

Same as fbc-0.15 (or current deprecated dialect) except the following:

1) Proposed dialect name is 'fblite'. To use it, pass '-lang fblite' on the command line to fbc
2) implicit variables have procedure scope
3) DIM'ed variables have procedure scope
4) no explicit SCOPE blocks
5) initializers work like assignments
6) GOSUB, but later (possibly much later)

After discussing the issue at length, we have determined that -lang deprecated exactly as it is, would be too complex to support long term and eventually it must be removed. Also we thought it too confusing to have different scoping rules in every dialect. Thanks to everyone that tried out -lang deprecated. The feedback was very helpful in our discussions.

I don't know how long it will be before this is "official" since we are still determining how much work it is going to take.

Comments or questions?
SMC
Coder
Posts: 20
Joined: Wed Jan 09, 2008 2:34 pm

Post by SMC »

That's really cool. Will all the new non-oop stuff be available? Also, will variables outside of procedures be considered global? Give me an example of what you meant by initializers working like assignments. I'm not sure I follow you. And thanks, you really put a lot of work into freebasic, and I for one appreciate it. I've actually been playing with version .18 recently and I like it (except for the oop). I feel it's a bit too much like c/c++ though in the sense that it requires a lot of clutter code to make sure everything works the way it's supposed to. I'll be looking forward to the simpler dialect of fblite regardless of what the naysayers think. That brings up another question. Do you think it will be possible to give the other data types some kind of shorthand notation? Thanks, again.
coderJeff
Coder
Posts: 16
Joined: Tue Jan 08, 2008 8:14 am

Post by coderJeff »

Thanks, SMC.

> Will all the new non-oop stuff be available?
Yes, data types (32-bit integer, byte, short, pointers, etc) will be same as fb dialect, plus multithreading, ImageCreate, anonymous types, and all that jazz should work. The main change is to scopes, which makes fblite have the exact same scoping rules as QB (and fbc-0.15 except for explicit SCOPE block).

> Also, will variables outside of procedures be considered global?
Not by default. Just like in qb/fb, must use SHARED to make variables visible to the entire module, and COMMON (or EXTERN) to make variables visible to other modules. That hasn't changed.

> Give me an example of what you meant by initializers working like assignments.
Output of this sample program same as in fbc-0.15:

Code: Select all

'' compile with fbc -lang fblite
defint a-z

sub test

  print "---- Initial Values

  print " i", " j", " k"

  goto there
back:

  print "---- FOR NEXT

  for i = 1 to 3    '' i has proc scope (defaults to 0)
    dim k           '' k has proc scope (defaults to 0)
    dim j = 10      '' j has proc scope (defaults to 0)
                    '' but assigned to 10 each time this
                    '' line encountered
    k = k + 1
    j = j + 1
    print i, j, k
  next i

  print "---- After FOR NEXT
  print i, j, k

  exit sub

there:
  print i, j, k
  goto back

end sub

test
OUTPUT:

Code: Select all

---- Initial Values
 i             j             k
 0             0             0
---- FOR NEXT
 1             11            1
 2             11            2
 3             11            3
---- After FOR NEXT
 4             11            3

> That brings up another question. Do you think it will be possible to give the other data types some kind of shorthand notation?
Technically possible? Proabably. But it was never discussed. Just the QB ones ( % & ! # $ ) are supported.
User avatar
Mentat
Veteran
Posts: 409
Joined: Tue Aug 07, 2007 3:39 pm
Location: NC, US

Post by Mentat »

How about small variables? Maybe variables using only a handful of bits? I don't know if it's possible, but a single-bit flag variable could be useful.
Or a four bit variable can be used for a range of 0-15, which also has uses. Just a suggestion, for lite variables.
For any grievances posted above, I blame whoever is in charge . . .
SMC
Coder
Posts: 20
Joined: Wed Jan 09, 2008 2:34 pm

Post by SMC »

Thanks for the reply coderjeff. At a glance it may seem silly to have three different dialects, but in the end I think it will only increase fb's appeal. The oop stuff will inevitably make fb more complicated (nothing wrong with that) and fblite will be a good jumping on point for new users used to qbasic and pb. You might even get back some of the people who jumped ship after .16
coderJeff
Coder
Posts: 16
Joined: Tue Jan 08, 2008 8:14 am

Post by coderJeff »

SMC, yeah I agree. Except for scoping (and gosub) everything else will generally be the same as .15/.16/.17(dep)/.18(dep).

The fblite dialect has been added to the compiler (in SVN), and it's looking solid so far, imo. I checked out OHRRPGCE, which is currently using 0.18.x(deprecated) for their project. With a minor change to their source (~4 lines, due to use of scopes), it compiled(~50K LOC) and ran. I think that's a pretty good test case.

Mentat, I think the focus will be on making the dialect stable. Of course, new features are nice so maybe in future, I dunno. However, bit-fields are currently supported in UDT's:

Code: Select all

'' compile with fb/fblite
type DoubleNibble
  LoBits:4 as ubyte
  HiBits:4 as ubyte
end type

dim x as DoubleNibble

x.LoBits = 3
x.HiBits = 5

'' show the bits
print "HHHHLLLL"
print bin( *cast( ubyte ptr, @x ), 8 )

'' OUTPUT:
'' HHHHLLLL
'' 01010011
User avatar
Mentat
Veteran
Posts: 409
Joined: Tue Aug 07, 2007 3:39 pm
Location: NC, US

Post by Mentat »

I was thinking about QB's style of graphics. A four bit variable would work well with 16 colors, and a single bit for monochrome. But stability should come first.
For any grievances posted above, I blame whoever is in charge . . .
Post Reply