DCT use cases - draft

[deadalnix]

Le 22/05/2012 20:33, Roman D. Boiko a écrit :
> On Tuesday, 22 May 2012 at 18:10:59 UTC, Jacob Carlborg wrote:
>> On 2012-05-22 19:14, Roman D. Boiko wrote:
>>
>>> This is a draft of use cases for all DCT libraries combined.
>>
>> This seems to be mostly focused on lexing? See below for some ideas.
> Yeah, about 50% is lexing. I pay more attention to it because lexer
> alone is enough for several uses. I would like to have at least some
> functionality used as early as possible, this would provide me great
> feedback.
>

Providing it as a Range of Tokens would be the awesomest design decision 
you could ever make.

>>> Scope for DCT is to provide semantic analysis, but not code
>>> generation (that may become another project some time). Information
>>> about projects, etc., is useful for e.g., analysing dependencies.
>>
>> That's a good point.
>>
>>> I'll improve overall structure and add some explanations + examples
>>> tomorrow. Could you elaborate on specific points which are vague?
>>
>> I would probably have specified some high level use cases first, like:
>>
>> * IDE integration
>> * Refactoring tool
>> * Static analysis
>> * Compiler
>> * Doc generating
>> * Build tool
> Thanks! I didn't think about build tool, for exapmle.
>
> I started this way, but after your comment on my previous post that
> there is nothing new I reconsidered my approach and decided to start
> from concrete (low-lewel), then improve it according to feedback, and
> then split into areas (which roughly correspond to your hi-level use
> cases).
>
>> In general, use cases that can span several compile phases, i.e.
>> lexing, parsing, semantic analysis and so on. Some of these use cases
>> can be broken in to several new use cases at a lower level. Some
>> examples:
>>
>> IDE integration:
>>
>> * Syntax highlighting
>> * Code completion
>> * Showing lex, syntax and semantic errors
>>
>> Refactoring:
>>
>> * Cross-referencing symbols
>>
>> Build tool:
>>
>> * Tracking module dependencies
>>
>> Doc generating:
>>
>> * Associate a declaration and its documentation
>>
>> Some of these "sub" use cases are needed by several tools, then you
>> can either repeat them or pick unique sub use cases for each high
>> level use case.
>>
>> Then you can get into more detail over lower level use cases for the
>> different compile phases. If you have enough to write you could
>> probably have a post about the use cases for each phase.
>
> Thanks for examples.
>
>> It seems some of your use cases are implementation details or design
>> goals, like "Store text efficiently".
> Actually, many of those are architectural (although low-level), because
> they are key to achieve the project goals, and failing in this area
> could cause overall failure. I intend to move any non-architectural
> information into a separate series of posts, feel free commenting what
> you don't consider important for the architecture (probably don't start
> yet, I'm reviewing text right now).
>
>> It would not be necessary to start with the high level goals, but it
>> would be nice. The next best thing would probably be to start with the
>> use cases compiler phase you already have started on, that is lexing,
>> if I have understood everything correctly.
>
> Yes, and even before that I'm going to document some fundamental
> primitives, like immutability and core data structures.