suzanne.soy/scribble-enhanced
1
0
Fork 0
Code Issues 1 Pull Requests 1 Actions Packages Projects Releases Wiki Activity

Partially fixed cross-references. Still needs to update Makefile.

Browse Source
This commit is contained in:
Georges Dupéron 2015-12-09 11:46:12 +01:00
parent d127d4d27f
commit 250f4e1137
8 changed files with 41 additions and 36 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
graph/graph/graph.lp2.rkt
View File

@ -125,7 +125,7 @@ desired result node, we can use the node's name as the transform name. We should
think about naming conflicts: when calling @tc[n], should it insert a link
request for the transform, or should it create an incomplete node?
@subsection[#:tag "complex-transforms-return-type-conclusion"]{Conclusion}
@subsection[#:tag "graph|complex-transforms-return-type-conclusion"]{Conclusion}
With this approach, we can write the graph creation macro with the guaranty
that the result of a transform always is exactly one node type. More complex

20
graph/graph/queue.lp2.rkt
View File

@ -13,15 +13,15 @@ the list being processed. In other words, we want to apply a @tc[lambda] to all
elements inside a queue, with the possibility to return new elements that should
be added to the queue.
We will first define a general version in section @secref{sec:general}, where
We will first define a general version in section @secref{queue|general}, where
most implementation details are parametrizable. We then use this as a building
block to define more specialized version, for example the section
@secref{sec:sets-add} defines a version where the queue is a set, and elements
@secref{queue|sets-add} defines a version where the queue is a set, and elements
can only be added to the queue, not removed (therefore the @tc[lambda] is
expected to return only the elements to be added, and not the ones already
present in the queue).
@section[#:tag "sec:general"]{General version}
@section[#:tag "queue|general"]{General version}
Since both lists, sets and other structures could be used to represent the
queue, we don't specify them here, and instead take the @tc[dequeue] and
@ -35,10 +35,10 @@ result for this element with the remaining ones, either by constructing the
overall result in the @tc[accumulator], or by using the value returned by
@tc[rec].
The former case is shown in section @secref{sec:tail-call-reverse-map}, where
The former case is shown in section @secref{queue|tail-call-reverse-map}, where
each element's result is combined with the accumulator using @tc[cons], whereas
the latter case is shown in @secref{sec:map}, where the result for an element is
combined with @tc[cons] to what @tc[process-rest] will return.
the latter case is shown in @secref{queue|map}, where the result for an element
is combined with @tc[cons] to what @tc[process-rest] will return.
The lambda @tc[process] takes four parameters: the @tc[element] to process, the
current accumulator, current queue, and a function to call recursively with the
@ -76,7 +76,7 @@ some of those need to be deleted before being processed).
(% element rest-queue = (dequeue queue)
(process element accumulator rest-queue process-rest)))))]
@section[#:tag "sec:map"]{@racket[map]}
@section[#:tag "queue|map"]{@racket[map]}
Here is a version that behaves like @tc[map] on the queue, returning a list of
the result of @tc[process] on the queue's elements, in the order in which they
@ -116,8 +116,8 @@ be discarded once all elements have been processed), and the @tc[new-queue].
(→ Element Accumulator Queue (→ Queue Accumulator (Listof Result))
(Listof Result)))]
@section[#:tag "sec:tail-call-reverse-map"]{Tail-call @racket[map], with results
in reverse order}
@section[#:tag "queue|tail-call-reverse-map"]{Tail-call @racket[map], with
results in reverse order}
@chunk[<tail-call-reverse-map-queue>
(: tail-call-reverse-map-queue
@ -153,7 +153,7 @@ be discarded once all elements have been processed), and the @tc[new-queue].
(→ Element RAccumulator Queue (→ Queue RAccumulator (Listof Result))
(Listof Result)))]
@section[#:tag "sec:sets-add"]{Variant using sets}
@section[#:tag "queue|sets-add"]{Variant using sets}
We define in this section a fold over queues represented using sets. This
version also disallows removing elements from the queue by making the union of

23
graph/graph/rewrite-type.lp2.rkt
View File

@ -5,7 +5,7 @@
@title[#:style manual-doc-style]{Rewriting data structures and their types}
@section[#:tag "sec:intro-example"]{Introductory example}
@section[#:tag "rewrite-type|intro-example"]{Introductory example}
This module allows purely functional substitution inside a data structure of
arbitrarily deep elements of a given type, while also computing the type of the
result.
@ -75,7 +75,7 @@ return type containing no more strings, and the correct return value.
Number)))
'(((tag2 (#(sym) 7 (2 3 4))) . 1)))]
@section[#:tag "sec:replace-in-type"]{Replacing parts of a type}
@section[#:tag "rewrite-type|replace-in-type"]{Replacing parts of a type}
The @tc[replace-in-type] @tc[for-syntax] function is pretty straightforward: it
checks whether the given type matches one of the substitution rules given in
@ -125,13 +125,14 @@ The other cases use @tc[~literal] and a syntax pattern to find uses of
TODO: If the type is a quoted primitive, we should replace it too, for example
@tc['("abc" symbol)] should be transformed into @tc['(3 symbol)] if we apply the
@tc[[String Number string-length]] substitution from the example in section
@secref{sec:intro-example}.
@secref{rewrite-type|intro-example}.
@CHUNK[<replace-in-type-case-quote>
[((~literal quote) a)
#`(quote a)]]
@section[#:tag "sec:replace-in-instance"]{Replacing parts of an instance}
@section[#:tag "rewrite-type|replace-in-instance"]{Replacing parts of an
instance}
The @tc[replace-in-instance] for-syntax function is defined in a similar way,
with an internal definition for @tc[recursive-replace]. The case of unions is
@ -251,7 +252,7 @@ detail in the
"Rethink-how-to-do-the-multi-step-types-more-inside")]
{FogBugz case 54}.
@section[#:tag "sec:fold"]{Folding over an instance}
@section[#:tag "rewrite-type|fold"]{Folding over an instance}
Replacing parts of an instance may require first extracting them. We define here
a general fold over some data structures, that allows the replacement function
@ -532,12 +533,12 @@ type.
@section{Replacing parts of an instance using fold}
We can use the @tc[fold-instance] for-syntax function defined in section
@secref{sec:fold} as a building block to write a new, simpler definition of the
@tc[replace-in-instance] for-syntax function defined in section
@secref{sec:replace-in-instance}. This method should give better consistency
between the behaviour of @tc[replace-in-instance] and @tc[fold-instance] as well
as better maintainability, but is slightly less efficient than the separate
implementation.
@secref{rewrite-type|fold} as a building block to write a new, simpler
definition of the @tc[replace-in-instance] for-syntax function defined in
section @secref{rewrite-type|replace-in-instance}. This method should give
better consistency between the behaviour of @tc[replace-in-instance] and
@tc[fold-instance] as well as better maintainability, but is slightly less
efficient than the separate implementation.
@CHUNK[<replace-in-instance2>
(define-for-syntax (replace-in-instance2 val t r)

15
graph/graph/structure.lp2.rkt
View File

@ -9,7 +9,7 @@
@section{@racket[define-structure]}
Structures are represented using regular racket @tc[struct]s, see
@seclink["structures" #:doc "type-system.scrbl"]{the overview document}.
@seclink["type-system|structures"]{the overview document}.
@;secref["structures" #:doc "type-system.scrbl"].
@chunk[<structure>
@ -90,11 +90,11 @@ We wish to pre-declare all @tc[struct] types for various reasons:
In order to pre-declare the @tc[struct]s, we need to remember them across
compilations, for that we use @tc[remember-all] and @tc[get-remembered] defined
below in section @secref{remember}. We then need to make these identifiers
available in the correct syntax scope. The easiest way to do that, is to have a
private macro @tc[(declare-all-structs (name field ...) ...)] which does all the
required definitions, namely defining the struct, as well as @tc[make-struct],
@tc[get-field], and the match-expander eventually.
below in section @secref{structure|remember}. We then need to make these
identifiers available in the correct syntax scope. The easiest way to do that,
is to have a private macro @tc[(declare-all-structs (name field ...) ...)] which
does all the required definitions, namely defining the struct, as well as
@tc[make-struct], @tc[get-field], and the match-expander eventually.
We do not wish to remember the type of each field, as they may be a non-exported
identifier from some module. It should not cause any problem when declaring the
@ -343,7 +343,8 @@ instead of needing an extra recompilation.
b)
"b")]
@section[#:tag "remember"]{Closed-world assumption and global compilation}
@section[#:tag "structure|remember"]{Closed-world assumption and global
compilation}
In order to be able to access elements in the list as deep as they can be, we
need to know the length of the longest structure used in the whole program.

2
graph/graph/type-system.scrbl
View File

@ -6,7 +6,7 @@
@;(table-of-contents)
@section[#:tag "structures"]{Structures}
@section[#:tag "type-system|structures"]{Structures}
@;(+ 1 2 3) gives @(format "~a" (+ 1 2 3)).

4
graph/lib/doc/example.lp2.rkt
View File

@ -14,9 +14,9 @@
@section{A section}
In section @secref{sec:foo} we present, blah blah.
In section @secref{doc/example|foo} we present, blah blah.
@subsection[#:tag "sec:foo"]{My subsection}
@subsection[#:tag "doc/example|foo"]{My subsection}
@$${\frac{2x}{x^2}}
@(colorize (filled-ellipse 30 15) "blue")

2
graph/make/make.rkt
View File

@ -159,11 +159,13 @@
[html html-files])
(html)
(scrbl-or-lp2)
;; TODO: compile twice, so that the cross-references are correct
(scribble scrbl-or-lp2 doc-sources "--html"))
(for/rules ([scrbl-or-lp2 doc-sources]
[pdf pdf-files])
(pdf)
(scrbl-or-lp2)
;; TODO: compile twice, so that the cross-references are correct
(scribble scrbl-or-lp2 doc-sources "--pdf"))
(for/rules ([mathjax-link mathjax-links])
(mathjax-link)

9
graph/type-expander/type-expander.lp2.rkt
View File

@ -260,7 +260,7 @@ Shadowing and @tc[∀] variables:
Througout this section, we provide alternative definitions of the
@tc[typed/racket] forms @tc[:], @tc[lambda], @tc[define], @tc[struct], @tc[ann],
@tc[inst]… . We write these definitions with @tc[syntax-parse], using the syntax
classes defined in section @secref{syntax-classes}.
classes defined in section @secref{type-expander|syntax-classes}.
Most of the time, we will use the experimental @tc[template] macro from
@tc[syntax/parse/experimental/template] which allows more concise code than the
@ -286,7 +286,7 @@ after expanding the type argument.
(: c0 `(2 "abc" #,,(Pairof (U 'x 'y) (U 'y 'z)) #(1 "b" x) d))
(define c0 '(2 "abc" #,(x . z) #(1 "b" x) d))]
@subsection[#:tag "syntax-classes"]{syntax classes}
@subsection[#:tag "type-expander|syntax-classes"]{syntax classes}
The syntax classes from @tc[typed-racket/base-env/annotate-classes] match
against the @tc[:] literal. Since we provide a new definition for it, the syntax
@ -674,7 +674,8 @@ them.
(check-equal? ((make-predicate (Repeat Number 3)) '(1 2 3)) #t)
(check-equal? ((make-predicate (Repeat Number 3)) '(1 "b" 3)) #f))]
@subsection[#:tag "other-forms"]{Other @racket[typed/racket] forms}
@subsection[#:tag "type-expander|other-forms"]{Other @racket[typed/racket]
forms}
The other @tc[typed/racket] forms below do not have an alternative definition
yet.
@ -784,7 +785,7 @@ yet.
@section{Future work}
We have not implemented alternative type-expanding definitions for all the
@tc[typed/racket] forms, as noted in @secref{other-forms}.
@tc[typed/racket] forms, as noted in @secref{type-expander|other-forms}.
Integrating the type-expander directly into typed/racket would avoid the need to
provide such definitions, and allow using type-expanders in vanilla