Re: MS Math layout (was: ZWJ, ZWNJ and VS in Latin and other Greek-derived scripts)

From: Philippe Verdy (
Date: Tue Jan 30 2007 - 22:26:08 CST

  • Next message: Michael Maxwell: "RE: MS Math layout (was: ZWJ, ZWNJ and VS in Latin and other Greek-derived scripts)"

    From: "Murray Sargent" <>
    > Nevertheless the codes chosen really aren't as bad as you think; at least people seem to get used to them.

    Which people? I've not seen any implementation of this editing format, or documents including instances of such formulas before reading this TechNote. On the opposite (La)Tex is quite popular, and even more now that Wikipedia includes its support, and made its documentation very visible, along with immediate applications within mathematical pages.

    > Section 6 of the paper discusses this question. I agree, programming languages
    > could and should be changed to look more like mathematics. For example in
    > C/C++/C#/Java using <= for seems really primitive. And using math alphabetics
    > as variable names gives you the same variables in a program as in the source
    > mathematics.

    I don't think that languages must be changed to adapt to this notation, or even to adapt to the visual mathematical rendering; this could be used instead within programming language editors, as a much better improvement than just syntax coloring and smart indentation.

    If the program editor understands the syntax of the language, and can parse it live, while editing the program, then it could as well present it to the programmer in a more user-friendly format, including when editing comments, indenting it in a much smarter way (with automated linewraps).

    Then when saving the program source, the classical plain-text syntax and lexical entities would still be used.

    This would be useful to get a more comprehensive view of some programs that need very complex expressions, and with a little more smart understanding of the syntax and semantics, the editor could not only transform equivalent expressions, but also generate a simpler saved source file, with cleaner indentation, coherent whitespaces, and so on, for those users that don't have the same editor.

    The editor could include non textual presentation as well, like symbolic diagrams, and various equivalent notations with a better visual impact, helping to find bugs with a more synthetic view. Why do programmers have to live with a single view of their program source?

    it would not help much for programs that perform basically procedural lists of calls, but for complex expressions, or for locating variables usage, or understanding many levels of parenthesis pairs, or for handling event-based programs full of many event-handlers, it would be helpful.

    For projects that are based on UML, working directly from within UML diagrams with many perspectives can help get the synthetic view needed to understand how a complex set of objects work. if needed, some meta-data about diagram presentations may also be saved in source comments, or using identifiers associated to a separate meta-data file or program database...

    Why do we have to live with plain-text for sources? Only because compilers are traditionnally working with this portable format. But there's no reason to keep it always for the visual editing of programs. This is just a technical view, and not necessarily the easiest.

    In that case, using Unicode in sources to create inline formulas is not really a need, when we could provide something better with true rendering of formulas and diagrams, directly edited in this mode... Such tool could also help removing the use of source preprocessors which are often hiding the effective way a program works, and often introduce unsuspected bugs: local #defines would be replaced by visual aliases, with short variable names that make expressions easier to read. The generation of variable names could be guided as well, and we could as well use symbols in this mode, instead of long qualified variable names, array indices would become true visual indices.

    This archive was generated by hypermail 2.1.5 : Tue Jan 30 2007 - 22:28:53 CST