Dyalog releases Version 12

Dyalog has released Version 12 of its APL, which now supports Unicode
for all character arrays. Version 12 also contains

--Conga for socket communications
--RainPro and NewLeaf for presentation
--a language bar for APL characters as an alternative to typing
--on-screen keyboard for Windows users.

Dyalog's newsletter (http://www.truepr.co.uk/news/dl/10/) also
announces

--tools for grid computing
--Dyalog 2008 conference 12-15 October in Denmark
--application development partners
--results of the first survey of usage by holders of their educational
licences

Stephen Taylor
editor@vector.org.uk

On Mar 4, 10:26=A0am, "Stephen Taylor <edi...@vector.org.uk>"
<StephenTaylorF...@googlemail.com> wrote:
> Dyalog has released Version 12 of its APL, which now supports Unicode
> for all character arrays. Version 12 also contains
>
> --Conga for socket communications
> --RainPro and NewLeaf for presentation
> --a language bar for APL characters as an alternative to typing
> --on-screen keyboard for Windows users.
>
> Dyalog's newsletter (http://www.truepr.co.uk/news/dl/10/) also
> announces
>
> --tools for grid computing
> --Dyalog 2008 conference 12-15 October in Denmark
> --application development partners
> --results of the first survey of usage by holders of their educational
> licences
>
> Stephen Taylor
> edi...@vector.org.uk

It is interesting that there are two versions.
One Classic and one with Unicode.

It may take a long time for the users to move over to the Unicode
version.
For my own use the Unicode version is the only one possible.
Unicode change will allow all kinds of new options.
There are several migration operations for the Classic users to move
over.
It will be interesting to see how long it will take for the users to
move over.

I guess that what will happen is that eventually some new
functionality will be introduced in the Unicode version and not in the
Classic version.
Companies with operations in countries outside the english speaking
countries it will probably be quicker to embrace the Unicode version.

The grid tools are also very interesting.
Grid and Apl enhance each other in a very natural way.

Chart and plotting is also there not to mention the possibility to use
external editors for Apl code!
APL source code can be stored in Unicode text files and edited using
any editor which supports these files.

As I understand it then this is just the first announcement in a long
line of new features that will be made available soon.
Not to mention a whole lot of new Help and much improved documentation
and the goal is to Re-introduce Apl to the masses.

Gosi wrote:
> On Mar 4, 10:26 am, "Stephen Taylor <edi...@vector.org.uk>"
> <StephenTaylorF...@googlemail.com> wrote: 
> <snip, snip>
>
> It is interesting that there are two versions.
> One Classic and one with Unicode.

think about the alternative: supporting both string types within the one
interpreter  --  that would be a nightmare for design and implementation
of the interpreter, and it would take forever to wean ASCII-only users
onto Unicode

Dyalog have taken the right decision, but instead of simply releasing
enhanced Unicode versions without enhanced "classic" versions, it might
be better received by their customer base if Dyalog were to announce an
end-date for ASCII-only enhancements first

Python 3 has taken a similar route, making all strings Unicode only, but
with support for "byte streams", which is handy when you don't yet know
what encoding the incoming stream uses

Perl 6 was headed down a similar route, but development seemed to be
mired in an over-ambitious design, and I haven't kept up with the story

> Companies with operations in countries outside the english speaking
> countries it will probably be quicker to embrace the Unicode version.

companies with operations entirely within the English-speaking world may
also find Unicode useful when they need to use a mathematical or
technical symbol or two, or even a quotation in Foreign (it adds so much
_style_, don't you think?)

regads   . . .   /phil

P.S: Python 3 also unifies the concepts of "type" and "object"  --  that
is such a *right* thing to do, I expect we shall similar developments in
other languages

On Mar 6, 9:11 am, phil chastney
<phil.hates.s...@amadeus.munged.eclipse.co.uk> wrote:
> Gosi wrote: 
> 
>
> think about the alternative: supporting both string types within the one
> interpreter  --  that would be a nightmare for design and implementation
> of the interpreter, and it would take forever to wean ASCII-only users
> onto Unicode
>
> Dyalog have taken the right decision, but instead of simply releasing
> enhanced Unicode versions without enhanced "classic" versions, it might
> be better received by their customer base if Dyalog were to announce an
> end-date for ASCII-only enhancements first
>
> Python 3 has taken a similar route, making all strings Unicode only, but
> with support for "byte streams", which is handy when you don't yet know
> what encoding the incoming stream uses
>
> Perl 6 was headed down a similar route, but development seemed to be
> mired in an over-ambitious design, and I haven't kept up with the story
> 
>
> companies with operations entirely within the English-speaking world may
> also find Unicode useful when they need to use a mathematical or
> technical symbol or two, or even a quotation in Foreign (it adds so much
> _style_, don't you think?)
>
> regads   . . .   /phil
>
> P.S: Python 3 also unifies the concepts of "type" and "object"  --  that
> is such a *right* thing to do, I expect we shall similar developments in
> other languages

It has been interesting to watch the glacial speed of Unicode
adaptation.
I guess we have talked about Unicode for 20 years in this group.
I think that APL2 is all Unicode now if I remember correctly.
J supports Unicode.

It will be interesting to see if people use Unicode to translate
scientific mathematical notations directly to Apl.

Has anyone tried that?

Do all the Apl:s that use Apl chars and have Unicode support use the
same Unicodes now?

Will the Apls be able to send Unicode files between them and use the
Apl functions and data?

APL2000, Dyalog, and APL2 all use the same Unicode (with some very slight
differences that I believe we all handle automatically.)  I'm not sure about
the other vendors.

For several years those three vendors have also all supported the SCAR
format which you can use to share data.

I know that Dyalog and APL2 can both read and write Unicode files.  I don't
know about APL2000.  I assume so.

David Liebtag

Gosi wrote:
> On Mar 6, 9:11 am, phil chastney
> <snip>
>
> It has been interesting to watch the glacial speed of Unicode
> adaptation.
> I guess we have talked about Unicode for 20 years in this group.
> I think that APL2 is all Unicode now if I remember correctly.
> J supports Unicode.

"glacial"? meaning "retreating rapidly in the face of climate change"?

I guess that's a fair metaphor for a general reluctance to adopt UTF-8

> It will be interesting to see if people use Unicode to translate
> scientific mathematical notations directly to Apl.
>
> Has anyone tried that?

what exactly are you looking for here? some sort of 2-D input encoded
using Unicode, being interpreted in (or translated into?) APL, perhaps?

because if you are, it seems to me the actual encoding being used is a
lot less important than the 2-D nature of the input

but there again, I may have misunderstood you completely   . . .   /phil

phil chastney wrote:
> Gosi wrote: 
>
> "glacial"? meaning "retreating rapidly in the face of climate change"?
>
> I guess that's a fair metaphor for a general reluctance to adopt UTF-8
> 
>
> what exactly are you looking for here? some sort of 2-D input encoded
> using Unicode, being interpreted in (or translated into?) APL, perhaps?
>
> because if you are, it seems to me the actual encoding being used is a
> lot less important than the 2-D nature of the input

Yes. You need something like TeX, or Omega. Or mathml? One might argue
that for mathematics as a working language to be supported, the
"encoding" would seem to be required to handle this 2d nature, and hence
that unicode would have to have something like TeX embedded. Other
languages require this as well... I think the Tibetan encoding has the
notion of a stacking operator, but I recall it seemed rather limited to
me, rather than a powerful general facility.

Sun has proposed the language fortress to support a bit of 2d
mathematics language and characters.

Sam

Yes, APLX uses the same Unicode code points, so you can (for example)
cut and paste text between all the main APLs.  Also APLX supports
reading and writing Unicode (UTF-8 and UTF-16) files directly.

Richard Nabavi
MicroAPL Ltd

On 6 Mar, 14:38, "David Liebtag" <DavidLieb...@vermontel.net> wrote:
> APL2000, Dyalog, and APL2 all use the same Unicode (with some very slight
> differences that I believe we all handle automatically.)  I'm not sure abo
ut
> the other vendors.
>
> For several years those three vendors have also all supported the SCAR
> format which you can use to share data.
>
> I know that Dyalog and APL2 can both read and write Unicode files.  I don'
t
> know about APL2000.  I assume so.
>
> David Liebtag

On Mar 6, 2:53=A0pm, phil chastney
<phil.hates.s...@amadeus.munged.eclipse.co.uk> wrote:
> 
> 
>
> what exactly are you looking for here? some sort of 2-D input encoded
> using Unicode, being interpreted in (or translated into?) APL, perhaps?

It was you who suggested that technical symbols could be used in
Unicode.

>companies with operations entirely within the English-speaking world may
>also find Unicode useful when they need to use a mathematical or
>technical symbol or two, or even a quotation in Foreign (it adds so much
>_style_, don't you think?)

>regads   . . .   /phil

That is why I asked if those symbols could be used to translate to Apl
functionality