Perfect Programming Language 
Author Message
 Perfect Programming Language

Quote:





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

Quote:
> > 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.

Quote:
> > 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



Tue, 27 Sep 2005 13:00:54 GMT  
 Perfect Programming Language

Quote:






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



Tue, 27 Sep 2005 13:10:16 GMT  
 Perfect Programming Language

Quote:

> 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{*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/



Tue, 27 Sep 2005 19:50:04 GMT  
 Perfect Programming Language

Quote:

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

--

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



Tue, 27 Sep 2005 23:07:59 GMT  
 Perfect Programming Language

Quote:

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


Wed, 28 Sep 2005 03:41:34 GMT  
 Perfect Programming Language


Quote:

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



Wed, 28 Sep 2005 10:25:59 GMT  
 Perfect Programming Language

Quote:

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



Wed, 28 Sep 2005 21:47:51 GMT  
 Perfect Programming Language

Quote:

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

Quote:

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

--

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.



Wed, 28 Sep 2005 23:23:12 GMT  
 Perfect Programming Language

Quote:

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


Wed, 28 Sep 2005 23:55:25 GMT  
 Perfect Programming Language

Quote:

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



Fri, 30 Sep 2005 05:27:39 GMT  
 Perfect Programming Language

Quote:

> 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



Fri, 30 Sep 2005 07:12:00 GMT  
 Perfect Programming Language

Quote:

> 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



Fri, 30 Sep 2005 07:27:49 GMT  
 Perfect Programming Language

Quote:


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



Fri, 30 Sep 2005 19:20:53 GMT  
 Perfect Programming Language

Quote:




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

Quote:
> "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.


Thu, 06 Oct 2005 21:29:11 GMT  
 Perfect Programming Language

Quote:


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

Quote:
> 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)



Thu, 06 Oct 2005 21:35:59 GMT  
 
 [ 17 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Perfect Programming Language

2. Perfect Programming Language

3. Golf - The perfect problem to compare languages with?

4. Your perfect language.

5. Make the language Perfect/SOS

6. Yet another perfect number program

7. Yet another perfect number program

8. A Language Primer required for A Programming Language

9. Use a new language: Structured Programming Language

10. All Languages Programming Contest -- Extending the language (4)

11. All Languages Programming Contest -- Extending the language (3)

12. The Icon Programming Language (was: Discussions of languages)

 

 
Powered by phpBB® Forum Software