Re: some code constructs in Poke

[Jose E. Marchesi]

Hi Indu.

> While working on making some improvements to the CTF pickles in GNU
> Poke, I ran into some aspects that I wanted to discuss.
>
> 1. Forward declaration of functions in Poke.
>
> It does not look like Poke allows forward declaration of
> functions. Without forward declarations allowed, some code patterns
> are simply not permitted.
>
>     func B ()
>     {
>       if (condB)
>       A ();
>     }
>
>     func A ()
>     {
>       if (condA)
>       B ();
>     }
>
> Above cannot be achieved. Is my understanding correct ?

Correct.

We still have to add support for forward declarations of functions, and
also for forward declarations of types (for defining recursive data
structures.)

> 2. Good to have (perhaps?): Some mechanism for structs to convey
> information to each other.
>
> In pickles/ctf.pk, see how type CTF_Func_Args needs to be defined
> inside CTF_Type due to its dependence on info.vlen. Well, this works
> fine as far as the requirement of "specification of types" goes.
>
>    type CTF_Type =
>      struct
>        {
>        CTF_Info info;
>        ...
>
>        type CTF_Func_Args =
>            struct
>            {
>              CTF_Type_Id[info.vlen] arg_types;
>              uint32[info.vlen % 2] padding;
>            };
>
>           /* Data, that depends on the kind of the type.  */
>           union
>         {
>           ...
>           CTF_Func_Args func_args : info.kind == CTF_KIND_FUNCTION;
>           ...
>         } data;
>       };
>
>
> The side effect of this, however, is that CTF_Func_Args is not a type
> at file-scope, so this limits the developers from writing functions
> for the    type at hand. E.g., see the need to write a function that
> takes CTF_Func_Args as an argument-
>
>   fun ctf_dump_func_args = (CTF_Func_Args fargs) void: {}
>
> Instead one can workaround by writing
>
>    fuc ctf_dump_func_args = (CTF_Type t) void: {}
>
> and do the necessary exception handling etc.
>
> I am a bit split on this one. The current behavior is logical, no
> denial; but defining functions for the parent type looks a bit
> twisted. The positive about the current way of working is that the
> syntax around type definitions is more C-like...WDYT ?

This is also already in the TODO: support for passing arguments to
struct type definitions.  In this case, we will have at top-level:

type CTF_Func_Args =
  struct (uint<25> vlen)
  {
    CTF_Type_Id[vlen] arg_types;
    uint32[vlen % 2] padding;
  };

And then use the type like this:

 CTF_Func_Args (info.vlen) func_args : info.kind == CTF_KIND_FUNCTION;

or like this:

 CTF_Func_Args<info.vlen> func_args : info.kind == CTF_KIND_FUNCTION;

depending on what syntax we adopt.  There are arguments for using () and
also for using <>.

Both features are scheduled for poke 2.0.