• From: Mukul Gandhi <gandhi.mukul@g...>
• To: COUTHURES Alain <alain.couthures@a...>
• Date: Sun, 22 Nov 2009 17:12:18 +0530

On Sun, Nov 22, 2009 at 12:59 PM, COUTHURES Alain
<alain.couthures@a...> wrote:
> It's sometimes very useful to consider programs as data.

Yes, definitely. Liam gave a nice example (XSLT to SVG conversion),
which looks like a good use case for this view.

> For example, the make utility treats programs to be compiled and linked: it's a sort of
> "meta-program" with programs as data.

That's true. Thanks for a nice example.

> Having an XML notation for programming language allows to process them as any XML data.

I agree.

> What is a program or what is data is just a point of view:

I agree. But I wanted to express, that a programming language (like,
XSLT for example) would generally be considered a "program" or
something that can execute via a suitable engine. Considering program
as data are special cases (it's also true, that such examples are in
abundance, like the "make" utility example you gave, or an example
with Liam gave), and help us design systems for certain needs (like,
say make system or "XSLT to SVG" conversion systems).

> It's the same for an HTML page: <h1> can be interpreted as the
> data for header at level 1 or as an instruction to write a header at level

I agree, and also concur that it's somebody's perception, that what
could be data and what are programs.

> Java or C languages don't benefit of an XML notation but it's mainly an
> human constraint: it's easier for developers to write instructions this way.

I agree. Perhaps designing imperative programming languages, was
easier in java/C like syntax and being able to express imperative
facilities for such languages, and also allowing programmers to easily
program (or express easily) in these languages. Also it looks like,
that Java/C syntax can be perhaps less verbose than say an equivalent
XML vocabulary (but I guess, verboseness is not the only factor that
can decide in which format to express a software program. There could
be other factors like, the nature of the technology itself. It seems,
XML format is inherently functional, and trying to design an
imperative system in XML vocabulary would be perhaps putting too much
effort, to bridge the imperative-functional mismatch). I am not sure,
how easy (or convenient, and developing an implementation for it) it
is to design imperative languages using XML vocabulary. I have
commonly found, that languages expressed as XML vocabulary are
generally functional in nature.

> It's in developers culture to distinguish between data and instructions
> since assembling languages and it's easy to accept but it is not true for
> computers.

I agree :)



-- 
Regards,
Mukul Gandhi

• Follow-Ups:
  • Re: An inquiry into the nature of XML and how it orientsour perception of information
    • From: Peter Hunsberger <peter.hunsberger@g...>

• References:
  • Re: An inquiry into the nature of XML and how it orientsour perception of information
    • From: Liam Quin <liam@w...>
  • RE: An inquiry into the nature of XML and how it orientsour perception of information
    • From: "Len Bullard" <cbullard@h...>
  • Re: An inquiry into the nature of XML and how it orientsour perception of information
    • From: Mukul Gandhi <gandhi.mukul@g...>
  • Re: An inquiry into the nature of XML and how it orientsour perception of information
    • From: Peter Hunsberger <peter.hunsberger@g...>
  • Re: An inquiry into the nature of XML and how it orientsour perception of information
    • From: Mukul Gandhi <gandhi.mukul@g...>
  • Re: An inquiry into the nature of XML and how it orientsour perception of information
    • From: COUTHURES Alain <alain.couthures@a...>