Automatic dereference operator: (Was: Language design question)

"Ira D. Baxter" <idbaxter@semdesigns.com>
13 Feb 2000 22:59:30 -0500

          From comp.compilers

Related articles
Language design question flisakow@ricotta.cs.wisc.edu (2000-02-13)
Automatic dereference operator: (Was: Language design question) idbaxter@semdesigns.com (Ira D. Baxter) (2000-02-13)
| List of all articles for this month |

From: "Ira D. Baxter" <idbaxter@semdesigns.com>
Newsgroups: comp.compilers
Date: 13 Feb 2000 22:59:30 -0500
Organization: Posted via Supernews, http://www.supernews.com
References: 00-02-065
Keywords: design

Our PARLANSE language ("C"-like, sorta, more below) has the notion of an
access path:
                    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
Yuk.


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.


-- IDB


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)


Post a followup to this message

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