[M3devel] Windows, Unicode file names

[Daniel Alejandro Benavides D.]

Hi all:
In reality it turns out that ASCII is still the suitable and adhered standard for Modula-2 Command control, structured text, formatting in PLCs systems programming.
We better when we pick something be clearer, but nevertheless I agree with internationalization as with compatibility, etc
>From what I gather TEXT is allowed to be Latin-1 superset
Thanks in advance

--- El mié, 27/6/12, Dragiša Durić <dragisha at m3w.org> escribió:

De: Dragiša Durić <dragisha at m3w.org>
Asunto: Re: [M3devel] Windows, Unicode file names
Para: "Jay K" <jay.krell at cornell.edu>
CC: "m3devel" <m3devel at elegosoft.com>
Fecha: miércoles, 27 de junio, 2012 06:26

This is one place where insisting on some imagined/future purity (fully compatible withyour argument - thread safety + immutability + non-quadratic performance) will lead to unreasonable fragmentation and de-facto gray area in CM3 and it's usage.
I am only one of people here who de-facto uses TEXT's to hold UTF8 content. And while we all think/talk about solution, every single user who needs international characters and wants to use them in sensible way - will go same way.
Then, some "proper" CM3 solution comes and what happens? We rewrite everything to support it? Or ignore it?
On Jun 27, 2012, at 1:14 PM, Dragiša Durić wrote:

On Jun 27, 2012, at 12:19 PM, Jay K wrote:
 > More and more is obvious how ideal structure would be: ARRAY OF CHAR, UTF8 encoded, using SRC M3 Text.Hash().

I don't quite agree.
There are two ideal approaches.
1)
  TEXT is like ARRAY OF CHAR and no values over 0xFF (or maybe even 0x7F)   "WiDETEXT" is like ARRAY OF WIDECHAR, for 16bit or 32bit WIDECHAR 

So we can have two representations for single thing: variable holding some text. And representation depends on a question "do you need non-basic-english-characters"?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120627/18f9ac1c/attachment-0002.html>