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.)

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.

My claim applies to all precedence languages....

-andy

Lispniks like to get at code programmatically.

--

  kenny tilton
  clinisys, inc
  http://www.tilton-technology.com/
  ---------------------------------------------------------------
"Everything is a cell." -- Alan Kay

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{*filter*}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.*-*-*.com/

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).

--

Looking for a developer in St. Louis? http://web.springies.com/~ats/
Insert New Disk for Drive C: Press ENTER when ready.

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).

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

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)

No.  

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.

--

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.

Actually, Ada is kind of a bad example because there *is* a
well-defined introspection facility. 8-)

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.

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

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

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.

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)

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.

Quite annoying yes. Luckily FreeBSD doesn't do this.

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)