Suggestion about the inner Dictionary or Collection.
Suggestion about the inner Dictionary or Collection.
Suggestion adding the inner Dictionary or Collection in FB.
Just like VB/VBA or ArrayList in C#.
Sorry for my poor English.
Just like VB/VBA or ArrayList in C#.
Sorry for my poor English.
Re: Suggestion about the inner Dictionary or Collection.
Do you suggest to implement it using hash table or binary tree?
Re: Suggestion about the inner Dictionary or Collection.
At this point it seems pretty safe to assume there won't be any fancier data structures installed with FB by default until it natively supports some sort of generics.
There are dozens of FB implementations of Dictionaries and other things that could've been picked up and included at some point in the last 15 years if there was a desire to do so. I mean, the compiler source code includes a list, stack, pool and hash table so it isn't as if nobody had ever heard of those things or of their utility
There are dozens of FB implementations of Dictionaries and other things that could've been picked up and included at some point in the last 15 years if there was a desire to do so. I mean, the compiler source code includes a list, stack, pool and hash table so it isn't as if nobody had ever heard of those things or of their utility
Re: Suggestion about the inner Dictionary or Collection.
Actually, there are two possibilities: one is implementing generics, the other is implementing only some containers (dictionaries and lists, for example) as part of the language.
Both solutions have advantages and disadvantages: generics and templates is surely more versatile, although more like c++. It would allow to implement every possible container, and even to invent new ones (although, is that really needed? In C++ I never saw someone creating new containers). Likely it's also easier to implement in the compiler. Of course, every time a container is needed you'd have to include the specific header
Implementing some containers directly in the language would be more "basic", and more immediate to learn for beginners. Although it would pollute the namespace, bloat the runtime, and would allow only a limited set of containers (that might be enough). It would be more consistent with the BASIC philosophy, that provides everything out of the box. Also, one container (vector) is already pretty similar to dynamic arrays used in FreeBasic.
So far, most people seem interested to go toward generics. It wouldn't be bad, after all even BlitzMax (that is considered a BASIC dialect) uses generics. I wonder: is there general consensus that the right way to go is generics, and not pre-built containers?
Both solutions have advantages and disadvantages: generics and templates is surely more versatile, although more like c++. It would allow to implement every possible container, and even to invent new ones (although, is that really needed? In C++ I never saw someone creating new containers). Likely it's also easier to implement in the compiler. Of course, every time a container is needed you'd have to include the specific header
Implementing some containers directly in the language would be more "basic", and more immediate to learn for beginners. Although it would pollute the namespace, bloat the runtime, and would allow only a limited set of containers (that might be enough). It would be more consistent with the BASIC philosophy, that provides everything out of the box. Also, one container (vector) is already pretty similar to dynamic arrays used in FreeBasic.
So far, most people seem interested to go toward generics. It wouldn't be bad, after all even BlitzMax (that is considered a BASIC dialect) uses generics. I wonder: is there general consensus that the right way to go is generics, and not pre-built containers?
-
- Posts: 538
- Joined: Dec 02, 2011 22:51
- Location: France
Re: Suggestion about the inner Dictionary or Collection.
As you can easily guess, I do prefer pre build containers (see lzle project and doc). The reason why is the compromise between easyness and versatility.
Well, I suppose this can also be achieved using generics, but you'd have to dig deeply in the language, to such an extent that it is not transparent to compiler.
So it is not just a question of 'immediate' (hum) learning, it also depends the targetted level (high or low).
I don't think lzle would pollute the namespace, because everything is done throught a single object's properties (type list) wich can be renamed in case of necessity.
The runtime speed will be depending on the use cases knowing that some the very versatile features making code less complicated do have a cost wich would need to be taken into account in comparison with generics. (ie pointer chasing in java, iterators design in c++).
But yes, for some use cases it will not be the mist appropriate solution (ie no need to build an index to sort strings).
By the way pre built containers proposal will impose a 'coding style' but enable a conceptual jump with ease.
Generics will require some very good skills in c c++ and compiler behaviour but faster results shall be expected.
Well, I suppose this can also be achieved using generics, but you'd have to dig deeply in the language, to such an extent that it is not transparent to compiler.
So it is not just a question of 'immediate' (hum) learning, it also depends the targetted level (high or low).
I don't think lzle would pollute the namespace, because everything is done throught a single object's properties (type list) wich can be renamed in case of necessity.
The runtime speed will be depending on the use cases knowing that some the very versatile features making code less complicated do have a cost wich would need to be taken into account in comparison with generics. (ie pointer chasing in java, iterators design in c++).
But yes, for some use cases it will not be the mist appropriate solution (ie no need to build an index to sort strings).
By the way pre built containers proposal will impose a 'coding style' but enable a conceptual jump with ease.
Generics will require some very good skills in c c++ and compiler behaviour but faster results shall be expected.
Re: Suggestion about the inner Dictionary or Collection.
Well, using generics you wouldn't have to dig deeply in the language, all you have to do is to include a simple header file. In C++ (that uses generics), if you want to implement a linked list, or an associative array, you can dig in the language, but you don't have to if you don't want. Declaring an associative array can be done with one single command.
Point is: there are many ways to implement a container: as I stated before, for example, to implement a dictionary you can use a binary tree, or a hashtable (and there is no "better" or "worse" methods: both have advantages and disadvantages). The languages that offer standard containers in the language itself must limit to the most used ones (Lua, for example, offers only hash-based dictionaries). A language that relies on generics can offer every single possible container (C++ allows to use both binary tree dictionaries and hash based dictionaries, for example)
Point is: there are many ways to implement a container: as I stated before, for example, to implement a dictionary you can use a binary tree, or a hashtable (and there is no "better" or "worse" methods: both have advantages and disadvantages). The languages that offer standard containers in the language itself must limit to the most used ones (Lua, for example, offers only hash-based dictionaries). A language that relies on generics can offer every single possible container (C++ allows to use both binary tree dictionaries and hash based dictionaries, for example)
Re: Suggestion about the inner Dictionary or Collection.
Generics is not just about defining all new containers. It is also about specializing them. E.g. specializing a hash with a type safe list or record with key,value type etc. This is way, way more common. (but I do also have some own build container types in e.g. Delphi)
It would be more basic interpreter yes, but FB is a compiler.Implementing some containers directly in the language would be more "basic", and more immediate to learn for beginners.
I think that is pretty slam dunk. Even some easy builtin containers could be implemented in generics and then shoved into the general namespace. The question is only if FB can afford developing generics, and which model (more Java/C# or C++, with the latter being more complicated) it should follow.So far, most people seem interested to go toward generics. It wouldn't be bad, after all even BlitzMax (that is considered a BASIC dialect) uses generics. I wonder: is there general consensus that the right way to go is generics, and not pre-built containers?
Re: Suggestion about the inner Dictionary or Collection.
Freepascal has more recently developed generics (Within these last 3 years if I am not mistaken)
IMO it is a great boon to the language, especially generic procedures, functions, records(types).
They are not all that different to C++ generics/templates as far as the user is concerned.
Freebasic has a more powerful macro than freepascal, and in the meantime the fb macro has to suffice.
One of the next logical steps in fb is generics, I would say, but with only a couple of developers I think it would be a massive amount of work.
And there aren't too many active members around these days to thoroughly test things (to destruction if necessary).
IMO it is a great boon to the language, especially generic procedures, functions, records(types).
They are not all that different to C++ generics/templates as far as the user is concerned.
Freebasic has a more powerful macro than freepascal, and in the meantime the fb macro has to suffice.
One of the next logical steps in fb is generics, I would say, but with only a couple of developers I think it would be a massive amount of work.
And there aren't too many active members around these days to thoroughly test things (to destruction if necessary).
Re: Suggestion about the inner Dictionary or Collection.
Work on generics started in 2007, and the first release version with Delphi compatible generics was 3.0 in 2015
Delphi compatibility of specially the libraries with predefined classes, is mainstream since 3.2.0 in june 2020, but those libraries emerged in 2015-2017 and were already as add-on for older versions.
Trunk contains some further out bits like auto specialization of generic functions.
FPC is a hybrid because FPC itself started out more C++ like, but Delphi more C# like (more declarative)IMO it is a great boon to the language, especially generic procedures, functions, records(types).
They are not all that different to C++ generics/templates as far as the user is concerned.
Or simply generators (e.g. external macro processors) from a template, which are more debuggable than macros.Freebasic has a more powerful macro than freepascal, and in the meantime the fb macro has to suffice.
But yeah, it is a non trivial feature.
-
- Posts: 538
- Joined: Dec 02, 2011 22:51
- Location: France
Re: Suggestion about the inner Dictionary or Collection.
Interesting debate, I'm back to original post from IBMInfo78, sorry.
Just go to lzle project page viewtopic.php?t=26533
Practical solutions you should handle almost quickly and easyly in FB till you already have some practise around Basics like lists and friends. Some more advanced features are designed to workaround the fact it is not really 'generic', meaning you may not be 'blocked' in the future by a missing functionnality. Have a try and have fun.
Questions, bugs report, exp returns are possible and welcome.
Ps : ok, it is not 'inner'. I'm not sure it could be. But it is just a copy past to use it.
Just go to lzle project page viewtopic.php?t=26533
Practical solutions you should handle almost quickly and easyly in FB till you already have some practise around Basics like lists and friends. Some more advanced features are designed to workaround the fact it is not really 'generic', meaning you may not be 'blocked' in the future by a missing functionnality. Have a try and have fun.
Questions, bugs report, exp returns are possible and welcome.
Ps : ok, it is not 'inner'. I'm not sure it could be. But it is just a copy past to use it.