German Umlauts does not work in symbols

I notices that I cannot have symbols containing german Umlaut characters (ä,
ö, ü) in Dolphin 5 Symbols?
Why is this so. I ported a piece of code from VW where it worked just fine.

Ciao

...Jochen

Jochen,

> I notices that I cannot have symbols containing german Umlaut characters
(ä,
> ö, ü) in Dolphin 5 Symbols?
> Why is this so. I ported a piece of code from VW where it worked just
fine.

Have you tried creating a string and then sending #asSymbol to it?  Put
another way, the limitation _might_ be in the compiler rather than Symbol or
elsewhere in the image.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

"Jochen Riekhof" <[hidden email]> wrote in message
news:aet58v$dfa$06$[hidden email]...
> I notices that I cannot have symbols containing german Umlaut characters
(ä,
> ö, ü) in Dolphin 5 Symbols?
> Why is this so. I ported a piece of code from VW where it worked just
fine.

 From the ANSI NCITS 319-1998 "Programming Languages - Smalltalk", 3.5.1
Character Categories, p25-26:

"...All implementations must support the following categories of characters:
    The lowercase letters of the English alphabet.
    The uppercase letters of the English alphabet.
    The Arabic numerals.
    A specific set of binary operators and other special characters.
    A set of characters that represent "white space".
An implementation may defined characters in addition to those listed below
[sic] in each character category. While the meaning of a program that uses
any such characters is well defined it may not be portable between
conforming implementations."

Our compiler enforces that identifiers be limited to the minimum ANSI set as
specified above, so identifiers (such as method selectors) will not be able
to contain anything other than digits, English letters, and underscores
(plus the binary selectors). Strings (and therefore quoted symbols) can
contain any character you like, though in some cases these may need to be
quoted.

Thus in portable Smalltalk one cannot use non-English characters in variable
and method names, but they can be used in literal Symbols, so you can define
a literal symbol #über (or more portably #'über'), but not define a method
'über ^2'.

Sorry

Blair

> Thus in portable Smalltalk one cannot use non-English characters in
variable
> and method names, but they can be used in literal Symbols, so you can
define
> a literal symbol #über
Nope, this one gives the error message on the transcript (in my case, with
an array, e.g.: #(#Januar #Februar #März), but also with standalone #März):

Error 2 on line 4 of BillingTool>>monthNames -> 'illegal character in
literal array'

However, the method is accepted (not red). The error also appears only in a
method definition, not in a workspace?!

(or more portably #'über')
This one works also in a method definition! So it saves me!


>, but not define a method 'über ^2'.
I never would have tried to define a METHOD SELECTOR with Umlauts ;-).

So,  the error message in the method body is a bug, or?

However, I now have a workaround with #'März'. Thanks!

Ciao

...Jochen

Jochen Riekhof wrote:

FWIW - I once had a customer who had the idea that they had to write selector
and class names in German. Got it running too, on the old Digitalk compiler.
Ugly as heck, it was, this mixture between English (the class names and
selectors in the base image) and German. Caused a lot of problems with foreign
consultants who came in. Oh, and when they switched from OS/2 to Windows, most
of the multi-lingual code got hosed. They couldn't get it out of Team/V, and
couldn't get it to compile. YMMV.

Cheers
--
Joseph Pelrine [ | ]
MetaProg GmbH
Email: [hidden email]
Web:   http://www.metaprog.com

"If you don't live on the edge, you're taking up too much space" -
Doug Robinson

> FWIW - I once had a customer who had the idea that they had to write
selector
> and class names in German. Got it running too, on the old Digitalk
compiler.
> Ugly as heck, it was, this mixture between English (the class names and
> selectors in the base image) and German. Caused a lot of problems with
foreign
> consultants who came in. Oh, and when they switched from OS/2 to Windows,
most
> of the multi-lingual code got hosed. They couldn't get it out of Team/V,
and
> couldn't get it to compile. YMMV.

Hah, yes I can imagine! As I said
> > I never would have tried to define a METHOD SELECTOR with Umlauts ;-).
And yes, not for Class names, too :-).

My income comes from Java/C++/VB/ASP etc., and I think none of these
languages allow foreign chars in code, and for a good reason.

Ciao

...Jochen

Jochen,
"Jochen Riekhof" <[hidden email]> wrote in message
news:aevdgu$bir$06$[hidden email]...
[...]
> Nope, this one gives the error message on the transcript (in my case, with
> an array, e.g.: #(#Januar #Februar #März), but also with standalone #März):
>
> Error 2 on line 4 of BillingTool>>monthNames -> 'illegal character in
> literal array'
In a workspace on my system (Locale default name = 'English (United States)'),
both of these work.  When used in a method in a browser, it works if I Accept
it (via the context menu or Ctrl-S), although I get the error on the
Transcript.  If I use Reformat/Accept, then I get the "Error: illegal character
in literal array" message.

I wonder whether it's due to the difference between the two parsers, Dolphin's
(which permits it) and the RefactoringBrowser's (which doesn't seem to like
it).  Just a semi-educated guess of course.

Don

"Don Rylander" <[hidden email]> wrote in
message news:aevh92$9v1ap$[hidden email]...
> Jochen,
> "Jochen Riekhof" <[hidden email]> wrote in message
> news:aevdgu$bir$06$[hidden email]...
> [...]
> > Nope, this one gives the error message on the transcript (in my case,
with
> > an array, e.g.: #(#Januar #Februar #März), but also with standalone
#März):
> >
> > Error 2 on line 4 of BillingTool>>monthNames -> 'illegal character in
> > literal array'
> In a workspace on my system (Locale default name = 'English (United
States)'),
> both of these work.  When used in a method in a browser, it works if I
Accept
> it (via the context menu or Ctrl-S), although I get the error on the
> Transcript.  If I use Reformat/Accept, then I get the "Error: illegal
character
> in literal array" message.
>
> I wonder whether it's due to the difference between the two parsers,
Dolphin's
> (which permits it) and the RefactoringBrowser's (which doesn't seem to
like
> it).  Just a semi-educated guess of course.

Most likely, this is the case. If you wish to change the RB's scanner to
accept the character, you can change the SmalltalkScanner class>>initialize
method (and then re-evaluate it). There are other places where it needs to
be synced up with Dolphin's definition. For example, the RB will support a
binary method named #± (plus/minus), but Dolphin doesn't support this. Since
the RB was initially created on VW, it supports the VW characters (circa
1995).


John Brant