Re: case insensitive tokens??

[hutch@RedRock.com (Bob Hutchison)]

On Fri, 29 May 1998 07:04:20 -0700, you wrote:

Now David, lets calm down a bit. Personally, I don't appreciate
uninformed rants, especially when directed at me.

Etienne designed SableCC to allow customisable lexers and parsers,
whether you like it or not. I just think he didn't make them
customisable enough.

You are obviously unaware that the use of 'private' to 'protect' clients
of a class is more than a bit controversial in the Software Engineering
field. Briefly, the use of 'private' requires prior knowledge of all
possible uses of the library. This is asking a lot. OO software has
specific mechanisms to deal with this problem. Etienne is aware of the
issue because he did include a number of protected features and added
the filter method. In my opinion he did not go far enough. In order to
continue using SableCC I had to temporarily write a simple little
routine in my custom lexer that looked something like:

protected int getChar(){
  int c = super.getChar();
  if(in a certain state){
    c = (int)Character.toLowerCase(c);
  }
  return c;
}

That's all. Can't do that if getChar is private. If I didn't have the
ability to change the source of SableCC, with which Etienne has so
graciously provided us, I would have been wasting my time using SableCC.

Since then I've become much "fancier", and have adjusted things so the
character is shifted only for comparison against the tables leaving the
original unshifted text in the token. But not even this is real hacking,
thank you, even though this kind of activity is potentially dangerous.
Unfortunately, until case insensitive tokens are supported this is the
way it is going to be.

I had a decision to make: toss SableCC or make it more customisable.

Bob

>
>=================================================
>BTW, this use of private in library classes is a bit problematic. It
>severely restricts the ability of users of the class to extend the
>library.
>===================================================
>Yea! Isn't that great.
>
>I'm sure if you hack away at it 
>you'll end up with your own version of yacc.
>
>Cute clever code may work for individual hackers.
>SableCC gives a clean clear OO implementation.
>When it comes to building and maintaining
>code for a project with a life cycle of more than
>one person a tool like SableCC is far superior
>to what ever its perceived or actual short comings.
>
>I have seen too many projects lost
>because some programmer 
>could write a better sort,
>do it better in assembler,
>just had to modify a tool that worked.
>
>I'm using Sable because I want the guy
>that comes after me to spend his time
>learning Sable not MY code.
>
>I want/have to, process source code
>If SableCC or xyz can generate an AST
>for me... that's what I want.
>That it does in in a Non-Procedural way
>is fine by me.
>
>Management 101 tells us
>Asking  for what you want
>not how you want it
>is more productive.
>The world would have lost the productivity
>of relational databases if every one 
>insisted on hacking Oracle and DB2.
>
>So, fine for you, fun for you.
>A  bloody night mare for the poor guy has to follow.
>
>Again, The real question is
>How productive is it.
>
>David
>

---
Bob Hutchison, hutch@RedRock.com, (416) 878-3454
RedRock, Toronto, Canada