public inbox archive for pandoc-discuss@googlegroups.com
 help / color / mirror / Atom feed
From: Albert Krewinkel <albert+pandoc-9EawChwDxG8hFhg+JK9F0w@public.gmane.org>
To: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
Subject: Re: Lua filter to process chunkedhtml output
Date: Sat, 21 Jan 2023 13:33:31 +0100	[thread overview]
Message-ID: <87fsc4koud.fsf@zeitkraut.de> (raw)
In-Reply-To: <CAEe_xxjkBZfgeh5jDbZNDNrFbG4SKTA0S9qjzaEXgxTr5BZVNw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>


"'William Lupton' via pandoc-discuss" <pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org> writes:

> pandoc.utils.type() return values seem to be a little inconsistent.
> For example, it can return:
>
>     'List' ... for pandoc.List (note: logging.lua leaves this alone)
>     'pandoc Xxx' ... for pandoc.Row etc. (note: logging.lua replaces
>     the space with a dot)
>     'HsLua.JSON.array' ... presumably for arrays that have come via a
>     JSON library

Thank you for digging and asking! It's great to have more eyeballs in
this part of the code.

A bit of background: all types have a corresponding entry in the Lua
"registry", a global table that contains all sorts of info. The Lua
manual states "you should use as key a string containing your library
name", hence the "pandoc" and "HsLua" prefixes. Additional
inconsistencies are cause by the fact that I didn't follow the Lua
manual's advice in the beginning, as name clashes with other packages
where not really a concern of mine.

> I was toying with not indicating HsLua.JSON.array (i.e., showing it
> like any other table) but perhaps it's better just to report things
> as they are. Can any other HsLua.JSON.xxx values be returned, e.g.,
> why not HsLua.JSON.object or indeed HsLua.JSON.
> {boolean,number,string,null}?

There's a technical reason for this: we must be able to round-trip
from JSON to Lua to JSON. Both JSON arrays and objects are represented
as Lua tables, but how can we know whether an empty Lua table `{}`
represents an empty array or an empty object? We solve this by assigning
a metatable/type to array values.

I guess we could also do this for JSON objects, but the advantage is
less clear in that case: being able to add metamethods like `insert`
makes sense for lists, but not for objects: String fields can shadow any
method, which would most likely lead to subtle bugs. E.g.,
`obj:merge(obj2)` would stop working if `obj` has a key `merge`.
Adding a metatable to objects would therefore be little more than
performance degrading overhead.

The other JSON types, boolean, numbers, and strings, map directly to the
respective Lua types of the same name, and pandoc.utils.type will report
the Lua type name in those cases.

Anyway, please do open issues for any inconsistencies you find. We may
want to keep some of those old names to keep error messages more
readable, but consistency would be nice to have, too.

> On Fri, 20 Jan 2023 at 16:33, William Lupton <
> wlupton-QSt+ys/nuMyEUIsrzH9SikB+6BGkLq7r@public.gmane.org> wrote:
>
>     Update: Until today, logging.lua assumed that pairs() would work
>     on all userdata. Option 2 (my favourite) should work well if
>     there are ever any other types of userdata (not sure whether
>     there ever will be).
>    
>     On Fri, 20 Jan 2023 at 16:29, William Lupton <
>     wlupton-QSt+ys/nuMyEUIsrzH9SikB+6BGkLq7r@public.gmane.org> wrote:
>    
>         Thanks Albert. I expect I'll raise an issue. I assume
>         that this is the only use of light userdata?
>        
>         Looking more closely (why didn't I do this before?) I see
>         that tostring() returns 'userdata: 0x0' for these values, so
>         I think it makes sense to report them as one of:
>             Whatever tostring() returns
>             As above with the leading 'userdata: ' removed           
>                    <--- probably my favourite
>             As above with '0x0' reported as 'nil' (not sure about
>             this)
>        
>         On Fri, 20 Jan 2023 at 16:05, ChrisD <
>         cd34-gg-4SSc53hpTiu9TMao6EloiEEOCMrvLtNR@public.gmane.org> wrote:
>        
>             On 1/20/2023 2:54 AM, 'William Lupton' via pandoc-discuss
>             wrote:
>             > I investigated, and parts of the writer options are
>             "light userdata" (I hadn't heard of that). I've committed
>             and merged a fix that will report such items as "
>             <pointer>". You can now list most of the writer options
>             (just a few colors show as <pointer>).
>            
>             Your update works well. (I didn't know about light
>             userdata either.) Thanks!
>            
>             --
>             You received this message because you are subscribed to
>             the Google Groups "pandoc-discuss" group.
>             To unsubscribe from this group and stop receiving emails
>             from it, send an email to 
>             pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
>             To view this discussion on the web visit https://
>             groups.google.com/d/msgid/pandoc-discuss/
>             fbca8e05-fed7-39e1-08f0-0498c399f33f%40intielectronics.com
>             .


-- 
Albert Krewinkel
GPG: 8eed e3e2 e8c5 6f18 81fe  e836 388d c0b2 1f63 1124

-- 
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/87fsc4koud.fsf%40zeitkraut.de.


  parent reply	other threads:[~2023-01-21 12:33 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-19 13:44 ChrisD
     [not found] ` <d5298c4a-9427-8f5b-c646-6370a3f998df-4SSc53hpTiu9TMao6EloiEEOCMrvLtNR@public.gmane.org>
2023-01-19 17:12   ` John MacFarlane
     [not found]     ` <1D22B433-211B-4033-8A63-F637F52B2008-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2023-01-19 17:14       ` John MacFarlane
2023-01-19 21:32       ` ChrisD
     [not found]         ` <f761231d-87ea-6bfb-38c3-99eb15184263-4SSc53hpTiu9TMao6EloiEEOCMrvLtNR@public.gmane.org>
2023-01-20  9:54           ` 'William Lupton' via pandoc-discuss
     [not found]             ` <CAEe_xxiQAz2MVihALKGes6Ai=UrOPKgkvGq19ULiLsjBhTuTbQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2023-01-20 15:46               ` Albert Krewinkel
2023-01-20 16:05               ` ChrisD
     [not found]                 ` <fbca8e05-fed7-39e1-08f0-0498c399f33f-4SSc53hpTiu9TMao6EloiEEOCMrvLtNR@public.gmane.org>
2023-01-20 16:29                   ` 'William Lupton' via pandoc-discuss
     [not found]                     ` <CAEe_xxiJdneKg+uqja3tdaWzQSWmc5NfO0aMFKaUGa_W1U5+qg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2023-01-20 16:33                       ` 'William Lupton' via pandoc-discuss
     [not found]                         ` <CAEe_xxhhsG_NA+PL+5A2TyHHqNOC-=sdi1jX-NYunf9fsHtH1A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2023-01-21 12:28                           ` 'William Lupton' via pandoc-discuss
     [not found]                             ` <CAEe_xxjkBZfgeh5jDbZNDNrFbG4SKTA0S9qjzaEXgxTr5BZVNw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2023-01-21 12:33                               ` Albert Krewinkel [this message]
     [not found]                                 ` <87fsc4koud.fsf-9EawChwDxG8hFhg+JK9F0w@public.gmane.org>
2023-01-21 17:41                                   ` logging.lua and 'light userdata' 'William Lupton' via pandoc-discuss
     [not found]                                     ` <CAEe_xxjsmxwx4B_f1j4buVT8P+cdVdVw4q8dbtxiuJNoXsNweQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2023-01-23 10:49                                       ` Albert Krewinkel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87fsc4koud.fsf@zeitkraut.de \
    --to=albert+pandoc-9eawchwdxg8hfhg+jk9f0w@public.gmane.org \
    --cc=pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).