2015-02-08 23:54 GMT+01:00 Pierpaolo Bernardi <olopierpa_at_gmail.com>:
> On Sun, Feb 8, 2015 at 11:27 PM, Alfred Zett <alfred_z_at_web.de> 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
Unicode_at_unicode.org
http://unicode.org/mailman/listinfo/unicode
Received on Sat Feb 14 2015 - 08:24:44 CST
This archive was generated by hypermail 2.2.0 : Sat Feb 14 2015 - 08:24:44 CST