An APL Archive
AA2e72E
is due to our lack of a huge archives of source.", so wrote <aplisfast> in
another thread.
Given the age of APL, it ought to have a huge archive; given that is does
not have an archive to speak of, perhaps we ought to document what is
available.
The FinnAPL Idioms library is probably the best authoritative
documentation of APL (first generation), followed by the IDIOMS workspace
in TryAPL2 (second generation).
APL+Win have a collection of open workspaces at:
http://apldn.apl2000.com/downloads/APLWI+Downloads/APLWIUF/default.aspx
Erics's site also has a collection of open workspaces on APL+Win:
Others are constantly looking for the Waterloo archive: it keeps
disappearing from the WEB.
VECTOR has twice launched an initiative to build an archive of
contemporary APL idioms but it seems to have faltered because of lack of
user interest: it cannot happen unless users contribute.
A good archive should be the starting point for solving problems for
novices and experts alike. It sould also be indicative of the strength of
APL.
How do we start build//document one?
Dick Bowman
news:9470b735c4c4c49d...@localhost.talkaboutprogramming.com:
> "Rumors of the death of APL may be overexargerated -- but how much of
> this is due to our lack of a huge archives of source.", so wrote
> <aplisfast> in another thread.
>
> Given the age of APL, it ought to have a huge archive;
[... deleted ...]
> How do we start build//document one?
>
I suspect that one way to start would be to have a neutrally-based resource
page somewhere which links to all of the individual sites where people are
willing to share code (and other worthwhile resource).
As you say, there have been numerous past attmpts to create libraries -
most of which have become dormant (if they ever got that far). I think
that a contributing factor has been that there's usually been a (self-
appointed?) librarian wanting to set quality/coding standards and the like
- which may have inhibited potential contributors. Perhaps a repository
where stuff stands or falls on its own merit might have a better chance of
survival.
Thinking about my own attitude to contributing material - I'd be happy to
tell people where they can find my stuff (and what my conditions might be
for having them use it) - but I wouldn't be so keen on bundling it up and
putting it into the care and custody of a third party (not to mention the
ongoing aggravation of sending out updates).
AA2e72E
Excellent idea ... until I ask who pays for it. The best sponsor I can
think of is British APL Association. They have already got their site
which could be extended. This would be ore viable if there was a surge in
people subscribing to VECTOR!.
"Perhaps a repository where stuff stands or falls on its own merit might
have a better chance of survival." Forums are an excellent platform for
exchanging ideas and code but it is let down by at least the inability to
show APL fonts.
However, the forum at www.lescasse.com IS able to show APL fonts.
Nonetheless, this is probably the only way to encourage contributions.
"Thinking about my own attitude to contributing material - I'd be happy to
tell people where they can find my stuff (and what my conditions might be
for having them use it)" Please do. You are probably unaware of this but
your name comes up quite often in (my) APL circles, usually along the
lines of "I learnt APL from Dick Bowman" or "Dick Bowman introduced me to
APL". I am sure your contributions would be much valued.
If any one is interested in exploring IDIOMS from TryAPL2 (I strongly
recommend it), the way to do it is
1. install tryAPL2 (free download)
2. )load the IDIOMS workspace and use )out to transfer it. All the APLS
can read the transferred out workspace.
3. write the variable that contains the idioms to a native file
4. read the naive file in WORD, set the font, create a PDF and add it to
the menu of your APL.
In spite of being an APL2 product, IDIOMS is vendor neutral: no special
requirements for APLX, use EVLEVEL 2 for APL+Win and ML 3 for Dyalog.
This site has a very big collection of "APL Software for Operations
Research" (runtime) workspaces (APL+Win):
http://www.icaen.uiowa.edu/~dbricker/APL_software.html
"not to mention the ongoing aggravation of sending out updates" I am not
sure what the answer is here but I imagine periodic updates will be
necessary.
AA2e72E
This site:
http://www.mat.uc.pt/ssp/APL_software.html
has a collection of workspaces dealing with "APL Software for Stochastic
Optimization" (APL+win)
This site is also sulution focussed:
http://www.unb.ca/web/transpo/mynet/mtx20.htm
dealing with "An Introduction to APL for analysis and planning"
phil chastney
> <snip>
> "Perhaps a repository where stuff stands or falls on its own merit might
> have a better chance of survival." Forums are an excellent platform for
> exchanging ideas and code but it is let down by at least the inability to
> show APL fonts.
just a point of detail: forums don't show fonts --
they pass through encoded messages, that's all
it must have been a few months ago now, but a recent
test using Unicode showed that many people could indeed
display messages from this group on their favourite
screen using APL-style symbols -- and it's possible
that many more could have sorted themselves out,
if there were any need to do so
the fault lies not in our forum, dear Brutus, but in
ourselves, who are the underlings
regards . . . /phil
AA2e72E
I can see the font clearly on
Jerry Koniecki
> "Rumors of the death of APL may be overexargerated -- but how much of this
> is due to our lack of a huge archives of source.", so wrote <aplisfast> in
> another thread.
>
> Given the age of APL, it ought to have a huge archive; given that is does
> not have an archive to speak of, perhaps we ought to document what is
> available.
>
> The FinnAPL Idioms library is probably the best authoritative
I like the FinnAPL idioms, not least because I can actually use them. It
was a bit of work trying to get the APL font to function with the web
page. (And there are still a couple of symbols that don't display
properly. Even the PDF version is flawed; page breaks vertically
splitting a line of APL text.)
But the biggest problem that I see, is that the offered workspaces are
in APL version specific format. ATF format use is almost non-existent.
Either you happen to use the same version of APL, or you can't even load
the workspace. The small APL community is further fractured by using
incompatible workspace formats. It seems to me the only valid community
library format is ATF. So why isn't it used? It can even be manually
read to extract the contents if necessary. (Been there; done that.)
Let's not forget the Toronto Toolkit. (I'm still waiting for the next
version that was supposed to be released. I'm not holding my breath.)
> ... followed by the IDIOMS workspace in TryAPL2 (second generation).
I thought )OUT was not functional in TRYAPL2? Or was it )SAVE? I seem to
remember not being able to harvest the functions except by copying them
from the monitor.
What about the Zark APL newsletter? Is it still available? Perhaps as a
book?
--
Jerry wa2rkn
David Liebtag
about users of other dialects.
The IDIOMS function is also available in the free demonstration version of
Workstation APL2. Like in TryAPL2, the IDIOMS function only returns those
idioms you have selected for inclusion in the external result or you have
specified should be added to the IDIOM_LIST variable. However, once you get
them into the session log, you can do what you like with them. In
particular, if you have Adobe Acrobat installed, you can print them to a PDF
file.
David Liebtag
IBM APL Products and Services
Doug White
>"Rumors of the death of APL may be overexargerated -- but how much of this
>is due to our lack of a huge archives of source.", so wrote <aplisfast> in
>another thread.
>
>Given the age of APL, it ought to have a huge archive; given that is does
>not have an archive to speak of, perhaps we ought to document what is
>available.
>
>The FinnAPL Idioms library is probably the best authoritative
>documentation of APL (first generation), followed by the IDIOMS workspace
>in TryAPL2 (second generation).
>
>APL+Win have a collection of open workspaces at:
>
>http://apldn.apl2000.com/downloads/APLWI+Downloads/APLWIUF/default.aspx
>
>Erics's site also has a collection of open workspaces on APL+Win:
>
>http://www.lescasse.com/
>
>Others are constantly looking for the Waterloo archive: it keeps
>disappearing from the WEB.
The Waterloo archives are alive & well at this point, but some of the
links were (are?) broken. These seem to be getting fixed as they get
identified. There's an enormous amount of good stuff there, and I think
it should be included (mirrored?) in any proposed archive. If we wan tto
convince the ACM that we are for real, maybe asking them for help in
hosting the archives would get their attention.
Doug White
Doug White
Another transfer format that used to be widely supported was Jim
Weigang's APL transliteration system. It is very easy to read manually,
and the translation can even be customized to match your favorite
operator names.
Doug White
AA2e72E
"However, once you get them into the session log, you can do what you like
with them."
What conditions would apply if a PDF of the idioms were to be made
available as a download?
Mike Kent
> Another transfer format that used to be widely supported was Jim
> Weigang's APL transliteration system. It is very easy to read manually,
> and the translation can even be customized to match your favorite
> operator names.
Jim's translation workspaces are available at Waterloo
http://www.math.uwaterloo.ca/apl_archives/apl/workspaces/aplascii/
and Dyalog (at least) supplies a version adapted to their APL.
I can provide ASCII-transliterated APL code to convert between
APL and an ASCII transliteration. It is directly suitable only
for moving functions and operators around ... it's only about 35
mostly short lines of brutally simple code, and 120 comments that
are really a data table ...
Also ... works for nested-array flavor only.
Originally posted December 18, 1993:
...
Here's some source code (for Manugistics APL*Plus II, but I think easily
adaptable to other dialects) for transliteration and its inverse. The
only large function is the one which builds the translate table.
Just to make things easy, and clear:
----------------------------------------------------------------------
NOTICE
I hereby grant to the public domain the following rights to the
software below:
1. The right to use the software for any purpose other
than direct commercial gain.
2. The right to copy and redistribute the software as long
as such copying and/or redistribution is not done for
direct commercial gain, and provided that any copies
made include the full text of this article, and
particularly this NOTICE and the following DISCLAIMER.
3. The right to produce derivative works incorporating all
or any part of the software.
Software Copyright (c) Michael Kent 1993
----------------------------------------------------------------------
----------------------------------------------------------------------
DISCLAIMER
The user of the software assumes all responsibility for the use, and
the consequences of the use, of the software, and all liability arising
from such use.
----------------------------------------------------------------------
"ASCII_FN" and "ASCII_FN_LIST" transliterate a single function or each
of a list of functions:
z___{assign}ASCII_FN f___
[1] {comment} Transliterate APL characters in ({quad}VR of) function.
[2] z___{assign}{epsilon}glyphAPL Translate {quad}VR f___
z___{assign}ASCII_FN_LIST f___
[1] {comment} Transliterate APL characters in ({quad}VR of)
functions in list.
[2] z___{assign}{enlist}glyphAPL Translate{enlist}
{quad}TCFF,{each}{quad}VR{each}Split f___
"APL" recovers the visual representation of a function from its
transliteration.
z{assign}APL v;i;j;t;vv;{quad}IO
[1] {comment} Recover transliterated APL characters in a vector.
[2] {quad}IO{assign}1
[3] vv{assign}v,' '
[4] i{assign}i/{iota}{shape}i{assign}vv='{'
[5] j{assign}1+j/{iota}{shape}j{assign}vv='}'
[6] t{assign}({shape}vv){take}1
[7] t[i,j]{assign}1
[8] t{assign}({high_minus}1{drop}t)PEnclose {high_minus}1{drop}vv
[9] z{assign}{enlist}({row_rotate}glyphAPL)Translate t
The heart of the matter; "glyphAPL" builds the translate table, with
APL glyphs in the first column, and transliterations in column two.
You can get preferred transliterations out by permuting the order of
the comment lines, which are in fact embedded data.
z{assign}glyphAPL;b;c;{quad}IO
[1] {quad}IO{assign}1
[2] c{assign}0 1{drop}('{comment}'=c[;{quad}IO])
{slash_bar}c{assign}{quad}CR'glyphAPL'
{diamond} b{assign}({shape}c){reshape}(1{drop}{shape}c){take}1 0 1
[3] c{assign}Mix(Split b)PEnclose{each}Split c
{diamond} c{assign}c~{each}' '
[4] c[;1]{assign}First{each}c[;1]
{diamond} c[;2]{assign}'{',{each}c[;2],{each}'}'
[5] z{assign}c
[6] {comment} {notmatch} notmatch
[7] {comment} {notmatch} /match
[8] {comment} {notmatch} /=_
[9] {comment} {find} find
[10] {comment} {find} epsilon_underscore
[11] {comment} {find} epsilon_
[12] {comment} {diamond} diamond
[13] {comment} {diamond} <>
[14] {comment} {each} each
[15] {comment} {assign} assign
[16] {comment} {assign} left_arrow
[17] {comment} {assign} <-
[18] {comment} {jot} jot
[19] {comment} {enclose} enclose
[20] {comment} {enclose} subset
[21] {comment} {enclose} left_shoe
[22] {comment} {disclose} disclose
[23] {comment} {disclose} superset
[24] {comment} {disclose} right_shoe
[25] {comment} {log} log
[26] {comment} {log} circle-star
[27] {comment} {log} wheel
[28] {comment} {jot_quad} jot_quad
[29] {comment} {backslash_quad} backslash_quad
[30] {comment} {backslash_quad} \quad
[31] {comment} {iota_underscore} iota_underscore
[32] {comment} {iota_underscore} iota_
[33] {comment} {del_tilde} del_tilde
[34] {comment} {del_tilde} del~
[35] {comment} {i_beam} i_beam
[36] {comment} {zilde} zilde
[37] {comment} {zilde} 0~
[38] {comment} {omega} omega
[39] {comment} {up_arrow} up_arrow
[40] {comment} {up_arrow} take
[41] {comment} {up_arrow} first
[42] {comment} {down_arrow} down_arrow
[43] {comment} {down_arrow} drop
[44] {comment} {goto} goto
[45] {comment} {goto} right_arrow
[46] {comment} {left_tack} left_tack
[47] {comment} {left_tack} lev
[48] {comment} {right_tack} right_tack
[49] {comment} {right_tack} dex
[50] {comment} {upgrade} upgrade
[51] {comment} {downgrade} downgrade
[52] {comment} {and} and
[53] {comment} {unequal} unequal
[54] {comment} {unequal} /=
[55] {comment} {ceiling} ceiling
[56] {comment} {ceiling} max
[57] {comment} {floor} floor
[58] {comment} {floor} min
[59] {comment} {delta} delta
[60] {comment} {times} times
[61] {comment} {quad} quad
[62] {comment} {quote_quad} quote_quad
[63] {comment} {quote_quad} 'quad
[64] {comment} {divide_quad} divide_quad
[65] {comment} {comma_bar} comma_bar
[66] {comment} {comma_bar} ,-
[67] {comment} {tilde_dieresis} tilde_dieresis
[68] {comment} {comment} comment
[69] {comment} {backslash_bar} backslash_bar
[70] {comment} {backslash_bar} \-
[71] {comment} {squad} squad
[72] {comment} {squad} []
[73] {comment} {encode_dieresis} encode_dieresis
[74] {comment} {del_dieresis} del_dieresis
[75] {comment} {star_dieresis} star_dieresis
[76] {comment} {alpha} alpha
[77] {comment} {iota} iota
[78] {comment} {jot_dieresis} jot_dieresis
[79] {comment} {circle_dieresis} circle_dieresis
[80] {comment} {nor} nor
[81] {comment} {up_tack} up_tack
[82] {comment} {up_tack} base
[83] {comment} {down_tack} down_tack
[84] {comment} {down_tack} encode
[85] {comment} {circle_stile} circle_stile
[86] {comment} {circle_stile} row_rotate
[87] {comment} {circle_bar} circle_bar
[88] {comment} {circle_bar} col_rotate
[89] {comment} {nand} nand
[90] {comment} {slash_bar} slash_bar
[91] {comment} {slash_bar} /-
[92] {comment} {del} del
[93] {comment} {backslash_circle} backslash_circle
[94] {comment} {backslash_circle} \circle
[95] {comment} {backslash_circle} transpose
[96] {comment} {epsilon} epsilon
[97] {comment} {up_shoe} up_shoe
[98] {comment} {up_shoe} intersection
[99] {comment} {up_shoe} cap
[100] {comment} {equal_underscore} equal_underscore
[101] {comment} {equal_underscore} =_
[102] {comment} {equal_underscore} match
[103] {comment} {delta_underscore} delta_underscore
[104] {comment} {delta_underscore} delta_
[105] {comment} {gteq} gteq
[106] {comment} {gteq} >=
[107] {comment} {lteq} lteq
[108] {comment} {lteq} <=
[109] {comment} {format} format
[110] {comment} {execute} execute
[111] {comment} {divide} divide
[112] {comment} {circle} circle
[113] {comment} {or} or
[114] {comment} {rho} rho
[115] {comment} {rho} shape
[116] {comment} {rho} reshape
[117] {comment} {down_shoe} down_shoe
[118] {comment} {down_shoe} union
[119] {comment} {down_shoe} cup
[120] {comment} {high_minus} high_minus
[121] {comment} {stile} stile
[122] {comment} {stile} absolute_value
[123] {comment} {stile} residue
[124] {comment} {epsilon} member
[125] {comment} {epsilon} enlist
"Translate" is a simple routine for substituting items in a vector.
z{assign}t Translate v;i;y;{quad}IO
[1] {comment} Replace items of v found in t[;1] by items from t[;2].
[2] {quad}IO{assign}1
[3] y{assign}v
[4] i{assign}i/{iota}{shape}i{assign}v{member}t[;1]
[5] y[i]{assign}t[t[;1]{iota}y[i];2]
[6] z{assign}y
"First", "Mix", "PEnclose", and "Split" are cover functions which need
to be rewritten for other dialects. "First" gives the first item of an
array; "Mix" and "Split" convert between matrices and vectors-of-vectors,
and "PEnclose" is boolean-controlled partitioned enclose.
z{assign}First a
[1] {comment} APL2-style first item of an array.
[2] z{assign}{up_arrow}a
z{assign}Split a
[1] {comment} APL2-style enclose-with-axis.
[2] z{assign}{quad}Split a
mat{assign}Mix vv
[1] {comment} APL2-style disclose.
[2] mat{assign}{quad}MIX({max}/{enlist}{shape}{each}vv)
{take}{each}vv
z{assign}b PEnclose a
[1] {comment} Portitioned enclose, boolean control.
[2] z{assign}b {quad}PEnclose a
...
In the intervening dozen years, I have sometimes found it useful to be able
to move data as well as code ...
The following put data values into something pretty close to APL2 2{quad}TF
transfer form, which can then be transliterated, and subsequently, well, ...
whatever. This takes about as much code as everytihing else combined ...
[a few abbreviations have crept into the translate table
{#} = {quad}
{@} = {comment}
{^} = {and}
{v} = {or}
{is} = {assign}
{;} = {diamond}
{go} = {goto}
{e} = {epsilon}
{i} = {iota}
{r} = {rho}
]
z{is}{delta}TFval a;b;i;p;r;s;t;v;{#}IO;{#}PP
[1] {@} Extended transfer form for array
[2] {#}PP{is}18 {;} {#}IO{is}1
[3] p{is}'abcdefghijklmnopqrstuvwxyz'
,'ABCDEFGHIJKLMNOPQRSTUVWXYZ'
[4] {@} Printable characters
[5] p{is}p,'0123456789~!@#$%{^}{amp}*()-=_+[]{[}{]}\{stile}'
,';'':{dquot},./{lt}{gt}?'
[6] p{is}p,'{each}{-}{leq}{geq}{/=}{v}{^}{x}{%}{ib}{del~}'
,'{dngrade}{upgrade}'
,'{o_stile}{o\}{o-}{o*}{~v}{~^}{[%]}{w}{e}{r}{take}{drop}'
,'{i}{o}{a}{max}{min}'{delta_}{del}{delta}{jot}{#}{[quot]}'
,'{is}{go}{;}{fmt}{exec}{lshoe}{rshoe}{cap}{cup}'
,'{bot}{top}{dex}{lev}{@}{\-}{/-}'
[7] r{is}'' {;} v{is}'' {;} s{is}{r}a
[8] {go}(0 1{i}{r}s){rshoe}L00 L10 L20
[9] L00: {@} Scalar
[10] {go}(a{e}p)/L02 {@} Printable char?
[11] {go}(a{e}{#}AV)/L03 {@} Other char?
[12] {go}(0{/=}{match}a)/L04 {@} Enclosed?
[13] {@} Scalar number (only case left)
[14] v{is}{fmt}a {;} {go}L90
[15] L02: {@} Printable char
[16] v{is}{quot}{quot}{quot}{quot},a,{quot}{quot}{quot}{quot} {;} {go}L90
[17] L03: {@} Non-printable char
[18] v{is}'{#}AV[{#}IO+',({exec}-1-{#}AV{i}a),''
[19] {go}L90
[20] L04: {@} Enclosed scalar
[21] v{is}'{lshoe}',{delta}TFval First a {;} {go}L90
[22] L10: {@} Vector
[23] r{is}(s{e}0 1)/({fmt}s),'{r}'
{@} Explict shape for empty or single
[24] t{is}a
[25] L11:
[26] t{is}(1{max}{r}t){take}t {@} Get prototype if empty
[27] {go}({^}/t{e}p)/L12 {@} All printable?
[28] {go}({^}/t{e}{#}AV)/L13 {@} All chars?
[29] {go}(1{/=}{match}t)/L19 {@} Non-simple?
[30] {go}({v}/{#}AV{e}t)/L13 {@} Heterogeneous?
[31] v{is}{fmt}t {;} {go}L90 {@} Simple numeric (only case left)
[32] L12: {@} Printable chars
[33] v{is}'''',t,'''' {;} {go}L90
[34] L13: {@} Chars, some non-printing, or simple heterogeneous
[35] v{is}1{drop}{delta}Enlist ' ',{each}{delta}TFval{each}t {;}
{go}L90
[36] L19: {@} Not simple
[37] r{is}r,(1{e}{r}t)/'{lshoe};
{;} v{is}{delta}Enlist'('{each}({delta}TFval{each}t)
,{each}')'
{;} {go}L90
[38] L20: {@} Rank {geq} 2
[39] r{is}({fmt}s),'{r}' {;} t{is},a {;} {go}L11
[40] L90:z{is}r,v
Dick Bowman
news:449c576df89df7c0...@localhost.talkaboutprogramming.com
:
> "I suspect that one way to start would be to have a neutrally-based
> resource page somewhere ..."
>
> Excellent idea ... until I ask who pays for it.[... deleted ...]
Well, that's always a stumbling block for volunteer efforts. My
preference is to stay away from "organisation" - let people do what they
want to do, fill the Web with APL-related material and trust in search
engines to lead us where they will. Trouble there is that it seems to
be getting more difficult to get search engines to notice new pages.
But if there's a thrust of people thinking (and doing) "I'll just write
this up and put it on my Web site" - which I find is good personal
discipline anyway - where's the cost in that?
>
>
> "Perhaps a repository where stuff stands or falls on its own merit
> might have a better chance of survival." Forums are an excellent
> platform for exchanging ideas and code [... deleted ...]
For me, repository (plunk the stuff somewhere - sort of like a left
luggage office) is different from a forum (ongoing exchange of ideas).
Getting APL into text messages is another matter.
>
> "Thinking about my own attitude to contributing material - I'd be
> happy to tell people where they can find my stuff (and what my
> conditions might be for having them use it)" Please do. [... deleted
...]
Most of my stuff is at www.apl.demon.co.uk, as it has been for many
years. I add to it "when I feel like it". There's a very basic ftp
site (apl.demon.co.uk) that people may be able to reach with their ftp
clients (it doesn't seem to like being looked at by browsers, which is
why it's low-key). If anybody wants to publish (or put links on) to
either of these places all they need to do is send me email.
>
> "not to mention the ongoing aggravation of sending out updates" I am
> not sure what the answer is here but I imagine periodic updates will
> be necessary.
As I wrote above, what I put in my space is entirely under my control
(same for others with their spaces) - but having to remember to send it
(with a cover note) to "the librarian" would be a chore. And being "the
librarian" somehow begins to feel like work.
Jerry Koniecki mentioned version-specificity as an obstacle. I'm not
sure about that in my current world-view. I think if I had a need for
(say) Heckman functions (and I don't think I do) - while it would be
ideal to be able to pick up an APL/W workspace or two, I'd feel it was a
worthwhile step forward to be able to find that someone had made an APL2
workspace containing useful stuff and to be able to reach them. Worst-
to-worst, we could exchange hard copy. Of course, once the discussions
reaches ATF files we begin to get to uncomfortable places like
implementations with features beyond the domain of ATF files (like APL/W
namespaces) - and (for portable code) the limitations of lowest-
denominator language commonality.
AA2e72E
uncomfortable places like implementations with features beyond the domain
of ATF files (like APL/W namespaces) - and (for portable code) the
limitations of lowest-
I agree; I think we might need to see things as hard/virtual copy--PDF
avoids the font issues-- as a first requirement and other electronic
versions.
So we have another useful link:
I am interested in SQAPL and storing APL objects in databases.
http://www.apl.demon.co.uk/aplandj/accessff.pdf
Also, there is an APL tutorial at:
brian.b.m...@lmco.com
vendor-independent text format, perhaps APLASCII, that could be
extended easily by the user community as needed. This would allow
automated porting of code beyond the capabilities of ATF files. For
example, if a workspace with namespaces were read into an APL
implementation that didn't support namespaces, the reader function
could implement a workaround, such as prepending the namespace name to
the names of member functions and variables.
I was also wondering about the possibility of adding a small APL
software library to the SIGAPL web page; is there enough storage space
provided by the ACM?
--- Brian
David Liebtag
our web site later today. Let me just check with my colleagues to make sure
it's okay.
phil chastney
and I cannot
which nicely illustrates the point I am trying to make
that forum is accessible via HTTP, and uses HTML to define
its display -- part of that definition is that, in certain
places, it specifies the APLPLUS font -- this effect
will only be visible if the user's machine has that font
installed
I repeat, the HTML -specifies- the font, the user's
machine -displays- it ... if it can
they are different acts,
and that was the point I was trying to make
but to continue: a permanent website is required for
an archive, but which particular APL font should its
users equip themselves with? -- but before you answer
that question, I would like to know why this archiving
website doesn't just use Unicode -- it would give 100%
coverage for all APLs, even if it doesn't give 100%
coverage for all APLers
outside of the HTTP, HTML can still be used with newsgroups,
and it has been suggested more than once that c.l.a should
switch to HTML
and if that is overkill, Unicode-encoded APL could be sent
and read over NTTP, preferably using UTF-8 -- this would not
affect plaintext, and while the user's machine still needs
a font of some sort endowed with APL symbols, the particular
font is not mandated, and for of us many Microsoft's Arial
Unicode would suffice
it is sometimes suggested that APL's character set has
inhibited its acceptance -- if APLers are unable to
communicate APL to each other over NTTP, then maybe there
is something in that argument
there again, maybe the fault is in ourselves
AA2...@lycos.co.uk
understand what you are saying.
There is a danger that if we reached for the 'ideal' archive (all
fonts, copy & paste code, all formats etc.) we end up with nothing.
To start with, I would be happy with
1. PDF content, illustrating code & ideas
2. links to other sites
Eventually, we could move to provide downloads, mirror linked sites
etc.
Lots of ideas so far and a truely premium bonus if David manages to put
the PDF of IDIOMS on his/IBM site.
What happens after enough ideas are submitted?
phil chastney
> Phil, this is already beyond my full comprehension; I sort of
> understand what you are saying.
>
> There is a danger that if we reached for the 'ideal' archive (all
> fonts, copy & paste code, all formats etc.) we end up with nothing.
for the archive(s), I was actually suggesting a minimalist
approach, requiring no special fonts
cut&paste of code will not necessarily work across dialects
even if (a) the document permits cut&paste, and (b) the code
is strictly APL-1
if cut&paste is possible, having the code in Unicode
will make it easier to convert between dialects
the ng, likewise, could do with going more minimalist --
that is, use the power of APL notation, and forget APL/ASCII
but that's just one man's opinion . . . /phil
Dick Bowman
@e56g2000cwe.googlegroups.com:
> [... deleted ...]
>
> I was also wondering about the possibility of adding a small APL
> software library to the SIGAPL web page; is there enough storage space
> provided by the ACM?
>
> --- Brian
>
>
You'd have to ask the SIGAPL people about that - my personal preference is
to avoid ACM Central.
Jimserac
Damn right! An important topic so I'll get right to the point.
I've already documented in past postings my merry traipsing thru the
web
trying to find lost/forgtotten bits of APL and APL2 code with which to
learn/experiment
with. NO such problem exists with Smalltalk, C++ , C or even Prolog
and Lisp - but, perhaps because of the font problem, a great deal of
source code from APl's golden age lies forgotten or lost. Here are
some ideas:
1. Tell ACM to get their precious QUOTE QUAD and their many scholarly
papers out in a PUBLICLY AVAILABLE and FREE web site. Learners are not
going to spend $200 per year to access this stuff, if they even know it
exists. Vector magazine has done a public service by making back
issues available - they need to post the earlier ones!
The French APL Association needs to make their earlier issues available
and if there are some costs involved we should probably donate some
money.
2. BEG Ted Edwards to release his APL code. When learning APL,
everytime I searched google for some information or fine point, Ted was
right there with some post that explained it or else pointed the way.
Too bad he had to spend more time in explaining the value of doing it
the APL way with uninformed skeptics than in showing code. He has
built himself a collection of amazing APL utilities over a 30 year
period (probably longer) and is a whiz at APL2. He has already shared
much of his stuff in individual postings but maybe he would be willing
to post some full workspaces, even if not fully documented. If he did,
the result would be a TREASURE TROVE of techniques and ideas in GPS,
Structural mechanics and math.
3. George White has been working on Paul Penfield's Martha and Llama
APL workspaces for quite some time - this code is both famous and
amazing and should be followed with great interest. It is probably
worth the trouble to become familiar with the vagaries of APLSE just to
try out this code and learn from it.
4. Tell IBM to MAKE A LOW COST ENTRY LEVEL APL2 (NOT THE TIME LIMITED
ONE THEY OFFER NOW) and also put online the numerous older journals,
historical workspaces and other materials moldering in their digital
vaults.
Just some ideas, the chances are practically nil on most of them.
Thanks
Jim
AA2...@lycos.co.uk
archive either; most of the material is in the minds, sites and
computers of generous and very able individuals. As pointed out, they
already have a wealth of information which irritatingly comes up on
searches only to be met with access barriers. In this respect, VECTOR
is to be commended indeed in making their material accessible to the
public.
APLX have a cheap licence for students, Dyalog have a policy that makes
their interpreter available subject to an undertaking for
non-commercial use. APL2 is available freely to 'educationalist' (I
presume this means teaching institutions) and APL2000 had a similar
intention (I am not sure what hapened to this). For all the vendors,
this applies to their current commercial interpreters.
The British APL Association's AGM is on 19 May 2006: if enough people
turned up and requested BAPL to host the archive on thier site, there
might be a positive outcome.
A donation to set up this archive is interesting: some more details on
how it will work is required for such an initiative.
David Liebtag
> papers out in a PUBLICLY AVAILABLE and FREE web site. Learners are not
> going to spend $200 per year to access this stuff, if they even know it
> exists.
I joined SIGAPL just a few days ago for $30 US. I don't think that's
unreasonable.
David Liebtag
Morten Kromberg
> I think that it would be useful to use some machine-readable
> vendor-independent text format, perhaps APLASCII, that could be
> extended easily by the user community as needed.
As far as the format of an archive is concerned, I think UNICODE has
become the right format to use. It contains all the symbols used by
past and present APL systems, and allows us to put APL code into files
which most computer systems are starting to treat as "simple text
files". This makes it amenable to processing by a variety of tools
including source code management systems. For example, I am now
comparing versions of APL code using a cheap tool I downloaded from the
internet - and it works perfectly!
There ARE still a few glitches when viewing APL encoded as UNICODE in
some web browsers, and there are possibly no tools for reading it into
some older APL systems (but these can easily be written in APL, I wrote
one for Dyalog APL in a couple of hours). I am convinced that even with
the problems which remain today, UNICODE is the best medium for code
sharing. In a short time, I am sure that the problems will be sorted
out and it will be "perfect".
Dyalog have an "Input Mode Editor" application, which allows typing APL
into any Windows application. If there is interest, we can put this in
the public domain - but as Microsoft is now providing a Unicode
keyboard editor, it is "straightforward" to build alternative input
mechanisms.
Dyalog aims to support loading from and saving APL code in Unicode
files in the very near future. To be precise, the format we intend to
support is (if I got this right) UCS-2, which is a relatively simple
file format in which the first two bytes of the file are FFFE or FEFF
depending on whether the file is big- or little-endian, followed by two
bytes for each UNICODE character.
There may still be a need for an additional format to describe DATA,
but again there are already suitable formats for this based on XML, in
the public domain. I believe that the combination of Unicode and the
right XML schema makes it straightforward to describe any APL array
(including arrays of objects if you are using Dyalog version 11.0).
This is also an area we intend to look more closely at in the near
future.
Morten Kromberg,
Dyalog Ltd.
David Liebtag
The UNIFILE function in the APL2 GUITOOLS workspace reads and write UCS-2
files.
Mike Kent
> 1. Tell ACM to get their precious QUOTE QUAD and their many scholarly
> papers out in a PUBLICLY AVAILABLE and FREE web site. Learners are not
> going to spend $200 per year to access this stuff, if they even know it
> exists.
SIGAPL, rather than the ACM parent organization, sets policy about access
to ACM Digital Library items that were originally published by SIGAPL.
SIGAPL members (annual dues, $30) have access to all the SIGAPL material
in the DL, without a general subscription to the DL, and whether or not
they also join ACM. Making everything (or at least, everything more than
say one year old) accessible generally and at no cost has been discussed,
more than once, by the SIGAPL Steering Committee with no decision taken; if
you would like this moved to a front burner (and if you favor a particular
decision) you might join SIGAPL an make your views known to the steering
committee. Or, you might write a letter to the editors of QQ, to publicize
your views to the entire SIG membership (I would be astounded if such a
letter were not published). You might even volunteer to take on some
of the SIG's work; SIGAPL (and ACM) have limited financial and manpower
resources.
Contact information is at
micr...@microapl.demon.co.uk
>
> As far as the format of an archive is concerned, I think UNICODE has
> become the right format to use. It contains all the symbols used by
> past and present APL systems, and allows us to put APL code into files
> which most computer systems are starting to treat as "simple text
> files".
> files in the very near future. To be precise, the format we intend to
> support is (if I got this right) UCS-2, which is a relatively simple
> file format in which the first two bytes of the file are FFFE or FEFF
> depending on whether the file is big- or little-endian, followed by two
> bytes for each UNICODE character.
I agree with Morten on this. Unicode is the way to go since it is
vendor-neutral, supported by non-APL applications, and even allows APL
code to be displayed tolerably well in generally-available fonts from
Microsoft and others. In particular, I agree with Morten that we
should standarize on the 2-byte UTF-16 representation, because it is
easy to deal with and is used directly by the Windows programming
interfaces.
APLX, and I believe all the other major APLs, already support data
exchange using Unicode. Even if a particular APL does not have
built-in Unicode support, it is trivial to translate back and forth
between UTF-16 and the Quad-AV of any given APL system.
>
> There may still be a need for an additional format to describe DATA,
> but again there are already suitable formats for this based on XML, in
> the public domain.
>
Absolutely right. I would like to propose that the APL vendors get
together to agree on a standard XML scheme for describing APL 'things'
(I would use the word 'objects', but that has too specific a meaning
here.) As a start, this should encompass simple and nested arrays,
user-defined functions, and workspaces which contain only the above.
'Things' of this kind should be pretty well portable amongst at least
APL2, APLX, Dyalog and APL+Win, and to a certain extent Sharp APL as
well. Extensions to this base scheme could be agreed for user-defined
operators (which should be portable between APL2, APLX and Dyalog, but
I believe are not supported by APL+Win). Dyalog has a number of
further language extensions (D-fns, namespaces, and now objects) which
would not currently be portable across APL interpreters, but if we
agree on a sensible XML scheme it might be possible in the future to
provide some portability here too.
It would also be easy to extend the XML scheme to represent component
files (it would be a rather verbose representation, but who cares -
storage is cheap nowadays).
Any takers?
Richard Nabavi
MicroAPL Ltd
phil chastney
> As far as the format of an archive is concerned, I think UNICODE has
> become the right format to use. It contains all the symbols used by
> past and present APL systems, and allows us to put APL code into files
> which most computer systems are starting to treat as "simple text
> files". This makes it amenable to processing by a variety of tools
> including source code management systems. For example, I am now
> comparing versions of APL code using a cheap tool I downloaded from the
> internet - and it works perfectly!
>
> There ARE still a few glitches when viewing APL encoded as UNICODE in
> some web browsers
Morten -- are those glitches down to the browsers, or simply
the result of HTML specifying fonts the user hasn't installed?
> <snip>
>
> Dyalog aims to support loading from and saving APL code in Unicode
> files in the very near future. To be precise, the format we intend to
> support is (if I got this right) UCS-2, which is a relatively simple
> file format in which the first two bytes of the file are FFFE or FEFF
> depending on whether the file is big- or little-endian, followed by two
> bytes for each UNICODE character.
make that "followed by two bytes for each Unicode character
in the Basic Multilingual Plane (BMP)"
there are characters beyond the BMP, requiring 32-bit addresses,
used by nutters who study arcane matters such as dead languages and
mathematics -- these characters can be accessed unambiguously, via
Unicode's "surrogate" mechanism, using two 16-bit quantities
UCS-2 is good for internal representation too, I would have
thought -- no nasty modalities when scanning a string, and it
coincides nicely with C's "wide" chars -- and UTF-8 makes most
sense for communications -- but these are things for you to decide
will you store your APL code using the ISO codepoints or near
equivalents from ASCII? (as an aside: among other things, Lee
Dickey and the other APL standards people persuaded Unicode to
include all the symbols used by past, present ->and proposed<-
APL systems)
all the best . . . /phil
brian.b.m...@lmco.com
>Jimserac wrote:
> 4. Tell IBM to MAKE A LOW COST ENTRY LEVEL APL2 (NOT THE TIME LIMITED
> ONE THEY OFFER NOW) and also put online the numerous older journals,
> historical workspaces and other materials moldering in their digital
> vaults.
I don't know why they don't release personal APL2 versions for $150 as
they did for OS/2, but people using Linux can get a free version of
APLX or Sharp APL for Linux. I have APLX running on Fedora Core 5 and
am fond of it. It is similar to APL2 but with many useful extensions
such as a #SS with search and replace capability. I haven't installed
Sharp APL recently as I have had problems getting the fonts to work,
but I'd like to try again when I have a chance. It has interesting
features, such as function rank, that I like to play with. I tried
running APLI386 in Dosbox but it didn't work, probably because of its
use of the Phar LAP memory extension software. APLIWIN used to run
under NT, but I don't know about XP; I'll have to try that some time.
The APLI packages were an incredible bargain -- a full second
generation APL interpreter for $30.
Some IBM journal articles can be found online, but it would be nice to
have them all in a central repository somewhere. Also note that you
can (or at least could a few years ago) request free publications from
IBM Santa Teresa Labs at an address given in one of the TryAPL2
workspaces, which also lists a number of these publications.
--- Brian
brian.b.m...@lmco.com
Since each APL implementation has a different method for accessing
files, in order to aid the creation of portable APL programs I think
that it would be useful to have a set of file I/O libraries, one for
each APL implementation, that all provided a set of identical cover
functions for reading and writing files. These could support various
formats such as ASCII, APLASCII, UCS-2, and UTF-8. It would be nice to
support portable binary I/O as well, which might be done by adopting a
standard set of binary formats as was done for the FITS file format for
astronomical data transfer. (See
http://heasarc.nasa.gov/docs/heasarc/fits.html for general information
or http://archive.stsci.edu/fits/fits_standard/ for the standard)
For speed, functions could be provided to do binary I/O in the local
host system format, with the understanding that the files produced
would not be directly portable to systems with a different word length
of byte ordering.
--- Brian
m...@privacy.net
>The UNIFILE function in the APL2 GUITOOLS workspace reads and write UCS-2
> files.
Is this WS available for us OS/2 users of APL2? I don't see it on my
system.
-- Dave
-----------------------------------------------------------
dhdurgee<at>verizon<dot>net
-----------------------------------------------------------
Morten Kromberg
> Morten Kromberg wrote:
> > There ARE still a few glitches when viewing APL encoded as UNICODE in
> > some web browsers
>
> Morten -- are those glitches down to the browsers, or simply
> the result of HTML specifying fonts the user hasn't installed?
I have not yet had time to study the problems in detail, but have been
following experiments performed by other from a distance. "Full Unicode
Support" is a target for Dyalog Version 11.1, so we will be taking a
close look at these issues over the summer, and will be aiming to be
ready to make statements about the details of what we intend to do and
how we expect browsers and other components to deal with it, at our
User Conference in October.
>
> make that "followed by two bytes for each Unicode character
> in the Basic Multilingual Plane (BMP)"
Yes, that is more correct.
>
> will you store your APL code using the ISO codepoints or near
> equivalents from ASCII?
This is a tricky issue and I know that there are some cases which are
very hard to decide on, like | and the various quotes. Very roughly,
our goal will be to be as compatible as possible with what other APL
vendors have done or are planning to do. Note that for each unique
256-element []AV (or 512, if you are still runnning DEC APLSF :-), a
mapping needs to be defined to Unicode. There is not a single mapping
for any particular APL system, as a Czech Dyalog user is likely to be
using a different 256-element subset of Unicode from someone in the UK.
Making the process of migrating transparently from existing systems to
a system which supports Unicode is going to be an interesting
challenge.
> (as an aside: among other things, Lee
> Dickey and the other APL standards people persuaded Unicode to
> include all the symbols used by past, present ->and proposed<-
> APL systems)
I know, there are lots of interesting symbols to pick from once we get
there!
By the way, with respect to sharing binary data between systems, there
IS a standard for this, which is used by quite a few people - but
remains relatively unknown. It is possible that the functions are not
quite accessible enough in the systems which support it. There is
support for the SCAR (Self-Contained ARay) format in APL2, APL+Win and
Dyalog APL. This format was designed for Insight Systems more than 10
years ago, is based on Unicode translate tables, and is now in the
public domain. For more information, see
http://www.insight.dk/scardesign
It may be worth doing something to make SCAR functions more accessible
- the format is highly efficient - but my feeling is that we will get
better long term mileage out of adopting something more standard, and
using an XML array representation based on Unicode. This way, we can
share our arrays with non-APL systems as well.
Morten
AA2e72E
Archive, or about attending their AGM!
I thought the APL archive was about collating all the [historical] APL
material in one location. At the outset, although this would obviously
not be of benefit to every single APL developer because some of the
material will not relate to their specific interpreter, everyone will
be able to recognise (and perhaps adapt) the content if it is shown in
APL (PDF being the most likely way of doing so).
Re the BAPL AGM: I understand that MicroAPL are going to demontrate
their APLX64 and that Dyalog will present 'APL Objects' ... cutting
edge APL, I believe, and still no interest!
So far APL2000 are notorious by their lack of input!
Re XML as an interchange format: Might we see an ActiveX control that
will expose the same set of methods, properties, and events to all APL
clients and manage the interpreter specific difference within the
black box? So, for instance, would we be able to save APLX's Grid
Object's content to an XML file and read it into a Dyalog Grid Object?
Re Unicode: This may well be the future. I wonder how the APL2000 []UCS
and []DR in version 6.0 fits into the schema seemingly agreed upon by
Dyalog & MicroAPL.. Could this lead to a truely Unified APL keyboard in
the conventional sense ... same mapping across interpreters?
phil chastney
> <snip>
>
> Re Unicode: This may well be the future. I wonder how the APL2000 []UCS
> and []DR in version 6.0 fits into the schema seemingly agreed upon by
> Dyalog & MicroAPL.. Could this lead to a truly Unified APL keyboard in
> the conventional sense ... same mapping across interpreters?
nothing's guaranteed, but the probability of being able to use
the same keyboard with different products does increase somewhat
dialectic differences will remain, of course, so some interpreters
may not recognise some characters as valid code
regards, &c . . . /phil
David Liebtag
As I recall, APL2 for OS/2 had a PMTOOLS workspace. GUITOOLS is the
analogous workspace for Windows. It's available in the demo version you can
download for free. And, I think the UNIFILE function might work on OS/2.
David Liebtag
Jimserac
I do.
Jim
Stefano "WildHeart" Lanzavecchia
> - the format is highly efficient - but my feeling is that we will get
> better long term mileage out of adopting something more standard, and
> using an XML array representation based on Unicode. This way, we can
> share our arrays with non-APL systems as well.
Alas, the world is moving too fast. The buzzword of the week:
http://www.json.org/ (unsurprisingly no APL bindings here).
To check its popularity, something from brand new Google Trends:
http://www.google.com/trends?q=ajax.net%2C+json but
http://www.google.com/trends?q=ajax%2C+json&ctab=0&geo=all&date=all
--
WildHeart'2k6
micr...@microapl.demon.co.uk
>
> It may be worth doing something to make SCAR functions more accessible
> - the format is highly efficient - but my feeling is that we will get
> better long term mileage out of adopting something more standard, and
> using an XML array representation based on Unicode. This way, we can
> share our arrays with non-APL systems as well.
>
Yes, sharing with non-APL systems, and taking advantage of all the
tools and utilities which exist for handling XML and exchanging data
over the internet, are important advantages of XML.
But I think there are other advantages too. XML is a very natural
format for representing arrays containing arrays, or workspaces
containing functions, operators and arrays-of-arrays. I think that
extensions such as Dyalog's namespaces can also be naturally repesented
- just an XML block containing (you guessed it...) functions,
operators, arrays-of-arrays, and maybe other namespaces as well. (XML
is intrinsically recursive).
And whilst I think we should try to keep things as simple as we can,
there are also some very interesting possibilities arising from using
XML tags to describe the properties of the APL 'thing' being
represented. These can be purely descriptive (copyright notices, date
of last modification, author, etc). But they can also do more than
that; you could have a tag giving an alternative version of a function
for a different APL flavour.
For example, you might have a utility function which did
string-search-and-replace using generic APL primitives, and a more
efficient variant for APLX which used our built-in
string-search-and-replace function Quad-SS. Or a version of a
workspace which used Dyalog namespaces, with a variant for APLs which
don't have that feature. In other words, it might be possible to
provide a portable format for a workspace, which when loaded would be
optimised for the particular APL you are using. This kind of approach
would allow vendors to continue to offfer cool new features in the
language, whilst still allowing APL code to be as portable as possible.
More thought is needed on all this, but I think it is worth exploring.
The goal, which would be of benefit to all APL vendors and to the APL
community in general, would be to provide a mechanism which would allow
any APL user, using any APL interpreter, to contribute code to a
vendor-neutral APL archive.
Richard Nabavi
MicroAPL
Morten Kromberg
> I agree with Morten on this. Unicode is the way to go since it is
> vendor-neutral, supported by non-APL applications, and even allows APL
> code to be displayed tolerably well in generally-available fonts from
> Microsoft and others. In particular, I agree with Morten that we
> should standarize on the 2-byte UTF-16 representation, because it is
> easy to deal with and is used directly by the Windows programming
> interfaces.
I believe that there have been discussions between Dyalog, IBM and
possibly others(?) to agree on which code points to use for the symbols
where there are alternatives available (like vertical stile). I suggest
that we revisit/reconfirm these mappings and publish a joint document
on all our common and separate web pages for everyone to be able to
check if in doubt. Longer term, we should discuss whether we it is
realistic to lobby for our common APL Font (APL385 Unicode) to be
distributed with Windows/Unix - and perhaps extending it so that it
includes Chinese, Japanese and other symbol sets (many interesting
issues here but we should talk).
> I would like to propose that the APL vendors get
> together to agree on a standard XML scheme for describing APL 'things'
> (I would use the word 'objects', but that has too specific a meaning
> here.) As a start, this should encompass simple and nested arrays,
> user-defined functions, and workspaces which contain only the above.
> (stuff snipped)
>
> Any takers?
See you on next Friday at the BAA AGM!
Regards,
Morten
David Liebtag
all the idioms displayed by the APL2 IDIOMS function. To get the PDF, go to
http://www.ibm.com/software/awdtools/apl/support.html and use the Search
Support field to search for idioms.
Ron
micr...@microapl.demon.co.uk wrote:
An added benefit of an XML based approach would be that, vendors
wouldn't even have to agree on a common schema - XSLT transformers would
easily handle transformations from one XML document format to another.
APL2 nested arrays and XML are an almost perfect match. I've been
exporting nested arrays as XML to read it into scheme code via SSAX and
represent them as s-expressions for processing.
roland
AA2e72E
contains
IBM APL Products and Services
Thank you very much; this is a great resource, one of the positive
outcomes of this thread. I am sure the APL community is grateful.
AA2e72E
Jimserac
I'm not going to join anything so I can use a computer language.
I did not have to join anything or pay any dues
to learn and use C or C++ and I'm not going to
do it for APL.
There's your problem As long as you have to deal
with committee, APL is going nowhere.
It must be placed in an environment in which its merits
can be freely discovered, downloaded, experimented
with and used. This has not happened.
Jim
Mike Kent
And here I thought you wanted what you said you wanted --
access to SIGAPL's publications. Silly me.
Marv
I've been following this topic with great interest.
Jimserac wrote:
> NO.
>
> I'm not going to join anything so I can use a computer language.
>
I'm with you on that. I wonder if ACM has been very good for APL?
Its structures, rules and "service for fee" operational style, always
bothered me.
> I did not have to join anything or pay any dues
> to learn and use C or C++ and I'm not going to
> do it for APL.
>
Nor did I tho I did have a patron. I ask for an account and a terminal
and got Gilman and Rose and logged on.
> There's your problem As long as you have to deal
> with committee, APL is going nowhere.
>
Might we discuss replacing "committee" with "community" ?
Could APL go anywhere dealing as a community? I think it might.
> It must be placed in an environment in which its merits
> can be freely discovered, downloaded, experimented
> with and used . This has not happened.
>
> Jim
What environment might that be? I've a few thoughts on that.
Look at where we are today. APLX running on GNU/Linux. IBM actively
involved with opensource. XML open standard. Unicode. ... (too
many to list).
"Can be freely discovered, downloaded, experimented with and used"
sounds like GNU to me. How might that happen? Well couldn't one
vendor just open the essentials parts of the interpreter? Or maybe
all in the community of interpreter writers agree on a core
interpreter to use and open that. It could happen, I think. Look
at the Linux kernel community.
Are there incentives for vendors to open a "core-interpreter"? I'm
not convinced that there aren't.
Maybe I'm all wet on this line of thinking. If so, what other
options are there for attaining a freely discoverable and useable APL.
Marv
Mike Kent
> I've been following this topic with great interest.
>
> Jimserac wrote:
>
>>NO.
>>
>>I'm not going to join anything so I can use a computer language.
>>
>
> I'm with you on that. I wonder if ACM has been very good for APL?
> Its structures, rules and "service for fee" operational style, always
> bothered me.
ACM is what it is and does not exist solely to serve the APL community.
What "structures and rules" do you object to -- specifically?
As to the "service for fee" operational style, ACM is /not/ a charity, and
what it does can't be done for free (though it might perhaps be done more
efficiently and at lower cost). Here are some more learned and professional
societies that also charge for membership, maintain online resources that
are available only to members, and run conferences at which attendance is
not without cost:
The American Mathematical Society
The American Chemical Society
The American Physical Society
The Modern Language Association
IEEE
The American Medical Association
The American Bar Association
>>I did not have to join anything or pay any dues
>>to learn and use C or C++ and I'm not going to
>>do it for APL.
This is an insanely stupid straw man. You do not have to join ACM to learn
APL. You *DO* have to join ACM and subscribe to the Digital Library (at
substantial cost) or join SIGAPL (at much lower cost) to have unlimited
access to SIGAPL's publications. Or you can search the bibliographic data
and read the abstracts for free, purchasing access only to articles you
might find of interest.
Nor do you have to purchase commercial software to get an APL interpreter --
though you do if you want a commercial grade interpreter
> > Nor did I tho I did have a patron. I ask for an account and a terminal
> and got Gilman and Rose and logged on.
>
>
>>There's your problem As long as you have to deal with committee,
>>APL is going nowhere.
>
> Might we discuss replacing "committee" with "community" ?
> Could APL go anywhere dealing as a community? I think it might.
Committee, volunteer community, whatever -- if there's more than
one person involved, there are going to be rules and structures.
>>It must be placed in an environment in which its merits
>>can be freely discovered, downloaded, experimented
>>with and used . This has not happened.
There has not been enough interest from people who are willing to
do the (considerable) work.
> What environment might that be? I've a few thoughts on that.
>
> Look at where we are today. APLX running on GNU/Linux. IBM actively
> involved with opensource. XML open standard. Unicode. ... (too
> many to list).
>
> "Can be freely discovered, downloaded, experimented with and used"
> sounds like GNU to me. How might that happen? Well couldn't one
> vendor just open the essentials parts of the interpreter? Or maybe
> all in the community of interpreter writers agree on a core
> interpreter to use and open that. It could happen, I think. Look
> at the Linux kernel community.
Commercially subsidized contributions to the Linux kernel started happening
/after/ there was a substantial community and it was apparent that there
were commercial opportunities in servicing that community.
> Are there incentives for vendors to open a "core-interpreter"? I'm
> not convinced that there aren't.
Then explain what they are, and convince one or more vendors to do so.
> Maybe I'm all wet on this line of thinking. If so, what other
> options are there for attaining a freely discoverable and useable APL.
The traditional way in the open source community is to do it yourself from
scratch, or to pick up a defunct or abandoned project, or to start
contributing to an existing active project. If you decide to do it
yourself, you can get hosting and other resources from -- for instance --
sourceforge.net. But be aware -- these resources are provided by
/organizations/ that have /rules/ and /structures/.
AA2e72E
guardians. SIGAPL has managed to rise out of the ashes; all indications
are that that happened because of voluntary effort by key individuals.
I think the obstinate stance to 'not pay' for APL material is
completely unrealistic. It costs money to make such material available
on the Web; that cost is best met by those who benefit. Everyone is
free to opt out provided it is understood that opting out means being
denied access.
There has to be a collection of individuals who maintain the archive;
this does not have to mean that they arbitrate on the content of the
archive but quite simply that they share the burden of keeping the
archive current. I think that all contributions should become part of
the archive: as has been said, a contribution should stand or fall
according to the merit it receives.
The question is not whether their is a committee (or whatever name is
used) but whether there can be a band of volunteers; likewise, the
question is not whether it costs to access the archive but how much it
costs. Nothing in life is universally free: someone has paid for it,
For example, the APL2 Idioms is now available for free download; it is
an invaluable source of reference and is tested. IBM met the cost of
this resource.
Why is a committee not a reasonable means of securing similar material
and why should we not be expected to pay a token price for access? At
$30 for SIGAPL, I think this is highly reasonable.
"I did not pay to learn C or C++" .... someone paid to make it
possible for you. It is time to put something back?
AA2e72E
http://discuss.fogcreek.com/joelonsoftware1/default.asp?cmd=show&ixPost=26695&ixReplies=8
This points to
http://www.kuro5hin.org/story/2002/11/14/22741/791
which has:
"A Shallow Introduction to the K Programming Language"
Jimserac
Marv wrote:
>What environment might that be? I've a few thoughts on that.
It is called the INTERNET and it did not originally exist
for commercial purposes nor for the opportunity
of charging "members" "dues" so they could use things.
Unlike more modern languages, prevailing views of the
milleau of APL remains trapped
in the thinking of the mainframe era which appears
to be re-iterated by proponents of the SIGAPL approch.
The impetus of modern software development is aleatory with
random offshoots starting (and stopping) at unexpected places
with contributions from disparate individuals acrross the world.
It is a genetic kind of thing with unexpected bifurcations
and unions. BUT, this is all based on multiple and freely available
archives scattered thru the net and NOT on the centralisation
of a single archive nor on the beneficence of some
organization who will charge some dues to view it.
To have one archive is good, yes Waterloo is good.
But are we to believe that that is all that there is or
all that could be in the realm of APL. And even
that one archive is woefully incomplete (1988,1989, 1990,1991, 1992
code all missing)
Perhaps the folks thinking of an APL to/from Matlab translator
are on the right track, or else something similar.
There are many possibilities but the important thing
is to stop this thinking as though it were 1976 and realize
that it is now 2006, 30 years later.
There are those who are uncomfortable in this
world of the future that is now. But NO retreat
to the ways or thinking of the past is ever going to work.
Get used to it.
Jim
brian.b.m...@lmco.com
http://www.soliton.com/services_sharp.html) and APLX 1.x (From
MicroAPL, http://www.microapl.co.uk/apl/aplx_downloads.html), are
freely downloadable for personal use on Linux systems, and therefore
suitable for experimenting with the language and learning it. There
are also some open source first generation APLs, such as APL11 and
OpenAPL, which could be extended to create a second generation APL.
There are also other alternatives, such as the APL descendant A+
(http://www.aplusdev.org/), released under the GNU open source license
by Morgan Stanley.
On the other hand, if you are looking for an interesting project you
might try writing your own APL interpreter. For example, APL arrays
could be implemented as an object class hierarchy in a language such
as, say, C++ or Ada 2005:
APL array - base class enforcing a minimal interface
Arithmetic progression vector
Namespace
Dimensioned array - contains a list of dimensions (e.g. as a C++
STL or Ada containers vector class)
Memory-mapped array
Normal array - generic template class that contains a list of
array elements
Boolean array
Character array (16-bit wide characters?)
Integer array
Floating point array
Complex array (e.g. pairs of floating points)
Expression array - array of executable APL expressions, ala
A+
Nested array (e.g. array of pointers to arrays)
Of course there are a number of interesting problems to deal with when
doing this, such as finding a type font that includes all of the
Unicode APL characters, including the ones not currently in use, so you
can add new primitive functions if you like, or figuring out how
function rank and axis specification would interact, but it would
probably be a fun project.
--- Brian
Jimserac
Well spoken objections.
I will consider them.
Thanks
Jim
phil chastney
> <snip>
>
> Of course there are a number of interesting problems to deal with when
> doing this, such as finding a type font that includes all of the
> Unicode APL characters, including the ones not currently in use, so you
> can add new primitive functions if you like, or figuring out how
> function rank and axis specification would interact, but it would
> probably be a fun project.
it is no longer so freely available as it once was,
but Arial Unicode MS contains all the basic stuff
for generations 1 and 2 of APL -- I see no reason
why this shouldn't work well under Linux, but I am
not able to test that right now
regards . . . /phil
Jesper Harder
> I have not yet had time to study the problems in detail, but have
> been following experiments performed by other from a distance. "Full
> Unicode Support" is a target for Dyalog Version 11.1,
Do you happen to have some forward-compatible code for Dyalog 10?
(i.e. some APL code to write and read utf-16 now, which can then be
swapped for the native support when that becomes available). That
would be very useful!
Morten Kromberg
> Do you happen to have some forward-compatible code for Dyalog 10?
> (i.e. some APL code to write and read utf-16 now, which can then be
> swapped for the native support when that becomes available). That
> would be very useful!
Almost - the code I have is embedded in a Class (and stored in a
Unicode file :-). Give me a day and I'll try to fish it out for you.
Please remind me if I forget, things are a little hectic at the moment.
Morten
AA2e72E
have published. See
http://portalparts.acm.org/1130000/1127556/fm/frontmatter.pdf
The relevant section is towards the end, "Notice to past authors of
ACM-published articles"
Morten Kromberg
> Do you happen to have some forward-compatible code for Dyalog 10?
> (i.e. some APL code to write and read utf-16 now, which can then be
> swapped for the native support when that becomes available). That
> would be very useful!
I have uploaded the v11 UnicodeFile Class definition to:
http://www.dyalog.com/download/unicode/unicodefile.dyalog
... and a v10.1 workspace extracted from this to:
http://www.dyalog.com/download/unicode/unicodefile.dws
See the function "Test" in the latter workspace for an example of how
to use it.
Regards,
Morten
P.S. Jesper: The latter is a tested version of what I sent you
yesterday; it does not rely on the built-in 'ReadUnicodeFile' root
method.