Re: Pointers to "why C behaves like that ?"

"Stephen J. Bevan" <stephen@dino.dnsalias.com>
24 Nov 2002 18:35:02 -0500

          From comp.compilers

Related articles
[25 earlier articles]
Re: Pointers to "why C behaves like that ?" anw@merlot.uucp (Dr A. N. Walker) (2002-11-24)
Re: Pointers to "why C behaves like that ?" whopkins@alpha2.csd.uwm.edu (Mark) (2002-11-24)
Re: Pointers to "why C behaves like that ?" whopkins@alpha2.csd.uwm.edu (Mark) (2002-11-24)
Re: Pointers to "why C behaves like that ?" thp@cs.ucr.edu (2002-11-24)
Re: Pointers to "why C behaves like that ?" thp@cs.ucr.edu (2002-11-24)
Re: Pointers to "why C behaves like that ?" thp@cs.ucr.edu (2002-11-24)
Re: Pointers to "why C behaves like that ?" stephen@dino.dnsalias.com (Stephen J. Bevan) (2002-11-24)
Re: Pointers to "why C behaves like that ?" cgweav@aol.com (Clayton Weaver) (2002-11-24)
Re: Pointers to "why C behaves like that ?" joachim_d@gmx.de (Joachim Durchholz) (2002-11-24)
Re: Pointers to "why C behaves like that ?" joachim_d@gmx.de (Joachim Durchholz) (2002-11-24)
Re: Pointers to "why C behaves like that ?" jacob@jacob.remcomp.fr (jacob navia) (2002-11-26)
Re: Pointers to "why C behaves like that ?" jacob@jacob.remcomp.fr (jacob navia) (2002-11-26)
Re: Pointers to "why C behaves like that ?" jacob@jacob.remcomp.fr (jacob navia) (2002-11-26)
[35 later articles]
| List of all articles for this month |
From: "Stephen J. Bevan" <stephen@dino.dnsalias.com>
Newsgroups: comp.compilers
Date: 24 Nov 2002 18:35:02 -0500
Organization: just me at home
References: 02-11-059 02-11-071 02-11-083 02-11-097 02-11-119 02-11-131
Keywords: types
Posted-Date: 24 Nov 2002 18:35:02 EST

"Fergus Henderson" <fjh@cs.mu.OZ.AU> writes:
> Furthermore, whichever choice you make, it is difficult for the system
> to presenting accurate results of type inference for the kinds of
> incomplete, not yet syntactically correct program fragments that
> result when the user is in the middle of making a modification to
> their source -- which is usually the point at which such information
> is most useful.


I agree with the above. One approach to try and deal with checking
the (static) semantics of program fragments is [Snelting:acta:1991].
It has been a while since I read it so I'm not sure if any of the
examples were of a language that included type-inference or if the
approach would work for such languages.


@article
{ Snelting:acta:1991
, author= "Gregor Snelting"
, title= "The calculus of context relations"
, journal= acta
, volume= 28
, number= 5
, pages= "411--445"
, year= 1991
, refs= 40
, checked= 19960406
, source= "Computer Science Library, University of Manchester"
, abstract= "We present the theory of conext relations. Context
    relations are a method for incremental semantic analysis in
    language-specific editors, which is able to handle incomplete program
    fragments. The algorithm is generated from the definition of a
    language's static semantics and is based on inference rules and
    order-sorted unification. The paper presents the underlying
    mathematical theory, optimal incremental analysis algorithms, handling
    of user-defined polymorphism and overloading, and implementation
    issues. It is intended as the concluding report on by now mature
    concept, which has successfully been used to generate efficient
    incremental type inferencers for languages like Ada and Fortran 8x."
, sjb= "Since this is in Acta Informatica it shouldn't come as a
    surprise that this is mainly a theoretical paper concentrating on
    proofs of the unification system used. There are a few pages of
    readable text intermingled though, enough to get an idea of how the
    system works."
, reffrom= Grosch:Snelting:plilp:1990
, reffrom= Nipkow:Snelting:fplca:1991
, reffrom= Poetzsch-Heffter:plilp:1993
}


Post a followup to this message

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