Re: Looking for new language features

A Johnstone wrote:


> I've got a lot of sympathy with Randy's philosophy, bit I think
> extensible languages are too hard to use, although being able to
> define new operators as in Algol-68 is great. 'Syntax du jour' is a
> great line, but the real problem is that people who enjoy this sort of
> thing end up producing write-only programs. A write-only language is
> one in which programs are written, and then never comprehended by a
> subsequent reader. I look at a lot of undergraduate programs, and the
> difficulty of extracting semantics from them is amazing: I don't know
> what I would do if I couldn't even recognise the keywords! Anybody who
> has ever done large scale programming in Forth or TeX (which is a
> macro expansion language) might recognise the write-only syndrome.


There are some great phrases in this thread: "Synatx du jour", and
"write only language". They're both quite true. But just like there's
also ADT du jour, I don't think the problem is extensible languages as
much as extensible abstractions. My experience has been that extending
any set of complex semantics is difficult unless the set of semantics
were originally designed to be extended. It doesn't matter if it's the
java gui classes, some math package, or some compiler writing
tool. It's easy to build higher level abstractions on top of
Java. It's not nearly as easy to build abstractions on top of the java
gui classes (no matter what they say). It's nearly impossible to add
new data types to something like petsc (a parallel math package)
because it was never intended to be extended this way. On the other
hand, as crude as cpp is, if it's used wisely it's very effective.


So I think there is room for compile time abstractions if it's done
right. I'm not completely sure what "right" is but I'd guess it also
applies to "normal" abstractions like ADT's. I'd also guess that this
news group could describe such criteria. But there are definitely
compile time abstractions I could use. For example, I need something
that looks at F90 derived data types and generates code to efficiently
move data around on a parallel machine. The key here is efficiency. It
would be possible to build something that uses tables and data
structures to describe the data to move, along with some code to
interpret the descriptors, but it wouldn't run efficiently. The result
is that I end up writing this code by hand. Furthermore, I'll never
convince the Fortran-xx committee to add this feature. So I still
would like the ability to build such an abstraction myself.


Matt

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