[gambit-list] {Spam?} (Marc + ML:) Extension/patch feedback & inclusion request: Practical custom types in the sexp reader (finally)

Adam adam.mlmb at gmail.com
Mon Feb 22 16:06:16 EST 2016


Marc & list,

Before getting into a specific response, I wish to re-emphasise the high
priority I feel this topic has. So better something now than something
slightly more perfect in couple years.

2016-02-23 2:57 GMT+07:00 Marc Feeley <feeley at iro.umontreal.ca>:

> There are two things I don’t like about this extension to the reader.  The
> implementation unconditionnaly throws away the location information (the
> “unwrap”) that could be useful if the form being read contains code.  I
> understand that this is probably what you want when the form is treated as
> a literal constant, but this is not always the case.
>

I agree that could be useful. Perhaps unwrapping could be exposed to the
user too, via an argument (do-you-want-the-value-unwrapped?) and/or
traversal routines (access-this-or-that-slot-in-the-wrapped-object).


> Also, it opens the door to add custom syntax that may clash with future
> extensions to Gambit's lexical syntax.  While it is good to have hooks to
> extend Gambit, it would be good if such extensions have some support from
> the community (in other words, do other people think this is the best way
> to extend the lexical syntax).
>

Sure.

We (you+community) are the ones to make up our minds about this now.

The clashing problem shouldn't be too bad though - the sexp format is set
in stone already. So I guess the worst thing would be if Gambit would
introduce some extension later, that an individual user would get to a
place of NOT wanting to overlap at the time then, and so hence his need to
remap that new Gambit feature to another hash sequence in order to be able
to use it, and that would cause suffering, confusion etc. for that
particular user and all his followers, then -

That's the problem surface (and also not worse than that).


> I remember SRFI 10, which is an extension to the lexical syntax with
> similar goals, and also the JazzScheme syntax for literal constants, i.e.
> {typename …}.  Perhaps something like that would be better to avoid a
> proliferation of different syntaxes for the same thing.


What options do we have on the table?

I like the "#C(typename slot1 slot2 ...)" form (with a simpler "#Cdatum"
variant).

My patch leaves the C letter to be chosen by the user, so also it could be
used to implement regexp forms e.g. #/regexp/ , etc., so it has a more
wide, general utility.

Also there are interesting “bootstrapping” issues such as the need to
> define the type before using the extended lexical syntax.  It would be nice
> if literal constants could be used in the same file that defines the types
> (i.e. no phasing problem).
>

Sure. But wait, can't you extract the current input port and from that in
turn the readtable - so at least as long as the custom form is installed
using |##readtable-char-sharp-handler-set!|, then there is in actuality no
problem?



Personally I think my thought highlighted in red above creates a rather
strong, wider argument for that something functionally like I suggest
should be introduced, even if perhaps it won't be used primarily for custom
types later on - and the blue text perhaps reinforces that additionally. So
like to sum it up it has a general purpose and it's simple.


The bigger question on this topic perhaps is what I highlighted in yellow
above, that is, what options do we have at hand for syntaxes for
used-defined sexp extensions?

Do you feel that we should give a look at that before making up our minds
about this particular?


Also, do you have any thoughts on how the wrapping aspect can be addressed
(purple)?


Would be great if we could clarify this point within 3 weeks from now :D

Thanks :D
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.iro.umontreal.ca/pipermail/gambit-list/attachments/20160223/8ee4db1a/attachment.htm>


More information about the Gambit-list mailing list