2015-02-08 23:54 GMT+01:00 Pierpaolo Bernardi <[email protected]>: > On Sun, Feb 8, 2015 at 11:27 PM, Alfred Zett <[email protected]> wrote: > > > That was exactly my thought, so I figured it couldn't harm to have these > > >> a Tab is exactly what you described. > > > > No. It's only half of what I described. > > It's still a typographical character that implies whitespace and may > appear > > everywhere in the text. > > How would your proposed character be displayed as plain text? >
You new language will have to invent another language syntax for exporting and serializing its native source into a plain text file. It will certainly use an escaping syntax (such as the commn use of backslahes), but that syntax will be a traditional syntax for traditional programs. And standard ASCII or UTF-8 encodings using standard characters will be largely enough. Your programming toll will need a separate serializer and a separate parser that that alternate syntax, or it could reuse some existing parsers (such as XML and JSON serializers and parsers,or existing generic libraries handing rich text documents containinig embedded collections, and an API more or less like DOM APIs offered with an adapting layer of "bindings" for lots of other languages, with a binary interface, or an SQL-like interface, or other convenient interfaces such as common collections and associative arrays, or containers like ZIP/JAR files) : The programmer will in fact not have to edit these complex source files, but may look inside with tricky tools can could corrupt its internal structure of references. They will just use the specific IDE made for your language, will select a file or resource (e.g. a network service) using that custom syntax, it will be loaded (or will perform queries) to edit some viewable and editable parts of the program, and many internal data used in the native format (notably the purely internal references and pointers) will be hidden to them and will change without notice, while preserving the intended structure of your langage. In many modern environments, in fact a single programmer cannot reprogram the whole project but can only edit some parts of it, and there are privileged operations (reservd to some groups of users) and some parts that will change in parallel and can be edited in teams of programmers/designers/correctors and that require another system to coordinate works and resolve edit conflicts, or to create alternate branches that someone else will merge into the common trunk: the programmers create their own branches not seen by others, until the programmer submits its proposed branch for review by more privileged users. It does not mean that, even if that branch is rejected for merging in the trunck, the bracnh will be necesarily deleted: that programmer/designer can still use his own branch without effecting other users using the common trunk or designing or using their own branch (o that want to keep an older version of the trunk, ignoring new versions). We are clkearly out of scope of Unciode because we are not speaking about text, but about programming tools and services, and about models of operations for working or cooperating teams (and those teams will include various types of peoiple, not just designers and programmers, but (as well) final users and customers creating their own customizations and adding their own features and data and interoperating using various "programming languages" and tools with various UIs, more friendly than traditional linear and text-based programming languages).
_______________________________________________ Unicode mailing list [email protected] http://unicode.org/mailman/listinfo/unicode
