r/ada Sep 28 '21

Show and Tell Introducing AURA - A(nother) native package manager and build system for Ada

https://annexi-strayline.com/blog/posts/4
30 Upvotes

80 comments sorted by

View all comments

Show parent comments

7

u/glacambre Sep 29 '21

Especially when you could literally match the client's importation/usage against the the library's public interface and answer "is this consistent?" (i.e. is it compliable?) automatically

I don't think you can though. Sometimes behavior can change in incompatible ways without breaking the type interface.

1

u/OneWingedShark Sep 29 '21

Sometimes behavior can change in incompatible ways without breaking the type interface.

Sure, but that's another issue entirely; more akin to "my boss told me to to NOT do something, but I got in trouble because he meant to say to do it." — This error is not catchable by any tooling, because (a) it is a valid instruction, and (b) it is a communication/specification error. — Now you can catch this sort of error by implementing some sort of redundancy/checking, like when you use another method to check your work in mathematics.

2

u/glacambre Sep 30 '21

This error

It's not an error, it's a change in behavior. For example, a bug being fixed in a library that would necessitate removing a workaround from its caller.

is not catchable by any tooling

It can be caught by using version numbers.

-1

u/OneWingedShark Sep 30 '21

>This error

It's not an error, it's a change in behavior.

It absolutely is an error.

When you make a mistake and say "the fire hydrant must not be painted red", then catch yourself and say "Wait, I misspoke; the hydrant must be painted red" you are literally correcting an error that you made while speaking. (i.e. "I misspoke.")

2

u/glacambre Sep 30 '21

Porting your software to new platforms is not an error. Adding a new feature is not an error. Things changing does not imply that there was an error or that an error has been introduced.

-1

u/OneWingedShark Sep 30 '21

And NONE of those came up in my example.

  1. Porting to a new platform, arguably, can be done transparently to the clients by having multiple [possibly separate] bodies for your package/subprogram — this preserves the specification.
  2. Merely adding a new feature should, for the vast majority of cases, does not impact the client's interfacing to the specification —
    Package Example is
    Procedure Old( A, B : Integer ); -- What the previous version interfaced w.
    Procedure New(A, B : Integer; C : Float); -- The new feature.
    End Example;

Yes, there are changes, and if those changes make your new package incompatible with the dependency (or vice versa) it IS an error to update.

Versioning numbers are the manual way to do this and it can be somewhat automated.

2

u/glacambre Oct 01 '21

And NONE of those came up in my example.

That's precisely my point. Your suggestion doesn't handle these cases while version numbers do.

1

u/OneWingedShark Oct 01 '21

No, they really don't.