Proposal3: Make $_ a valid identifier character

Eric Arseneau eat at huv.com
Tue May 30 05:00:44 UTC 2000


> I'll buy into this debate:
>
> I can remember programming in an environment where '_' was used and
> always going off to the documentation to find out where they belonged
> because I could never remember!
>
> Would you have Sequenceable_Collection or Sequenceable_collection?
>
> In a world without '_''s, I can say the name of a class to somebody
> and they would be able to have a pretty good idea of how it was
> spelt, but if '_''s are included, they will never know the exact
> spelling: BroadcastDate vs BroadcastDate or Broadcast_Date or
> Broadcast_date.
Oh, well.  There's a case for where allowing both would provide for even
more confusion.  I didn't think it through well enough.

> What I'd really like is for the case significance of identifiers to
> be relaxed.  If I write broadcastdate or Broadcastdate, the system
> should know what I mean!

Maybe another solution is to let the environment provide some extra
semantics.  Maybe all of the different variants with case and '_' could be
canonized into a single form, and let the compiler find the appropriate
cannonized form.  An example of this would be HelloWorld vs Hello_World.  It
would be very simple for the environment to store the cannonized form in
something like Hello$World, and to allow Hello_World and HelloWorld to match
to this same variable.  I know I'm greatly simplifying this, but it seems
that a solution like this would get around the issue ?  I'll let better
minds than mind find the holes in this.

I recall that a friend of mine had created a language syntax without the use
of BEGIN..END, [..], {..} or whatever form of bracketing is used in your
favorite language.  Instead use the indentation of the code and let the
compiler figure out the begin and end of a 'block' of code.  Although there
are many issues with something like this, there is dome definit appeal to
it.  It seems to me that the cannonized form I mentioned above fits along
those lines.





More information about the Squeak-dev mailing list