[darcs-users] Eclipse integration, refactoring, and combinato rial explosion?

[BARBOUR Timothy]

> -----Original Message-----
[...]
> So the question would be how to define a domain-specific 
> patch definition
> language such that 2 and 3 can be solved.  As you point out, 
> this would of
> course require that each patch type be capable of being defined
> independently of any other patch type.  I don't believe this 
> is practical
> or desirable for all patch types.

AFAIK darcs tries to treat changes in terms of their meaning. But the
meaning of the change depends on the language used in the source files
stored in darcs (as you mention). Perhaps the representation of programs as
lines of text is wrong, and darcs (and refactoring tools) really should be
storing and operating on the same kind of representation that the compiler
uses (e.g. parse-trees).

In fact I am working on an implementation of persistent memory (similar to
virtual memory), for the Linux kernel (in particular). My aim is that the
data structures used (at present internally) by compilers such as ghc will
become long lived and accessible to other programs.

Tim

-- sorry about the lame .sig --

IMPORTANT NOTICE: This e-mail and any attachment to it are intended only to be read or used by the named addressee. It is confidential and may contain legally privileged information. No confidentiality or privilege is waived or lost by any mistaken transmission to you. The RTA is not responsible for any unauthorised alterations to this e-mail or attachment to it. Views expressed in this message are those of the individual sender, and are not necessarily the views of the RTA. If you receive this e-mail in error, please immediately delete it from your system and notify the sender. You must not disclose, copy or use any part of this e-mail if you are not the intended recipient.