Nicola Bernardini wrote:
>
> I was cced this mail so I'll jump in in the discussion for a moment...
Great. I've added saol-dev as well.
For context, Davide Rocchesso has students working on a
csound-to-saol translator, an error-recovery unit for the compiler,
and other SAOL tools
> 1) last time I tried a pass through bison of the saol.y bison popped up
> some hundreds of reduce/reduce conflicts; even though the parser might
> work just the same, that's way too much - interpreting gets very fragile
> and while the parser can be tested to parse the right code it should
> be also tested *not* to grok the *wrong* code: with reduce/reduce conflicts
> this is likely not to happen for some odd input. Also, from a first look
> I think that it is mostly the error cases which lie all around the code that
> produce the reduce/reduce conflicts: I took the saol skeleton as a
> reference while writing the csound parser and had to remove a number
> of these error cases because they were useless and conflicting.
Yes, that was because I didn't know how to write error productions.
They're fixed now -- I don't get any reduce-reduce conflicts with
true YACC. I haven't installed Bison yet, but I'd welcome build
reports against the latest source.
> I did not look at the macro-system in saolc. My only worry here is that
> we do the same error that was done with the new Csound macro system:
> since they were worried not to be able to port cpp (the C preprocessor)
> to all platforms, they ended up cooking a brand-new preprocessor syntax
> which is inferior, badly coded and difficult to mantain because it is
> deeply nested into the language itself. Now it is in and it is going to
> be very difficult to move it out without breaking backward-compatibility.
> IMHO, there are plenty of public domain pre-processors that can be used
> (cpp, m4, etc.) and ported to all platforms as needed: to write a new
> one without very important reasons means asking for trouble. I have gathered
> some info on very small and portable cpp pre-processors available in
> the public domain at the request of csound main maintainer (John Fitch)
> but to no avail. I hope this will not happen for saolc.
Oh, no, this is not this kind of macro pre-processing. There is no
built in macro expansion for the language, and won't be for saolc anyway.
The latest version of saolc has a hook so that you can plug in your
own macro preprocessor before compilation -- I use cpp. But I totally
agree with you on this.
The demacroizing I'm speaking of is the implementation of user-defined
opcodes in SAOL. SAOL allows the description of new unit generators
in SAOL, and these have to be compiled into the instrument somehow,
either with 'real procedures' like displays or stack frames, or with
macro expansion. The macro expansion way is more complicated but
more efficient in saolc. But this is a design decision for each
implementor -- you can do it either way according to the standard.
> would it be at all feasible to write a csound-to-saol portability library?
> a sort of wrapper that gets called when a csound ugen is involved so that
> csound ugens could be used without touching at their code? The only advantage
> of csound over saol, at this time, is that it is widespread and lots of
> people are developing code for it (even if lots of it is really yukky) -
> this could be a good point for straight code re-use.
Csound is also much faster than saolc.
Do you mean translation of the C code implementing Csound, or of the
Csound code itself? I think the latter is a better idea than the
former -- there's lots of differences between calling mechanisms
between Csound ugens and saolc 'core opcodes' that make the former
hard (for example, Csound is always block-based, and saolc is always
sample-based right now).
> Sorry for jumping in so single-handedly, especially because I won't be
> able to put time into these things for a while. I just could'nt resist...
> (rather, I am a csound user and I have been watching quite closely the
> turn of things there and I am quite distressed about that).
I think a number of things that concern you are the issues we're
trying to address with standardisation -- not just creating
another language for its own sake, but fixing it in stone.
Please read the standard and make sure everything is to your
liking before September!
Best to all,
-- Eric
-- +-----------------+ | Eric Scheirer |A-7b5 D7b9|G-7 C7|Cb C-7b5 F7#9|Bb |B-7 E7| |eds@media.mit.edu| < http://sound.media.mit.edu/~eds > | 617 253 0112 |A A/G# F#-7 F#-/E|Eb-7b5 D7b5|Db|C7b5 B7b5|Bb| +-----------------+
This archive was generated by hypermail 2b29 : Wed May 10 2000 - 12:14:10 EDT