Welcome, Guest
Username: Password: Remember me
This public forum is meant for questions and discussions about Visual FoxPro
  • Page:
  • 1

TOPIC:

Input needed on FoxPro array support 23 Nov 2020 22:07 #16750

  • robert
  • robert's Avatar
  • Topic Author


  • Posts: 3289
  • We are working on the implementation of the FoxPro array support.
    From what we have seen the FoxPro arrays are one dimensional arrays that also support a 2 dimensional indexes.
    You can declare an array like this
    Dimension myArray(2,2)
    myArray(1,1) = 1
    myArray(1,2) = 2
    myArray(2,1) = 3
    myArray(2,2) = 4
    and then access
    myArray(4) and see the value 4.

    or
    Redimension the array to
    Dimension myArray(4)
    and see that the contents has been saved and the elements have the values 1 through 4.

    We have this working.

    However this works quite different from the array support that we already have in the system, which is based on the Clipper array support (sometimes also called Ragged Arrays) where each array is in fact a single dimensional array, but the elements of the array can also be arrays, which allows unlimited nested arrays. This array support is also available in Visual Objects, Vulcan and Xbase++.

    The questions that we have are:
    1) In the FoxPro dialect should there be both the FoxPro compatible arrays (for example declared with the Dimension keyword) and Clipper compatible (Ragged) arrays ? Or should we map the ARRAY keyword in the FoxPro dialect to the special FoxPro array type?
    2) There are many functions in the FoxPro runtime that take an not declared, unitialized array and fill the array. See for example this code from the VFP helpfile:
    Set PATH TO (HOME(2) + 'data\')     && Sets path to database
    Open Database testdata && Opens the database
    ? ADatabases(gaDatabase)     && Creates an array of open databases

    As you can see gaDatabase is not declared and not initialized. The runtime magically creates the array inside the ADatabases() function and adds it as private to the function that called it.

    In most other XBase dialects you would write it like this
    LOCAL gaDatabase           && declare the array (could also be PRIVATE gaDatabase)
    ? ADatabases(@gaDatabase)     && pass the array by reference so ADatabases() can create it 

    or
    LOCAL gaDatabase           && declare the array (could also be PRIVATE gaDatabase)
    gaDatabase = ADatabases()      && then the array gets returned, but we loose the numeric return value

    How common is this kind of code (like the example from the help file) in your code? Would it be a problem to require people to declare the private first. We can add the @ character automatically in the compiler. We already have support for that.

    If it is a problem to require people to declare the variable first then it would also be possible to mark functions such as ADatabase() with a special attribute in the runtime, so the compiler "knows" that this is a function that may create a new local and then it can automatically generate a private (or local) declaration at compile time.

    Robert
    XSharp Development Team
    The Netherlands

    Please Log in or Create an account to join the conversation.

    Input needed on FoxPro array support 25 Nov 2020 23:15 #16762

    • atlopes
    • atlopes's Avatar


  • Posts: 84
  • Robert,

    I'll try to refer to as many points as possible and number them in the process to facilitate further references.
    1. DIMENSION an array not previously declared creates a PRIVATE array.
    2. DIMENSION an array that was previously declared respects the current scope of the array (PUBLIC, PRIVATE, or LOCAL).
    3. All elements of a DIMENSIONed or LOCAL ARRAY are initialized to FALSE.
    4. All the Axxxx() functions that populate an array with some content start by creating a PRIVATE array if it does not exists. Otherwise, they operate as the DIMENSION command.
    5. The first parameter of the Axxxx() functions is passed by reference.
    6. Elements of a bidimensional array can be addressed as if the array is unidimensional (the contrary is not supported).
    7. The array can be used as a simple variable (if Qry is the name of an array, ? Qry is possible and refers to the first element of the array).
    8. All elements of the array can be assigned at once with a single statement (Qry = "x" stores the value "x" to all elements, no matter if the array is bi or unidimensional).
    9. Arrays can be a property of a class, declared as DIMENSION propertyName(initialDimension) in the property section of the class definition.
    10. An array property can also be added to an object in run time using the ADDPROPERTY() function or the AddProperty() method of containers.
    11. Imposing the need for variable declaration - arrays or not - will break lots of VFP code. Is it possible for a pre-processor to look for undeclared variables and make the necessary amends (at least for arrays)?

    Other aspects may come to mind with further discussion. I hope this covers most of the behavior that will require your attention.

    Please Log in or Create an account to join the conversation.

    Input needed on FoxPro array support 26 Nov 2020 09:12 #16763

    • robert
    • robert's Avatar
    • Topic Author


  • Posts: 3289
  • Antonio,
    Thanks for your input.
    What about question 1:
    In the FoxPro dialect should there be both the FoxPro compatible arrays (for example declared with the Dimension keyword) and Clipper compatible (Ragged) arrays ? Or should we map the ARRAY keyword in the FoxPro dialect to the special FoxPro array type?

    Robert
    XSharp Development Team
    The Netherlands

    Please Log in or Create an account to join the conversation.

    Input needed on FoxPro array support 26 Nov 2020 21:52 #16771

    • atlopes
    • atlopes's Avatar


  • Posts: 84
  • Robert,

    As a rule of thumb, I would prefer a combination of retro compatibility support with additional features. Of course, I cannot fathom the dimension (sorry for the pun...) of the task.

    Please Log in or Create an account to join the conversation.

    Input needed on FoxPro array support 26 Nov 2020 23:05 #16772

    • robert
    • robert's Avatar
    • Topic Author


  • Posts: 3289
  • Antonio,
    So would it be OK with you if the Dimension and Declare statements produce a FoxPro compatible array (as well as functions like ADatabases).
    And a declaration like
    LOCAL myArray AS ARRAY
    or
    VAR myArray := {1,2,3}
    would then produce a Clipper compatible array, that can grow with functions such as AAdd()

    Robert

    PS Is there a syntax for a "literal array" in FoxPro? I have not found it.
    XSharp Development Team
    The Netherlands

    Please Log in or Create an account to join the conversation.

    Input needed on FoxPro array support 27 Nov 2020 17:37 #16781

    • atlopes
    • atlopes's Avatar


  • Posts: 84
  • Robert,

    Yes, I think that the way you're proposing would be great. Just a note I would like to add: the syntax
    PUBLIC ARRAY x(1)
    LOCAL ARRAY y(1)
    should also produce FoxPro like arrays (scoped as the declaration suggests).

    I can confirm that there is no way to create literal arrays in FoxPro.

    Please Log in or Create an account to join the conversation.

    Input needed on FoxPro array support 27 Nov 2020 17:38 #16783

    • robert
    • robert's Avatar
    • Topic Author


  • Posts: 3289
  • Antonio,
    Thanks.

    Robert
    XSharp Development Team
    The Netherlands

    Please Log in or Create an account to join the conversation.

    Input needed on FoxPro array support 29 Nov 2020 20:01 #16791

    • mainhatten
    • mainhatten's Avatar


  • Posts: 199
  • Hi Robert,
    Antonio already ticked off most of the things to watch out for. Only a few things left unsaid after on 27. adding local [ARRAY] la(arraydim):
    Numbering to his first answer:
    4 ) vfp will check whether the first parameter exists or not - but if it exists it is also checked if it really is a vfp Array, otherwise error.
    8 ) the ability to set all array elements with a single line without referring array element like
    laMyArray = luForWholeArray
    this encompasses only simple data types like strings, dates or numbers - you cannot assign an object to all array elements at once, those must be assigned to individual array elements.
    9 and 10: for me one of the more illogical syntax parts in vfp, in prg code class code you use Dimension again, whereas in object.addproperty("aMyNewArrayProperty[3]" [, ValueforAllNewElements)
    method plus the addproperty function with the object as first parameter.indicating dimensionality inside property name string is enough.
    Here I wonder if it is enough to have a Clipper ragged array as last parameter on a undimensioned property name, but see no obstacles, as
    obj.addproperty("PropertyName", createobject("MyWishedforClass")) adds complex property, which could be the ragged type

    robert wrote: So would it be OK with you if the Dimension and Declare statements produce a FoxPro compatible array (as well as functions like ADatabases).
    And a declaration like

    LOCAL myArray AS ARRAY
    or
    VAR myArray := {1,2,3}
    would then produce a Clipper compatible array, that can grow with functions such as AAdd()

    gets also strong yes, perhaps with new keyword RAGGEDARRAY to register when speedreading code - as long as previously written vfp code works as expected, having more code options is a benefit. Would the vartype(RaggedArray)/type("RaggedArray") be "O" with further checking the object or a new return value like "R" ? Checking Alen() probably could not differentiate between vfp and RAGGEDARRAY ?

    How common is this kind of code (like the example from the help file) in your code? Would it be a problem to require people to declare the private first. We can add the @ character automatically in the compiler. We already have support for that.

    If it is a problem to require people to declare the variable first then it would also be possible to mark functions such as ADatabase() with a special attribute in the runtime, so the compiler "knows" that this is a function that may create a new local and then it can automatically generate a private (or local) declaration at compile time.


    On 11) I think I wrote a simple Try Catch when topic was raised a few months back which will handle creation of non-existing variable without heavy lifting, can en passant check that any existing variable really is a vfp array and otherwise throw error - Adding automatic @ / ref parameter after parse as not in vfp code for first parameter should be easy.in same step.
    If every vfp Array function is automatically wrapped with that Try Catch no real speed or other problems should crop up...

    edit: rethinking a bit, as 1. parameter is a reference, perhaps not even try-catch is needed if the macrocompiler works without failure if encountering lines along
    lnLines  =  ALINES(&tcMak, "1,2,3,5",5,",")
    where tcMak might be a string parameter the compiler cannot parse in advance, as checking only is done on globals, privates and locals in that scope defined by function or method.
    /edit

    regards
    thomas

    Please Log in or Create an account to join the conversation.

    Last edit: by mainhatten.

    Input needed on FoxPro array support 23 Mar 2021 18:23 #17836

    • jpmoschi
    • jpmoschi's Avatar


  • Posts: 76
  • I found this nice thread about foxpro arrays.
    It is clear that all of you catch the real situation.
    I even gave you examples to help to understand the case without lost the macrosubsitution.
    I understand the problem between brackets and parenthesis and accept the brackets like a good solution.

    When do you think I'm going to be able to jump to the latest version? And when do you think the vectors are going to be reasonably contemplated?

    Best regards
    Juan

    Please Log in or Create an account to join the conversation.

    Input needed on FoxPro array support 23 Mar 2021 22:28 #17838

    • robert
    • robert's Avatar
    • Topic Author


  • Posts: 3289
  • Juan,

    We plan to release a new version (2.8 ) of the product 2-3 weeks from now. This will include the new FoxPro array support, but will NOT support the Parenthesized array operators. So it will work with square brackets only. The only place where parentheses will be allowed is in the DIMENSION statement and in the LOCAL ARRAY statement.
    It also includes improved support for exposing locals in your code to the X# runtime. In fact you will no longer have to use the ./fox2 compiler option to tell the compiler that your code wants to expose locals.
    We have added a special attribute to the runtime and we have marked functions that need to read and/or write to local variables with this attribute. The compiler now checks for this attribute and will automatically add code to make locals visible to the runtime.
    Examples of runtime functions that are marked with this attribute are SqlExec(), the Redim functions for foxpro arrays, Evaluate(), Type() etc.

    The Dimension statement should also work and it should also allow you to re-dimension arrays without loosing the contents of the array.
    The only thing that I am not sure about if we can include in the next build is the construct where you pass the name of the variable in a macro to the dimension statement like in
    DIMENSION &varName.(10).
    This may or may nor be easy I need to have a look.
    Your test code to test various array functions is part of our test suite now (see github.com/X-Sharp/XSharpDev/blob/main/T...ns/C771/Prg/C771.prg) We will use this to fix and test the array support.

    Robert
    XSharp Development Team
    The Netherlands

    Please Log in or Create an account to join the conversation.

    Last edit: by robert.

    Input needed on FoxPro array support 25 Mar 2021 16:27 #17851

    • kevclark64
    • kevclark64's Avatar


  • Posts: 123
  • I don't know how hard it would be to implement, but 1 of the things that I've always wished I could with Foxpro arrays is to declare an array with members, such as Dimension myArray = {1,2,3}

    It would be great to be able to use that syntax but otherwise have the array be a standard Foxpro array.

    Please Log in or Create an account to join the conversation.

    Input needed on FoxPro array support 25 Mar 2021 17:24 #17855

    • robert
    • robert's Avatar
    • Topic Author


  • Posts: 3289
  • Kevin,

    Right now we do not support this for FoxPro arrays. But we could add that when needed.

    FYI: FoxPro arrays are implemented as a type that inherits from the "normal" XBase array and the literal that you specify in your example is a "normal XBase array" at this moment.

    These XBase arrays are quite different from FoxPro arrays, since every array element may contain another array element. And you can nest them infinitely. You can even point an array element back to the root of the array (circular arrays).
    So you cannot redimension them from (2,5) to (5,2) and expect the values to be saved.

    However if you code in the FoxPro dialect then you can use the Normal XBase arrays as well.
    You just have to declare them in a different way:
    LOCAL myArray = {1,2,3}   AS ARRAY    // AS ARRAY is optional but will produce better code
    or
    VAR myArray := {1,2,3}     // := required at this moment

    or
    myObject.Property = {1,2,3}

    You can also use similar functions ALen(), AIns() and ADel() but they work a bit different.

    Robert
    XSharp Development Team
    The Netherlands

    Please Log in or Create an account to join the conversation.

    Last edit: by robert.

    Input needed on FoxPro array support 05 Jul 2021 08:49 #18977

    • mainhatten
    • mainhatten's Avatar


  • Posts: 199
  • robert wrote: We plan to release a new version (2.8 ) of the product 2-3 weeks from now. This will include the new FoxPro array support
    ...
    The Dimension statement should also work and it should also allow you to re-dimension arrays without loosing the contents of the array.

    Hi Robert,
    there is a chance I might enhance GetWord.Prg in August to cover alines() functionality as well (if it is not already assigned or done). There are a few kinks in alines() having more features (read behäviours to implement) than what is plausible or expected from documentation.
    This could lead to sometimes having discrete implementations for edge cases to keep performance at vfp expectation level. But I already have some ideas how to to hook up the patterns currently used with the approach already for some scenarios - should cover most usage currently done in vfp similar to the "separators" from there for default, single parse char and list of single parse chars. Perhaps take a stab at table munging with GetWordCount/GetWordNum "better practice". Hope by then a good idea for string "Parsechar" list comes up.
    Till August I'll get myself reaquainted with x# (have not played a lot with newer versions). Will holler if I get bribed into doing other stuff and have not enough time to do it.

    regards
    thomas

    Please Log in or Create an account to join the conversation.

    Last edit: by mainhatten.

    Input needed on FoxPro array support 05 Jul 2021 19:59 #18995

    • mainhatten
    • mainhatten's Avatar


  • Posts: 199
  • Robert,
    looked up current version of GetWord - I still recognize it ;-)

    When fumbling along without real knowledge what declarations like "new export method" map to when overriding I was glad when I found something working (tested in detail only speed differences of delegate method vs. classic method overload for single char, Whitespace and so on).

    Are your changes just more in line with current coding style, but resolving to equally performant IL (or perhaps identical IL sometimes) or are some constructs addled with slower performance ?

    Can you point me somewhere in the docs to read up on, as I saw nothing on "best practice" and more or less coded by trial and error ? I believe I know more than typical vfp coder about runtimes like IL or JVM and their concepts, but when searching back then in part in C# literature and x# docs I was info overloaded without guiding light, map or compass. Will probably happen to other vfp as well. I can read "Core-x#" now better and will try to find my hints in those sources, but a hint in the docs on what keywords map to and are best practice might help those coming in and run headlong into new world of Dotnet, Visual Studio, Compiler switches and much more.

    tia
    thomas

    Please Log in or Create an account to join the conversation.

    • Page:
    • 1