On Mar 6, 10:11=A0am, phil chastney
<phil.hates.s...@[EMAIL PROTECTED]
> wrote:
> 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
Phil, thanks for the first bit! I am not sure I understand the rest of
the comment, or what the perceived problem is with the Unicode/Classic
split - can you elaborate?
The Classic and Unicode versions are built using the same source code
and are identical in "functionality". They ONLY differ in the way that
they translate data as it goes in and out of the system, that
character arrays in the Classic version are restricted to the 256-
element selection from Unicode known as the "Atomic Vector", and that
the byte which represents a character in the Classic version is an
index into "Quad-AV". The arguments and results of monadic upgrade and
Quad-DR differ from one version to the other.
Note that BOTH versions have a single-byte character data type, but
that Unicode version will also use 2- and 4-byte internal
representations if you use code points beyond 255 (the Unicode product
views characters in the same way as integers, which also come in 1-,
2- and 4-byte flavours, depending on the range of the data).
We have NOT set a date for the end of the Classic version because we
want to give our customers some time to think about the issue and how
it will impact applications first. Some applications will just load
and run in the Unicode version, others which use a lot of casting
([]DR) and clever tricks when importing and exporting data may need
work. We do not yet know what would be a "reasonable" deadline.
Actually taking advantage of Unicode in applications (as opposed to
just being able to run on the Unicode version) may be a massive effort
involving rewriting all your interfaces, converting all your SQL
databases and other forms of external media, your applications
understanding of sorting and searching, etc: We don't expect many of
our customers to go all the way down that path, but it is very
important that those who want to CAN do it easily.
Note that the Classic and Unicode versions are fully inter-operable,
they can share workspaces, component files and TCP socket connections
- with the "obvious" limitation that a Classic version will choke if
it encounters a character not in its QuadAV (QuadAV can be defined by
the user - so Russians can define a different 256-element subset than
English Dyalog users). The Unicode version can be configured so that
it knows which subset a Classic "partner system" is working with and
translate data accordingly.
v12 Unicode can be instructed to continue to write non-Unicode
component files (on a per file basis) and give an error if this is not
possible, so that it does not "accidentally" write files that Classic
(or v10 and v11) cannot read.
Version 12 is carefully designed to avoid big bang conversion events
and make the transition to Unicode as smooth as possible: We want
encourage our users to move to Unicode as quickly as possibly but will
not force anyone to move hastily.
We are NOT setting a deadline at this time. My advice would be to
install the Unicode version as soon as possible and start up a project
team to evaluate how hard it will be to move, and how (if) your
applications can benefit from extending the range of characters
handled. I would plan to starting a move to the Unicode version with 3
years and try to complete it in 5. But DON'T PANIC, we do not leave
people "up the creek": So long as there is any significant use of the
Classic version it will continue to be supported.
Come to our User Group conference in October to talk to colleagues
about what they are doing and put pressure on Dyalog to do the right
thing :-).
Morten
|
