Syntax extensions
Jakub T. Jankiewicz
(05 Mar 2021 20:44 UTC)
|
Re: Syntax extensions
Marc Nieper-Wißkirchen
(06 Mar 2021 09:10 UTC)
|
Re: Syntax extensions Amirouche Boubekki (06 Mar 2021 09:23 UTC)
|
Re: Syntax extensions
Jakub T. Jankiewicz
(06 Mar 2021 14:26 UTC)
|
Re: Syntax extensions
Marc Nieper-Wißkirchen
(06 Mar 2021 14:43 UTC)
|
Re: Syntax extensions
Jakub T. Jankiewicz
(06 Mar 2021 16:03 UTC)
|
Re: Syntax extensions
Marc Nieper-Wißkirchen
(06 Mar 2021 16:20 UTC)
|
Re: Syntax extensions
Marc Nieper-Wißkirchen
(07 Mar 2021 22:08 UTC)
|
Re: Syntax extensions
Jakub T. Jankiewicz
(08 Mar 2021 07:47 UTC)
|
Re: Syntax extensions
Marc Nieper-Wißkirchen
(08 Mar 2021 08:25 UTC)
|
Re: Syntax extensions
John Cowan
(15 Mar 2021 02:54 UTC)
|
Re: Syntax extensions
Jakub T. Jankiewicz
(15 Mar 2021 08:01 UTC)
|
Re: Syntax extensions
Marc Nieper-Wißkirchen
(15 Mar 2021 15:53 UTC)
|
Re: Syntax extensions
Adam Nelson
(16 Mar 2021 12:07 UTC)
|
Re: Syntax extensions
Marc Nieper-Wißkirchen
(16 Mar 2021 12:50 UTC)
|
Re: Syntax extensions
Jakub T. Jankiewicz
(16 Mar 2021 16:37 UTC)
|
Re: Syntax extensions
Marc Nieper-Wißkirchen
(16 Mar 2021 17:12 UTC)
|
Re: Syntax extensions
Jakub T. Jankiewicz
(16 Mar 2021 17:31 UTC)
|
Re: Syntax extensions
Marc Nieper-Wißkirchen
(16 Mar 2021 19:53 UTC)
|
Re: Syntax extensions
John Cowan
(18 Mar 2021 20:10 UTC)
|
Re: Syntax extensions
Marc Nieper-Wißkirchen
(18 Mar 2021 21:36 UTC)
|
Re: Syntax extensions
John Cowan
(19 Mar 2021 04:18 UTC)
|
Re: Syntax extensions
Marc Nieper-Wißkirchen
(19 Mar 2021 06:43 UTC)
|
Re: Syntax extensions
Jakub T. Jankiewicz
(19 Mar 2021 08:04 UTC)
|
Re: Syntax extensions
Marc Nieper-Wißkirchen
(19 Mar 2021 08:12 UTC)
|
Re: Syntax extensions
Marc Nieper-Wißkirchen
(15 Mar 2021 15:42 UTC)
|
Re: Syntax extensions
John Cowan
(18 Mar 2021 00:38 UTC)
|
Re: Syntax extensions
Marc Nieper-Wißkirchen
(18 Mar 2021 06:36 UTC)
|
Re: Syntax extensions
Amirouche Boubekki
(06 Mar 2021 09:47 UTC)
|
Re: Syntax extensions
Jakub T. Jankiewicz
(20 Aug 2021 21:03 UTC)
|
Re: Syntax extensions
Marc Nieper-Wißkirchen
(20 Aug 2021 21:18 UTC)
|
Le sam. 6 mars 2021 à 10:10, Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> a écrit : > > It's not at all clear to me how the special forms you suggest fit into the RnRS scheme model of reading, expanding, and executing a program (with libraries). > > Can you explain the semantics in detail? Say for a file containing "specials" like `#:` that is read through the `read` procedure. When is `set-special!` evaluated and how and when do the implied reader extensions apply? > If a program.scm contains `set-special!` and use that reader extension defined in the very same file, how does it work or how can it be implemented? > -- Marc > > Am Fr., 5. März 2021 um 21:44 Uhr schrieb Jakub T. Jankiewicz <xxxxxx@onet.pl>: >> >> Hi, >> >> I plan to work on new SRFI I would know what you think about my idea. >> I've already implemented first idea in my Scheme based lisp called LIPS >> written in JavaScript. >> >> The feature I want to work on is called syntax extensions is the way to add >> new syntax like build in , ' ` ,@ that work exactly the same, that would >> allow users to modify the parser/reader. The feature work similar to >> compiler extensions in Common Lisp. You define the mapping - string of one or >> more characters and symbol for a function or macro that will be called when >> parser/reader will read the token with S-Expression that immediately follow >> the token. >> >> Example from my own code: >> >> (set-special! "#:" 'gensym-interal) >> >> (define (gensym-interal symbol) >> "(gensym-interal symbol) >> >> Parser extension that create new quoted named gensym." >> `(quote ,(gensym symbol))) >> >> If gensym function is defined (most Scheme implementation support this or >> other similar function together with lisp macros). >> >> If you execute #:foo it will return unique gensym symbol. >> >> With this you can implement lot of features that are already in R7RS spec or >> in other SRFI documents. The syntax can be simplified to have single >> expression that define prefix and function. But I think this is better >> because you have normal function that can also be used elsewhere not only in >> parser. >> >> Another example is alias for quotation: >> >> (set-special! "’" 'quote) >> >> and this will allow to run every example in R7RS pdf that have different >> quote character that throw syntax error when copy pasting. >> >> Another use is to implement SRFI-10, vectors, byte vectors or >> All types of Typed vectors that I've found in this document: >> >> https://small.r7rs.org/wiki/NumericVectorsCowan/17/ >> >> In my implementation I also have complementary feature that all to add >> string representation for objects. They are JavaScript objects so I just check >> the type. >> >> Example: >> >> (set-repr! Uint8Array (lambda (x) >> (string-append "#u8" (repr (u8vector->list x))))) >> >> This is code based on my standard library (in my code I have one big macro >> that define all different types from Numeric vectors by Cowan) that add >> support for printing byte vectors as "#u8(...)" which make the data type >> transparent to read and write. >> >> My implementation is kind of special because it's interpreter created in >> other runtime dynamic language (JavaScript). But this can be extended into >> records or different generic data types that can be easily identify by >> Scheme system. >> >> Why this is useful (if you don't think that it's useful already). >> It's because if this type of extensions are supported by the language (in >> form of SRFI) library can create missing syntax that are in other SRFI or >> future versions of Scheme. It can be useful to add new syntax. Of course >> the same as with macros or even more you should use those only when >> necessary, that would make the code simpler and easier to read. >> >> Those can be two different SRFI, the second (set-repr!) can be defined as a >> way to define representation for records that are new data type defined by >> R7RS, but can be left for implementers to add different objects >> that the Scheme system allow users to define, basic support can be for >> records. >> >> With records one can define their own list type (like example from R7RS >> document) >> >> (define-record-type <pare> >> (kons x y) >> pare? >> (x kar set-kar!) >> (y kdr)) >> >> (set-special! "<>" 'k-list) >> >> (define (k-list rest) >> (fold-left kons nil rest)) >> >> >> (define (type->string x) >> (if (pare? x) >> (pare->string x) >> (let ((p (open-output-string))) >> (write x p) >> (get-output-string p)))) >> >> (define (pare->string pare) >> (if (pare? pare) >> (string-append "<>(" (pare->join pare) ")") >> (type->string x))) >> >> >> (define (pare->join pare) >> (if (pare? pare) >> (string-append (type->string (kar pare)) >> (if (pare? (kdr pare)) " " "") >> (pare->join (kdr pare))) >> "")) >> >> >> Usage: >> >> (print (pare->string (kons 1 (kons 2 nil)))) >> (print (pare->string <>(1 2 3 4))) >> >> and if set-repr! support records (in my implementation as I've said it only >> support JavaScript instances, but this is something I can easily add) >> the only thing that left is that you can execute this: >> >> (set-repr! <pare> pare->string) >> >> and you have fully working transparent new data type. >> >> Unfortunately you can't add support for <1 2 3> as representation and to make >> this align better with other SRFI we can suggest users to use # prefix for >> user data types, but I think that this should be only suggestion. User should >> be allowed to use any syntax he want. >> >> I want to know what you think about those proposals. I've already talk with >> Arthur A. Gleckler and he suggested that I should mention this here. >> >> -- >> Jakub T. Jankiewicz, Web Developer >> https://jcubic.pl/me >> -- Amirouche ~ https://hyper.dev