Re: U : Unbounded_String := "bla bla bla"; (was: Is the Writing...)

["Robert I. Eachus" <rieachus@comcast.net>]

Alexandre E. Kopilovitch wrote:

> I consulted my home linguist once more, and this time a discussion became
> slightly hot: although she confirmed genesis of Hiragana and Katakana, she
> had a big trouble with understanding your final sentence in the paragraph.
> After some discussion it appeared that she had two disagreements with your
> thesis and example: first, she insisted that the thesis is far from generally
> applicable, and actually may be true for borderline cases only; second, that
> your particular example isn't good, at least for current state of Japanese:
> if you want to write "trousers", you may write just that, not specializing a
> particular kind (the word taken from French, naturally using Katakana), and
> what is most important, all those words are different by themselves, without
> regard to particular notation.

Shrug, she is taking the point of view that a native Japanese speaker 
would: That you just know these things.  Today the Katakana version is 
never wrong, but thirty or forty years ago, it might get you in trouble 
speaking with/of a man, and definitely when speaking of what a woman was 
wearing--unless she was wearking blue jeans, and I guess then that was 
scandal enough! ;-)

But speaking as an external observer who has watched as the Japanese 
language adopted to new technology and phrases, there are no rules that 
can be reliably used in advance to determine which spelling or spellings 
will prevail.  As your friend says, the feminine implication of Hirigana 
and the foreign connotation of Katakana provide some guidance, but they 
are definitely not hard and fast rules.

> Well, this is somehow true for perhaps every language. For example, there is
> a classical "mine" for a foreigner trying to speak Russian: just shift the stress
> in the word from the second syllable to first one, and you instantly convert
> "to write" into "to urinate" (or, adding a short prefix, "to describe" into
> "to urinate on [something]"); and note that a stress is almost never showed in
> regular Russian written or printed texts.

Of course, my point was that most of the unexploded bombs in Japanese 
tend to be in written Japanese instead of the spoken langage.

> Implicit conversions for literals is the most important case, both practically
> and ideologically. So, if the choice is between "implicit conversions for
> literals only" and "no implicit conversions at all, as it is now" then I
> definitely choose first option.

Go ahead and advocate it, I certainly won't vote against it.  The tricky 
part would be proposing the language notation for binding a set of 
literals to a private type.

> I recall that there was discussion in Ada-Comment on this issue (in think in
> 2002) and the name "@" was proposed (perhaps by Robert Dewar, but I may be
> mistaken in that) for those conversions, or for some broader purpose, I don't
> remember exactly. I think that if both above conversions will have the same
> name then "@" is much better than "+" for them.

Yes, another proposal in this area that has never made it into the 
language.  It would not be hard for implementors to define a few "extra" 
unary and binary operators that programmers could define for specific types.

> Yes, sometimes it is even slightly better than "+". Perhaps just because of
> the presence of "1 *" that "+" was left out.

I have never used the "1 *" operation, preferring to define/overload 
unary "+".  But I have occasionally used say 80*" " for initial values.

> Actually no, because one can override it for derived type only, but there is
> no relation for derived type that can guarantee commutativity of the diagram.
> In other words, a type derived by extension ("with" for tagged types) does not
> inherit relations of this kind. Therefore, if you derive some type, say,
> Decorated_Unbounded_String from Unbounded_String, there will be no implicit
> conversion between String and Decorated_Unbounded_String, unless you re-establish
> the appropriate relation between them, with all associated verification.

No the operations are defined.  In some tagged type cases they become 
abstract and you have to override them, but it doesn't mean they aren't 
there.

-- 
                                                     Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig