Re: Vector themed issue: How to wear sheepskin

On Aug 30, 6:32*am, Dick Bowman <d...@dickbowman.org.uk> wrote:
> Peter Keller <psil...@merlin.cs.wisc.edu> wrote innews:48b85fe2$0$9898$80265adb@spool.cs.wisc.edu:
>
> > [... deleted ...]
>
> > I looked around, and I simply couldn't find a document which basically
> > says "This is the definition of APL" which described a dialect and
> > functionality that would work (as agreed upon by the vendors) on any
> > popular APL interpreter. [... deleted ...]
>
> There is an ISO Standard, but it was produced more than 20 years ago and
> reactively rather than proactively. *As a consequence, the APL it
> describes/defines is a rather small subset of the functionality of current
> interpreters. *I don't know whether there is any ongoing effort to produce
> anything more current.

Maybe ISOAPL2 would be a more meaningful effort?

Gosi wrote:
> On Aug 30, 6:32 am, Dick Bowman <d...@dickbowman.org.uk> wrote:
>> Peter Keller <psil...@merlin.cs.wisc.edu> wrote innews:48b85fe2$0$9898$80265adb@spool.cs.wisc.edu:
>>
>>> [... deleted ...]
>>> I looked around, and I simply couldn't find a document which basically
>>> says "This is the definition of APL" which described a dialect and
>>> functionality that would work (as agreed upon by the vendors) on any
>>> popular APL interpreter. [... deleted ...]
>>
>> There is an ISO Standard, but it was produced more than 20 years ago and
>> reactively rather than proactively. As a consequence, the APL it
>> describes/defines is a rather small subset of the functionality of current
>> interpreters. I don't know whether there is any ongoing effort to produce
>> anything more current.
>
> Maybe ISOAPL2 would be a more meaningful effort?

the problem was, and is, generalised arrays: arrays of arrays

when the market was strong, vendors implemented their own different,
incompatible, definitions

any ISO APL2 (not the best name, incidentally) would have to choose a
definition of generalised arrays -- and once that choice has been
made, somebody's implementation would thereby become "non-standard"

so who finances the production of this ISO document? you can't expect
vendors to provide facilities for a project which might, potentially,
render their implementation "non-standard"

/phil

On Aug 30, 9:28*am, phil chastney
<phil.hates.s...@amadeus.munged.eclipse.co.uk> wrote:
> Gosi wrote:
> > On Aug 30, 6:32 am, Dick Bowman <d...@dickbowman.org.uk> wrote:
> >> Peter Keller <psil...@merlin.cs.wisc.edu> wrote innews:48b85fe2$0$9898$80265adb@spool.cs.wisc.edu:
>
> >>> [... deleted ...]
> >>> I looked around, and I simply couldn't find a document which basically
> >>> says "This is the definition of APL" which described a dialect and
> >>> functionality that would work (as agreed upon by the vendors) on any
> >>> popular APL interpreter. [... deleted ...]
>
> >> There is an ISO Standard, but it was produced more than 20 years ago and
> >> reactively rather than proactively. *As a consequence, the APL it
> >> describes/defines is a rather small subset of the functionality of current
> >> interpreters. *I don't know whether there is any ongoing effort to produce
> >> anything more current.
>
> > Maybe ISOAPL2 would be a more meaningful effort?
>
> the problem was, and is, generalised arrays: arrays of arrays
>
> when the market was strong, vendors implemented their own different,
> incompatible, definitions
>
> any ISO APL2 (not the best name, incidentally) would have to choose a
> definition of generalised arrays *-- *and once that choice has been
> made, somebody's implementation would thereby become "non-standard"
>
> so who finances the production of this ISO document? you can't expect
> vendors to provide facilities for a project which might, potentially,
> render their implementation "non-standard"
>
> /phil

As far as I know there are only two definitions APL2 and Sax
ISO APL2 would be funded by IBM

>any ISO APL2 (not the best name, incidentally)

Luckily, the standard naming scheme for standard revisions would rather
call it "ISO APL-bis", avoiding the ambiguity Gosi already fell prey for.

Martin

On Aug 30, 6:57*pm, neit...@marshlabs.gaertner.de (Martin Neitzel)
wrote:
> >any ISO APL2 (not the best name, incidentally)
>
> Luckily, the standard naming scheme for standard revisions would rather
> call it "ISO APL-bis", avoiding the ambiguity Gosi already fell prey for.
>
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * Martin

I did mean APL2

> ...how do you write a hash table in APL?

For a specific hash table example see:
http://forum.apl2000.com/viewtopic.php?p=1296#1296

For more descriptions of how VisualAPL extends APL to provide
mainstream functionality, see:
http://forum.apl2000.com/viewtopic.php?t=325

An alternative philosophy is to remain within the APL domain and
emulate common algorithms, i.e. APL idioms:
http://forum.apl2000.com/viewtopic.php?t=325

> ...foreign function interface to C...
APL implementations have a long history of this, e.g. APL+Win's
ActiveX, []na, []wcall, []wi interfaces and the recent []new of some
APL's.

By treating the non-APL languages as 'foreign', there has been a
tendency to emulate, simulate and candy-coat the features of a
'foreign' programming language for APL programmers. This further
isolates and possibly entombs APL outside of the mainstream
programming world. In this APL-centric world, the APL programmer never
really learns about or works with the full capabilities the mainstream
and the APL programming language implementer can never really catch up
to the genuine innovations in programming that can rapidly occur in
the mainstream.

Instead, by basing the APL implementation on a mainstream programming
environment, VisualAPL takes a different approach so that the
programmer may choose to incorporate C# statements, code snippets,
algorithms, etc., directly within a VisualAPL function. VisualAPL also
provides the best of both worlds by supporting the interactive,
interpretive session for experimentation, design and testing and the
compiled .Net dll for performance and full inter-operability with the
mainstream environment. VisualAPL does these things, not by emulation,
but by implementing APL using the Visual Studio environment, compiler,
editor and the rest of the Visual Studio IDE as the fundamental basis
of VisualAPL.

The choice to base an APL implementation on the Visual Studio IDE and
C# was made based on the potential market this environment represents,
but a similar approach is certainly possible using Unix/Linux and C or
some other mainstream IDE.

An alternative philosophy is to remain within the APL domain and
emulate common algorithms, i.e. APL idioms:

The correct link should be:

http://forum.apl2000.com/viewtopic.php?t=92

phil chastney <phil.hates.spam@amadeus.munged.eclipse.co.uk> wrote:
> the problem was, and is, generalised arrays: arrays of arrays

If this is the proverbial elephant in the room, then, for the purposes
of the ease of the user of APL pick the one that is best, or collaborate
and create s superset, and everyone moves toward it. Get the vendors
into a room and don't come out until a solution has been found.

> when the market was strong, vendors implemented their own different,
> incompatible, definitions

Even SQL was able to get its way out of that maze with an ANSI document
that now damn near everyone supports. I'd say SQL was very much like
APL in its diversity, maybe even still is--but there is a strong core
anyone can learn and it'll work everywhere. If the vendors have to,
define a new better and method of instead of the competing definitions
and everyone implements it, then it goes into the standard.

> any ISO APL2 (not the best name, incidentally) would have to choose a
> definition of generalised arrays -- and once that choice has been
> made, somebody's implementation would thereby become "non-standard"

This is why the vendors themselves have to get together and talk about it.
Once something is agreed upon, it is up the the vendors to make their
implementations "standard". This takes money and work, and I didn't say
it would be easy. Competition between the vendors is no good if all it
does it kill all of them off and now there are no APL vendors...

The Portland Group C Compiler, the Intel C Compiler, and GCC all have
strange and wierd proprietary extensions to C. However, all of them
implement ANSI C and they all make money and are going to for a long
time. The money is in innovative compiler optimizations and performance
enhancements, features people pay them to implement as an extension into
the language or compiler, and a wide user base that they support where
they have attained critical mass and a sustainable future due to the
sheer number of people that use C. Vendors can still find niche areas
to make plenty of money.

The lynchpin here was ANSI C is a standard vendors agreed upon. Back
when it was happening some stuff made the cut and some stuff
didn't. Portability ruled in the end and compilers that had wierd features
simply became vestiges as the language marched forward. Compilers that
were non standard adapted to the standard or died. I would say that the
vendors and the users won, as C is now vastly popular (well, authoring
unix with it was a pretty damn big chunk of that too).

Vendors can't stay in the same safe zone forever, it moves around as
time passes and the vendors must move with it, not only on a micro scale,
but on a macro one as well.

> so who finances the production of this ISO document? you can't expect
> vendors to provide facilities for a project which might, potentially,
> render their implementation "non-standard"

ISO? I think there is too much damn paperwork and red tape in that....

The vendors are the law, if they create a document over pizza and
coffee and say it is the standard and follow it, it *is* the standard,
ISO or not.

My viewpoint in this debate is that the vendors cling to a relatively
small set of customers and they probably know that as their expert user
base and programmers age, more and more APL will be replaced incrementally
by other languages like matlab by younger programmers who know only that.
When APL is no longer viable at an institution, gets replaced and if
this repeats for enough institutions, then all the vendors get wiped
out and the language goes into the history books. It is APL's future
at stake, which by definition, also means the vendor's futures. Is the
family going to argue about the best way out of a house fire until they
suffocate and die? No they going to pick a direction and go cause it is
better than standing there.

It is my belief that if APL is to become more than what it is and a
serious thing new programmers clamour to learn, it will require blood,
pain, money, and unsavory characters lying in shallow graves. If I said
it was anything else, I wouldn't be very realistic now would I?

Maybe some APL experts should get together and write a Fluent (the
computational fluid dynamics simulator) clone/competitor in APL. No
buildings, no secretaries, no paperwork, no anything but some programmers
and mathematicians in a room with a few fast computers and plenty of
coffee. If APL is really as expressive and powerful as it tries to be,
then the core of the simulator could be written in a _very short_ amount
of time, could be far cheaper to license than the competition, and get
serious monetary inflow. Also, try to get into the physics community since
they do all kinds of powerful mathematics (quantum gravity simulations,
string theory, colliding black holes, etc) which could most certainly
benefit from APL use. Most of that stuff is written in fortran or C++
and the code is a scary as it sounds. Big inroads could be made there
both in market acceptance and reasons for reasearch and development of
non-vendor specific tools in a standard APL...

A radical idea could be that applications like these could be written by
programmers and mathematicians funded by the various APL vendors. Then
some of the profits of these programs could go back to the vendors. Thus
the collaborations are funded, APL is relevant, and the small number
of vendors that already exist have a stranglehold on useful products
people need. The IP created by the collaboratively funded groups get
shared, with no exceptions, by the whole of the vendors. I believe this
type of equality ensures everyone plays well with each other and has
impetus to feed the development cycle. A thing (from my own experience)
to remember is the less mindless paperwork and useless middle managment
there is in that collaborative group, the fiscally tighter and more
productive the team becomes and the faster the results come.

Get some cash cows, then use it to remodel the house of APL.

Of course, I, personally, have no power to effect any movement of anyone
at all and I'm young and probably an idealistic idiot, but I just want
to see APL live, cause it is really damn cool!

Thank you.

-pete

phil chastney <phil.hates.spam@amadeus.munged.eclipse.co.uk> wrote in
news:bp8uk.401385$eu.296054@fe01.news.easynews.com :

> Gosi wrote:
>> [... deleted ...]
>>
>> Maybe ISOAPL2 would be a more meaningful effort?
>
> the problem was, and is, generalised arrays: arrays of arrays
>
> when the market was strong, vendors implemented their own different,
> incompatible, definitions
>
> any ISO APL2 (not the best name, incidentally) would have to choose a
> definition of generalised arrays -- and once that choice has been
> made, somebody's implementation would thereby become "non-standard"
>
> [... deleted ...]

Part of my recollection goes that "enclose" (as in APL2 and other
offshoots from NARS) is different from "box" (as in SharpAPL and J).
There was talk at one time that APL2 might be extended to include both
"enclosed" and "boxed" arrays - some people could see sense/value in
this, but it never happened. So maybe a standard could find room for
both.

I think there's a deeper organisational problem in so far as the goal of
the APL standards people of the 1980s was to encapsulate an agreed and
compatible subset of what was out there as APL product - that they were
not in the language design business.

The direct beneficiaries of a designed standard would be the users -
gaining the freedom to move their code from one vendor's product to
another. There might be benefit further down the line from a general
market growth - but I can't really see the vendors rushing into any new
initiative that might take away their current USPs.

Gosi wrote:
> On Aug 30, 6:57 pm, neit...@marshlabs.gaertner.de (Martin Neitzel)
> wrote:
>>> any ISO APL2 (not the best name, incidentally)
>> Luckily, the standard naming scheme for standard revisions would rather
>> call it "ISO APL-bis", avoiding the ambiguity Gosi already fell prey for.
>>
>> Martin
>
> I did mean APL2

then you don't need ISO, surely?