search

kaitai-io / kaitai_struct

Kaitai Struct: declarative language to generate binary data parsers in C++ / C# / Go / Java / JavaScript / Lua / Nim / Perl / PHP / Python / Ruby
https://kaitai.io
4.04k stars 199 forks source link

Templates/generics #135

Open KOLANICH opened 7 years ago

KOLANICH commented 7 years ago

I think we need templates/generics, don't we? the proposed syntax:

types:
  a:
    template:
      - id: first
        type: type
      - id: second
        type: enum
      - id: third
        type: u8
    seq:
      - id: b
        type: first
        enum: second
    instances:
      c:
        value: third*b

All the template arguments should be known at compile time. For languages having templates/generics they should be used.

GreyCat commented 7 years ago

I've proposed approximately the same syntax some time ago: https://github.com/kaitai-io/kaitai_struct/issues/78#issuecomment-272581874

Could you show what you propose for usage of your example template?

KOLANICH commented 7 years ago

Could you show what you propose for usage of your example template?

This was just an example. The use cases are strings and other arrays prepended by count of elements, wrappers for data structures, where first structure must have certain type (see flac.ksy, the first frame is always metadata one), etc.

SerhiiPok commented 2 years ago

In my point of view also the generics is much needed: some use-cases in this duplicate thread of mine.

Also, here, I have posted a workaround implementation of generics that I am using as long as no generics is avialable in kaitai so far.

anonhostpi commented 2 months ago

I would like to point out that its probably worth dictating how seq > type should behave for this proposal prior to trying an implementation.

Like for example, what should happen if one of the template parameters is called u4?

anonhostpi commented 2 months ago

Also, another consideration is depth and complexity of parameterization.

How should Kaitai react to parametric or template types being passed as template parameters?

Can we add an option to limit or permit these behaviors?

For example, should Katai (and how should Kaitai) abstract this signature:

class Template<T extends AnotherTemplate<TypeParameter>> { ... } // TypeScript