Re: Generating runtime type information.

[Ryan Gonzalez <rymg19@xxxxxxxxx>]

I'm kind of confused as to why argtype is 3rd on the stack. But this still
looks cool.

One interesting twist would be to allow access to arguments via a trait's
API, so we'd have something like:

const fmt : (vals : stringable... )

assuming stringable is a trait with a `tostr` method or something.

So then we could use custom structs with put:

type X = struct
    blah: int
;;

impl stringable int =
    tostr = {x
        -> tostr(x.blah)
    }
;;

var x: X = [.blah = 1234]
std.put("our string: %?", x)
/* puts 1234 */


On Fri, Mar 27, 2015 at 1:19 AM, Ori Bernstein <ori@xxxxxxxxxxxxxx> wrote:

> Congratulations everyone! you get to rebuild as we break ABI
> again!
>
> We now generate type descriptions for variadic types, and push
> a pointer to the variadic arguments on to the stack when we call.
> The valist code currently ignores this, and does nothing useful
> with it -- this should be fixed.
>
> In other words, if you have a variadic function f:
>
>         const f : (a : int, b : byte[:], ... -> void)
>
> and you call it like this:
>
>         f(1, "asdf", 'c', "blah", false)
>
> you will get, on the stack:
>
>         [
>         1       : int,
>         "asdf"  : byte[:],
>         argtype : byte#
>         'c'     : char,
>         "blah"  : byte[:],
>         false   : bool
>         ]
>
> The argtype will be a binary encoded description of the types
> of the tuple (char, byte[:], bool)
>
> This means that you can write (admittedly, slightly hairy) code
> to parse out the types passed in for variadics, and write code
> that looks like:
>
>         const pack : (vals : ... -> byte[:])
>
> One goal that I would like to support is making std.fmt()
> callable as such:
>
>         std.fmt("%: list contains %\n", 1, [1,2,3][:])
>
>
> --
> Ori Bernstein <ori@xxxxxxxxxxxxxx>
>
>


-- 
Ryan
[ERROR]: Your autotools build scripts are 200 lines longer than your
program. Something’s wrong.
http://kirbyfan64.github.io/