mirror of
https://git.savannah.gnu.org/git/guile.git
synced 2025-04-30 20:00:19 +02:00
reformat comments
* module/language/elisp/bindings.scm: * module/language/elisp/compile-tree-il.scm: * module/language/elisp/lexer.scm: * module/language/elisp/parser.scm: * module/language/elisp/runtime.scm: * module/language/elisp/runtime/function-slot.scm: * module/language/elisp/runtime/macro-slot.scm: * module/language/elisp/runtime/value-slot.scm: Reformat comments.
This commit is contained in:
parent
372b11fc73
commit
27b9476a8d
8 changed files with 478 additions and 450 deletions
|
@ -2,19 +2,20 @@
|
|||
|
||||
;;; Copyright (C) 2009 Free Software Foundation, Inc.
|
||||
;;;
|
||||
;;; This library is free software; you can redistribute it and/or
|
||||
;;; modify it under the terms of the GNU Lesser General Public
|
||||
;;; License as published by the Free Software Foundation; either
|
||||
;;; version 3 of the License, or (at your option) any later version.
|
||||
;;; This library is free software; you can redistribute it and/or modify
|
||||
;;; it under the terms of the GNU Lesser General Public License as
|
||||
;;; published by the Free Software Foundation; either version 3 of the
|
||||
;;; License, or (at your option) any later version.
|
||||
;;;
|
||||
;;; This library is distributed in the hope that it will be useful,
|
||||
;;; but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
||||
;;; This library is distributed in the hope that it will be useful, but
|
||||
;;; WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
||||
;;; Lesser General Public License for more details.
|
||||
;;;
|
||||
;;; You should have received a copy of the GNU Lesser General Public
|
||||
;;; License along with this library; if not, write to the Free Software
|
||||
;;; Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
|
||||
;;; Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
|
||||
;;; 02110-1301 USA
|
||||
|
||||
;;; Code:
|
||||
|
||||
|
@ -22,28 +23,28 @@
|
|||
#:use-module (language elisp lexer)
|
||||
#:export (read-elisp))
|
||||
|
||||
; The parser (reader) for elisp expressions.
|
||||
; Is is hand-written (just as the lexer is) instead of using some parser
|
||||
; generator because this allows easier transfer of source properties from the
|
||||
; lexer ((text parse-lalr) seems not to allow access to the original lexer
|
||||
; token-pair) and is easy enough anyways.
|
||||
;;; The parser (reader) for elisp expressions. Is is hand-written (just
|
||||
;;; as the lexer is) instead of using some parser generator because this
|
||||
;;; allows easier transfer of source properties from the lexer ((text
|
||||
;;; parse-lalr) seems not to allow access to the original lexer
|
||||
;;; token-pair) and is easy enough anyways.
|
||||
|
||||
; Report a parse error. The first argument is some current lexer token
|
||||
; where source information is available should it be useful.
|
||||
;;; Report a parse error. The first argument is some current lexer token
|
||||
;;; where source information is available should it be useful.
|
||||
|
||||
(define (parse-error token msg . args)
|
||||
(apply error msg args))
|
||||
|
||||
; For parsing circular structures, we keep track of definitions in a
|
||||
; hash-map that maps the id's to their values.
|
||||
; When defining a new id, though, we immediatly fill the slot with a promise
|
||||
; before parsing and setting the real value, because it must already be
|
||||
; available at that time in case of a circular reference. The promise refers
|
||||
; to a local variable that will be set when the real value is available through
|
||||
; a closure. After parsing the expression is completed, we work through it
|
||||
; again and force all promises we find.
|
||||
; The definitions themselves are stored in a fluid and their scope is one
|
||||
; call to read-elisp (but not only the currently parsed expression!).
|
||||
;;; For parsing circular structures, we keep track of definitions in a
|
||||
;;; hash-map that maps the id's to their values. When defining a new id,
|
||||
;;; though, we immediatly fill the slot with a promise before parsing
|
||||
;;; and setting the real value, because it must already be available at
|
||||
;;; that time in case of a circular reference. The promise refers to a
|
||||
;;; local variable that will be set when the real value is available
|
||||
;;; through a closure. After parsing the expression is completed, we
|
||||
;;; work through it again and force all promises we find. The
|
||||
;;; definitions themselves are stored in a fluid and their scope is one
|
||||
;;; call to read-elisp (but not only the currently parsed expression!).
|
||||
|
||||
(define circular-definitions (make-fluid))
|
||||
|
||||
|
@ -59,9 +60,9 @@
|
|||
value
|
||||
(parse-error token "undefined circular reference" id))))
|
||||
|
||||
; Returned is a closure that, when invoked, will set the final value.
|
||||
; This means both the variable the promise will return and the hash-table
|
||||
; slot so we don't generate promises any longer.
|
||||
;;; Returned is a closure that, when invoked, will set the final value.
|
||||
;;; This means both the variable the promise will return and the
|
||||
;;; hash-table slot so we don't generate promises any longer.
|
||||
|
||||
(define (circular-define! token)
|
||||
(if (not (eq? (car token) 'circular-def))
|
||||
|
@ -74,11 +75,12 @@
|
|||
(set! value real-value)
|
||||
(hashq-set! table id real-value))))
|
||||
|
||||
; Work through a parsed data structure and force the promises there.
|
||||
; After a promise is forced, the resulting value must not be recursed on;
|
||||
; this may lead to infinite recursion with a circular structure, and
|
||||
; additionally this value was already processed when it was defined.
|
||||
; All deep data structures that can be parsed must be handled here!
|
||||
;;; Work through a parsed data structure and force the promises there.
|
||||
;;; After a promise is forced, the resulting value must not be recursed
|
||||
;;; on; this may lead to infinite recursion with a circular structure,
|
||||
;;; and additionally this value was already processed when it was
|
||||
;;; defined. All deep data structures that can be parsed must be handled
|
||||
;;; here!
|
||||
|
||||
(define (force-promises! data)
|
||||
(cond
|
||||
|
@ -99,15 +101,15 @@
|
|||
(vector-set! data i (force el))
|
||||
(force-promises! el))
|
||||
(iterate (1+ i)))))))
|
||||
; Else nothing needs to be done.
|
||||
;; Else nothing needs to be done.
|
||||
))
|
||||
|
||||
; We need peek-functionality for the next lexer token, this is done with some
|
||||
; single token look-ahead storage. This is handled by a closure which allows
|
||||
; getting or peeking the next token.
|
||||
; When one expression is fully parsed, we don't want a look-ahead stored here
|
||||
; because it would miss from future parsing. This is verified by the finish
|
||||
; action.
|
||||
;;; We need peek-functionality for the next lexer token, this is done
|
||||
;;; with some single token look-ahead storage. This is handled by a
|
||||
;;; closure which allows getting or peeking the next token. When one
|
||||
;;; expression is fully parsed, we don't want a look-ahead stored here
|
||||
;;; because it would miss from future parsing. This is verified by the
|
||||
;;; finish action.
|
||||
|
||||
(define (make-lexer-buffer lex)
|
||||
(let ((look-ahead #f))
|
||||
|
@ -127,12 +129,12 @@
|
|||
result))
|
||||
(else (error "invalid lexer-buffer action" action))))))))
|
||||
|
||||
; Get the contents of a list, where the opening parentheses has already been
|
||||
; found. The same code is used for vectors and lists, where lists allow the
|
||||
; dotted tail syntax and vectors not; additionally, the closing parenthesis
|
||||
; must of course match.
|
||||
; The implementation here is not tail-recursive, but I think it is clearer
|
||||
; and simpler this way.
|
||||
;;; Get the contents of a list, where the opening parentheses has
|
||||
;;; already been found. The same code is used for vectors and lists,
|
||||
;;; where lists allow the dotted tail syntax and vectors not;
|
||||
;;; additionally, the closing parenthesis must of course match. The
|
||||
;;; implementation here is not tail-recursive, but I think it is clearer
|
||||
;;; and simpler this way.
|
||||
|
||||
(define (get-list lex allow-dot close-square)
|
||||
(let* ((next (lex 'peek))
|
||||
|
@ -152,13 +154,13 @@
|
|||
(parse-error next "expected exactly one element after dot"))
|
||||
(car tail))))
|
||||
(else
|
||||
; Do both parses in exactly this sequence!
|
||||
;; Do both parses in exactly this sequence!
|
||||
(let* ((head (get-expression lex))
|
||||
(tail (get-list lex allow-dot close-square)))
|
||||
(cons head tail))))))
|
||||
|
||||
; Parse a single expression from a lexer-buffer. This is the main routine in
|
||||
; our recursive-descent parser.
|
||||
;;; Parse a single expression from a lexer-buffer. This is the main
|
||||
;;; routine in our recursive-descent parser.
|
||||
|
||||
(define quotation-symbols '((quote . quote)
|
||||
(backquote . \`)
|
||||
|
@ -184,7 +186,7 @@
|
|||
((circular-ref)
|
||||
(circular-ref token))
|
||||
((circular-def)
|
||||
; The order of definitions is important!
|
||||
;; The order of definitions is important!
|
||||
(let* ((setter (circular-define! token))
|
||||
(expr (get-expression lex)))
|
||||
(setter expr)
|
||||
|
@ -193,9 +195,9 @@
|
|||
(else
|
||||
(parse-error token "expected expression, got" token)))))
|
||||
|
||||
; Define the reader function based on this; build a lexer, a lexer-buffer,
|
||||
; and then parse a single expression to return.
|
||||
; We also define a circular-definitions data structure to use.
|
||||
;;; Define the reader function based on this; build a lexer, a
|
||||
;;; lexer-buffer, and then parse a single expression to return. We also
|
||||
;;; define a circular-definitions data structure to use.
|
||||
|
||||
(define (read-elisp port)
|
||||
(with-fluids ((circular-definitions (make-circular-definitions)))
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue