Description

This article is from the FAQ, by with numerous contributions by others.

F04) Why can't I have instances in attributes-fragments?

Allowing instances in attribute forms makes separate compilation of
fragments very difficult due to problems in calculating the size of objects
being allocated from the descriptor in which the fragment form is bound (to
a slot). E.g.

fSource.bet:
   ORIGIN '...'
   --- lib: attributes ---
   f: (# t: @text;
         <<SLOT fLib: attributes>>
      enter t[]
      <<SLOT fBody: dopart>>
      #)

fUsage.bet:
   ORIGIN '...';
   INCLUDE 'fSource'
   --- program: descriptor ---
   (# foo: @f
   do (* ... usage of foo ... *)
   #)

fImpl1.bet:
   ORIGIN 'fSource'
   --- fLib: attributes ---
   i,j: @integer; r: @real
   --- fBody: dopart ---
   do  (* ... some code implementing f ... *)

fImpl2.bet:
   ORIGIN 'fSource'
   --- fLib: attributes ---
   i,j,k: @integer; r, s: @real
   --- fBody: dopart ---
   do  (* ... some code implementing f ... *)

fProg1.bet:
   ORIGIN 'fUsage';
   BODY 'fImpl1'

fProg2.bet:
   ORIGIN 'fUsage';
   BODY 'fImpl2'

When compiling the fUsage.bet fragment separately, it is impossible to
pre-calculate the size of the foo object, since foo will contain i,j,r in
fProg1.bet, whereas foo will contain i,j,k,r,s in fProg2.bet.

A solution to this problem is being investigated by Mjolner Informatics, but
there are no plan for when this will be supported.

 

Continue to:

• prev: F03) How do I work around "Only pattern-declarations may appear in a fragment of category 'attributes'"?
• Index
• next: F05) Why can't I have virtual declarations/bindings in attributes-fragments?

Share and Enjoy

Tags

programming