Deserialise-- does it work as expected?

General APL language issues

Deserialise-- does it work as expected?

Postby petermsiegel on Tue Jul 26, 2022 6:40 pm

⍝ Is the result of 0 Deserialise 'A[ 1 2 3 ]' correct?
⍝ Shouldn't it be interpreted as a simple index expression? A[ 1 2 3 ]
⍝ since there are no statement terminators (CRs or '⋄')?

⍝ Let's investigate...
      ...
⍝ Relocate needed fn Deserialise (and others it may call) to # for convenience
'#' ⎕NS ⎕SE.Dyalog.Array
⍝ This makes sense: special case because of embedded statement end via '⋄'
0 Deserialise '(1 2 ⋄ ⍳3)'
((1 2 )( ⍳3))
⍝ This makes sense: not special case so same as ordinary expression (1 2 ⍳ 3)
0 Deserialise '(1 2 ⍳3)'
(1 2 ⍳3)
⍝ This too makes sense: it's a special case
⍝ because of embedded statement end via '⋄'
0 Deserialise '[1 2 ⋄ ⍳3]'
({⎕ML←1⋄↑⍵}1/¨((1 2 )( ⍳3))) ⍝ <==== Expected response, so all's well!

⍝ Now let's try A[...], where A is just a vector of numbers.
⍝ First, we assign A.
A←1 2 3 4 5
⍝ We'd expect the case below to return the simple code A[1 2 ⍳ 3] below.
0 Deserialise 'A[1 2 ⍳ 3]'
⍝ But it produces this, two side by side expressions of the form:
⍝ A( ...... )
A({⎕ML←1⋄↑⍵}1/¨(1 2 ⍳ 3)) ⍝ Huh?
⍝ ... which has the value:
1 2 3 4 5 3
⍝ AKA...
┌─────────┬──┐
│1 2 3 4 5│ 3│
└─────────┴──┘
⍝ NOT WHAT WE EXPECTED.
⍝ We expected this:
A[1 2 ⍳ 3]
3

Is there an error in the handling of
    0 Deserialise 'A[1 2 ⍳ 3]'
with its simple expressions (no CR, no '⋄') inside brackets?
petermsiegel
 
Posts: 123
Joined: Thu Nov 11, 2010 11:04 pm

Re: Deserialise-- does it work as expected?

Postby crishog on Thu Jul 28, 2022 12:02 pm

Your expression is

A({⎕ML←1 ⋄ ↑⍵}1/¨(1 2⍳3))

Which means there is no left argument - A is stranded onto the result

Run

({⎕ML←1 ⋄ ↑⍵}1/¨(1 2⍳3))
3

Is would probably be simpler to use ⊃ for first without "fiddling" with ⎕ML inside a dfn to use ↑
crishog
 
Posts: 61
Joined: Mon Jan 25, 2010 9:52 am

Re: Deserialise-- does it work as expected?

Postby Vince|Dyalog on Thu Jul 28, 2022 3:54 pm

Hi Peter,

I have asked about this and the answer is that Deserialise expects input in array notation as output by Serialise.

It is not a substitute for ⍎ and does not take any APL expression.

Regards,

Vince
Vince|Dyalog
 
Posts: 374
Joined: Wed Oct 01, 2008 9:39 am

Re: Deserialise-- does it work as expected?

Postby Phil Last on Sat Jul 30, 2022 9:07 am

Vince|Dyalog wrote:... and does not take any APL expression.


In other words "... and does not take all APL expressions".

Very specifically it will always (?) assume square brackets are rank rather than either index or axis indicators.
User avatar
Phil Last
 
Posts: 606
Joined: Thu Jun 18, 2009 6:29 pm

Re: Deserialise-- does it work as expected?

Postby petermsiegel on Sun Jul 31, 2022 10:43 pm

Philosophy Minute:
Have you thought about creating/sharing formal specifications for potential future functionality, along the lines of Python PEPs ([language] enhancement proposals)? ...Something that goes a bit beyond the excellent Powerpoint presentations and web posts from Adám.

Turns out, PEPs (or, in this case, DEPs???) are really useful for in-house developers, because community members make suggestions, changes, refinements, and (heaven forfend!) their own proposals. (This very functionality went through an illustrative variant of such a process, albeit a less formal and quite lengthy one).

P.S. To "fix" the actual Deserialise code requires tiny changes to one or two lines, so this isn't actually a hard case to turn into a formal "specification" in code form.

Cheers
petermsiegel
 
Posts: 123
Joined: Thu Nov 11, 2010 11:04 pm

Re: Deserialise-- does it work as expected?

Postby Phil Last on Thu Aug 04, 2022 8:52 am

      Conclusion
The need for such a notation and the desirability of its being
defined to be cross-platform is unquestionable. If a round-trip
is desirable, as I believe it is, then the above limitations are
serious but I do not believe they constitute a show-stopper. But
they will require more than one person's imagination to
overcome. I believe the nested bracket approach could be the
simplest and most versatile for multi-dimensional data, that
outlined here possibly forming a basis for discussion. Given the
power of vector notation APL needs very little enhancement to
make it work. Other details here might be questionable and
could undoubtedly be bettered. An agreed design should be
made with an eye on extensibility and forward compatibility
such that providers could include their own enhancements.


Conclusion of my A Notation for the Embedding and
Serialization of APL Data
from 2014-12-20 published in Vector.

This wasn't my first attempt to get the idea of array notation in the (APL) public eye but it does mark the start of the gathering momentum anf was followed the next year by my remote presentation at Dyalog'15.

Unfortunately only Dyalog took up the idea and there was no attempt at any wider consultation before Adam was tasked with re-implementing it in APL.

It is to be hoped that Dyalog will seek more feedback before finally inplementing array notation as an intrinsic part of the interpreter.
User avatar
Phil Last
 
Posts: 606
Joined: Thu Jun 18, 2009 6:29 pm

Re: Deserialise-- does it work as expected?

Postby petermsiegel on Fri Aug 05, 2022 6:25 pm

Thanks for reminding me/us about your excellent and early article that makes strong arguments on technical issues and the value of community involvement. PEPs (or DEPs) are really all about using community to amplify the skills and insights of the core development team.

PEPs have their drawbacks, e.g. there are certainly issues for software projects that have benevolent dictators for life (yeah, really), insofar as really well supported projects could be derailed arbitrarily, but vendors in principle have a strong motivation to be responsive to customers.

Thanks again...
petermsiegel
 
Posts: 123
Joined: Thu Nov 11, 2010 11:04 pm

Re: Deserialise-- does it work as expected?

Postby Morten|Dyalog on Mon Aug 08, 2022 7:42 pm

Hi Phil

We would definitely appreciate more feedback! After your Dyalog '15 presentation, Adám presented Array Notation at Dyalog ‘17, Dyalog '18, and Dyalog '20, (each time asking for feedback) as well as wrote an article for APL Germany's newsletter and on APL Wiki. Unfortunately, feedback has been sparse. We do have further plans for eliciting feedback on the refined proposal (as detailed on APL Wiki), including talking about it again at Dyalog ’22, reaching out to Log-On, APL2000 and the GNU APL community, prompting through social media and forums, and directly contacting some key implementers (present and past). We really want to ensure that we get it right, as we may only get one shot at this.

To all readers of this forum: We welcome all feedback on the notation and suggestions for how to increase awareness. Please look at the Wiki page describing the proposal and send your feedback to Dyalog directly or through this forum post (or talk to us in person at Dyalog ’22!)
User avatar
Morten|Dyalog
 
Posts: 432
Joined: Tue Sep 09, 2008 3:52 pm

Re: Deserialise-- does it work as expected?

Postby Phil Last on Tue Aug 09, 2022 11:07 pm

Morten

First let me apologise for any implication that Dyalog has not attempted to include others in decision making with regard to array notation. As I found in the several years before you were finally persuaded, drumming up enthusiasm for an idea for which others have never perceived a need is not easy.

But to make the acquisition of feedback easier can you elaborate on ... and send your feedback to Dyalog directly ... ? Should this be addressed to you or to Adám or to support? Or is there a "Suggestions box" of which I'm unaware? Or perhaps a new forum dedicated to this and related topics?

And as the subject contains a number of potentially contentious issues could some way be found to ensure that a consensus is reached.

Peter's original observation that started this thread is one such. My earliest proposals introduced the idea that only an opening bracket that is currently disallowed, i.e. following an opening bracket, parenthesis or brace, a closing bracket, a diamond or a line-end, would denote an array. Otherwise it would continue to denote an index or axis. My original model ignored this restriction merely because I fould the parsing effort too much for the possible benefit. I guess the same has remained the case throughout.


This would lead Peter's A[1 2 ⍳ 3] correctly to denote an index selection of A and necessitate parentheses as A([1 2 ⍳ 3]) to force the stranded two item array.

I'm not suggesting that Adám undertake what I couldn't be bothereed to do. But as the implementation of array notation in the interpreter will already have all the intricacies of the parser at its disposal it wouldn't be an impossibility. There is little or no ambiguity in APL syntax per se. Let's hope array notation improves clarity without introducing its opposite.
User avatar
Phil Last
 
Posts: 606
Joined: Thu Jun 18, 2009 6:29 pm

Re: Deserialise-- does it work as expected?

Postby Adam|Dyalog on Wed Aug 10, 2022 12:09 pm

Phil Last wrote:Should this be addressed to you or to Adám or to support? Or is there a "Suggestions box" of which I'm unaware? Or perhaps a new forum dedicated to this and related topics?

Any way of contacting us is perfectly fine. We can continue the discussion in this forum, but we do not want to limit feedback to forum users. We will do our best to record feedback, responses and any resulting modifications on the APL Wiki page.
Phil Last wrote:a number of potentially contentious issues (…) Peter's original observation that started this thread is one such. My earliest proposals introduced the idea that only an opening bracket that is currently disallowed, i.e. following an opening bracket, parenthesis or brace, a closing bracket, a diamond or a line-end, would denote an array. Otherwise it would continue to denote an index or axis. (…) it wouldn't be an impossibility.

To be perfectly clear: The Deserialise function is but a simplistic model, and does not attempt to be equivalent with the current APL parser plus array notation. It simply assumes being fed just array notation with a subset (namely excluding other uses of brackets) of current APL. The plan is to support all APL code (even indexing/axis brackets) inside the new notation.

The proposal is to have brackets mean array notation only when "broken", meaning containing a line break or diamond; not when an unbroken bracket appears in an otherwise disallowed context, as the latter would make the meaning of a snippet of APL depend on its outer context rather than its inner content, something I'd like to avoid.
User avatar
Adam|Dyalog
 
Posts: 113
Joined: Thu Jun 25, 2015 1:13 pm

Next

Return to Language

Who is online

Users browsing this forum: No registered users and 1 guest