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@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