|Language design question email@example.com (2000-02-13)|
|Automatic dereference operator: (Was: Language design question) firstname.lastname@example.org (Ira D. Baxter) (2000-02-13)|
|From:||"Ira D. Baxter" <email@example.com>|
|Date:||13 Feb 2000 22:59:30 -0500|
|Organization:||Posted via Supernews, http://www.supernews.com|
Our PARLANSE language ("C"-like, sorta, more below) has the notion of an
A : B: ... : Z,
where the elements are language values, often thought of as Maps
("functions"), but instantiated in the usual forms: functions, structs,
arrays, strings, you name it.
So A:B means apply A to B; A:B:C means apply
A to B, and apply that result to C, etc. One nice property of these
paths is you can replace one map implementatin by another
(say, a function by a struct or an array) with no
change in access path syntax in the rest of the program.
If you do this in C, all the redundant path syntax for map accesses
have to change. Good thing there's so many of them: -> [ ] f() dot
The PARLANSE compiler does something like what Shaun proposes; if an
access path result is a *pointer* to a map (e.g., A is a pointer in
A:B), the compiler simply inserts a dereference operation. Actually,
it'll issue as many implicit dereferences as it takes to get to a map.
So you can likewise change the indirection distance to a map without
changing access paths.
We've used PARLANSE internally for several years now, to build a large
parallel symbolic computation application ("DMS"). The path idea and
implicit derefencing have worked out pretty well in practice.
PARLANSE is much more interesting than the access path notation; it
offers efficient support for irregular, medium to fine grain
computation. The compiler schedules grains at the sub-thread level to
control context switching costs.
Shaun Flisakowski wrote in message 00-02-065...
>I'm working on a language design that is a hybrid of C and pascal.
>It seems that with strong typing, there is no need for a dereferencing
>operator, as the compiler could add these automatically. (I'd still
>have an address-of operator)
Return to the
Search the comp.compilers archives again.