Re: Seprerating algorithms from implementations (long)

"felix" <>
2 Sep 2000 16:21:42 -0400

          From comp.compilers

Related articles
Seprerating algorithms from implementations (long) (Toby Sharp) (2000-08-27)
Re: Seprerating algorithms from implementations (long) (felix) (2000-09-02)
Re: Seprerating algorithms from implementations (long) (Rob Hutchinson) (2000-09-08)
| List of all articles for this month |

From: "felix" <>
Date: 2 Sep 2000 16:21:42 -0400
Organization: Posted via Supernews,
References: 00-08-124
Keywords: design

Toby Sharp wrote in message 00-08-124...

> [...]
>The crux of the idea is to have a new language which describes
>algorithms separately from implementations. The language also provides
>a way to give extra information about supplied input and required
>output, so that highly optimised code can be created. A compiler goes
>into great detail to find the best implementation for the supplied
>algorithm information.
>So, has anyone done it? Suggested it? Any thoughts on whether
>theoretically possible? Or practically feasible? All comments welcome
>at this stage.

An idea I recently read about is Aspect Oriented Programming (AOP). In
this paradigm (if I understand it right) you split a program into
several "aspects", where each aspect represents a particular
implementation issue. A special "aspect-language" is used to describe
the problem/issue and a program called "aspect-weaver" builds the
final application. I do not claim to understand it thoroughly, but it
appears to me that this strategy targets the problem that a program
often has certain implementation issues that do not fall under a
single specific class. Aspects help to clearly define a problem that
touches several parts of the overall project.

A couple of interesting papers are at
Especially the texts
"What A Metaobject Protocal Based Compiler Can Do For Lisp"
"An Architecture For An Open Compiler".
(All quite LISP specific, but nevertheless very interesting)

Another interesting point is that the compiler-architecture mentioned
in the papers gets active assistance from the programmer, and so it
can go a lot further than a traditional compiler, without being
exceptionally clever.

I hope this is of any help,

Post a followup to this message

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