Hi,

I would refresh the conversion with new ideas, The last issue that was
against syntax extensions that I've proposed was that it may be conflicting
with libraries.

When looking at: https://doc.scheme.org/surveys/KeywordSyntax/

Keyword syntax that my Scheme have as syntax extension (mostly as example)
look the same #:foo but the syntax just return new gensym:

(set-special! "#:" 'gensym-interal)

(define (gensym-interal symbol)
  "(gensym-interal symbol)

   Parser extension that create new quoted named gensym."
  `(quote ,(gensym symbol)))

And I was wondering how to define library that will import different syntax.
And the simplest solution is to defined new syntax for import.
There few composable rules for import and export in R7RS What about we
introduce new rules on top of exiting and make them composable.

(import (syntax (lips core) "#:"))

just an example this will import only the syntax, or syntax and whole
library. I'm fine with any solution.

Then for instance if this SRFI is supported the library can implement byte
vectors that are not supported and to import bytevectors you use:

(import (syntax (foo bytevectors) "#u8" "#u16" ...)
        (foo bytevectors))

This will import whole library including new syntax. To make this shorter the
syntax can be (only-syntax ...) and (with-syntax ...) and (except-syntax ...)

On Fri, 5 Mar 2021 21:44:06 +0100
"Jakub T. Jankiewicz" <xxxxxx@onet.pl> wrote:

> 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