> I also started to
> think about how to handle things like definitions needed for the global
> block, but it sounds like John has a better solution with the distributed
> global block idea.
Yes, basically, unless the -isosyntax switch is set, sfront can handle
more than one global block distributed over the files following the
-orc option, in the upcoming sfront 0.59. Like all non-compliances
allowed under the -isosyntax flag, the .mp4 file created will be pure
ISO via mechanical conversion -- in the multiple-global case, by
concatenating all the global statements together into one giant
global block, with lines in the global ordered according to the
presentation order. Given how important global variables are in
SAOL, it just seemed hard to encourage re-usable libraries without
some way for each library to have its own global block.
In a related note, unless the -isosyntax switch is set, sfront 0.59
will also allow stray ;'s after {, }, and (except for the innards of
the send statement) other ;'s. This is needed in order for pre-processor
macros to resolve to the null string without causing a SAOL syntax error,
or without pushing the ;'s into the macro definition itself. In other
words:
#ifdef HASFLANGE
#define FLANGER(x,rate,depth) x = flange(x,rate,depth)
#else
#define FLANGER(x,rate,depth)
#endif
[...]
x = (1+depth)*input[0];
FLANGER(x,10,90);
output(x);
will actually produce a syntax error in SAOL if HASFLANGE is
not defined, because after pre-processing:
if(count> 0 ){
x=( 1 +depth)*input[ 0 ];
;
output(x);
}
is produced, which is illegal SAOL. The only way arond this,
aside from the stray semicolon cleanup code in sfront 0.59,
is to do:
#ifdef HASFLANGE
#define FLANGER(x,rate,depth) x = flange(x,rate,depth);
#else
#define FLANGER(x,rate,depth)
#endif
and call it like
x = (1+depth)*input[0];
FLANGER(x,10,90)
output(x);
which would require undo-ing a lot of hard-wired syntax checking
in programmers brains ...
--jl
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 12:03:54 EST