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.
