Using C for competitive advantage

[fft1976]

Wolfram is certainly a genius. He is also an insufferable git.

You are probably thinking of Linux Torvalds. He himself said he was a
git, and that's why he named his CVS clone like that. I don't think he
likes LISP any more than he likes Richard Stallmann.

 

[Alex Queiroz]

You are probably thinking of Linux Torvalds. He himself said he was a
git, and that's why he named his CVS clone like that. I don't think he
likes LISP any more than he likes Richard Stallmann.

"CVS clone"? :-D

-alex

 

[Paul Wallich]

You are probably thinking of Linux Torvalds. He himself said he was a
git, and that's why he named his CVS clone like that. I don't think he
likes LISP any more than he likes Richard Stallmann.

Nope, he was thinking of Wolfram, who has a reputation for being
uncertain far fewer times than he might be mistaken.

 

[Aatu Koskensilta]

You are probably thinking of Linux Torvalds.

A peculiar suggestion. But perhaps it was intended jocularly. Linus may
well be something of a git at times, but he differs from Wolfram in an
important regard, that of demonstrably having a sense of humour and
being able to occasionally apply it to himself. Insufferable gits
invariably fail to see anything amusing in even their most bizarre
antics -- and some of Wolfram's more megalomaniacal pontifications in _A
New Kind of Science_, for example, certainly are quite bizarre indeed.

 

[cr88192]

Reinventing LISP in C is not how C is meant to be used, is it?

but, it is very useful for some tasks, and can be used along with good old
traditional C practices...

Before some LISP code monkey quotes Greenspun, tell me, does Linux
reinvent LISP, or is Linux insufficiently complex? What about Git?

Linux does not, but Linux does not need to for what it does (as an OS...).

By the way, closures are not runtime-generated code!

runtime code generation, however, is one way to get closures in C...

this is actually because of a subtle issue in how C is usually implemented:
a function pointer is just a raw address to some code, so to call it, more
or less the call-frame is set up, and control is transferred to this
address...

often, there is no other context for this function available.

so, one can generate a new piece of code, which itself knows where the
captured state is, and so can pass it on to the closed-over function (in the
implementation, for example, as a hidden argument...).


the actual underlying mechanisms, however, are far more general and powerful
than something just "getting LISP implemented in C...".


FWIW, I will note that my compiler represents its AST's in XML, and not
S-Exps... (the reason is that XML is actually more flexible and adaptable...
even if heavier weight and more effort to work with...).

this may well be part of why XML eats S-Exps' cake, as for all their merit
S-Exps would seem to have a notable flaw for general-purpose data
processing: in non-trivial cases they are about as flexible as if the
structure were made of glass... (in XML you can almost always add a new
attribute or namespace to fudge around whatever comes up, but S-Exps tend to
provide no real way to "bend" the structure with new data, only the
combination of so many 'forms'...).

so, one can't usually bend the forms, and instead adaptations may tend to
require fundamental alterations to the structure, ...


although, sadly, XML does have its performance costs... and, yes, I still do
use S-Exps in more than a few places...

 

[Raffael Cavallaro]

this may well be part of why XML eats S-Exps' cake, as for all their merit
S-Exps would seem to have a notable flaw for general-purpose data
processing: in non-trivial cases they are about as flexible as if the
structure were made of glass... (in XML you can almost always add a new
attribute or namespace to fudge around whatever comes up, but S-Exps tend to
provide no real way to "bend" the structure with new data, only the
combination of so many 'forms'...).

Many of us here think it's the other way round.

from: <http://homepages.inf.ed.ac.uk/wadler/papers/xml-essence/xml-essence.pdf>

" XML is touted as an external format for representing data.
This is not a hard problem. All we require are two proper-
ties:
• Self-describing From the external representation one
should be able to derive the corresponding internal
representation.
• Round-tripping If one converts from an internal rep-
resentation to the external representation and back
again, the new internal representation should equal the
old.

Lisp S-expressions, for example, possess these properties.

XML has neither property. It is not always self-describing,
since the internal format corresponding to an external XML
description depends crucially on the XML Schema that is
used for validation (for instance, to tell whether data is an
integer or a string). And it is not always round-tripping,
since some pathological Schemas lack this property (for in-
stance, if there is a type union of integers and strings). So
the essence of XML is this: the problem it solves is not hard,
and it does not solve the problem well."

 

[Kaz Kylheku]

FWIW, I will note that my compiler represents its AST's in XML, and not
S-Exps... (the reason is that XML is actually more flexible and adaptable...
even if heavier weight and more effort to work with...).

You're using character strings for representing trees inside a compiler?

 

[Raymond Wiker]

Many of us here think it's the other way round.

from: <http://homepages.inf.ed.ac.uk/wadler/papers/xml-essence/xml-essence.pdf>

" XML is touted as an external format for representing data.
This is not a hard problem. All we require are two proper-
ties:
~ Self-describing From the external representation one
should be able to derive the corresponding internal
representation.
~ Round-tripping If one converts from an internal rep-
resentation to the external representation and back
again, the new internal representation should equal the
old.

Lisp S-expressions, for example, possess these properties.

XML has neither property. It is not always self-describing,
since the internal format corresponding to an external XML
description depends crucially on the XML Schema that is
used for validation (for instance, to tell whether data is an
integer or a string). And it is not always round-tripping,
since some pathological Schemas lack this property (for in-
stance, if there is a type union of integers and strings). So
the essence of XML is this: the problem it solves is not hard,
and it does not solve the problem well."

Right... as long as XML documents cannot be understood without
reference to a system/application/whatever, it is only a solution to
the "quoting" problem - a mechanism for describing data using a
limited alphabet, and a facility for quoting symbols that would
otherwise be interpreted as belonging to the set of "control"
symbols.

Now, in XML there are certain code points that are illegal
(even in encoded form), and the quoting mechanisms are none too good,
so I'd be happy to agree with your conclusion. The only advantage to
XML is that there are a fair number of decent libraries available for
parsing/constructing XML. On the other hand, because XML appears to
be so simple, there is no shortage of programmers that implement their
own XML parsers/builders - and get it wrong.