Lisp newbie here. As someone very interested in AI who has only
recently come to realize that trying to achieve AI in
procedural/structured languages is probably futile, I've lately been
exploring a great number of "alternatives", trying to find that right
combination of expressive power, speed, simplicity, reflective
abilities, and, most importantly, user support. Dylan is my favorite
thus far, but while excelling in most categories, it seems to be
coming up quite a bit short in the user support area. So I figure, I
can sacrifice a bit of syntactic sugar (as far as I can tell, the only
significant difference between CL and Dylan) for a much larger user
base and simply learn Common Lisp.
Getting to the point of this post, in my web wanderings I also came
across a proposal for a new language project (open source) that seemed
to be quite promising. I'm just wondering if anyone with a lot more
language experience than myself has evaluated this language yet, and
has opinions, etc. Here is the link:
http://flarelang.sourceforge.net/
The statement that most intrigued me went something like this: "XML is
to Flare what linked lists are to Lisp." I'm still not sure what all
that would imply, but it sure sounds interesting. What I really want
to know is if Flare, as initially proposed, seems to be capable of
making some AI task much easier than Lisp.
From: Wade Humeniuk
Subject: Re: Representing code as XML: the Flare Programming Language
Date:
Message-ID: <9lfikl$fr3$1@news3.cadvision.com>
> that would imply, but it sure sounds interesting. What I really want
> to know is if Flare, as initially proposed, seems to be capable of
> making some AI task much easier than Lisp.
<gag!>
_Much_ easier? No.
Easier? No.
The same? No.
Harder? Yes.
Much Harder? Yes.
The very comment that somehow Lisp is made up of linked lists is disturbing.
</gag!>
Wade
In article <····························@posting.google.com>, Levi Conley wrote:
>The statement that most intrigued me went something like this: "XML is
>to Flare what linked lists are to Lisp." I'm still not sure what all
>that would imply, but it sure sounds interesting.
I'm exactly sure what that implies: the authors don't have a clue. For one
thing, XML is a read representation, and lists are data structures. They
are confusing the lexical, printed representation of program text,
and a deeper structural representation.
The nice thing about the printed representation of Lisp programs
and data is that it is easy to write, easy to read and easy
to parse.
>What I really want
>to know is if Flare, as initially proposed, seems to be capable of
>making some AI task much easier than Lisp.
Anything that uses XML to specify programs is going to make your life
difficult by forcing you to type loads of crap. So what you will probably
end up doing is using some painful XML editor which hides the markup,
so that you can feel you are working with the structure of the program
more directly.
And guess what, that's what the minimal Lisp syntax does, without
requiring a special editor. You can comfortably write Lisp even with
a the most bare-bones simple text editor.
Flare has an answer for that: a surface syntax called FlareSpeak that is
translated to XML. So now you have two representations for Flare programs:
FlareSpeak and XML. But, as far as I can tell, arbitrary XML cannot
be turned into FlareSpeak. In other words, FlareSpeak is a one-way
printed representation. FlareSpeak is turned into XML temporarily,
and the XML is turned into a structure. So of what use is the XML?
You could write a FlareSpeak implementation which skips the XML and
translates straight into structure. The only time you'd have to deal
with XML is when preparing data to be read by the FlareSpeak program,
or dealing with its XML output.
The problem with having whole different language layer like FlareSpeak
is that code transformations become awkward. How do you write a FlareSpeak
function which breaks apart a FlareSpeak function, and then assembles
the pieces to make a different FlareSpeak function?
In Lisp, there is a nearly 1-1 correspondence between the printed tokens
and the tree structure, so that these transformations are natural, and
feel almost as simple as token manipulation. In a language like
FlareSpeak, the configuration of tokens of a construct doesn't directly
correspond to a tree structure. Macro processing in a language like that
turns into a farce resembling the C preprocessing, in which substitutions
can produce bad syntax. The alternative is to do transformations on the
structure, using constructs that bear no resemblance to the language
in which they are written, and which are written with an implicit
understanding of the internal representation that corresponds to each
surface construct. The problem there is that trees could be constructed
which have no backward mapping to the syntax of the language.
Let's take C as an example. Suppose that it was possible to access
a list-based representation of "for (X; Y; Z) S;", and suppose
that the representation looked like the tree (for (X Y Z) S).
What would stop one from adding a node to make (for (X Y Z W) S).
And then, what would happen if an attempt was made to turn it back to
the printed language? Would it produce for (X; Y; Z; W) S;?
Or for (X; Y; Z, W) S;? Or a bizarre error message, like
``Oops: for node doesn't fit the mold of a for statement''?
After taking a superficial look at the C-like syntax of FlareSpeak,
I can't understand how it can avoid this issue.
In Lisp, you can create a tree of arbitrary nonsense, and it can still be
turned back into a sensible printed representation, so you can debug
the procedure that created that nonsense!
The obvious answer, in the case of FlareSpeak, is to cop out of the
question, and use XML as the printed representation. FlareSpeak is
used as the very initial read representation that is lost once
the program is scanned by the language implementation. Thereafter,
anything that is regugigated, be it program or data, is XML.
I don't see this is being a language design idea at all. I simply see it
as a terrible default choice for printed data and code representation.
You could output Lisp forms in XML too, and make Lisp understand XML,
too. Only, you wouldn't *want* to! The only reason for using XML is
to satisify an externally imposed requirement to interoperate with
XML-based software. XML has no technical merit as the representation
of structure.
From: Marco Antoniotti
Subject: Re: Representing code as XML: the Flare Programming Language
Date:
Message-ID: <y6c7kw4m9dn.fsf@octagon.mrl.nyu.edu>
···············@cs.com (Levi Conley) writes:
> Lisp newbie here. As someone very interested in AI who has only
> recently come to realize that trying to achieve AI in
> procedural/structured languages is probably futile, I've lately been
> exploring a great number of "alternatives", trying to find that right
> combination of expressive power, speed, simplicity, reflective
> abilities, and, most importantly, user support. Dylan is my favorite
> thus far, but while excelling in most categories, it seems to be
> coming up quite a bit short in the user support area. So I figure, I
> can sacrifice a bit of syntactic sugar (as far as I can tell, the only
> significant difference between CL and Dylan) for a much larger user
> base and simply learn Common Lisp.
>
> Getting to the point of this post, in my web wanderings I also came
> across a proposal for a new language project (open source) that seemed
> to be quite promising. I'm just wondering if anyone with a lot more
> language experience than myself has evaluated this language yet, and
> has opinions, etc. Here is the link:
>
> http://flarelang.sourceforge.net/
>
> The statement that most intrigued me went something like this: "XML is
> to Flare what linked lists are to Lisp." I'm still not sure what all
> that would imply, but it sure sounds interesting.
What you are impliying, pardon my bluntness, is that you have no
recent and in-depth exposure to (Common) Lisp.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
"Marco Antoniotti" <·······@cs.nyu.edu> wrote in message
····················@octagon.mrl.nyu.edu...
>
> ···············@cs.com (Levi Conley) writes:
>
> > Lisp newbie here. As someone very interested in AI who has only
> > recently come to realize that trying to achieve AI in
[snip]
> > Getting to the point of this post, in my web wanderings I also came
> > across a proposal for a new language project (open source) that seemed
> > to be quite promising. I'm just wondering if anyone with a lot more
> > language experience than myself has evaluated this language yet, and
> > has opinions, etc. Here is the link:
> >
> > http://flarelang.sourceforge.net/
> >
> > The statement that most intrigued me went something like this: "XML is
> > to Flare what linked lists are to Lisp." I'm still not sure what all
> > that would imply, but it sure sounds interesting.
>
> What you are impliying, pardon my bluntness, is that you have no
> recent and in-depth exposure to (Common) Lisp.
>
>
I think he made that clear in the first sentence of his post. I think a
more apropo comment is that the people making the statement that intrigued
him are implying they have no in-depth exposure to CL.
Glancing through the link above, I didn't see anything intriguing. It
didn't seem there is anything there that CL doesn't have already well
designed and established tools for...?
There is no harm in someone asking what "lispers" think!
Coby
--
(remove #\space "coby . beck @ opentechgroup . com")
From: Craig Brozefsky
Subject: Re: Representing code as XML: the Flare Programming Language
Date:
Message-ID: <874rr8f1zh.fsf@piracy.red-bean.com>
Marco Antoniotti <·······@cs.nyu.edu> writes:
> > http://flarelang.sourceforge.net/
> >
> > The statement that most intrigued me went something like this: "XML is
> > to Flare what linked lists are to Lisp." I'm still not sure what all
> > that would imply, but it sure sounds interesting.
>
> What you are impliying, pardon my bluntness, is that you have no
> recent and in-depth exposure to (Common) Lisp.
Why would he have to imply something that he said directly a few
paragraphs above?
--
Craig Brozefsky <·····@red-bean.com>
http://www.red-bean.com/~craig
The outer space which me wears it has sexual intercourse. - opus
···············@cs.com (Levi Conley) wrote in message news:<····························@posting.google.com>...
[...]
> http://flarelang.sourceforge.net/
>
> The statement that most intrigued me went something like this: "XML is
> to Flare what linked lists are to Lisp." I'm still not sure what all
> that would imply, but it sure sounds interesting. What I really want
> to know is if Flare, as initially proposed, seems to be capable of
> making some AI task much easier than Lisp.
I'm no guru, but there are a lot of things that i think are horribly
wrong with Flare:
(1) separation from the text you type to the text the compiler sees.
The language is supposed to be XML, but you end up programming in a
dialect of Python. You have to depend on an IDE. This is wrong; you
should be able to use your favorite text editor to code.
(2) just like Python, form is confused with content. The indentation
IS the logical structure. Some people think this is great, but i hate
it. I should be able to format my code as i damn please. This goes
against the grain of XML too. In XML, the indentation is not supposed
to be part of the meaning of the message. You're allowed to add
indentation to make it more readable during development then remove
the indentation to save space when you go to production.
(3) So, is this thing XML or Python? In some places it looks like a
weird Perl thing too. All the problems of Python and all the beauty of
Perl syntax, with some strange variation of OOP thrown in for good
measure.
(4) What the hell is "annotative"? They didn't know what they were
talking about and thought they would get away with it if they invented
a new term. XML is hierarchical, not "annotative". There is no such
thing as "annotative". Yuk!
(5) The actual XML is very verbose and cryptic. What's good does it do
to use XML to represent your code if you can't work with it? In Lisp,
code is data is lists, and this is a very simple representation.
Nobody needs a frigging IDE to translate from Python to lists!
(6) The Web page says the copyright belongs with http://singinst.org/.
That's another site that's weird beyond what's normally tolerated
outside of the asylum.
As Ace Ventura would say, "do not go in there!"
g
> (3) So, is this thing XML or Python? In some places it looks like a
> weird Perl thing too. All the problems of Python and all the beauty of
> Perl syntax, with some strange variation of OOP thrown in for good
> measure.
>
> (4) What the hell is "annotative"? They didn't know what they were
> talking about and thought they would get away with it if they invented
> a new term. XML is hierarchical, not "annotative". There is no such
> thing as "annotative". Yuk!
>
> (6) The Web page says the copyright belongs with http://singinst.org/.
> That's another site that's weird beyond what's normally tolerated
> outside of the asylum.
>
>
> As Ace Ventura would say, "do not go in there!"
>
> g
LOL! Isn't that like saying, "For the next 10 seconds, DON'T THINK OF
A PINK ELEPHANT!"
Weird is not quite the word I would use for The Singularity Institute.
Absurdly ambitious, perhaps. Still, I believe there are a great many
fertile ideas there, even if Flare is demonstrably not one of them.
I think the intention behind Flare is to make self-modifying programs
easier to write by somehow taking advantage of the META tag aspects of
XML. I believe that is what they are trying to get at by use of the
term "annotative". They want to say that by being able to represent
program, data, and program state as well-formed XML, that this will
somehow magically make it easier to construct programs that bootstrap
themselves to higher and higher levels of intelligence by
improving/evolving their code. I can't really get hold of how that
would work, or whether or not Common Lisp is already capable of this
sort of thing, but then, I am far from an expert in either computer
languages or AI.
Thanks to all for their wonderfully detailed insights and opinions
concerning Flare.
On 16 Aug 2001, glauber wrote:
[snip]
> (2) just like Python, form is confused with content.
Someone, perhaps you perhaps not, said something similar to this a short
while ago.
> The indentation
> IS the logical structure.
No, indentation is *part* of the syntactic structure.
> Some people think this is great, but i hate
> it. I should be able to format my code as i damn please.
This is true of very few languages. E.g., most langauges require
whitespace between most (but not all) tokens. Most languages have fairly
strict conventions on what counts as a statement/expression terminator,
etc. Many langauges have a restricted set of operators, and non-adjustable
precedence and associtivity rules. (Compare with Prolog, where you can
make any atom an infix left associtive, high precedence operator with a
single predicate.)
> This goes
> against the grain of XML too. In XML, the indentation is not supposed
> to be part of the meaning of the message.
Baloney. Sometimes it is, and sometimes it isn't. A lot depends on whether
you have a structure controlled or markup sensitive application (i.e., a
data serializer or an editor).
Plus, what do you think all the whitespace hand wringing is
*about*. Sometimes it matters and sometimes it does.
> You're allowed to add
> indentation to make it more readable during development then remove
> the indentation to save space when you go to production.
Saving space has to be the worst possible justification for stripping
whitespace.
[snip]
I agree, however, that Flare looks yucky :)
Cheers,
Bijan Parsia.
In article <····························@posting.google.com>,
··········@my-deja.com (glauber) wrote:
> (4) What the hell is "annotative"? They didn't know what they were
> talking about and thought they would get away with it if they invented
> a new term. XML is hierarchical, not "annotative". There is no such
> thing as "annotative". Yuk!
Well, actually there *is* ... but anywhere else it would be called a
comment ;-)
rgds
BK
--
bk <·········@yahoo.com>
ATTENTION! Email to this address *must* contain "USENET" in the subject line
otherwise it will be considered spam, automatically deleted and never reach me.
From: Erik Naggum
Subject: Re: Representing code as XML: the Flare Programming Language
Date:
Message-ID: <3206985430398054@naggum.net>
* ···············@cs.com (Levi Conley)
> Getting to the point of this post, in my web wanderings I also came
> across a proposal for a new language project (open source) that seemed
> to be quite promising. I'm just wondering if anyone with a lot more
> language experience than myself has evaluated this language yet, and
> has opinions, etc. Here is the link:
>
> http://flarelang.sourceforge.net/
>
> The statement that most intrigued me went something like this: "XML is
> to Flare what linked lists are to Lisp." I'm still not sure what all
> that would imply, but it sure sounds interesting. What I really want
> to know is if Flare, as initially proposed, seems to be capable of
> making some AI task much easier than Lisp.
There is a simple and elegant answer to this question: Just learn Common
Lisp well first. New languages are exciting to people who know mostly
new languages, so learn an old language before you learn new ones and get
out of the maelstrom that will drown you in ever new languages that add
nothing at all except some miniscule additional feature from another
language that someone needed to make a whole new language to implement
because he did not know (Common) Lisp to begin with. A "new" language
that differs from the rest of the crop by one or a couple features is
proof positive that both what it came from and what it has become are
mutations about to die. There are tens if not hundreds of thousands of
such "languages" that people have invented over the yeare, for all sorts
of weird purposes where they just could not use whatever language they
were already using, could not extend it, and could not fathom how to
modify its tools without making a whole new language. They never stopped
to think about how horribly wasteful this is, they just went on to create
yet another language called Dodo, the Titanic, Edsel, Kyoto-agreement...
John Foderaro has been credited with this profound statement about the
nature of Lisp:
Lisp is a programmable programming language.
People who have not programmed in (Common) Lisp do not understand what
this means because they are used to programming tools that build a Berlin
wall between the language and the user. This, ironically, is a manifest
feature of XML -- the language in which there are containers for data,
but where the writing on the outside of the container is in a different
language than the contents. This applies to attributes in elements, to
the XML declarations, to the Schema thing, to the parent language SGML.
All of these languages scream at the user: "The language you users should
use is not good enough for us language developers!"
Simply put, Lisp _is_ good enough for both language developer and user.
If you really want to produce XML that can be used by this Flare thing,
use (Common) Lisp instead of FlareSpeak to write it originally, once you
learn (Common) Lisp. Then, if Flare is really worth looking into once it
matures for a few years, you will have done both communities a favor.
And if Flare fizzles, you will at least not have wasted your time.
///