Re: Current work in compiler/language design.

preston@dawn.cs.rice.edu (Preston Briggs) writes:
// is narrow and significantly biased towards high-performance computing. In
// particular, we usually think about the problems posed by all these new
// machines.
// ... (if "narrow and biased" sounds bad, think "focused")


martens@laurel.cis.ohio-state.edu (Jeff Martens) writes:
// Parallelization is a hot area in compilers within CS departments, not just
// in EE departments. And most people aren't working on parallelizing
// compilers just for the latest architecture unless perhaps they're working


I think 'focused' above covers what I meant to say. Parallelization is a
small area of compilers and programming languages; you could add an
automatic parallelizer onto any compiler and even add explicitly parallel
constructs onto any language, but this is only one small issue, probably
covered under concurrency, and is not what I would first describe to a
newcomer of programming languages and compilers. Actually, in my EE
graduate level course on parallelization, we did discover that good global
data-flow analysis is required for parallelization and this is an
interesting CS area, but still belongs in the back-end facilities by my
reconning. Since whenever I bring up parallelism I usually hear: "I
haven't read up on this in 25 years or so, but I know my program will run
slower if it runs on several processors...", I'm just glad there are
people who are keeping up, so enough by me on this subject.


preston@dawn.cs.rice.edu (Preston Briggs) writes:
//> The hot spot in programming languages today is object-oriented
//
// This also seems narrow and biased. Every year, POPL is filled with plenty
// of papers on topics besides OO. I think POPL reflects (some of) the
// direction(s) of the programming language community -- OOPSLA reflects the
// interests of people who are into OOP.


martens@laurel.cis.ohio-state.edu (Jeff Martens) writes:
// Certainly there is research in object oriented languages and such nowadays
// -- SIGPLAN members get reams of OOPSLA stuff whether they're interested or
// not -- but contrary to the prior poster's opinion, object oriented
// techniques are not the only ones being worked on by compiler people within
// the computer science community -- it's just a small corner of a large
// field.


Yes, my opinion is biased towards the OO paradigm, but so is the
programming language community, in my opinion. Look at the books, the new
software engineering methodologies, the latest trends, all point to
object-oriented. I am a programming languages 'person' and after covering
the field, OO beats all other existing methodologies in almost every
respect, and if it doesn't, I can just add it as a new OO feature. If it
exists in the real world, it exists in the object-oriented one too (really
want a formal pattern matcher, implement a proglog object). Do you see a
special logic or functional programming journal addition to sigplan, no
you see object-oriented ones. This is most significant to people entering
the programming languages/compilers domain, since this is most likely to
be a primary area of study, if not the primary area.


As for other paradigms (Really *my* opinion here):


Logic programming solves a very limited domain, that is the domain of
logic. Is this general purpose? No, it works well with logic. Is this
the way we solve problems? No, we do poorly with logic and usually
transcend logic to simply arrive at intelligent solutions to problems
which may not be solvable with logic at all.


Functional programming solves mathematical problems in a clean way. Is
this general purpose? No, it leaves out simple statement sequences and
and only allows single (constant) assignments, this has yet to be shown
that it can solve even simple problems (i.e. violates every software
engineering principle I can think of except provable code), let alone
complex ones (just ask a functional programmer if they would like to
bootstrap their compiler, they'll tell you they wrote it in C and it will
stay that way (unless they upgrade to C++)).


How about LISP based systems (boy do I expect it here): Are they general
purpose? Not really, they are interpreted and run several hundred times
slower than compiled code (although this could change). They usually
don't have static typing, so you have no choice, dynamic typing or naught.
They have an unnatural syntax, big violation here. Recently, they claim
to have 'Multi-Methods' and claim they are more powerful than method
passing in traditional OO. But, these are just function calls at
run-time, and their system works at run-time, so what are they really? you
guessed it, function calls! If you add dynamic typing to C++ guess what
you get when you invoke a function dynamically??? This is not better than
object-oriented message passing, in fact, this is a joke. As far as other
nice features of Lisp based (OO) languages, functional, logic, etc., just
identify them, if they're useful we can add them to almost any programming
language. Want logic-style pattern matching, type inferencing, user
defined control-structures, meta-level access, just ask or provide, don't
go to something really weird(unusable).


Standard 3rd generation programming (by CS reconning) falls apart when
large or complex systems are involved, and incremental improvements
for abstraction and reuse (etc.) to solve these problems often go by
another name, yes, you guessed it, Object-Oriented! In fact if we add
up all of the new facilities we would like to add to existing programming
languages, this is also a common definition of object-oriented programming.
I think its pretty easy to defend future directions of programming languages
and compilers as object-oriented, if that is its very definition. And if
object-oriented programming languages are what we need to write compilers
for, then we as compiler writers have a good direction to focus on (I also
think this is a good direction to focus hardware and systems on too).
And for a last word, I've worked with and seen quite a few compilers and
am well aware of their strong and weak points, and the weakest,
most bug-ridden, maintenance nightmarish point (Don't ever do this) is:
    They Were All Data Structure Oriented:
        Lack of encapsulation: unstructured, indescriminant, and undocumented
        access to primary data structures.
    Solution to 97% of all compiler related bugs and problems(by my best guess):
        Encapsulation as provided by object-oriented programs.


Anyway, I think a programming language and what is needed by it comes
first, then how to write a compiler and implement it. My first posting
covered a few of the latest areas to look into (right now) in the
programming language design literature, and for now I'll stand by it.


Bob Hathaway
objsys@netcom.com
[Gentle readers: try and keep your flames tasteful. I have to say that
most of the complaints about Lisp seem a little out of date -- modern
Scheme systems have static typing, good compilers, etc. -John]
--

Return to the comp.compilers page.
Search the comp.compilers archives again.