Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Templates/generics #135

Open
KOLANICH opened this issue Mar 21, 2017 · 5 comments
Open

Templates/generics #135

KOLANICH opened this issue Mar 21, 2017 · 5 comments

Comments

@KOLANICH
Copy link

KOLANICH commented Mar 21, 2017

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
Copy link
Member

GreyCat commented Mar 21, 2017

I've proposed approximately the same syntax some time ago: #78 (comment)

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

@KOLANICH
Copy link
Author

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
Copy link

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
Copy link

anonhostpi commented Sep 9, 2024

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?

  • Should it error out while compiling?
    • I would argue this would be the easiest solution
  • Should it respect the original definition of u4?
    • ...this would be the most type safe
  • Should it accept the new definition?
    • ...this would make the most sense logically

@anonhostpi
Copy link

anonhostpi commented Sep 9, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants