mailing-list for TeXmacs Users

["Sam Liddicott" <address@hidden>]

On 14/10/10 12:19, sylvain wrote:

Another problem I wanted to try to solve is to explore the possibility
to convert Texmacs advanced typesetting into one-lined ASCII concrete
syntax understood by a compiler. I believe the one-dimensional one-line
input from the good old 70's is holding us back. Not when you program in
traditional languages, but when you want to program in modern languages
like ATS, whose text source, when forced to be one-dimensional, become
rapidly unreadable. Other languages I can think of that would benefit of
that are Agda and Haskell.
(The trouble is, I am stuck with a bug in my version of Texmacs
(1.0.7.3, Ubuntu) and didn't made much progress on this front.)

On idea I have considered a few times is being able convert between source representations and rich representations, so that a pleasant table of initialization values can be converted to a C static array initializer.

Likewise, for rendering of BNF grammars, entity relationship diagrams and so forth.

An in effort to avoid this one dimensional stuff you speak of I cause the code chunks to be able to take parameters, so that an algorithm may be expressed generally as an abstract code chunk that can then be included in any file or other chunk with placeholders expanded to actual data references. Thus even high level concepts like generics are provided for

- although meaningful typeset representations of "syntactic sugar" needs further examination, the "invoke paramterized chunk" notation is not helpful.

texmacs <with|...> construct seems a better idea. I was going to expand to named parameters but I now think that ZERO parameters is a better idea and that abstract chunks can be invoked inside some kind of <with|...> construct as this better suits the humans understanding of what is being done. It also has the effect of avoiding unwieldy parameter lists when an abstract chunk invokes other abstract chunks - instead an outer <with|...> environment can be established and then the chunks invoked without any parameter lists. The <with|...> environment can be expressed as an annotation or margin-comment at the point of invocation.

I'm also probably gong to avoid #line type comments in generated output but instead produce a separate map file, and a converter to convert row/column compiler errors to the document - to even work if the generated source has been pretty-printed. This should also facilliate back-annotation if someone edits the source, to take a diff of the edit and then backtrack to see what changes need making to the document (even into invoked sub-chunks).

Anyway... these are the lines of my thinking.

--