On Tue, Mar 12, 2019 at 7:02 PM Arthur A. Gleckler <xxxxxx@speechcode.com> wrote:
> On Tue, Mar 12, 2019 at 6:22 AM Lassi Kortela <xxxxxx@lassi.io> wrote:
>> Personally, I'm pleased with the way this format turned out and would
>> consider it almost done for publication. If you want any changes or
>> additions, please don't hesitate to say so :)

@Lassi I don't know what is your intended timeline for this project,
but I would take a more "thorough" approach...  I would say that
before we actually submit something for "ratification", we take our
time to experiment, design, and implement the required tools.

(Given that I don't work full time in Scheme, but I touched this
subject when I implemented my own Scheme interpreter in Rust -- a
project that is now "paused" -- this is more a hobby/side-project or
an academic endeavor for me.  As is I guess everyone's involvement in
SRFI.  Therefore any realistic timeline should also take this into
account.)

I say this, because if we are to "modify" anything in the SRFI
process, I think it should be done only once (else it would lose
credibility and traction).  Thus we should have everything
"integrated" before we start going through old SRFI documents and
propose the new process.

> Could you and Ciprian work together on coming up with a proposed format that would satisfy your combined goals?  The idea would be to encode all the information your code is already able to extract, in addition to the manually added category information, while being extensible to support the more detailed type information, for example, that Ciprian envisions.  There's no need to specify exactly how that detailed type information, etc. would be encoded — just how a place would be held in the format so that it could be added later.

I think the "how" is very important, especially given typing
information.  How would for example one handle `range-length` type
definition (i.e. an exact integer that is positive or zero)?  Should
this type be re-defined in each SRFI that might use one?  Should it be
defined as part of an R7RS stub?  (How about SRFI's that don't target
R7RS?)

Therefore the "devil is in the details"...  Just saying that "a place
would be held in the format" is not enough, as these SRFI's
cross-reference each-other.

> I'm happy to participate in the discussion, too, and to have other people contribute as well.  But you both have thought about this carefully, so it would be nice to have you two take the lead.
>
> What do you both think?

As said above, at least for me, my time is quite limited on this
project and it would take some while for me to go through my
"experiment".  At the same time I could try to "document" my proposed
signature format.  However as said above we should take our time to
make sure everything "clicks" before we move to pushing this as a
"proposal".  I also propose that this experimental process should be
done in the open, perhaps on this mailing list if there are no
objections.

Ciprian.