You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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)
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.
The text was updated successfully, but these errors were encountered:
Taking up the comment of @UWN at #2569 (comment):
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:
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.
The text was updated successfully, but these errors were encountered: