On Mon, Aug 06, 2001 at 10:01:51AM +0100, Tim Phipps wrote:
> [EMAIL PROTECTED] wrote:
> > 
> > On 05 Aug 2001 13:34:02 +0200, Dominik Vogt wrote:
> > >
> > > How about this enhancement to conditional commands:
> > >
> > >   Next (conditions) { false-action } true-action
> > >
> > This may work, but is this the best possible solution? This syntax is not
> > very readable and having else-command before then-command does not make it
> > better. As before there is still a limit to one command in both branches,
> > so you are forced to create small functions without a real need. It also
> > adds a problem of escaping curly brackets in else-command when needed.
> > What about parsing of nested conditional commands, braces in braces? :)
> > It seems that an idea of 2 commands on the same line is not very good.
> 
> I think we can already do conditional code using self modifying
> functions:
> 
> AddtoFunc true_case
> + I true case commands
> + ...
> 
> AddToFunc false_case
> + I false case commands
> + ...
> 
> AddToFunc its_true
> + I DestroyFunc conditional_code
> + I AddToFunc conditional_code I true_case
> 
> AddToFunc its_false
> + I DestroyFunc conditional_code
> + I AddToFunc conditional_code I false_case
> 
> AddToFunc test
> + I its_true
> + I Next (whatever) its_false
> + I conditional_code
> 
> I know it's a bit wordy but it's probably possible to use FvwmM4 to wrap
> it up into something a bit easier to type.
> 
> > 
> > Here is my revised proposal that solves all problems described above.
> 
> long example snipped...
> 
> > There are 5 new commands "if", "else", "elsif", "{" and "}" in this
> > proposal. No existing command syntax is changed, which is an advantage.
> 
> But then you'll end up doing a "while" command, then a "switch", then a
> "break" and I think you've got youself a new language to learn. I think
> the SCWM approach is better if this is what you want i.e. put a real
> interpreter in there (I'd prefer TCL since I already know it) so that
> people don't have to learn a new language and we don't have to design
> and test it.

I agree with Tim.  It might be better to only implement some basic
functionality.  Of course the syntax I proposed is not nice and
flexible, but it is very easy to implement.  Other approaches
require that commands have a return value on which to base the
decision which bracnch to take.

Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]

Reply via email to