Re: [Unicon-ldif] Unicon as n(1,2,3,4), why not add n{1;2;3;4}?

[David G. <dav...@ro...>]

Jafar,

I don't know about the book but had noticed that lone line :)

I think I went to play with array once and not sure what happened. I probably got sidetracked.  


I can't recall if array shows up differently as a type from a list.

I'm not sure if there are any operations that would coerce a list into an array.

I understand your caution. I'm stretching to think of how smarter lists might break things.  But I haven't fully absorbed all of this.

I'm not sure if this breaks anything, but I'm thinking that !x might will behave differently or unexpectedly with arrays vs. lists. Consider:


    l := list(10); every !l := list(10,0); l[2,5] := 77

    a := array(l) # i assume this create a 2D array from l's list of lists?
    

Any use of !l and !a after the initialization above will behave differently.


Now here's a thought (possibly dangerous or erroneous).  Suppose you had the ability to construct a data object and make it non-coercible. So let's say the array A in your example was made non-coercible.  Then pop(A) would result in a run time error.  This would only make sense in cases like structured types where a function alters the base object.  Cases like string/integer coercion would be non-sensible.  If it were general, it could be a general function.
   noncoercible(A) # make array A non-coercible
   noncoercible(i) # fails, if i is something like an integer, real, string
Then of course you'd want to be able to make it coercible too.  So a second function coercible().

All this might help with performance.  Mind you it could probably be monitored with the execution monitor which wouldn't likely require anything else. Or less implementation effort on the language side.


I can't fully get my head around the mechanics of accessing arrays in interesting ways.  My limited exposure with this idea was in PL/I.  Specifically, many years back I was working on a project to convert PL/I to C with significant automation.  We needed to be able to recognize slicing so that we could generate entirely different array logic in translation. Or at least around calls using slicing. I'm not sure if PL/1 produced a copy of the sliced object or if it had a funky way just indexing into the existing structure. Consider:

    cube := array(10,10,10,0) 

    ...   # populate cube
    transpose(cube(*,3,*))

I just can't recall the semantics of what happened to the original structure on return from the function. Also as I recall the use of slices was limited to calls, you couldn't just assign a slice to something.

In Unicon transpose likey returns the new structured type.  However, in the PL/1 equivalent cube itself may have been altered.  (The reason I can't recall is that a viable PL/1 compiler became available on the target platform while we were working through the feasiblity.)


David




>________________________________
> From: Jafar Al-Gharaibeh <to....@gm...>
>To: David Gamey <dav...@ro...> 
>Cc: Steve Wampler <swa...@no...>; Unicon-features <uni...@li...> 
>Sent: Thursday, May 15, 2014 4:01:16 PM
>Subject: Re: [Unicon-ldif] Unicon as n(1,2,3,4), why not add n{1;2;3;4}?
> 
>
>
>Hi David,
>
>
>    In away, array has been intentionally under documented because it was meant to be just a list sub-type. Not sure it if is mentioned in the Unicon book, but it is talked about in one line at unicon.org main page. For all intents and purposes an array currently is just a list form the point of view of a Unicon user. If you have a fixed size list of integers or reals, array() gives you a better (or worse! depending on whom you ask :) ) representation of your data internally; better performance and half the memory requirement. At the Unicon level it is the same.  Clint has suggested to me several times to drop array() altogether and make list() smarter, i.e list would allocate an array instead of a list when possible depending on passed parameters. The only reason I haven't done is that I wasn't sure if this would break any existing Unicon programs. although, the implementation is smart enough to convert an array to a list transparently anytime a
 non-array friendly operation is applied to an array. Foe example, you can do:
>
>
>A := Array(10, 0)                  # create a  list with array representaion
>every i:=1 to 10 do A[i]:=i      # still an array
>x:=pop(A)                             # x is 1, A is silently converted to have a conventional list representation: [2..10]
>
>
>
>
>Currently, the actual benefit of of arrays in Unicon lies in the ability of passing array data to C libraries without conversion. It is heavily used in Unicon's 3D graphics/OpenGL. Before arrays, every screen refresh required vertex/scene data stored in lists to be converted to arrays in order to send them to OpenGL. More details about this can be found in my Ph.D dissertation under technical reports at unicon.org.
>
>
>Now the discussion is about the good stuff that lies head: generalizing arrays (multi-dimensional) and supporting all of their goodies at the Unicon level. As I mentioned earlier, at the moment array() supports multi-dimensions, but oddly enough we still don't have a good way (no interface) to use them at the Unicon level. Besides the need of working out all of the implementation details and support throughout the runtime system. 
>
>
>--Jafar
>
>
>
>
>On Thu, May 15, 2014 at 2:19 PM, David Gamey <dav...@ro...> wrote:
>
>Hi all,
>>
>>
>>Is it just me or is array under documented?
>>
>>
>>This functionality sounds like what was called array slicing in PL/1.  Very powerful as it let you write say a matrix function and the apply it to a subset/slice of a higher dimensioned array.  It's been a very long time but I think the syntax used an '*', e.g.:
>>
>>
>>    E := A[*,20,*]
>>
>>
>>or
>>
>>
>>    I := invert(A[*,20,*])
>>
>>
>>I suspect that unless this usage was planned for it might be tricky to implement.
>>
>>
>>
>>David
>>
>>
>>
>>
>>>________________________________
>>> From: Jafar Al-Gharaibeh <to....@gm...>
>>>To: Steve Wampler <swa...@no...> 
>>>Cc: Unicon-features <uni...@li...> 
>>>Sent: Thursday, May 15, 2014 2:15:16 PM
>>>Subject: Re: [Unicon-ldif] Unicon as n(1,2,3,4), why not add n{1;2;3;4}?
>>> 
>>>
>>>
>>>I'm sure if we can get sponsors/volunteers for such work, it would be done sooner rather than later ;). such work would pave the road (or be part of) GPU acceleration support for Unicon.  
>>>
>>>
>>>
>>>On Thu, May 15, 2014 at 12:32 PM, Steve Wampler <swa...@no...> wrote:
>>>
>>>On 05/15/2014 10:17 AM, Jafar Al-Gharaibeh wrote:
>>>>
>>>>On Thu, May 15, 2014 at 11:51 AM, Steve Wampler <swa...@no... <mailto:swa...@no...>> wrote:
>>>>>
>>>>>        C := A[,2,3]           # 1D array of plane at row 2, col 3?
>>>>>>        D := A[1]              # 2D array of plane 1?
>>>>>>        E := A[,20,]           # 2D array of row 20?
>>>>>>
The envisioned/eventual goal is to support all of the expressions above
>>>>>
>>>>Definitely cool!  Can you have it ready by, oh say, 5pm?  :)
>>>>
>>>>
>>>>-- 
>>>>Steve Wampler -- swa...@no...
>>>>The gods that smiled on your birth are now laughing out loud.
>>>>
>>>
>>>
>>>------------------------------------------------------------------------------
>>>"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
>>>Instantly run your Selenium tests across 300+ browser/OS combos.
>>>Get unparalleled scalability from the best Selenium testing platform available
>>>Simple to use. Nothing to install. Get started now for free."
>>>http://p.sf.net/sfu/SauceLabs
>>>
>>>_______________________________________________
>>>Unicon-ldif mailing list
>>>Uni...@li...
>>>https://lists.sourceforge.net/lists/listinfo/unicon-ldif
>>>
>>>
>>>
>
>
>