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)

Syntax extensions Jakub T. Jankiewicz 05 Mar 2021 20:44 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