Email list hosting service & mailing list manager

Fwd: Re: Want to kickstart the Scheme API already? Frank Ruben (24 Apr 2019 18:06 UTC)
Re: Want to kickstart the Scheme API already? Frank Ruben (28 Apr 2019 06:52 UTC)
Re: Want to kickstart the Scheme API already? Frank Ruben (28 Apr 2019 07:06 UTC)
Re: Want to kickstart the Scheme API already? Lassi Kortela (28 Apr 2019 10:09 UTC)
Re: Want to kickstart the Scheme API already? Lassi Kortela (28 Apr 2019 10:20 UTC)
Re: Want to kickstart the Scheme API already? Frank Ruben (28 Apr 2019 12:12 UTC)
Re: Want to kickstart the Scheme API already? Lassi Kortela (28 Apr 2019 14:16 UTC)
Re: Want to kickstart the Scheme API already? Frank Ruben (28 Apr 2019 14:44 UTC)
Re: Want to kickstart the Scheme API already? Lassi Kortela (28 Apr 2019 15:26 UTC)
Re: Want to kickstart the Scheme API already? Frank Ruben (28 Apr 2019 15:50 UTC)
Re: Want to kickstart the Scheme API already? Lassi Kortela (28 Apr 2019 15:57 UTC)
Re: Want to kickstart the Scheme API already? Frank Ruben (28 Apr 2019 12:47 UTC)
Re: Want to kickstart the Scheme API already? Lassi Kortela (28 Apr 2019 14:04 UTC)
Fwd: Re: Want to kickstart the Scheme API already? Frank Ruben (06 May 2019 16:50 UTC)
Re: Fwd: Re: Want to kickstart the Scheme API already? Lassi Kortela (06 May 2019 18:20 UTC)
Re: Fwd: Re: Want to kickstart the Scheme API already? Frank Ruben (06 May 2019 18:54 UTC)
Re: Fwd: Re: Want to kickstart the Scheme API already? Lassi Kortela (06 May 2019 19:18 UTC)
(missing)
Re: Fwd: Re: Want to kickstart the Scheme API already? Lassi Kortela (06 May 2019 20:11 UTC)

Re: Fwd: Re: Want to kickstart the Scheme API already? Lassi Kortela 06 May 2019 20:11 UTC

>     Is it that simple though?
>
> Nope, sadly not - so that "something better over time..." can be very
> much later ;)
>
>     Or do you have some scenario in mind where the tables would take too
>     much memory and it would be better to have just the rules on the
>     client side?
>
> I didn't yet think about the memory part, but I would hope that we can
> move most of the complexity out of the client and into the API-server.

> I'll try to find a syntax/API, to support not only plain
> string-concatenation, but some alternative using a mapping. And no need
> to change the files in the repo in the meantime.

Would something simple like this work (adapted straight from the URLs in
the Gauche symbol index):

(symbol-base-url "https://practical-scheme.net/gauche/man/gauche-refe/")

(symbol %macroexpand
   (url "Macro-expansion.html#index-_0025macroexpand"))
(symbol %macroexpand-1
   (url "Macro-expansion.html#index-_0025macroexpand_002d1"))
(symbol (setter cgi-test-enviornment-ref)
   (url
"CGI-testing.html#index-_0028setter-cgi_002dtest_002denviornment_002dref_0029"))
(symbol (setter dict-get)
   (url "Dictionary-framework.html#index-_0028setter-dict_002dget_0029"))
(symbol (setter object-apply)
   (url
"Procedures-and-continuations.html#index-_0028setter-object_002dapply_0029"))
(symbol (setter port-buffering)
   (url "Input-and-output.html#index-_0028setter-port_002dbuffering_0029"))
(symbol (setter random-data-seed)
   (url
"Random-data-generators.html#index-_0028setter-random_002ddata_002dseed_0029"))
(symbol (setter ref)
   (url "Hashtables.html#index-_0028setter-ref_0029"))

So the symbol URLs would simply be appended to the 'symbol-base-url'.

This table could be auto-generated quite easily by HTML-scraping the
Gauche symbol index page.

I put the URLs in a separate (url ...) form in the symbol since there
could eventually be other information about a symbol too (e.g. arg
list). But we could also make a separate table with only the names and
URLs if it's easier, e.g.:

((%macroexpand
   "Macro-expansion.html#index-_0025macroexpand")
  (%macroexpand-1
   "Macro-expansion.html#index-_0025macroexpand_002d1")
  ((setter cgi-test-enviornment-ref)

"CGI-testing.html#index-_0028setter-cgi_002dtest_002denviornment_002dref_0029")
  ...)