Re: [Seed7-users] Beginner questions

[Thomas M. <tho...@gm...>]

Great that you are writing a program to read elf-files. This is something that
Seed7 is currently missing.

Regarding your questions:

1. Using functions from bytedata.s7i is IMHO the right approach. Read the data
   directly into a structure is not supported.

   In Seed7 there are no integer types of various sizes like in C or ASM,
   where types with 1, 2, 4 and 8 bytes exist. This was a design decision
   driven by the "one size fits all" principle used in Seed7. In many cases
   this "one size fits all" makes programming easier, since you can just use
   integer (or bigInteger if an 64-bit integer is not enough) instead of
   thinking which size of integer you want to use. As a consequence it is not
   possible to create a struct which has a 1:1 mapping to the data in a
   file. Therefore you cannot read data directly into a struct and you need to
   write a function to read a structure from a file.

   In C and ASM reading data directly into a structure can also trigger
   problems. If the data structure in the file uses big-endian integers and
   your program runs on a little-endian computer direct reading
   into a structure will not work in C and ASM. C and ASM would need the
   possibility to specify if an integer is big- or little-endian to fully
   support reading data structures directly.

   This is the reason bytedata.s7i supports reading big-endian and
   little-endian values. The explicit conversions make it obvious, what is
   going on.

2. A call-by-name parameter is not the same as a function pointer in C.
   E.g.: In
     if aVariable = 5 then
       writeln;
     end if;
   the actual call-by-name parameter
     aVariable = 5
   is an expression that is not executed immediately.
   A call-by-name parameter corresponds to the combination of a function
   pointer (to a function without parameters) and the environment (local
   variables) used by the function.

   Normally I prefer a case statement to have a mapping from integer to code
   to be executed. Usually this is also easy to read, as the case labels and
   the code stand nearby. In compiled programs case statements are translated
   usually to efficient machine code.

   You mentioned many possibilities. How much is many?

   In file formats integers often correspond to enumeration types. If the
   integers are converted to an enumeration type object orientation can be
   used to execute code depending on the enumeration value. E.g.:

---------- begin enumfuncts.sd7 ----------
$ include "seed7_05.s7i";

const type: anEnumType is new enum
    ONE, TWO, THREE
  end enum;

const proc: doSomething (in anEnumType: anEnum) is DYNAMIC;

const proc: doSomething (ONE) is func
  begin
    writeln("one");
  end func;

const proc: doSomething (TWO) is func
  begin
    writeln("two");
  end func;

const proc: doSomething (THREE) is func
  begin
    writeln("three");
  end func;

const proc: main is func
  begin
    doSomething(anEnumType conv rand(0, 2));
  end func;
---------- end enumfuncts.sd7 ----------

3. The Seed7 type system is static, safe, nominative and manifest.
- Static means that the types are specified at compile time. All violations of
  the type system trigger compilation errors.
- Safe means that there are no operations or conversions that violate the
  rules of the type system.
- Nominative means that the compatibility and equivalence of data types is
  determined by the name of the type. This means that two struct types
  are different even if both structs are defined with the same elements.
- Manifest typing means explicit identification of the type of each variable
  being declared. For example: If variable X is going to store integers then
  its type must be declared as integer.

Regards
Thomas Mertes