[SR-Dev] script parsing: string switch support

[Andrei Pelinescu-Onciul]

On Feb 20, 2009 at 14:03, Jan Janak <jan at iptel.org> wrote:
> On 20-02 12:22, Andrei Pelinescu-Onciul wrote:
> > On Feb 20, 2009 at 11:15, Daniel-Constantin Mierla <miconda at gmail.com> wrote:
> > > Hello Andrei,
> > > 
> > > On 02/20/2009 12:50 AM, Andrei Pelinescu-Onciul wrote:
> > > >[...]
> > > >
> > > >script parsing: string switch support
> > > >  
> > > that's great, thanks. From the next example, to understand the the case 
> > > can take expression that evaluates to static strings or integers?
> > 
> > Yes.
> > There are the following restriction:
> > 
> > - case labels must be static (no vars allowed)
> > - in the same switch you can have only one type of case labels: strings
> >   or integers (1)
> > - the first case label sets the required type for all the others
> >  (so if your first case label is a string => all the other must be
> >  strings, if it's an integer all the other must be integers).
> > 
> > (1) - could be changed in some cases (e.g. string case with some int
> > label allowed, which could be automatically converted to string), but I
> >  think it would too confusing and I disallowed it (in general having
> >  mixed types in a switch() are 99% an error).
> 
> I would suggest to convert numbers to strings in this case automatically. For
> most people things get more confusing with the increasing amount of details
> they have to remember about the configuration language.

This would only make sense if we use match() for strings and switch()
for ints. Otherwise it would be too confusing.
Anyway I don't think the amount of details of the configuration language
is ever a problem, as long as one gets meaningful error messages when
checking the config (and before ser startup).
The other approaches trade-off less config details for guessing what the
user intended, which IMO is much more dangerous. Is much better to get
meaningful errors when running ser -cf ... , then getting unexpected
behaviour at runtime (a very good example for this are typed variables
vs. untyped ones or operators that try to guess the type and assume the
user made the right choice).


> 
> This is similar to the difference between
> if (method == INVITE) and if (method == "INVITE")
> I guess most people won't be able to tell you the difference if you asked them.
> 
> I would not assume that mixed integers and strings are 99% errors, we don't
> really know what people have in their configuration scripts and why, so this
> assumption is IMHO not justified.
> 
> > I still think that using a different switch() name for strings will be
> > less confusing (e.g. switch() for integers and match() for strings).
> 
> Yes, I like match for strings better too, especially if regular expression
> matching is involved.
> 
> > Any opinion on how to differentiate regular expressions from strings?
> > Right now a '/' in front means a regular expression (but there's no way
> > to specify case insensitive match for example).
> 
> How about enclosing regular expressions in a pair of // like in awk or
> perl. It would be possible to introduce a flag for case-insensitive matching, something like:A

I tried //, but it produces an extra shift-reduce conflict in the
grammar (so it needs at least more testing).

> 
> i/regex/

I was thinking more of /regex/i. Unfortunately for this we need a bigger
change in the grammar (I don't see an easier way right now). I agree
that it would be nicer, but I want to move to something else :-) (so if
there are some volunteers for adding the cfg.y support, I can then
easily enable the runtime code support for it, everything else is in
place).
> 
> For example:
> 
> case i/From/:
> 
>   my two cents, Jan.


Andrei