FreeBASIC 1.08 Development

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

Re: FreeBASIC 1.08 Development

Postby marcov » Aug 26, 2020 19:53

jj2007 wrote:
marcov wrote:Why make unnecessary shorthand exceptions. What's next, assign every type a char from the unicode table as suffix?
Being able to see the type of a variable increases the readability of code.


It disturbs as much as it adds. Coded messages(letters that are not normal syllables and interpunction) slow reading. If you don't need the info constantly it is slowing.

jj2007 wrote: Suffixes are very similar to Hungarian notation. Can you imagine MSDN without Hungarian notation?


Yes, sure. Why not? And now Microsoft is scaling down its Basic business after 40 years, maybe that will come sooner that you think for new APIs.

Hungarian notation is a sign of (1) a defective, too weak typed language (2) and unproductive IDE. Hovering above a variable can simply show declaration/type.
marcov
Posts: 3019
Joined: Jun 16, 2005 9:45
Location: Eindhoven, NL
Contact:

Re: FreeBASIC 1.08 Development

Postby marcov » Aug 26, 2020 19:55

deltarho[1859] wrote:Sometimes suffixes are essential.

Code: Select all

Print 1234567*1234567
Print 1234567ull*1234567
Sleep

gives

Code: Select all

-557712591
1524155677489

in 32-bit. In 64-bit we are OK.


This is something totally else. But still I don't agree in this case either. I think a cast like syntax would be better, better readable and more universal (for all types, not just the 10 that have a suffix).

So e.g. ulonglong(1234567). These are are relics from an awkward past.
caseih
Posts: 1555
Joined: Feb 26, 2007 5:32

Re: FreeBASIC 1.08 Development

Postby caseih » Aug 27, 2020 2:20

marcov wrote:Hungarian notation is a sign of (1) a defective, too weak typed language (2) and unproductive IDE. Hovering above a variable can simply show declaration/type.
Well I've heard people argue that a language that requires an IDE to be productive is not necessarily a good thing. And there are arguments for keeping functions short so that they can be understood quickly without requiring help from an IDE, and that can be actually tested as a unit. And sometimes it's not the language itself that is the problem. Java, like C, is a very simple language syntactically, with few keywords. But the frameworks, design patterns, and methodologies used in Java are kind of grotesque to be honest. Some of that is dictated by the language's design. Like using classes as a means of defining namespaces.

C, C++, and Java are all strongly typed languages (albeit with implicit type coercion). I think hungarian notation is more of a corporate culture thing than a reflection on limitations of the language or tools used. I dislike it personally, but understand why it's used. And when doing heavily object-oriented coding, I can understand why it would be desirable to use a prefix for a member variable. Although I think I prefer explicit scope selection in those cases.
caseih
Posts: 1555
Joined: Feb 26, 2007 5:32

Re: FreeBASIC 1.08 Development

Postby caseih » Aug 27, 2020 2:23

caseih wrote:
marcov wrote:Hungarian notation is a sign of (1) a defective, too weak typed language (2) and unproductive IDE. Hovering above a variable can simply show declaration/type.
Well I've heard people argue that a language that requires an IDE to be productive is not necessarily a good thing. And there are arguments for keeping functions short so that they can be understood quickly without requiring help from an IDE, and that can be actually tested as a unit. And sometimes it's not the language itself that is the problem. Java, like C, is a very simple language syntactically, with few keywords. But the frameworks, design patterns, and methodologies used in Java are kind of grotesque to be honest. Some of that is dictated by the language's design. Like using classes as a means of defining namespaces.

The only time I really find an IDE necessary is when working with a large class library, such as Qt. Then it becomes very useful to navigate through the myriad of classes and their members. For my own code, I haven't needed to rely solely on the IDE to navigate my own code. Granted my projects are not that large.

C, C++, and Java are all strongly typed languages (albeit with implicit type coercion). I think hungarian notation is more of a corporate culture thing than a reflection on limitations of the language or tools used. I dislike it personally, but understand why it's used. And when doing heavily object-oriented coding, I can understand why it would be desirable to use a prefix for a member variable. Although I think I prefer explicit scope selection in those cases.
coderJeff
Site Admin
Posts: 3342
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: FreeBASIC 1.08 Development

Postby coderJeff » Aug 27, 2020 2:38

gnihtyna daer ot flesruoy niart nac ecitcarp hguone htiW

I'd just like a moment to remember why we have suffixes at all:

Code: Select all

'$lang: "qb"
function r$(a$)
   for i%=1 to len(a$)
      s$=s$+mid$(a$,len(a$)-i%+1,1)
   next i%
   r$=s$
end function

input "Enter text:"; a$
print r$(a$)

Yeah, this will compile in fbc. in "fblite" too.

Under fbc's hood, the lexer expects identifiers to possibly have suffixes so it reads suffixes. But out of the 800+ places in the parser where a decision should be made about suffixes, only about 5 places are handled, often resulting in an error.

My personal preference is that '-lang fb' be suffix free. In the meantime, we can do better and have fbc at least report to the user what's happening as warnings. I've been working on this suffix thing for several days now and have written many tests. It's not perfect though. If there is some expectation that users will try out and report back the problems then I think I would feel OK about merging in a not quite complete change.
fxm
Posts: 9987
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: FreeBASIC 1.08 Development

Postby fxm » Aug 27, 2020 5:17

fxm wrote:2) Should we remove the "-w suffix" compile option that I had already included in the documentation?

3) Should we set back that the "$" suffix for string functions is optional in -lang fb (like for the -lang fblite)?

Following the test of the last build from stw, I still wonder about these 2 points?
counting_pine
Site Admin
Posts: 6229
Joined: Jul 05, 2005 17:32
Location: Manchester, Lancs

Re: FreeBASIC 1.08 Development

Postby counting_pine » Aug 27, 2020 8:24

coderJeff wrote:Under fbc's hood, the lexer expects identifiers to possibly have suffixes so it reads suffixes. But out of the 800+ places in the parser where a decision should be made about suffixes, only about 5 places are handled, often resulting in an error.

My personal preference is that '-lang fb' be suffix free. In the meantime, we can do better and have fbc at least report to the user what's happening as warnings. I've been working on this suffix thing for several days now and have written many tests. It's not perfect though. If there is some expectation that users will try out and report back the problems then I think I would feel OK about merging in a not quite complete change.

Just going to throw an idea out here..

What if the '-lang fb' lexer precluded the very possibility of suffixes - particularly '$' - by including those symbols within the variable name? e.g. dim a$b$c as integer.
Then in order to support legacy functions, it's just a matter of making sure both forms (e.g. mid and mid$) are registered as keywords/function names, or that one is registered as a #define for the other.
jj2007
Posts: 1724
Joined: Oct 23, 2016 15:28
Location: Roma, Italia
Contact:

Re: FreeBASIC 1.08 Development

Postby jj2007 » Aug 27, 2020 11:06

counting_pine wrote:Just going to throw an idea out here..

What if the '-lang fb' lexer precluded the very possibility of suffixes - particularly '$' - by including those symbols within the variable name? e.g. dim a$b$c as integer.
Then in order to support legacy functions, it's just a matter of making sure both forms (e.g. mid and mid$) are registered as keywords/function names, or that one is registered as a #define for the other.
Sounds good! Your example dim a$b$c as integer is slightly perverse by BASIC standards ;-) ... but getting My$="Hello" by allowing the "$" in a variable name sounds like a good compromise.
marcov
Posts: 3019
Joined: Jun 16, 2005 9:45
Location: Eindhoven, NL
Contact:

Re: FreeBASIC 1.08 Development

Postby marcov » Aug 27, 2020 14:49

counting_pine wrote:What if the '-lang fb' lexer precluded the very possibility of suffixes - particularly '$' - by including those symbols within the variable name? e.g. dim a$b$c as integer.
Then in order to support legacy functions, it's just a matter of making sure both forms (e.g. mid and mid$) are registered as keywords/function names, or that one is registered as a #define for the other.


Dollarsigns are used a lot as special character/separator in mangled names. Not a good idea IMHO to allow them in identifiers.
marcov
Posts: 3019
Joined: Jun 16, 2005 9:45
Location: Eindhoven, NL
Contact:

Re: FreeBASIC 1.08 Development

Postby marcov » Aug 27, 2020 15:06

caseih wrote:
marcov wrote:Hungarian notation is a sign of (1) a defective, too weak typed language (2) and unproductive IDE. Hovering above a variable can simply show declaration/type.
Well I've heard people argue that a language that requires an IDE to be productive is not necessarily a good thing.


I also hear a lot of people saying that you shouldn't need more than 1MB, and I don't believe them either.


And there are arguments for keeping functions short so that they can be understood quickly without requiring help from an IDE, and that can be actually tested as a unit.


Even then not all symbols used in the function are declared in the function, so this is an irrelevant argument.

And sometimes it's not the language itself that is the problem. Java, like C, is a very simple language syntactically, with few keywords. But the frameworks, design patterns, and methodologies used in Java are kind of grotesque to be honest. Some of that is dictated by the language's design. Like using classes as a means of defining namespaces.


Yes. And same in C++, Delphi or any grown up language. It is not even a OO thing, or framework thing, just about readiness to make very large programs over an extended period in time, so that you can't know every detail at every moment anymore. And work in teams, so that you didn't necessarily write all code.

The only time I really find an IDE necessary is when working with a large class library, such as Qt. Then it becomes very useful to navigate through the myriad of classes and their members. For my own code, I haven't needed to rely solely on the IDE to navigate my own code. Granted my projects are not that large.


But then you also don't need to employ Hungarian notation everywhere as hackety replacement for decent IDE codetools/intellisense.


C, C++, and Java are all strongly typed languages (albeit with implicit type coercion). I think hungarian notation is more of a corporate culture thing than a reflection on limitations of the language or tools used.


I agree there. I think it is something from the past (nineties). And somehow I somewhat agree with the principle of just keep it going as it is, as the problem is less than making MSDN a hodge podge of styles, or worse, renaming everything.

But that doesn't mean that MSDN using it is automatically some best practice (well, other than if your best practice is being consequent long term, and not bend to every IT fashion)


I dislike it personally, but understand why it's used. And when doing heavily object-oriented coding, I can understand why it would be desirable to use a prefix for a member variable. Although I think I prefer explicit scope selection in those cases.


Suff/Prefixes for various scopes (field, global variable, local var, parameter) is a different subject again. But I wouldn't go as far as stating that there is a one size fits all solution because it also depends on the language.

E.g. Delphi uses "f" prefix for fields, to keep the identifier without prefix free for properties, which is its preferred way of making state visible. It uses "a" for parameters of methods so that it won't clash with fields or properties in setter functions.

If you have a language without properties, this makes less sense. Also in some languages types and other symbols are in the same namespace, and some have a separate (sub-)namespace for types. Delphi has an unified namespace (though with some exceptions, mostly for MSDN interfacing), so types are generally prefixed with T
caseih
Posts: 1555
Joined: Feb 26, 2007 5:32

Re: FreeBASIC 1.08 Development

Postby caseih » Aug 27, 2020 18:45

marcov wrote:I also hear a lot of people saying that you shouldn't need more than 1MB, and I don't believe them either.

Glad to hear that!
Even then not all symbols used in the function are declared in the function, so this is an irrelevant argument.

I disagree. Although I have forgotten what the argument was about. :)

I am slowly coming around to many (okay some) of the ideas of functional programming.
counting_pine
Site Admin
Posts: 6229
Joined: Jul 05, 2005 17:32
Location: Manchester, Lancs

Re: FreeBASIC 1.08 Development

Postby counting_pine » Aug 28, 2020 8:29

marcov wrote:
counting_pine wrote:What if the '-lang fb' lexer precluded the very possibility of suffixes - particularly '$' - by including those symbols within the variable name? e.g. dim a$b$c as integer.
Then in order to support legacy functions, it's just a matter of making sure both forms (e.g. mid and mid$) are registered as keywords/function names, or that one is registered as a #define for the other.


Dollarsigns are used a lot as special character/separator in mangled names. Not a good idea IMHO to allow them in identifiers.

Good point..
Would it cause any clashes if the lexer accepted '$' as part of the identifier, but gave some sort of "illegal character" error unless it's the final character?
marcov
Posts: 3019
Joined: Jun 16, 2005 9:45
Location: Eindhoven, NL
Contact:

Re: FreeBASIC 1.08 Development

Postby marcov » Aug 28, 2020 20:23

counting_pine wrote:
marcov wrote:
counting_pine wrote:What if the '-lang fb' lexer precluded the very possibility of suffixes - particularly '$' - by including those symbols within the variable name? e.g. dim a$b$c as integer.
Then in order to support legacy functions, it's just a matter of making sure both forms (e.g. mid and mid$) are registered as keywords/function names, or that one is registered as a #define for the other.


Dollarsigns are used a lot as special character/separator in mangled names. Not a good idea IMHO to allow them in identifiers.

Good point..
Would it cause any clashes if the lexer accepted '$' as part of the identifier, but gave some sort of "illegal character" error unless it's the final character?


Sure, if you really want to. You'd maybe lose exact character position for the error generation though, since most tokenizers only register the character index of the start/end of a token. You could even replace the dollar sign with something else in mangled names, creating your own mangled name scheme. You'd probably need to anyway, for e.g. C output.

But IMHO this is all best avoided. Keep the dollar legacy junk at the periphery as much as possible, and don't let it permeate too far.
Last edited by marcov on Aug 29, 2020 18:25, edited 1 time in total.
jj2007
Posts: 1724
Joined: Oct 23, 2016 15:28
Location: Roma, Italia
Contact:

Re: FreeBASIC 1.08 Development

Postby jj2007 » Aug 28, 2020 21:40

marcov wrote:Keep the dollar legacy junk at the periphery as much as possible, and don't let it permeate too far.
Does it hurt?
coderJeff
Site Admin
Posts: 3342
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: FreeBASIC 1.08 Development

Postby coderJeff » Aug 29, 2020 18:32

It will hurt some, yes, he he. The '$' character is special in name decoration (name mangling) and fbc assumes that it is never part of user named symbols. As marcov correctly advises, including it in the actual name of the symbol will require some translation to some other character or escape sequence. Honestly, not sure what other troubles it gives us as I have not tried.

I have merged in a good sized compiler change that deals with all the stuff nobody cares about, however, is a needed update due to years of neglect. Mostly users and developers have not been overly concerned with suffixes, The recent fbc change deals with all the silly stuff.

Code: Select all

if! true# then%
end& if$

OUTPUT:
silly.bas(1) warning 44(1): Suffix ignored in 'if!'
silly.bas(1) warning 44(1): Suffix ignored in 'true#'
silly.bas(1) warning 44(1): Suffix ignored in 'then%'
silly.bas(2) warning 44(1): Suffix ignored in 'end&'
silly.bas(2) warning 44(1): Suffix ignored in 'if$'


I assessed 820+ (for real) locations in the fbc code where suffixes are ignored and then created coverage tests. If interested check the following links for the nonsense that fbc allowows:
https://github.com/freebasic/fbc/blob/m ... fix-fb.bas
https://github.com/freebasic/fbc/blob/m ... fblite.bas
https://github.com/freebasic/fbc/blob/m ... fix-qb.bas

That leaves us with about 15 or so cases in the fbc compiler source where suffix really matters depending on the dialect: 1) variables 2) Procedure Call or Assign, and 3) function return type. So for now, will still get errors on suffixes in some places. We'll keep working on it in future updates.

For anyone hacking on fbc compiler, I think this makes it very clear where the effort needs to be. I have some other changes in mind to get through first before returning to suffixes, though.

I've left a note in fbc sources under lex.bashReadIdentifier(): if one wanted to very cleanly and robustly eliminate suffixes from '-lang fb' it needs only about 3 lines of code to simply not read suffixes in the '-lang fb' dialect. If such an option were implemented, it would look something like this on the output:

Code: Select all

if! true# then%
end& if$

OUTPUT:
silly.bas(1) error 9: Expected expression, found '!' in 'if! true# then%'
silly.bas(1) error 3: Expected End-of-Line, found '!' in 'if! true# then%'
silly.bas(2) error 3: Expected End-of-Line, found '&' in 'end& if$'


However, this global change for suffixes in '-lang fb' does nothing for the '-lang qb|fblite' dialects so I think the other changes still valid.

Return to “Community Discussion”

Who is online

Users browsing this forum: jj2007 and 11 guests