search

mthom / scryer-prolog

A modern Prolog implementation written mostly in Rust.
BSD 3-Clause "New" or "Revised" License
2.03k stars 118 forks source link

rebis-dev: max_arity should ideally be unbounded #2594

Open triska opened 1 week ago

triska commented 1 week ago

Taking up the comment of @UWN at https://github.com/mthom/scryer-prolog/discussions/2569#discussioncomment-10816242:

A limit of 255 is complete overkill for the vast majority of Prolog applications, and at the same time too limited for a few of them.

Suggestion:

  1. an efficient (internal) type for compound terms with bounded arity, such as 32, which is by far large enough for most Prolog applications (even 16 would be enough)
  2. a second (internal) type for compound term with unbounded arity, where the speed almost doesn't matter because an application that needs such large arities will tend to do many other things as well which also cost time.

A dedicated tag can be used to distinguish the types internally, for example using one of the bits that now denotes arities greater than 127, which would leave terms with up to 127 arguments to be stored compactly, far enough for typical Prolog applications.

Prolog programs would of course see nothing of this difference, which is completely internal to the engine.

hurufu commented 1 week ago

I just want to add that #2576 would benefit from unbounded term arity.