[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-apl] Improving the visibility of programming languages derived

From: Devon McCormick
Subject: Re: [Bug-apl] Improving the visibility of programming languages derived from Iverson’s mathematical notation
Date: Thu, 10 Mar 2016 13:16:25 -0500

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:


   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.


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

tel: +1 416 203 0854


Devon McCormick, CFA

Quantitative Consultant

reply via email to

[Prev in Thread] Current Thread [Next in Thread]