Data abstraction in APL
Aaron W. Hsu
operations and so forth, but there is something that I feel like I'm
lacking a bit when I use APL compared to when I use Scheme.
I am used to doing a lot of data based abstraction when I work in Scheme.
Specifically, I can use the define-record-type form to construct disjoint
datatypes that have their own operations specifically for those data
types. Moreover, I can define syntactic abstractions on top of these data
abstractions and get things like type dispatch or algebraic data types
that work just like they were native to the system.
I am wondering what APL programmers do to work with complex forms of data
without either syntactic or data abstraction facilities like these? I was
looking at the way that nested XML structures are handled with ⎕XML, but
unless I am wrong, it seems like using nested arrays will hit hard limits
on the nesting levels in some APL systems. Moreover, what if I wanted to
distinguish particularly XML node types?
Another thought is a generalized tree data type. Or a hashtable, or any
number of other systems. How do I abstract the data in the system and
represent it in a meaningful and properly enclosed API in APL?
Aaron W. Hsu
--
Programming is just another word for the lost art of thinking.
Stefano "WildHeart"
> Another thought is a generalized tree data type. Or a hashtable, or any
> number of other systems. How do I abstract the data in the system and
> represent it in a meaningful and properly enclosed API in APL?
A quick reply (I'm a bit in a hurry), more food for thoughts than a
real answer...
A tree can be represented in a straightforward way with a nested array
(http://www.dyalog.com/dfnsdws/n_Trees.htm), but you might find other
linearised representations faster (if you dare interpret the very
terse syntax of K, there's an interesting "article" here: http://nsl.com/k/trees.k).
Hash tables can also be represented as nested arrays, but the
interpretative overhead might make them less interesting than in other
languages. But not all hope is lost: the typical implementation of the
primitive "dyadic iota" resorts to building a hash tables for many
cases of left and right arguments (typically nested arrays containing
simple characters arrays aka list of strings). In Dyalog APL certain
idioms are recognised and the hash-table is retained across successive
calls. This means, though, that the data table must be built and then
accessed for reads only.
To be honest, in practical use cases even if the interpreter has to
rebuild the hash table for every search, the performance is more than
acceptable.
Notice that, in my opinion, certain kinds of abstractions are not
encouraged in APL, because anything tends to be more verbose than the
use of the primitives (which hide certain data abstractions as in the
case of the dyadic iota) and to a trained eye a certain pattern of
primitives is more self-explaining than a more descriptive abstraction
based on keywords.
As far as XML is concerned, I have experimented with nested arrays, as
well as object trees (leveraging Dyalog APL's OO extensions), with
the .NET bridge and also with []XML. All have their pros and cons (in
the same way sometimes a pull interface is better than a push
interface). []XML has the benefit that, unlike the other
representations, the XML document is completely linearised (the
structure is pretty much a flat matrix). The spirit of the
representation used by []XML is the one described in the article
regarding trees in K I mentioned above.
Here's an essay on linked lists (cons lists) has one might go about
implementing them in APL: http://www.dyalog.com/dfnsdws/n_list.htm
Have fun!
--
Stefano
Bakul Shah
> On Mar 28, 7:07 pm, "Aaron W. Hsu"<arcf...@sacrideo.us> wrote:
>> Another thought is a generalized tree data type. Or a hashtable, or any
>> number of other systems. How do I abstract the data in the system and
>> represent it in a meaningful and properly enclosed API in APL?
>
> A quick reply (I'm a bit in a hurry), more food for thoughts than a
> real answer...
> A tree can be represented in a straightforward way with a nested array
> (http://www.dyalog.com/dfnsdws/n_Trees.htm), but you might find other
> linearised representations faster (if you dare interpret the very
> terse syntax of K, there's an interesting "article" here: http://nsl.com/k/trees.k).
k4 (or Q) has hashtables ("dictionaries") and tables.
http://kx.com/q/d/q1.htm
IIRC even k3 had something similar but not as easy to use.