Re: Non-text format for source code

[Ivan Shmakov]

>>>>> Paul <pa...@pcserviceselectronics.co.uk> writes:
>>>>> In article <kemoel$ulg$1...@dont-email.me>, mwi...@the-wire.com says...

[Cross-posting to news:comp.infosystems.www.misc.]

[On a second though, cross-posting to news:comp.lang.misc, too.]

[...]

>> I was too elliptical. I was actually thinking about HTML as the
>> markup lanugage. I just forgot to say so.

> Then you get into which HTML subset you allow that does not have
> deprecated or browser specific HTML tags

Why not to take just what's needed from, say, [1]?

There's a catch, however: to make the better use of XML
processing tools and libraries, there should be a way to write
the code itself in XML, too. Of which the only example I know
is XSLT, and I'm not certain if it's a particularly good one.

[1] http://www.w3.org/TR/xhtml-modularization

--
FSF associate member #7257

[Paul]

In article <871ucwy...@violet.siamics.net>, onei...@gmail.com
says...

The trouble is every tool will have its own different implementation
which wont necessarily be compatible. Even XHTML across browsers is
bad enough, let alone effectively vendor specific extensions.

And great another three layers of DLL and bloatware potentially, which
of course will be different on each platform and platform version :-)

--
Paul Carpenter | pa...@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/> PC Services
<http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font
<http://www.gnuh8.org.uk/> GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
<http://www.badweb.org.uk/> For those web sites you hate

[dp]

On Feb 4, 6:21 pm, Paul <p...@pcserviceselectronics.co.uk> wrote:
> ...

>
> And great another three layers of DLL and bloatware potentially, which
> of course will be different on each platform and platform version :-)
>

:D
As if the bloatware is insufficient at its present what, 99+%? of
all ware indeed...

But including a few html links and images in the source
comments could be practical. If they point to resources
in the same archive, at least. Even if the source would confuse
browsers etc. copying the link is not a big deal anyway.
If someone finds *that* a big deal then programming should
not be that persons job of choice. Which I suppose is the reason
why we stick with plain ASCII to this day; nothing has beaten
the Latin alphabet for millenia, in fact it has beaten lots
of hieroglyph based languages. So it can't be all bad, I
suppose, we should stick to it for the time being.

Dimiter

------------------------------------------------------
Dimiter Popoff Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/

[John Devereux]

dp <d...@tgi-sci.com> writes:

> On Feb 4, 6:21 pm, Paul <p...@pcserviceselectronics.co.uk> wrote:
>> ...
>>
>> And great another three layers of DLL and bloatware potentially, which
>> of course will be different on each platform and platform version :-)
>>
>
> :D
> As if the bloatware is insufficient at its present what, 99+%? of
> all ware indeed...
>
> But including a few html links and images in the source
> comments could be practical. If they point to resources
> in the same archive, at least. Even if the source would confuse
> browsers etc. copying the link is not a big deal anyway.
> If someone finds *that* a big deal then programming should
> not be that persons job of choice. Which I suppose is the reason
> why we stick with plain ASCII to this day; nothing has beaten
> the Latin alphabet for millenia, in fact it has beaten lots
> of hieroglyph based languages. So it can't be all bad, I
> suppose, we should stick to it for the time being.

I think to really do what Vladimir wanted it would need a full "compound
document" format, like ODF perhaps. So he can do what he wants in the
document, include pictures, spreadsheets, videos, a facebook game,
whatever. Actual code would be formatted in a "code" style, say. A
preprocessor (possibly a macro) would extract these into a source code
file and call make etc.

Sounds awful :)

--

John Devereux

[Roberto Waltman]

John Devereux wrote:
>I think to really do what Vladimir wanted it would need a full "compound
>document" format, like ODF perhaps. So he can do what he wants in the
>document, include pictures, spreadsheets, videos, a facebook game,
>whatever. Actual code would be formatted in a "code" style, say. A
>preprocessor (possibly a macro) would extract these into a source code
>file and call make etc.
>
>Sounds awful :)

Yes it does.

What about the other way around?
Compilable code files as the main format, with commands embedded in
comments to include graphics, control the page layout, update/retrieve
file from SCM, etc.

A dedicated "browser" (for lack of better term) cowould bring all the
components needed to display a compound document, while a language
compiler will just process the files as-is.

Sounds awful :)

Yes it does...

R.

PS: As others pointed out, I believe literate programming tools
already can do that. (Anything that Tex/Latex can do could be
available.) The result will be anything but easy to use.
--
Roberto Waltman

[ Please reply to the group,
return address is invalid ]

[John Devereux]

Roberto Waltman <use...@rwaltman.com> writes:

> John Devereux wrote:
>>I think to really do what Vladimir wanted it would need a full "compound
>>document" format, like ODF perhaps. So he can do what he wants in the
>>document, include pictures, spreadsheets, videos, a facebook game,
>>whatever. Actual code would be formatted in a "code" style, say. A
>>preprocessor (possibly a macro) would extract these into a source code
>>file and call make etc.
>>
>>Sounds awful :)
>
> Yes it does.
>
> What about the other way around?
> Compilable code files as the main format, with commands embedded in
> comments to include graphics, control the page layout, update/retrieve
> file from SCM, etc.
>
> A dedicated "browser" (for lack of better term) cowould bring all the
> components needed to display a compound document, while a language
> compiler will just process the files as-is.
>
> Sounds awful :)
>
> Yes it does...

But that is what doxygen et al already do AIUI.

> R.
>
> PS: As others pointed out, I believe literate programming tools
> already can do that. (Anything that Tex/Latex can do could be
> available.) The result will be anything but easy to use.

I think that was me. I have a programming textbook or two written using
this technique, which is explained a bit in the first chapter. ("C
interfaces and implementions" by Hanson). Good book I thought.

[...]


--

John Devereux

[David Brown]

On 04/02/13 20:10, John Devereux wrote:
> dp <d...@tgi-sci.com> writes:
>
>> On Feb 4, 6:21 pm, Paul <p...@pcserviceselectronics.co.uk> wrote:
>>> ...
>>>
>>> And great another three layers of DLL and bloatware potentially, which
>>> of course will be different on each platform and platform version :-)
>>>
>>
>> :D
>> As if the bloatware is insufficient at its present what, 99+%? of
>> all ware indeed...
>>
>> But including a few html links and images in the source
>> comments could be practical. If they point to resources
>> in the same archive, at least. Even if the source would confuse
>> browsers etc. copying the link is not a big deal anyway.
>> If someone finds *that* a big deal then programming should
>> not be that persons job of choice. Which I suppose is the reason
>> why we stick with plain ASCII to this day; nothing has beaten
>> the Latin alphabet for millenia, in fact it has beaten lots
>> of hieroglyph based languages. So it can't be all bad, I
>> suppose, we should stick to it for the time being.

Doxygen has this covered.

And I expect that most compilers are quite happy for you to use a
slightly wider character set (Latin-1, UTF-8, etc.) in comments, even if
you can't use them in actual program identifiers.

>
> I think to really do what Vladimir wanted it would need a full "compound
> document" format, like ODF perhaps. So he can do what he wants in the
> document, include pictures, spreadsheets, videos, a facebook game,
> whatever. Actual code would be formatted in a "code" style, say. A
> preprocessor (possibly a macro) would extract these into a source code
> file and call make etc.
>
> Sounds awful :)
>

Indeed it does sound terrible.

But perhaps Vladimir could tell us what he wants - there seems to be a
lot of guessing going on in this thread. There has been some
interesting discussion and ideas here, but I don't think we are helping
the OP much. (This is no bad thing, of course - after all, these are
discussion groups rather than helplines.)

[Walter Banks]

David Brown wrote:

> And I expect that most compilers are quite happy for you to use a
> slightly wider character set (Latin-1, UTF-8, etc.) in comments, even if
> you can't use them in actual program identifiers.

Most if not all compilers that support 8 bit chars (as opposed to
truncating to 7 bits) will support extended wider character sets.

I think that was an issue in the design of the character extensions and
comment delimiters in most languages.

> But perhaps Vladimir could tell us what he wants - there seems to be a
> lot of guessing going on in this thread. There has been some
> interesting discussion and ideas here, but I don't think we are helping
> the OP much.

Missing from most of the discussion has been the intended audience.
Are we documenting an application design and doing a running
implementations with the design as a handy reference. Are we
documenting the implementation considerations or are we
providing user documentation.

I'm sure that most is part of all of the above, but the considerations
and requirements are different for each.

Order is also significant. I personally use spread sheets to
gather material for a project. In truest sense of an electronic
blackboard with spec pages, images and design calculations
spread out on several pages.

User requirements and documentation come next in a
document that eventually has implementation choices
and implementation overview documented. I personally
like to keep the actual code sparse of additional material
so I have a better overview of the code when reading
through it.

This too is a strawman guessing at Vladimir's intentions.

w..

[Jacko]

It seems we have similar ideas. The "identifier" for inlining as a text height of media with maybe a right click window would be ok.

The idea of generalized coloured text, where coloured could mean linked to or other object inheritance properties, maybe is where to go.

A serialization protocol for such things is perhaps the best storage format. As for hard copy, (B&W), maybe font identifier figure numbers would be good.

[Jacko]