First login?
Lost password?
 
 
 
mailing-list for TeXmacs Users

Text archives Help


Re: [TeXmacs] ANNOUNCE: texmacs-fedit plug-in


Chronological Thread 
  • From: "Sam Liddicott" <address@hidden>
  • To: address@hidden
  • Subject: Re: [TeXmacs] ANNOUNCE: texmacs-fedit plug-in
  • Date: Fri, 15 Oct 2010 09:21:26 +0100
  • Envelope-to:
  • Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwCAMAAABg3Am1AAAAAXNSR0IArs4c6QAAADxQTFRF NTdQY2Z/i286eHFugnNXoJBwm5GCs5VeoqO0ua+fwLCQ4c2q19C81NDF4eLr/unQ/PTf/fXW+/rq /f/7XKo76wAAAAlwSFlzAAALEwAACxMBAJqcGAAAAi9JREFUSMetloGSqyAMRVsFNAQkxP//15cE 62rFdt/MZqbTVu/hBhLEx/qf8fgDIAN455wHyPk7wCIe9nA+fwGSH87hgD8AHPfRpy2GwdMtcBh+ mg4Ech9Ih+RNixJKDLEL0GF8VLkSojePHrDlryNijbFW8zBg8PUKbBOI6D1WCV5Rf2DzxCtgBlMs tRRVW5LyVW3ew1TfAZZ6RcQicpb4yZmaC74DJADK6BdATOrUAbJzsZie+K22ZnEBknNYysvhVH6u 1X8CqAe4DuANoPoOrAbsHXUARJ5knc5z4EyyTnHoAqj7xvkYIdk65AwhyEZKMusOIDV2QQQaCnDQ gBiDR3RdIEb5CBESt2wgQJI0Yx/Agphg1MgNsD+QkszM9wHVPx/PeQOW+fmcR9DF8+4CyCJhCuP8 fDzmBbLqs8JzMODqYNfDvKhoGYM2lDosy5jlRozccRAgrPM8iygQS3Mv87IugUgKlC7NZ6liuy4r uresVq5QuQAr09ZKEga8OkluyKXeQ6Bs3SrtqgC1pWLNqAfwDhBnB+sK8OrVL4D4h1B4zWPWhJhu gPUHKA5EwSMYUMsdQK+UKDhIOTSHeg+8HCoTOGtB/gwcl4mSdGybwXegPWhM/RHYKwchkckhUNMX 6j7ueQNScLbZZOPRxaADyO2UQCJpl7wbnE6gQ+ksWjpngxOwF1tF5ecP3R6KB+AQxPfHLncQ+nKw 06fhu68OTIfJ869eTtg22l+9zfwDK3mKl5BFHMYAAAAASUVORK5CYII=
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.

--

PNG image


Archive powered by MHonArc 2.6.19.

Top of page