Bruce Hoult <·····@hoult.org> wrote in message news:<···························@copper.ipg.tsnz.net>...
> In article <····························@posting.google.com>,
> ······@earthlink.net (Andy Freeman) wrote:
>
> > Bruce Hoult <·····@hoult.org> wrote in message
> > news:<···························@copper.ipg.tsnz.net>...
> > > Why is this such an important thing? You only have to write the parser
> > > *once*. After that anyone can use it (if you make it available as a
> > > library, and not just as a monolithic part of the compiler).
> >
> > The "make a parser available" problem is arguably fixable, even though
> > said fix isn't generally available and people spend lots of time on related
> > hacks.
>
> I don't know why language implementators don't generally make their
> compiler's parser available to users :-(
Since that parser (for non-lisp languages) won't help me parse the vast
majority of the languages that I might care about (lisp or non-lisp), I
can see why they wouldn't bother.
But - I'll bite. How often do you need to parse a language that is
close enough to the (non-lisp) programming language that you're using
that having the parser available makes a difference. (Note that if you're
just compiling said language, you don't need the parser.)
> > The more serious problem is that humans aren't all that competent writing
> > and reading languages with precedence. That's unlikely to change.
> >
> > Precedence languages are sort of like keyboards with keys in alphabetical
> > order. Both look like they'd be easy to use (no learning curve), but
> > the learning curve isn't the important problem.
>
> I agree that the learning curve isn't the important problem, but surely
> it's Lisp that has the lower learning curve for syntax -- there almost
> *isn't* any.
For someone starting from scratch, yes, but the argument for precedence
languages is that they're familiar because similar notations are used
elsewhere, such as math textbooks. (My analogy depends on the fact that
it used to be that most folks knew alphabetical order before they used
their first keyboard.) Lisp notation isn't used elsewhere, so it has
to be learned.
My point is that the seeming headstart doesn't help. Precedence languages
are a mistake whenever humans are involved, and that has nothing to do
with the availability of parsers. People think that they can use precedence
languages without learning anything, but they're wrong. Still, they
compare that "no learning" with the small bit of learning req'd for
lisp. They don't seem to notice that precedence languages require a
lot of learning and comprehension effort. That's why folks spend so
much more time with syntax errors in non-lisp languages.
> > I don't know what definition of "readability" you're using, but if it
> > C scores higher than Lisp, it's measuring the wrong thing.
>
> Oh, I don't think *C* is readable.
My claim applies to all precedence languages....
-andy
Andy Freeman wrote:
> Bruce Hoult <·····@hoult.org> wrote in message news:<···························@copper.ipg.tsnz.net>...
>
>>In article <····························@posting.google.com>,
>> ······@earthlink.net (Andy Freeman) wrote:
>>
>>
>>>Bruce Hoult <·····@hoult.org> wrote in message
>>>news:<···························@copper.ipg.tsnz.net>...
>>>
>>>>Why is this such an important thing? You only have to write the parser
>>>>*once*. After that anyone can use it (if you make it available as a
>>>>library, and not just as a monolithic part of the compiler).
>>>
>>>The "make a parser available" problem is arguably fixable, even though
>>>said fix isn't generally available and people spend lots of time on related
>>>hacks.
>>
>>I don't know why language implementators don't generally make their
>>compiler's parser available to users :-(
>
>
> Since that parser (for non-lisp languages) won't help me parse the vast
> majority of the languages that I might care about (lisp or non-lisp), I
> can see why they wouldn't bother.
>
> But - I'll bite. How often do you need to parse a language that is
> close enough to the (non-lisp) programming language that you're using
> that having the parser available makes a difference. (Note that if you're
> just compiling said language, you don't need the parser.)
Lispniks like to get at code programmatically.
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Everything is a cell." -- Alan Kay
······@earthlink.net (Andy Freeman) writes:
> But - I'll bite. How often do you need to parse a language that is
> close enough to the (non-lisp) programming language that you're using
> that having the parser available makes a difference. (Note that if you're
> just compiling said language, you don't need the parser.)
Whenever I want an editor that knows how to indent, colourize, or
recognize keywords or syntactic blocks in that language. More
generally, writing pretty-printers (e.g. to convert program source to
neatly marked up LaTeX or HTML).
Also, in the specific case of C on unix, it would be very convenient
to be able to parse header files and automatically transform them into
FFI definitions for some non-C language. Anyone using Linux will be
aware that the glibc include maze is full of pits, spikes, traps, and
carefully half-rotted floorboards - you just can't send anything other
than the True Gcc in there unless it has volunteered for the mission
and understands it probably won't make it out alive.
(Yes, I accept that this won't get me an idiomatic library interface
for whatever non-C language i had in mind. But if it gets me out of
having to hand-transcribe the values of O_EXCL and SIGBUS and the
offset and size of stat.st_mtime, it would save an awful lot of time
anyway)
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
Daniel Barlow <···@telent.net> writes:
> Whenever I want an editor that knows how to indent, colourize, or
> recognize keywords or syntactic blocks in that language.
Also, for things like "intellisense" (completing methods allowed on
an object), generating documentation templates from function
prototypes, lookup of variable definitions following correct
scoping, code-assisted refactoring, class browsers... the list goes
on and on.
It's so useful to have that Eric Ludlam started a separate
parser-generator project for Emacs, so that one could write a full
parser for these kinds of things. It would be much less work if one
could just hook into the compiler's parser, which is how Visual
Studio does it (from what I've been told).
--
Alan Shutko <···@acm.org> - I am the rocks.
Looking for a developer in St. Louis? http://web.springies.com/~ats/
Insert New Disk for Drive C: Press ENTER when ready.
"Alan Shutko" <···@acm.org> wrote in message
···················@wesley.springies.com...
> Daniel Barlow <···@telent.net> writes:
>
> > Whenever I want an editor that knows how to indent, colourize, or
> > recognize keywords or syntactic blocks in that language.
>
> Also, for things like "intellisense" (completing methods allowed on
> an object), generating documentation templates from function
> prototypes, lookup of variable definitions following correct
> scoping, code-assisted refactoring, class browsers... the list goes
> on and on.
So, the language standard (for said mythical language) needs this
capability, built-in, so that folks can write a snazzy editor faster? Is
that what I'm hearing?
"I'd like to use Ada for my Autonomous RDBMS backed Learning Expert System
Internet Shopping Agent, but it can't pretty print it's source code by
itself very easily".
Yeah, Ok.
I know the IDE is the primary deciding factor behind all of my language
decsions.
Regards,
Will Hartung
(·····@msoft.com)
"Will Hartung" <·····@msoft.com> writes:
> So, the language standard (for said mythical language) needs this
> capability, built-in, so that folks can write a snazzy editor faster? Is
> that what I'm hearing?
No.
Bruce Hoult <·····@hoult.org> wrote in message news:<···························@copper.ipg.tsnz.net>...
> I don't know why language implementators don't generally make their
> compiler's parser available to users :-(
It would be convenient if compiler vendors were to expose their
parser. Nobody said anything about requiring it in the language
standard. Just talking about one simple thing which would make
several real life problems easier.
--
Alan Shutko <···@acm.org> - I am the rocks.
Looking for a developer in St. Louis? http://web.springies.com/~ats/
PRIDE OF CHANUR: A great read if you don't mind the pits.
"Will Hartung" <·····@msoft.com> writes:
> "I'd like to use Ada for my Autonomous RDBMS backed Learning Expert System
> Internet Shopping Agent, but it can't pretty print it's source code by
> itself very easily".
Actually, Ada is kind of a bad example because there *is* a
well-defined introspection facility. 8-)
In article <·················@newssvr16.news.prodigy.com>, Will Hartung wrote:
>
> "Alan Shutko" <···@acm.org> wrote in message
> ···················@wesley.springies.com...
>> Daniel Barlow <···@telent.net> writes:
>>
>> > Whenever I want an editor that knows how to indent, colourize, or
>> > recognize keywords or syntactic blocks in that language.
>>
>> Also, for things like "intellisense" (completing methods allowed on
>> an object), generating documentation templates from function
>> prototypes, lookup of variable definitions following correct
>> scoping, code-assisted refactoring, class browsers... the list goes
>> on and on.
>
> So, the language standard (for said mythical language) needs this
> capability, built-in, so that folks can write a snazzy editor faster? Is
> that what I'm hearing?
Yes, maybe it would be wise when designing a new language to allow for
incremental parsing/ parsing code with errors in it.
I myself use Delphi and JBuilder, and I noticed that JBuilders autocomplete often
stalls (doesn't list methods), when I make a very simple error in de code above (like
forgetting a semi-colon), while Delphi doesn't.
Such things could be related to the language parsability (Pascal is easy parsable, and though
something like Delphi is afaik not really LL(1) anymore, it's still easy to parse)
> "I'd like to use Ada for my Autonomous RDBMS backed Learning Expert System
> Internet Shopping Agent, but it can't pretty print it's source code by
> itself very easily".
While this is not realistic (it is a tool problem, not language), I can
imagine people having to do source-transforms and creating own tools
avoiding complex to parse (and large) languages.
Daniel Barlow <···@telent.net> writes:
> (Yes, I accept that this won't get me an idiomatic library interface
> for whatever non-C language i had in mind. But if it gets me out of
> having to hand-transcribe the values of O_EXCL and SIGBUS and the
> offset and size of stat.st_mtime, it would save an awful lot of time
> anyway)
I've used autoconf successfully to extract constants, struct sizes and
offsets. No real need to reinvent the wheel (and aiming for GCC
compatibility is futile anyway).
Florian Weimer <··@deneb.enyo.de> writes:
> I've used autoconf successfully to extract constants, struct sizes and
> offsets. No real need to reinvent the wheel (and aiming for GCC
> compatibility is futile anyway).
Yes, but (unless autoconf is a lot more featureful than it was last
time I looked at it) you do this by means of writing small programs
and giving them to the C compiler. If the parser were available
separately, that would be notably less inefficient (and be rather
easier to do in a cross-compile)
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
Daniel Barlow <···@telent.net> writes:
> Florian Weimer <··@deneb.enyo.de> writes:
>
> > I've used autoconf successfully to extract constants, struct sizes and
> > offsets. No real need to reinvent the wheel (and aiming for GCC
> > compatibility is futile anyway).
>
> Yes, but (unless autoconf is a lot more featureful than it was last
> time I looked at it) you do this by means of writing small programs
> and giving them to the C compiler. If the parser were available
> separately, that would be notably less inefficient (and be rather
> easier to do in a cross-compile)
There's an autoconf macro[1] in the GNU autoconf macro archive[2]
which solves the cross compiling issue. Basically, what it does is
this: you have a constant expression in C, and want to know the value
without running the generated code. Obviously you can do this by
surrounding the value by some magic constant data and then grepping
the generated executable file. This sounds horrible, but in practice
it works quite well.
Of course there's no need to use autoconf for this at all, the
mechanism is the magic, not the tool.
[1] compile_value,
http://www.gnu.org/software/ac-archive/htmldoc/compile_value.html
[2] http://www.gnu.org/software/ac-archive/
--
Teemu Kalvas
Teemu Kalvas <·····@s2.org> writes:
> Basically, what it does is this: you have a constant expression
> in C, and want to know the value without running the generated
> code. Obviously you can do this by surrounding the value by
> some magic constant data and then grepping the generated
> executable file.
Current versions of Autoconf can also evaluate a constant Boolean
expression by compiling a test program and checking the exit code
of the compiler. This lets them deduce the value of a constant
integer expression with a binary search when cross-compiling.
_AC_COMPUTE_INT_COMPILE is the essential macro.
Daniel Barlow <···@telent.net> writes:
> Also, in the specific case of C on unix, it would be very convenient
> to be able to parse header files and automatically transform them into
> FFI definitions for some non-C language. Anyone using Linux will be
> aware that the glibc include maze is full of pits, spikes, traps, and
> carefully half-rotted floorboards - you just can't send anything other
> than the True Gcc in there unless it has volunteered for the mission
> and understands it probably won't make it out alive.
Aye. I particularly like the fact that Linux (or rather, the glibc)
doesn't even come with a complete set of headers, some are provided by
gcc, and you have to know that you'll find them in
$ gcc --print-file-name=include
/usr/lib/gcc-lib/i386-linux/3.2.3/include
rather than /usr/include, where they are on more decent systems.
In the Gwydion Dylan project, we have a tool called melange that does
generate C-FFI from header files. After 5 years if intense training,
it manages to get out alive with most headers. We've been using it to
wrap things like the OpenGL headers, an improved version of the parser
is being used for wrapping GTK.
Andreas
--
"In my eyes it is never a crime to steal knowledge. It is a good
theft. The pirate of knowledge is a good pirate."
(Michel Serres)
In article <··············@meo-dipt.andreas.org>, Andreas Bogk wrote:
> Daniel Barlow <···@telent.net> writes:
>
>> Also, in the specific case of C on unix, it would be very convenient
>> to be able to parse header files and automatically transform them into
>> FFI definitions for some non-C language. Anyone using Linux will be
>> aware that the glibc include maze is full of pits, spikes, traps, and
>> carefully half-rotted floorboards - you just can't send anything other
>> than the True Gcc in there unless it has volunteered for the mission
>> and understands it probably won't make it out alive.
>
> Aye. I particularly like the fact that Linux (or rather, the glibc)
> doesn't even come with a complete set of headers, some are provided by
> gcc, and you have to know that you'll find them in
>
> $ gcc --print-file-name=include
> /usr/lib/gcc-lib/i386-linux/3.2.3/include
Quite annoying yes. Luckily FreeBSD doesn't do this.
> rather than /usr/include, where they are on more decent systems.
>
> In the Gwydion Dylan project, we have a tool called melange that does
> generate C-FFI from header files. After 5 years if intense training,
> it manages to get out alive with most headers. We've been using it to
> wrap things like the OpenGL headers, an improved version of the parser
> is being used for wrapping GTK.
We've similar problems with *nix headers for our Pascal compiler. There is
some header tool that works on moderately clean headers only. Also a lot of
API's are quite C oriented. (like e.g. IOCTL definitions)
I heard QT seems to have some Perl tool that generates the C headers from
some mother format, and this tool can be adapted to generate headers for
other languages/compilers.
Seems like a nice system in principle. (if one can unify the projects to
standarise on one or a few of such converter tools)
From: Joachim Durchholz
Subject: Re: Perfect Programming Language
Date:
Message-ID: <3E99D64B.9030503@gmx.de>
Daniel Barlow wrote:
>
> Also, in the specific case of C on unix, it would be very convenient
> to be able to parse header files and automatically transform them into
> FFI definitions for some non-C language. Anyone using Linux will be
> aware that the glibc include maze is full of pits, spikes, traps, and
> carefully half-rotted floorboards - you just can't send anything other
> than the True Gcc in there unless it has volunteered for the mission
> and understands it probably won't make it out alive.
Then send in GCC.
More specifically: send in GPP, and let it return the definitions.
Usually, you want to wrap some specific part of all the API. I.e. you
have a file foo.h that says
#define SOME_CONFIGURATION_VALUE
#include <lots-of-cruft>
#define BLAH ...
typedef ... X
Write a small "detector" file that has
#include <foo.h>
blah: BLAH
x: X
send this to gpp, then look for the blah: and x: headers and look what
gpp made of them.
Doesn't seem to be very difficult.
Or did I overlook something here?
Regards,
Joachim
--
Currently looking for a new job.
Joachim Durchholz <·········@gmx.de> writes:
> Write a small "detector" file that has
> #include <foo.h>
> blah: BLAH
> x: X
> send this to gpp, then look for the blah: and x: headers and look what
> gpp made of them.
This is insufficient for sizeof, offsetof, or to get the values of
enums - you need to run the compiler all the way through to pick these
up. I do this already, and frankly it's pretty kludgey.
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
Joachim Durchholz <·········@gmx.de> writes:
> Daniel Barlow wrote:
> > Also, in the specific case of C on unix, it would be very convenient
> > to be able to parse header files and automatically transform them into
> > FFI definitions for some non-C language. Anyone using Linux will be
> > aware that the glibc include maze is full of pits, spikes, traps, and
> > carefully half-rotted floorboards - you just can't send anything other
> > than the True Gcc in there unless it has volunteered for the mission
> > and understands it probably won't make it out alive.
>
> Then send in GCC.
>
> More specifically: send in GPP,
I would have thought that this is a job for GCC-XML:
http://www.gccxml.org
... then use the full power of Lisp (or whatever happens to be at
hand) to finish off the job.