LISP Atom in autoit

[NerdFencer]

Although I am relatively new to the AutoIt language, I have found it quite useful. One thing that I personally believe could be improved about the language is the lack of the atom data type that is used exclusively in LISP. If I were to make the required source code revisions and submit the added features to support this, would anybody else find it useful?

[AdmiralAlkex]

I am not a developer of AutoIt nor do I know much about data-types so feel free to ignore what I am about to say.

So as I didn't know whaw the "atom data type" was i googled and ended up here and after reading that I somehow got the understanding that they work like a variable created with Global but what would then be the reason to have it??

Could you perhaps explain why you "found it quite useful" and what it's purpose are??

And how do you expect to get the source code for AutoIt? It hasn't been freely available for a very long time and more than one thing has changed since the old sources lying in the download archive were new.

[NerdFencer]

Ok, I am not a developer either, but i could write general functions that a developer could fairly easily meld into the source.

Speaking of which, I forgot to ask in my orig post if any developer would be willing to patch it in if i made it...

Your conceptualization of the atom data type is also incomprehensibly incorrect, so I will attempt to explain it in some form here...

The atom is a variable with 2 parts a CAR (where the data is stored) and a CDR (a link to another atom, or NIL).

In using the atom for list processing you can create a function that evaluates the CAR of the Atom, then passes itself the CDR of an Atom.

This and other properties make it ideal for list processing in any form.

Although that isn't a very detailed description, it gets the general point across.

[-Ultima-]

Hah, CAR and CDR... haven't seen those 2 in forever xD

What you're describing is a linked list, which is what lists are in LISP. LISP lists do have CARs and CDRs; LISP atoms (AFAIK/AFAIR) don't.

As far as whether anybody else would find it useful... Truthfully, I haven't seen in many (if any) situations where I needed linked lists to do anything. I'd rate built-in/native associative arrays with a higher priority/usefulness factor than linked lists, but that's probably besides the point muttley

Edited July 8, 2008 by -Ultima-

[AdmiralAlkex]

I wish you had ignored me muttley

I am afraid I didn't understand much of that at all so I think I will retreat and watch this thread from a distance. (Like climbing up my neighbours tree and use a pair of binoculars to read my computer screen )

[Valik]

It's not going to happen. As mentioned, you just described a linked-list. AutoIt is mostly a typeless language so there's really no place for a linked-list type.

[NerdFencer]

Hah, CAR and CDR... haven't seen those 2 in forever xD

I work with them every day

What you're describing is a linked list, which is what lists are in LISP. LISP lists do have CARs and CDRs; LISP atoms (AFAIK/AFAIR) don't.

It all depends on which standard for lisp you are using (there are a lot of them)

As far as whether anybody else would find it useful... Truthfully, I haven't been in many (if any) situations where I needed linked lists to do anything. I'd rate built-in/native associative arrays with a higher priority/usefulness factor than linked lists, but that's probably besides the point muttley

The point for me isnt the need for them, it is the ease of doing things with them instead of with the alternative.

[-Ultima-]

The only thing that's slightly more difficult about arrays (at least with what you've described -- passing it into a function as a parameter, then recursively calling the function with the CDR) is that you'd have to manually keep track of the index (and whether it's out of bounds). But that's completely trivial, and takes probably one additional parameter (for keeping track of the index). Bounds checking for arrays would just be comparing the current index with the array capacity, as opposed to comparing the CAR against null (or whatever). I'm not even sure an additional parameter is needed either -- you can store the current index as the first element in the array too. In that way, you can create some _CAR() and _CDR() function, where _CAR() returns $avArray[$avArray[0]] (after bounds checking), and _CDR() simply increments $avArray[0] and returns $avArray.

Basically, an array can be easily made to emulate a linked list without too much performance penalty. On the other hand, linked lists can't be made to emulate arrays without a hit for... say, direct element access. I don't see linked lists as being all that easy to use (at least, not really easier than arrays). Then again, I guess I don't try to solve the same problems as you might.

Indeed, different problems can be solved more easily or efficiently with different models (data representations), but linked lists don't really make problems easier to solve, overall (which your posts sorta seem to be hinting at).

Edited July 8, 2008 by -Ultima-

[Valik]

Implementing a singly-linked-list or even a doubly-linked-list is rather trivial to do with an array. Sure, the data is stored in a linear array. But, if you use a 2D array, with 2 (single) or 3 (double) elements, then element0 can be the data, element1 can be "next" which would be an index into the array and optionally element2 could be "previous" which would also be an index. New items are added at the end of the array as far as storage goes but the insertion takes place by adjusting the "next" (and "previous") elements of the array. Deleting items just removes the references from the adjacent elements but doesn't actually do anything else (Could be a memory waste if items are deleted a lot, but then a simple garbage collection scheme could be contrived). A handful of Insert* functions for quick positioning. And the obligatory Data(), Next() and Previous() type functions for iteration and data-access and you're all set. The actual implementation, should of course, be hidden from the user. All access should be handled via functions so the user can just treat the list as an opaque handle to a linked-list.

In short, implementing them is pretty straight-forward. Couple hours or less and a nice set of functions can be turned out for working with linked-lists. My implementation wouldn't really deviate too much from my C++ implementation (except it wouldn't have iterators, although I could contrive something like for_each() with callback support for list traversal and operations).

[James]

To me, it sounds like Valik is thinking of adding the functions, however above he said no.

[NerdFencer]

Truthfully, although the recursive abilities that this would make more feasible are nice, what I am hoping for is a little more interesting. Because of the nature of this data construct in LISP, you can implement haphazardly dimensioned arrays by passing the CDR to CAR. This basic functionality is one of the reasons that LISP is the one true language of AI.

EX of haphazardly dimensioned array concerning fruit:

((apple (color green red) Malus_domestica) (grapefruit (color (inside red pale-yellow) (outside orange yellow) Citrus_paradisi)))

This makes it so you do not need the extra memory space that all the dimensions that hardly anything uses occupies. (to store this data in an array right now, it would have to be 3-dimensional)

[Valik]

To me, it sounds like Valik is thinking of adding the functions, however above he said no.

I was talking about implementing it with AutoIt, not in C++ and exposing it to AutoIt. In other words, there's nothing stopping somebody from writing their own linked-list functions in AutoIt.

Truthfully, although the recursive abilities that this would make more feasible are nice, what I am hoping for is a little more interesting. Because of the nature of this data construct in LISP, you can implement haphazardly dimensioned arrays by passing the CDR to CAR. This basic functionality is one of the reasons that LISP is the one true language of AI.

EX of haphazardly dimensioned array concerning fruit:

((apple (color green red) Malus_domestica) (grapefruit (color (inside red pale-yellow) (outside orange yellow) Citrus_paradisi)))

This makes it so you do not need the extra memory space that all the dimensions that hardly anything uses occupies. (to store this data in an array right now, it would have to be 3-dimensional)

Have you tried storing an array inside an array element? Do so, you might be surprised at the result. Remember, AutoIt's variables are of Variant "type" so anything you can store in a variable can be stored in an array element, too, because they are Variants as well. For example:

; Data
Local $a1[2] = [ "red", "blue" ]
Local $a2[3] = [ "more", "useless", "data" ]
Local $s3 = "Data again"

; Container
Local $aContainer[3] = [ $a1, $a2, $s3 ]

; Loop through container printing data.  Recurse into arrays (1 level)
For $i = 0 To UBound($aContainer) - 1
   ; Grab the data
    Local $vData = $aContainer[$i]

   ; Check if it's a single-dimension array, if so, print the contents.
    If IsArray($vData) And UBound($vData, 0) = 1 Then
        For $j = 0 To UBound($vData) - 1
            ConsoleWrite("Container[" & $i & "], Array[" & $j & "]: " & $vData[$j] & @CRLF)
        Next
    Else
       ; Not an array, just display the data as-is.
        ConsoleWrite("Container[" & $i & "]: " & $vData & @CRLF)
    EndIf
Next

[NerdFencer]

Have you tried storing an array inside an array element? Do so, you might be surprised at the result. Remember, AutoIt's variables are of Variant "type" so anything you can store in a variable can be stored in an array element, too, because they are Variants as well. For example:

I had actually not tried that before in AutoIt, and that is a nice feature, but it could be made better by allowing implicit merging instead of explicit merging EX:

Explicit:

; Data

Local $a1[2] = [ "red", "blue" ]

Local $a2[3] = [ "more", "useless", "data" ]

Local $s3 = "Data again"

; Container

Local $aContainer[3] = [ $a1, $a2, $s3 ]

Implicit

; Container

Local $aContainer[3] = [ [ "red", "blue" ], [ "more", "useless", "data" ], "Data again" ]

that way when you are loading up a database, you don't have x number of extra arrays floating around with the data, and running the machine out of ram (Most of the AI projects I have been involved in could easily run a well-equipped (8 gig of ram) machine out of ram when queried with something like "Hi, How are you?") Although not a perfect solution, this would be a good improvement that could add a good amount of power to the language.

What do you think?

[Valik]

Given that the behavior purely a fluke and not a design decision, I wouldn't hold your breath on seeing it get improved any time soon. It won't be removed but there are no plans to support it any further, either.

Your point is moot, anyway. My example is contrived and obviously all the variables are at global scope. In a real script I wouldn't expect those lingering variables like you suggest since I would populate the array in a function which means the variables would go away.

On a technical note, it's not wasting much space, anyway. Array's are referenced counted (copy-on-write) so copying and storing array's is cheap until you start writing to them to force a copy.

I'm starting to think we need to document the copy-on-write property of array's since that's some critical performance information and may change the way scripts are written (I know that I write code differently knowing array's are cheaper than one might think).

[NerdFencer]

That is reasonable, and documentation would be quite nice.

[Valik]

Ironically, I have a need for a doubly-linked list in AutoIt. Perhaps I'll post my implementation once I'm finished.

[ValeryVal]

Although I am relatively new to the AutoIt language, I have found it quite useful. One thing that I personally believe could be improved about the language is the lack of the atom data type that is used exclusively in LISP. If I were to make the required source code revisions and submit the added features to support this, would anybody else find it useful?

You can use any Lisp functionality from AutoIt by newLisp and ALisp.au3

I hope that script ALisp.au3 is alive on old forum, too.

ALisp thread