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
Amirouche Boubekki
(06 Mar 2021 09:47 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
Jakub T. Jankiewicz
(20 Aug 2021 21:03 UTC)
|
Re: Syntax extensions
Marc Nieper-Wißkirchen
(20 Aug 2021 21:18 UTC)
|
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