How to add new features? (syntax, user API)

[Juergen Kuehlwein]

Well, i have learned that adding multiple new key words (like in your proposal) is a "no go" - the more the more words are needed. Some even don´t want to add one single new word to the global namespace, however justified this might be.

Hiding your new words in a namespace is only of limited help, because you must either use the namespace.procedure syntax, or you must code "using <namespace>" which then adds all of these words to the global namespace as long as "using" is active. So implementing "using" doesn´t prevent naming conflicts in all cases, if there are any.

The macro method i propose keeps all procedures inside their namespace (no "using" needed, because the macro adds the namespace prefix [and can do other things to parameters]), therefore the only word, which could raise naming conflicts is the macro itself (one single word), which therefore gives less possibility for a naming conflict than with the other method.

[coderJeff]

I'd like to help this discussion along. Please be patient with me. I'm a slow typist at times, when trying to communicate my thoughts. I'm going continue in multiple posts.

First, the personal level nonsense banter going on. That's gotta stop. Yes, MrSwiss does tend to trigger this in most people. Usually the reason I will defend him at all is that there is sometimes a valid point buried in there. But truly, the presentation is horrendous.

Second, people have the right to change their mind, including me.

Hopefully we can move on with the topic at hand. If you feel you must say more, email me, coder@execulink.com

[coderJeff]

The array.insert() syntax looks oop, while array(insert, args) looks odd. What about
ArrayInsert()
AudioOpen()
AudioPlay()
NetConnect()
NetTransmit()
etc? I would not be worried about namespace problems as long as it is consistent and Google doesn't find hits for FreeBasic ArrayInsert etc...

This naming looks OK to me. Indeed, if I were writing a procedural library for myself this is likely how I would name things.

[coderJeff]

There have already been discussions about how new features should be added to the language.
I can see two positions:

1.) don´t add new keywords to the main namespace, put everything new into an include file into it´s own namespace in order not to enlarge and "pollute" the main namespace.
2.) add new keywords to the main namespace, because having to use the namespace prefix all the time, is laborious and makes the code look ugly.

I'm just going to re-post what I already mentioned in audio library thread.

I would prefer to see the initial addition as an #include only as it is the most trouble free for everyone right now and would allow development to continue. And by doing this, it pretty much guarantees that the API can be 100% expressed naturally in fbc language itself.

Also, I would like to at least retain the option for a namespace as I think the major complaint from the advanced users is that fbc's many keywords just get in the way or are irrelevant for what they want to express in their code. Not just adding new keywords, but existing keywords too.

For a long term solution that will hopefully satisfy more users, then I think we are headed towards FreeBASIC Namespace Project as an advanced user option.

This is not the only option as there is possibility of having some things included by default in -lang "qb" & "fblite" but not in -lang "fb".

[coderJeff]

Well, i have learned that adding multiple new key words (like in your proposal) is a "no go" - the more the more words are needed. Some even don´t want to add one single new word to the global namespace, however justified this might be.

The macro method i propose keeps all procedures inside their namespace (no "using" needed, because the macro adds the namespace prefix [and can do other things to parameters]), therefore the only word, which could raise naming conflicts is the macro itself (one single word), which therefore gives less possibility for a naming conflict than with the other method.

1) #include + namespace is a solid method for adding stuff. It has the least impact on all existing user code.

2) For stuff that is built-in to fb, the FB namespace is reserved since long ago, and recently FBC namespace for internals. Utilizing these two namespaces for fb built-ins should allow continued development without conflicting with how users want to express their own code.

3) If at all possible I would prefer that new custom/versatile/quirk syntax be avoided. Many basics (including freebasic) have special unique syntax for some statements that can only be handled by the compiler/parser itself because of the context sensitive keywords and clauses. For example OPEN, PRINT, LINE, DRAW STRING, PUT, etc. There is no way for the user to express (construct) their own procedures using this unique syntax naturally within the language. Also there is no alternatives for invoking the procedure with normal variables/constants as an argument list due the special syntax.

4) #macro & #define are typically only usable where a simple text substitution would work. #macro & #define are not well suited as-is to extend the language itself since preprocessor has very limited capability as far as a macro language goes. Developing additional token processing operators or macro-text processing functions is a possibility, but there are other issues.

5) #macro & define do not follow same rules as other symbols. They respect scope but not namespaces. #macro's can't respect namespace due to being a simple text substitution facility and allowing forward reference. Rules could be changed, I guess. For a really old discussion on this: viewtopic.php?f=3&t=10650

Code: Select all

namespace ns
  #define G() print F
  #define F "text"
end namespace
#define F "hello"
'' which "F" will be used?
ns.G()

[coderJeff]

Hiding your new words in a namespace is only of limited help, because you must either use the namespace.procedure syntax, or you must code "using <namespace>" which then adds all of these words to the global namespace as long as "using" is active. So implementing "using" doesn´t prevent naming conflicts in all cases, if there are any.

It's completely up to the user if they use "using fb" or not, we're not forcing them to.
- they can use it, for convenience and deal with all the conflicts, their choice
- or if suits them use the fully qualified "fb." name

I have a feeling here that some difference in preference is due to the difference in how FB and PB typically use include files -- .bi versus .inc.
- A common FB practice, especially for larger projects, is to have separate .bas files compiled as separate modules, where each module can control what symbols are #included as each module has it's own global namespace.
- A common PB practice (I think), is to #include all sources from the main .bas file once, in which case there is only one global namespace.

[Josep Roca]

There is a third one that I'm using: I use include files instead of modules, but many of the includes use a namespace. I prefer to use include files instead of modules to benefit from conditional compilation and dead code removal.

[Juergen Kuehlwein]

i agree to point #1 and #2 in your preceding post, i disagree with #3 and #4 (please have a look at my pull requests: array and string. The new pp operators make a versatile syntax possible, without the need to re-write lots of the compiler) i made it work! i see your point #5 and i admit this is the only drawback, marcos are global and don´t respect namespaces. But i see it like angros47, a BASIC dialect like FreeBASIC should support at least the basic topics on it´s own (without having to include this or that before).

What i propose allows for adding new features at the cost of one (one single, only one, i promise) new key word (which could become a new global key word) for each new topic. All the rest is hidden without even a possibility of a naming conflict. It´s about weighing the pros and cons, what do i get, what must i pay for it. The price is "sacrificing" one new reserved word, the gain is a bunch of new (and expandable) features. Of course the will be users, who will have to adapt their code (mostly run a replace function in their editor, this is inevitable), but there will be a benefit for the whole community.

Talking about PB (this is where i come from), handling includes is not so much different. I know and use the concept of multiple code and include files. PB doesn´t support namespaces, so you have to be careful choosing names in order to avoid naming conflicts. There is one major difference though: As long as PB has been actively developed (until Bob´s passing), every new version brought new keywords. I never heard complains about the implications (maybe having to adapt existing code, because of new reserved words). On the contrary everyone was excited about the new possibilities the next version had to offer and people helped each other with the transition.

This is what i miss badly here sometimes, a little more enthusiasm for new things, trying to bring FreeBASIC foreward. A little more support and a little more respect for those doing the actual work (in their spare time). Only very few actually do contribute. In PB we had a beta forum for each new version and a lot of very capable people helped to test and fine tune each new version.

[Juergen Kuehlwein]

Ah, i see José cross-posted.

I would call José´s stuff "advanced" (i recommend having a look, by all all means) while the stuff i´m speaking of is far more basic. In general i´m not against including things with an include file. It´s a great method of adding (advanced - this is my point!) features. The basic features should be available through language statements, at least in language called BASIC.

[coderJeff]

- I wrote functions for basic array processing, which currently sit as a PR on Github.
- I wrote code for real unicode support of I/O functions in Window. Needs some polishing, but currently sits as a PR at Github
- I´m writing string processing functions (extract, parse, replace, remove, etc.) for all kinds of strings types (including the new dynamic wide string type). The goal is to be able to have embedded nulls in this new type just as it´s possible in STRINGs including all existing and new functions. Of course none of this will break existing code.

I have noticed the PRs. I'm grateful that you are giving up your time to contribute.

Hopefully I can be honest without offending. For a while I thought I could keep up with your efforts, offering some guidance help keep you on track, but it's not possible. There is a lot of unfinished work sitting in those PRs. I'm still working through earlier string related stuff.

[Lost Zergling]

From a purely technical point of view and common sense, I share for my part quite the point of view expressed by CoderJeff. More generally, however, I think that the idea of "user defined keywords" (UDKs), in the same way that there are UDTs, is not necessarily irrelevant, but only from the moment a coherent conceptual framework can be found. The idea would be to frame this in a declarative and procedural language (FB), which would be a challenge because it would then be possible to stand out conceptually from the object approach to reinvent something alternative but conceptually new. So I think hypothetical UDKs should go hand in hand with a real conceptual advance. How about it ?

[marcov]

Well, maybe for the dummies like me, it is wise to first define keyword narrowly in FB context.

Usually a keyword is something that the language (=compiler) knows. A language construct like FOR or While, or even PRINT if it has special syntax to parse the arguments.

However I get the feeling that people are here talking about anything in the default scope, which is a combination of keywords and the startup namespace of the libraries. (the identifiers seen without including anything)

Moreover, both keywords and default library scope could be dependent on the chosen language mode.

A similar confusion I sometimes feel with "namespace". I sometimes have the feeling namespace is used where scope is meant.

An example is the default namespace. IF you can change it by including something, it is not a namespace but a scope.

Both are bunches of compiler state (e.g. identifiers), but scope is more dynamic and a resulting from combining identifiers from multiple places.

E.g. default visible identifiers + some import that adds to that, and then a WITH that adds to the scope (but that is undone when WITH exists)

[Lost Zergling]

I agree fxm point of view as he says he doesn t see any fundamental difference with a classic namespace usage, meaning, in my opinion, the requirement of a conceptual differenciation compare to existing FB object oriented capabilities. Thus, I tend to interpret "the language" not strictly technical that is too say from user point of view the keywords he knows best, the way he will prefer using them. User define kwd idea must be understood in this context, obviously the compiler cannot invent kwd yet !!

[andykmv]

From a purely technical point of view and common sense, I share for my part quite the point of view expressed by CoderJeff. More generally, however, I think that the idea of "user defined keywords" (UDKs), in the same way that there are UDTs, is not necessarily irrelevant, but only from the moment a coherent conceptual framework can be found. The idea would be to frame this in a declarative and procedural language (FB), which would be a challenge because it would then be possible to stand out conceptually from the object approach to reinvent something alternative but conceptually new. So I think hypothetical UDKs should go hand in hand with a real conceptual advance. How about it ?

the concept of udks brings Forth to mind.
https://www.gnu.org/software/gforth/

[Lost Zergling]

I m a genious I know, my ideas whenever not formulated in my mind were already covered by GPL V3 , how could I imagine it ? Seriously again, probably not the same UDKs I had in mind whenever this idea was not yet fixed. This reminds me on the "round corners" on smartphones. How about my licence ? User can choice beetween a Cecil and a freeware and the cecil can mutate into a GPL. So far the GPL can be facing an (open source) freeware. The Public Domain then exclude itself from itself into itself. GPL is turning itself into freeware... Isn t it Great is it ?!? You may deserve my best Zerglinglies...