Hi Devon,
I agree that Bob’s ideas should be considered. The idea is not to create a unique organisation
or replace existing web sites, but to facilitate the linkages among the different web sites and
improve communications. Also, there are at least two other venues not currently covered that
may be promising:
organization of webinars, and development of
efficient means of internet
communications among organizations and users.
Guy
From: Devon McCormick [mailto:address@hidden
Sent: March 10, 2016 01:16 PM
To: Robert Bernecky
Cc: LaRocque, Guy (NRCan/RNCan); address@hidden; address@hidden; address@hidden; address@hidden; address@hidden; address@hidden; address@hidden; address@hidden; address@hidden; address@hidden;
address@hidden; address@hidden; address@hidden; address@hidden; address@hidden; address@hidden; address@hidden; address@hidden; address@hidden; address@hidden; address@hidden; address@hidden; address@hidden;
address@hidden; address@hidden; address@hidden; address@hidden; address@hidden; address@hidden; address@hidden; address@hidden; address@hidden; address@hidden; address@hidden;
address@hidden; address@hidden; address@hidden; address@hidden; address@hidden; address@hidden; address@hidden; address@hidden; address@hidden; address@hidden; address@hidden;
address@hidden; address@hidden; address@hidden; address@hidden; address@hidden; address@hidden
Subject: Re: Improving the visibility of programming languages derived from Iverson’s mathematical notation
Bob has good ideas we should consider. I've been updating the SIGAPL page with notices of these functional-language conferences to which he refers: please take a look and recommend any other venues that look
promising.
On Thu, Mar 10, 2016 at 9:58 AM, Robert Bernecky <address@hidden> wrote:
Hi, all,
I am not convinced that this group is a good idea, for several reasons.
Here are some of those reasons, as I see them,
being somebody who has worked
in the area of Functional Array Languages for a while:
0. Oh, please include SAC (Sven-Bodo Scholz,
at Heriot-Watt U in Edinburgh) in the language list.
SAC is beating everybody else
in performance, as the attached papers show.
Think of SAC as an extensible APL, even though it lacks
some important features (no higher-order functions).
1. ACM SIGAPL existed outside of SIGPLAN, rather than as Just Another
Language within the SIGPLAN umbrella. The effect of this, although
perhaps intended to provide an incubator for a fledgling language,
was to prevent the good ideas of APL from being exposed to
the more larger programming language community.
Action plan: Infect the extant SIGPLAN, IFL, ICFP, and other
functional and programming communities with the ideas of APL,
showing how it is better than what they are using now, and
why. See the attached as an example (with a lousy summary)
of this.
2. There is already a small group associated with ACM PLDI,
promoting the ideas of functional array languages, and exchanging
ideas among those interested in them.
These are the PLDI Arrays Workshops. I am one a member of the
Program Committee of this year's Workshop. As far as I know,
no papers have been received for this workshop yet. It has
not been well-advertised, as far as I can tell:
http://conf.researchr.org/track/pldi-2016/ARRAY-2016
Laurie Hendren, David Padua, Stephen Herhut, and
Clemens Grelck are also on the program committee.
Action plan: Work within the extant programming languages
community, rather than building yet another island of exiles.
Action plan: Volunteer for the PLDI Arrays Workshops, and
PLEASE submit papers to same, giving your concrete research
results. Soon!
3. The ideas presented in the Arrays Workshops have been,
by and large, quite primitive, and ignorant (sorry!) of the
APL language. For example, one paper given at the Edinburgh
conference recently touted their invention of something
that we know as "scalar extension".
Action plan: Get the fundamental ideas behind APL out to
the larger programming community by concrete actions.
These ideas include, but are not limited to:
- functional notation (no side effects)
- rectangular arrays (NOT vectors of vectors!!) as fundamental
data objects, passed by value and and out of functions.
- higher-order functions: adverbs and conjunctions.
- typeless programming.
Personally, I consider that being able to compile code to achieve
better performance than traditional languages can do (See
attached papers again) is crucial to acceptance, as is
achieving excellent parallel performance with NO source code changes.
We have achieved both of these goals with SAC, but much
remains to be done.
4. There is much wasted effort in the functional array languages
community, that could be avoided if we worked together, instead
of reinventing the wheel. For example, in compiler projects alone,
we have SAC, APEX, and at least two different Dyalog APL compilers.
Action plan: Work within the functional array languages community
to develop tool sets, such as compiler optimizations, that
be used in a variety of settings. Like gcc, one key here is
to define a common intermediate language that can be used to
express the source languages for the relevant functional
array languages.
I have, in my back pocket, but in need of funding, an idea
for a book that describes, the current state of array language
optimizations, much as Bacon, et al's:
Compiler Transformations for High-Performance Computing
describes classical ones. The idea behind my "Optimizations
for Functional Array Languages" (OFFAL) is that each chapter
introduces a new optimization, of set of related optimizations,
offering the motivation for each of them, with benchmarks
and executable APL code that implements the optimization.
The result should be, ignoring things that I don't care
about, such as tokenization, syntax analysis, and run-time code
generation, a usable optimizer for a generic, high-performance
functional array language compiler.
5. APLers are extremely good at ignoring work done outside the
APL community. This blinkered approach (some call it focused,
but we know better...) does not do us any good. As a simple
example, consider that NO APL dialect, with the sole exception
of SAC allows users to create their own derived data types.
Instead, new data types can only be created by the anointed
high priests of implementation. This is a waste of everybody's
time, and results in applications that are harder to write,
harder to maintain, harder to communicate, and harder to
compile effectively. [Gluing things together with "enclose"
does NOT constitute a new data type; it's merely a kludge.]
You have until April 1 to submit papers to Array'16.
Bob
On 16-03-09 07:35 PM, LaRocque, Guy (NRCan/RNCan) wrote:
> Dear colleagues,
>
>
>
> You are receiving this email because you are a member of the steering
> committee of an association or belong to the community of developers or
> consultants of a programming language derived from Iverson’s
> mathematical notation, including APL, J, K, A+, Nial or Gauss. Recently,
> I had a discussion with APL colleagues about the international
> visibility of these different array programming languages. We are aware
> of the fact that the majority of associations, developers and
> consultants have good web sites with a lot of good information, but our
> impression is that there is a lack of good communications among the
> different associations in different parts of the world.
>
>
>
> The reason I am sending you this email is to suggest the idea of forming
> an informal international group that will improve communications among
> the organizations and users of languages derived from Iverson’s
> mathematical notation. This international group could (1) establish
> linkages between the web sites of the different associations, developers
> or consultants, (2) organize webinars, (3) assemble lists of users
> across the world, and (4) provide efficient means of internet
> communications among organizations and users.
>
>
>
> The objective of this idea is not to create a “super” organization that
> will consider existing groups as affiliates, but simply to promote good
> communications and improve the visibility and use of the different
> languages. If you like the idea and wish to initiate discussions,
> please, let me know.
>
>
>
> Kind Regards
>
>
>
> Guy Larocque
>
>
>
> *************************************************
>
> Guy Larocque, Ph.D.
>
> Research scientist/Chercheur scientifique
>
> Natural Resources Canada/Ressources naturelles Canada
>
> Canadian Forest Service/Service canadien des forêts
>
> Laurentian Forestry Centre/Centre de foresterie des Laurentides
>
> 1055 du P.E.P.S.
>
> POB Box 10380, Stn. Ste-Foy
>
> Québec (QC), G1V 4C7
>
> Canada
>
> Tel: 418-648-5791
>
> Email:
address@hidden <mailto:address@hidden>
>
> Editor of/ Éditeur deEcological Forest Management Handbook
> <https://www.crcpress.com/Ecological-Forest-Management-Handbook/Larocque/9781482247855>
>
>
>
>
>
>
>
--
Robert Bernecky
Snake Island Research Inc
18 Fifth Street
Ward's Island
Toronto, Ontario M5J 2B9
address@hidden
tel: +1 416 203 0854
--
Devon McCormick, CFA
Quantitative Consultant
|