New array features

[Juergen Kuehlwein]

Jeff,

i don´t claim, that the solutions i found for various problems, are the most efficient solutions. I first want to make it work (somehow), then i don´t mind making it faster, better, more efficient, whatever. My overall knowledge about the compiler and how things might be done most efficent is still limited compared to yours. Nevertheless i try to find ways of acchieving what i want.

Making a pull request for every little thing (i don´t even know, if it needs to be changed or removed again or in the course of development), wouldn´t let me make any progress. I would have to wait, if it is accepted or not, or if it is accepted with changes, which might make it worthless for my purposes. I would have to justify every request (why, what for).

So i choose to go on and to make it work as a whole before making maybe useless pull requests. There is still one feature (array scan) to add, then i´m ready and open for comments, critics and improvements.

TYPEOF:
i need a method of retrieving a variables type (any type, not only the predefined ones) at run time too. Integer values representing each standard type and one for UDTs would do as well. Something like "vartype" would indeed come in handy. I´m sure there are more places, where my code could/should be improved.


JK

[MrSwiss]

@JK,

Nevertheless i try to find ways of acchieving what i want.

This sounds very self centered.
Why don't you focus more on: what the community as a whole, deems important.

Like as a first step, the possibility to distinguish between "Fix-Len" and "Dynamic"
array? This implementation (as a first step) could be a first commit, to start off
with. It might also be the only one, that people like myself whould appreciate (use
in practice). The remainder (whatever that might be), is of a far lesser interest.
(As already discussed between you and fxm.)

[fxm]

I agree.
The most important thing for a user is to add in FBC features that do not exist yet and that the user can not code himself, or do it, but in a twisted way.
For me, this ability to discriminate between an array of fixed size and an array of variable size is interesting (like the ability to easily obtain certain information contained in the array descriptor). The rest, I can code it myself in a own reusable module.

[Lost Zergling]

In my opinion, it is very important to be able to offer "high level" libraries but at the same time easy to use because it contributes to the attractiveness of the language. The question of how only arises in the case where one envisages targeted evolutions of the functions low-level, this point being outside my scope of proposal. We thus have, it seems to me, three lines of contradictory explorations: the openness to the high level, the ease, the need to preserve the performances and the low level optimization consistency. Another point to consider is that the language have to live, evolve: thus more people are attracted to language.

[fxm]

Yes, but for example for the new array copy feature:

• it would be nice to be able to write it in the natural form:
  array2() = array1()
  => evolution of the implicit 'Let operator',
• and not:
  copyArray(array2, array1)
  => where 'copyArray' would be for example a macro name in a library.

[dodicat]

In pascal you can do this for fixed length arrays, but not for dynamic arrays (which always start at element[0] thus can be regarded as pointers)
So in pascal for dynamic arrays, the result is as memcpy.
Also I notice in python (lists) that it seems to be a pointer copy also.

Code: Select all

a=[1,2,3]
b=a
b[1]=5
print(a)
#resuts was [1, 5, 3] 

What would freebasic's array2() = array1() aspire to be?
Both static and dynamic arrays with similar dimensions up to 8 resulting in completely individual arrays ?

You could perhaps extend dim byref array2() = array1() for an alternative.
At the moment:
"Array of references - not supported yet"
If any of this stuff has been done yet then I apologise, I have not been testing code in this thread.

[fxm]

What would freebasic's array2() = array1() aspire to be?
Both static and dynamic arrays with similar dimensions up to 8 resulting in completely individual arrays ?

For example, only allowed by the compiler for two arrays of the same type and number of dimensions (or the destination array of same type declared as dynamic without specifying the number of dimensions):
- If the destination array is static, copy only common elements (corresponding to all index combinations defined for both).
- If the destination array is dynamic, resize it as is the source array, and copy all the elements.

[caseih]

FB is a language that implements variables as boxes in memory that you can address, so I would expect a deep copy in FB, and that appears to be what happens. Python is more abstract and its variables do not work the same way.

Also I notice in python (lists) that it seems to be a pointer copy also.

This is obviously off topic here, but it's interesting. Python "variables" are simply names bound to objects, not slots in memory. In Python "=" is not copying, but rather binding a name to a value or object. The same object can have multiple names bound to it. Also objects like a list can refer to other objects of course. If one needs an actual copy of a list or other mutable object, there's a bunch of methods for doing this in the copy module. When an object is unbound from a name, or a reference is removed, the count on the object is decremented and when it hits zero, the garbage collector will remove it, which works well most of the time if the references are not circular.

[Juergen Kuehlwein]

This sounds very self centered.

Sigh...

Despite of the fact, that i´m definitely not the most experienced FreeBASIC compiler coder (Nevertheless) i try to find ways of acchieving what i want (the compiler to do)


If Jeff accepts my appoach for this specific problem, there will be something like this:

Code: Select all

dim a(1 to 5) as long

...

if array(isfixed, a) then

...

This would be a wrapper for a RTL function, which inside the RTL could be used for fixing the issues about erasing fixed size arrays you dicussed with Jeff. Tests show, that combining binaries compiled with prior versions of the compiler with new binaries doesn´t raise combatibility problems. The only drawback would be that as long as "old" binaries are involved you cannot tell for sure, if an array is of fixed size or not (just as you cannot right now).

All array macros returning a value will finally be written in a way that they can be used in a function like manner even inside expressions.


And there will be methods of retrieving the descriptor values e.g.

Code: Select all

dim a(1 to 5) as long
dim p as any ptr

...

p = array(data, a)  'returns pointer to memory location, where the array´s data is stored

...

Of course there are coders here, who don´t need array sort/insert/..., because they can easily code it themselves. But i think the average FreeBASIC user will appreciate a ready made high level solution. I ran some speed tests, it seems that my implementation runs at least as fast as dodicat´s code from this thread.


JK

[fxm]

I hope that all these new features for arrays will be compatible not only of all types predefined by fbc (including the var-len string, the fix-len strings, the pointers, ...), but also any type defined by the user (taking into account its own constructors/destructor and overload operators if exist).

[Juergen Kuehlwein]

It will be compatible with all kinds of arrays, i will do my very best ;-)

[speedfixer]

@MrSwiss:

This sounds very self centered. ...

Are YOU extending, fixing, maintaining the language? Has his effort cost YOU something?
He has made it clear: he is not sure what he will do, how he will solve all problems, what he will change while working toward his goal. An early commit fixes a POSSIBLE fix for an issue. To change it, now it then becomes a triple step to get what he would need. THAT is not a smart very practice.

If YOU want something, YOU should author and submit that change. Or is that too self-centered?

@fxm

The most important thing for a user is to add in FBC features that do not exist yet and that the user can not code himself, or do it, but in a twisted way.

You are making valuable contributions on the wiki and helping many, many people improve their code with your perceptive, critical eye. Clearly, your knowledge of FB is deep. But ... what does an added feature teach a newbie when it is added "in a twisted way"? Is the message to be: obfuscation and code tricks are a good practice? Or - go away, you aren't ready for this?

Someone said: Everything Should Be Made as Simple as Possible, But Not Simpler
Are you smarter than that guy?

All of you:
1 - JK IS attempting to add new features
2 - it is his desire; he is making the effort and not doing it in secret and is inviting the community to help
3 - he has been sensitive to advice and criticism from others - trying to follow any rules suggested to him

You should all be applauding him.

[fxm]

But ... what does an added feature teach a newbie when it is added "in a twisted way"? Is the message to be: obfuscation and code tricks are a good practice? Or - go away, you aren't ready for this?

Maybe I did not express myself well, but on the contrary I wanted to say that it is better to have a proper feature added in fbc to prevent the user from being content with a twisted personal code.

[speedfixer]

@fxm:

Please forgive me. I thank you for the clarification.


david

[MrSwiss]

If YOU want something, YOU should author and submit that change. Or is that too self-centered?

Yes, as soon as nobody else of the community as a whole, gains anything by doing so.