> (Aside: you would not believe what I had to go through to get even a > modestly short url for this book.)
Thanks. Reading this thread and your contribution to try to pull away from sterile debate, I realize now, a fear strikes me that I may have misjudged and treated you too harshly in past threads. Besides, it seem clear to me that you have demonstrated coherence in your announced motivation in this thread. Finally I begin to realize that some people are doing much more harm to RM than you.
For the above reasons, I apologize to some of the treatment I have given you. Some people deserve more than you. Therefore, I am sorry to inform that you just lost your fraud status,rank and all the priviledges that come with it..;)
> mAsterdam wrote: > ... > > Yes, a reference (I like the term) is what the (i) defines ... > ...
> Not to tout SQL of which I know very little but I believe it or at least > some implementations, uses the keyword "REFERENCES". For all I know, > the same implementations also support "FOREIGN KEY" phrase. If that's > so, I'd be curious to know from SQL experts whether the typical > implementations require the latter to reference a "primary key" and if > the former doesn't. If that's so I'd be really curious to hear of > examples where REFERENCES is superior in practice to "FOREIGN KEY".
I would be very hesitant to draw deep philosophical inferences from the choices that the designers of SQL made regarding keywords. The same goes for any other computer language.
And I say htis as someone who likes SQL a bit more than the purists of this newsgroup.
>>>Yes, a reference (I like the term) is what the (i) defines ...
>>...
>>Not to tout SQL of which I know very little but I believe it or at least >>some implementations, uses the keyword "REFERENCES". For all I know, >>the same implementations also support "FOREIGN KEY" phrase. If that's >>so, I'd be curious to know from SQL experts whether the typical >>implementations require the latter to reference a "primary key" and if >>the former doesn't. If that's so I'd be really curious to hear of >>examples where REFERENCES is superior in practice to "FOREIGN KEY".
> I would be very hesitant to draw deep philosophical inferences from the > choices that the designers of SQL made regarding keywords. The same goes > for any other computer language.
> And I say htis as someone who likes SQL a bit more than the purists of this > newsgroup.
> >>>Yes, a reference (I like the term) is what the (i) defines ...
> >>...
> >>Not to tout SQL of which I know very little but I believe it or at least > >>some implementations, uses the keyword "REFERENCES". For all I know, > >>the same implementations also support "FOREIGN KEY" phrase. If that's > >>so, I'd be curious to know from SQL experts whether the typical > >>implementations require the latter to reference a "primary key" and if > >>the former doesn't. If that's so I'd be really curious to hear of > >>examples where REFERENCES is superior in practice to "FOREIGN KEY".
> > I would be very hesitant to draw deep philosophical inferences from the > > choices that the designers of SQL made regarding keywords. The same goes > > for any other computer language.
> > And I say htis as someone who likes SQL a bit more than the purists of this > > newsgroup.
> What do you like about it?
It's "good enough" for a lot of purposes (to quote a post fo your from a few weeks back).
>>>>>Yes, a reference (I like the term) is what the (i) defines ...
>>>>...
>>>>Not to tout SQL of which I know very little but I believe it or at least >>>>some implementations, uses the keyword "REFERENCES". For all I know, >>>>the same implementations also support "FOREIGN KEY" phrase. If that's >>>>so, I'd be curious to know from SQL experts whether the typical >>>>implementations require the latter to reference a "primary key" and if >>>>the former doesn't. If that's so I'd be really curious to hear of >>>>examples where REFERENCES is superior in practice to "FOREIGN KEY".
>>>I would be very hesitant to draw deep philosophical inferences from the >>>choices that the designers of SQL made regarding keywords. The same
> goes
>>>for any other computer language.
>>>And I say htis as someone who likes SQL a bit more than the purists of
> this
>>>newsgroup.
>>What do you like about it?
> It's "good enough" for a lot of purposes (to quote a post fo your from a > few weeks back).
As is assembler. You answer is a good answer to the question: "Why do you use it?" I asked, "What do you like about it?" Can you do any better than an analog for "It doesn't sweat too bad for a fat chick."
>>>are tables with multiple candidate keys, one of them is chosen as the so >>>called "primary key", and all foreign key references to that table are
> made
>>>by way of that key.
>>Can you list a few ways primary keys make things easier?
> Yes, but with the caveat that they probably don't have any theoretical > significance. > ...
As John Lennon said, "You know my name, look up my number". Just to drop a couple more names, I once heard Codd speak for an hour about nothing except Christie Brinkley's phone number. I'm quite sure what he called primary keys and other people call candidate keys were part of his theory, just as they are part of my understanding of that theory.
They are the most fundamental way to make inferences. Fundamental because if the computer is ignored one can infer from them more or less without any relational operators. In fact, that was true before Codd.
I'll grant that a system could get the same answers without keys, but it would take a lot more effort and a lot more plumbing. If we didn't have them, I'd like to know how we would ensure that a person doesn't have more than one name. The same ways that people did that with IMS or IDMS? Uggh!
Marshall wrote: > mAsterdam wrote: >> Of course. But then several subthreads (contributions by paul c, >> Cimode and Marshall) would be irrelevant. I am sure Marshall >> would have had the courtesy to point that out.
> Um, I want to point out that I'm having trouble keeping up with the > bandwidth of posts on this thread. I want to respond to as much as > I can but I'm falling behind!
Take it easy. The posts will still be here next week. Thank you for starting this thread.
>>> If S(b) is actually a shorthand notation for >>> S(b,b0...bn) then one can express that b is a ck by: >>> forall b: exists c0,...cn: forall b0...bn: >>> S(b,b0...bn): b0 = c0 ... bn = cn >>> Correct? >> In Marshall's notation that would be >> (1) {b} -> {b0,...bn} =def= >> (2) forall S(b, b0,...bn): forall S(b, b0'...bn'): >> (3) b=b' => b0 = b0' ... bn = bn'
>> I think.
> Yes. (Where the minterms to the left of the => in the > third line are connected by "and".)
Check.
> Note that for this > to be a key definition {b, b0, ... bn} must be every > attribute of S.
!
> This is not the case for the definition of referential integrity > I posted earlier, in which attribute a of R is restricted to > values of attribute b of S
> forall R(a): exists S(b): a = b
> In this case, both R and S may have additional attributes; > all we're saying is that R projected over a is a subset of > S projected over b.
> Of the three lines I quoted above, line (1) is just the standard > notation for functional dependencies as best I understand > it. The "=def=" is also a fairly standard shorthand for > "is defined to be equal to."
On the blackboard: three horizontal lines above each other, a kind of thick equals sign. Does this (unicode 2261) come through: ≡ or does it look like gibberish?
> In other words, what I was > doing was *defining* how a functional dependency would > be encoded into a relvar-range-restricted FOL constraint. > Lines (2) and (3) are the constraint itself; only these would > be passed to the system.
>> Note that for instance "exists c0,...cn:" simply disappears, >> because of
>>> We can use the existing attribute >>> names as the names of the logic variables. >> , a chosen ambiguity I already pointed out: >> P(a) denotes both 'P has an attribute a' as well as a value for a.
>> This is just how I understood it. >> To be sure you shouldn't ask me.
> Hope this makes things a bit clearer.
Yes, thanks. The only little thing left to do is to convince DBMS vendors and the SQL committee that references should not require keyness at the referenced side :-)
On Feb 24, 2:01 am, "Marshall" <marshall.spi...@gmail.com> wrote:
> I hope no one will mind too much if I take a break from our > usual sort of discussion and talk about database theory for > a bit.
OK, Marshall
--because I take this as a dig (perhaps simply being overly sensitive in this ng), knowing that my interest is in data modeling and only in "database theory" as it relates to data modeling and software development, rather than in "doing" some pure form of database theory; --because I do not "feel" it is a friendly dig, but rather a form of a "good ole' boy" self-righteous dig --because I'm sick of letting the really nasty digs (which this is not) slide by, not having figure out what to do with them to date; --because this ng seems to have decided it is acceptable behavior to be nasty while I find it indefensible, a sad part of this ng, and very unfortunate; --because I would rather do something about it than bemoan this fact; --and because I think you along with many others have the capacity to rise above such nastiness, I'm going to reply to this.
Please review the charter below and note that this charter does not indicate that any one of the below topics is somehow better than another in this newsgroup. If this ng is no longer about data modeling or if it is not acceptable to discuss and ask questions about database theory from the perspective of a data modeler (a user of database theory), or if this ng is strictly about relational theory, then let's change the charter so that is clear.
Then I still might not understand why this ng does not self-police by working in force to clean it up (individuals do attempt it at times, but it seems it will take more than what one individual can do on their own), but at least I would understand whether my questions were on topic according to the new charter rather than relying on the current one. I do not and would not intend to start discussions that are out of the scope of the charter for the ng.
I don't know the ng voting process for changing a charter, but I'm pretty sure it can be changed. We could change it as indicated above, or we could add a clear statement about what we consider unacceptable behavior, or we can change it in any other way.
So, what would you like to see as the charter moving forward, or is it acceptable as it is? If it is acceptable as it is, if there are discussions about data modeling or about database theory from the perspective of a data modeler (an end-user) or if someone questions a premise of relational theory and some do not find such topics interesting, ignore them, get over it, no need to dig in a way that is "anti-" other people (friendly digs are, of course, always acceptable). Your take? --dawn
Charter of cdt below---------------------------->
CHARTER: Discussion of topics relating to advances in database technology including debate on theoretical, prototypical and performance aspects of Database Systems, Data Modelling and Logical and Physical Database Design.
NOTE: Specifically excluded are discussions relating to implemented DBMS whether commercial or not.
> > (Aside: you would not believe what I had to go through to get even a > > modestly short url for this book.)
> Thanks. Reading this thread and your contribution to try to pull away > from sterile debate, I realize now, a fear strikes me that I may have > misjudged and treated you too harshly in past threads. Besides, it > seem clear to me that you have demonstrated coherence in your > announced motivation in this thread. > Finally I begin to realize that some people are doing much more harm > to RM than you.
> For the above reasons, I apologize to some of the treatment I have > given you. Some people deserve more than you. Therefore, I am sorry > to inform that you just lost your fraud status,rank and all the > priviledges that come with it..;)
Thank you for saying so. For myself, I find it difficult to admit publicly my mistakes, so I recognize this may not have been an easy post to make.
On Feb 26, 2:08 pm, Bob Badour <bbad...@pei.sympatico.ca> wrote:
> Walt wrote:
> >>What do you like about it?
> > It's "good enough" for a lot of purposes (to quote a post fo your from a > > few weeks back).
> As is assembler. You answer is a good answer to the question: "Why do > you use it?" I asked, "What do you like about it?" Can you do any better > than an analog for "It doesn't sweat too bad for a fat chick."
You didn't ask me, but I can tell you what *I* like about SQL:
select, project, extend, union, aggregate, and especially join! Join is awesome.
On 27 fév, 16:30, "Marshall" <marshall.spi...@gmail.com> wrote:
> On Feb 26, 10:41 am, "Cimode" <cim...@hotmail.com> wrote: > Thank you for saying so. For myself, I find it difficult to admit > publicly > my mistakes, so I recognize this may not have been an easy post > to make.
Not really. Secret is to put things in perspective and be honest and coherent toward oneself. Lately, I have come to realize that I underestimated the state of decay in which database management is because of ignorance. I see now clearly that such state of decay is not only european (I live in France) but also american and has many shapes among which sme I ignored. As a consequence, I reevaluated my priorities to promote truth and fight ignorance with appropriate evaluation of the local context.
While I identified that you are handicapped by a poor mathematical background whithout being aware of it, you are fighting the right fight in general computing terms thanks to the enlightnment that is brought by RM concepts. I just shifted my targets to more damageable enemies of science than you will ever be (no offense intended :)).
My pride as a person may take a slight hit but I have thick skin and there are more important things than my simple ego which is relatively less important than the reason we are here today.
On Feb 27, 3:35 pm, "Marshall" <marshall.spi...@gmail.com> wrote:
> You didn't ask me, but I can tell you what *I* like about SQL:
> select, project, extend, union, aggregate, and especially join! Join > is awesome.
> Oh, and constraints.
> Marshall
For a first attempt, SQL was ok, I guess. Who knows what might have happened if QUEL had been presented to the standards committee as a serious alternative to SQL though ... (Ingres users can, of course, try it and find out for themselves ;)
On Feb 24, 8:01 am, "Marshall" <marshall.spi...@gmail.com> wrote:
> I hope no one will mind too much if I take a break from our > usual sort of discussion and talk about database theory for > a bit. I feel like free associating about functional dependencies.
[ snippage ]
Best thread in ages, BTW. Thanks to everyone for plenty of stuff to chew over ;)
On Feb 27, 7:59 am, "Cimode" <cim...@hotmail.com> wrote:
> While I identified that you are handicapped by a poor mathematical > background whithout being aware of it, you are fighting the right > fight in general computing terms thanks to the enlightnment that is > brought by RM concepts.
Please let me make a small correction to the above if I may: I am in fact excruciatingly aware of my limited mathematical background.
On Feb 27, 9:26 am, "Tony D" <tonyisyour...@netscape.net> wrote:
> On Feb 27, 3:35 pm, "Marshall" <marshall.spi...@gmail.com> wrote:
> > You didn't ask me, but I can tell you what *I* like about SQL:
> > select, project, extend, union, aggregate, and especially join! Join > > is awesome.
> > Oh, and constraints.
> > Marshall
> For a first attempt, SQL was ok, I guess. Who knows what might have > happened if QUEL had been presented to the standards committee as a > serious alternative to SQL though ... (Ingres users can, of course, > try it and find out for themselves ;)
Do you have any references for QUEL for someone who would like to read about the language? If one is interested in learning about functional languages, or OO languages, one has many to choose from, and can see many different approaches being tried, and compare features, etc. For relational languages, there is SQL, and not a lot else. Setl or Nestl? Not altogether algebraic. There's TutD, of course. I am impressed with its semantics, but I can't say I find it compelling. Its relational features are of course very advanced but outside of that it's quite staid. My aspiration is for the advanced relational semantics of TutD combined with some of the goodness of modern functional languages. My expectation, Tony, is that you would be sympathetic for the desire for higher order functions. :-)
In any event, I expect I would enjoy reading about QUEL.
On 27 fév, 19:14, "Marshall" <marshall.spi...@gmail.com> wrote:
> On Feb 27, 7:59 am, "Cimode" <cim...@hotmail.com> wrote: > > While I identified that you are handicapped by a poor mathematical > > background whithout being aware of it, you are fighting the right > > fight in general computing terms thanks to the enlightnment that is > > brought by RM concepts.
> Please let me make a small correction to the above if I may: > I am in fact excruciatingly aware of my limited mathematical > background.
You are not to blame because this is a result of an educational system that does not place math as a priority in learning. Having spent 6 years in your country, I found the teaching of math at university level quite unsufficient both in rigor and level. At university graduate level, I was astonished correcting my instructors on fallacies and themes I had discovered mostly at freshman years in french university system.
What I begin to believe is that people who advocate RM in France and (europe maybe) probably have a more mathematical fundamentalist *bias* into studying RM than in the US where the computing perspective defined by the gang of four is predominant. Such bias difference on the same model may explain some of the difficulties getting some issues I have found to communicate databse theory with american audiences....
For instance, I have found puzzling and sometime irritating the explanation of mathematical concepts which seemed elementary and quite obvious in their impact over RM expression and formalism in my perspective but not to the computing approach to which americans are more accustomed.
It was my responsability to cope with this and adapt to this mode of communication but my frustration not to be able to communicate more efficiently and abstractly took over. For such lack of patience, I blame myself for some of the treatment (deserved or not) I have reserved to some people around.
I hope this ironic mea culpa makes sense and that we will be to communicate better in future. RM is probably the best thing that happened not only to computing but to math as well in the past 50 years...
On Feb 26, 3:22 pm, mAsterdam <mAster...@vrijdag.org> wrote:
> Marshall wrote:
> > Of the three lines I quoted above, line (1) is just the standard > > notation for functional dependencies as best I understand > > it. The "=def=" is also a fairly standard shorthand for > > "is defined to be equal to."
> On the blackboard: three horizontal lines above each other, > a kind of thick equals sign. Does this (unicode 2261) > come through: ≡ or does it look like gibberish?
Yes, that's the one. Comes through just fine. (It's always a shock when my browser renders anything more challenging than ASCII.)
>>> Does this (unicode 2261) >>> come through: ≡ or does it look like gibberish?
>> Yes, that's the one. Comes through just fine. (It's always >> a shock when my browser renders anything more challenging >> than ASCII.)
> Brace yourself before you scroll down :-)
> Playing a little with Unicode:
> Mp (Marshall/paul) referential integrity =def= > forall R(a): exists S(b): a = b
> becomes
> R(a) references S(b) ≡ > ∀R(a): ∃S(b)| a=b
> or
> (using レ = katakana re for references)
> R(a) レ S(b) ≡ > ∀R(a): ∃S(b)| a=b
> Classic referential integrity (no need, says paul c)
> (ル = ru for references unique)
> R(a) ル S(b) ≡ > ∀R(a): ∃!S(b)| a=b
Held my breath as I scrolled down. Congrats. Maybe some old-timers and all the levelers will object, but I'm all in favour of anything that encourages precision here, at least if I can figure out get the unused letters on my keyboard to echo them.
Once heard a guy say what was wrong with Linux - 1) fonts, 2) fonts, 3) fonts.
On Feb 27, 6:29 pm, "Marshall" <marshall.spi...@gmail.com> wrote:
> Do you have any references for QUEL for someone who would like > to read about the language?
Well, you can go to http://www.ingres.com and download a GPL edition of Ingres 2006 and the documentation, and read about QUEL and even try it out ;) Sadly, QUEL is in something approaching deep freeze, as Ingres don't add QUEL specifics for new things they add to the SQL implementation, but it's pretty much industrial strength - to the point that many of Ingres' system catalogues are QUEL views.
> If one is interested in learning about > functional languages, or OO languages, one has many to choose > from, and can see many different approaches being tried, and > compare features, etc. For relational languages, there is SQL, > and not a lot else.
I was going to bemoan this in my first post, but opted not to. Has anyone ever made publicly available an implementation of the likes of Modula-R, I wonder ?
> Setl or Nestl? Not altogether algebraic. There's TutD, of course. I > am impressed with its semantics, but I can't say I find it compelling.
I wish I could agree about the semantics, but I'm not yet convinced. I'm also not 100% convinced about the utility of possreps. What exactly do they get me that conversion functions don't, with fewer additional concepts ? The utility I *do* see for them is in version control. Imagine you have a database with user defined types, and you need to add some additional detail to one of those types. Without possreps, you may end up having to copy the data out, amend the datatype definition, then copy the data back in. Hardly a vote grabber. (That's (a) well off the topic and (b) overly practical, I know...)
> Its relational features are > of course very advanced but outside of that it's quite staid. > My aspiration is for the advanced relational semantics of > TutD combined with some of the goodness of modern > functional languages. > My expectation, Tony, is that you > would be sympathetic for the desire for higher order > functions. :-)
Now whatever gave you *that* idea, Marshall ? ;))))
Haskell + full support for relations = a very worthwhile experiment,to me.
> In any event, I expect I would enjoy reading about QUEL.
I think you would. Go for it :) Any questions, ask Roy Hann - he did have an email alias of "quelgeek" at one time, I'm pretty sure !
paul c wrote: > mAsterdam wrote: >> Mp (Marshall/paul) referential integrity =def= ... >> (using レ = katakana re for references)
>> R(a) レ S(b) ≡ >> ∀R(a): ∃S(b)| a=b
>> Classic referential integrity (no need, says paul c)
>> (ル = ru for references unique)
(ii) >> R(a) ル S(b) ≡ >> ∀R(a): ∃!S(b)| a=b
> ... Congrats.
Thanks.
Hmm...
Note (afterthought): (ii) doesn't need that b should be /defined/ as ck for relvar S (which would really be the classic ri), just that it /could/ be ck in the current relvalue S.
About the notation: Note (not afterthought): 1. that the katakana re, レ for _reference_ could read as 'check' (it looks like a check mark), verbose 'check that there is', and 2. the katakana ru, ル for _reference_unique_ as 'check one' (it looks like a check mark with a sloppy 1 before it), verbose 'check that there is only one'.
Marshall wrote: > On Feb 27, 7:59 am, "Cimode" <cim...@hotmail.com> wrote:
>>While I identified that you are handicapped by a poor mathematical >>background whithout being aware of it, you are fighting the right >>fight in general computing terms thanks to the enlightnment that is >>brought by RM concepts.
> Please let me make a small correction to the above if I may: > I am in fact excruciatingly aware of my limited mathematical > background.
As I am. When exceptions have been made, here and there, I've also been pained to notice how we can break a theory and then can no longer depend on what it predicts. However, when we make a theory, the pre-eminent decisions are whether we are happy with it and whether we are willing to abide by it for some limited purpose. We must agree to let the math try and help us before all else but we must keep it in its place, subservient to our motives, otherwise we become slaves.
mAsterdam <mAster...@vrijdag.org> wrote: >paul c wrote: >> mAsterdam wrote: >>> ... >>> A rephrase to (i) could be:
>>> <reference> >>> (i a) >>> A relation R with attribute a (written as R(a)) having >>> a as a reference into S(b) >>> is expressed as follows:
>>> forall R(a): exists S(b): a = b
>>> Note that b need not be a ck to S, hence 'into', not 'to'. >>> </reference>
>>> But what exactly is the reference referencing?
>> I'm sure there is a term for that kind of English phrasing. For myself, >> the phrase "reference referencing" seems unnecessarily ornamental.
>Ornamental? I am a non-native speaker of English - maybe a >native speaker (you are, aren't you?) can put into less words >than this what I mean with it.
>How would you say: "The stuff referenced is not a tuple in S, >but a subset of S".
"What is referred to is not a tuple in S, but a subset of S."
I am confused by it though. Do you mean "What is referred to is a subset of S." (emphasis on set) or "What is referred to is a tuple in a subset of S." (subset definition not specified)?
>> In ordinary English, one relation references another.
^^^^^^^^^^ "refers to".
>One relation may reference several others. >What do you call the individual referencing attribute sets?
I do not know.
>What do you call the stuff being referenced?
"referee" is possible, but probably "target" or "object".
[snip]
Sincerely,
Gene Wirchenko
Computerese Irregular Verb Conjugation: I have preferences. You have biases. He/She has prejudices.
>>>><reference> >>>>(i a) >>>> A relation R with attribute a (written as R(a)) having >>>> a as a reference into S(b) >>>> is expressed as follows:
>>>> forall R(a): exists S(b): a = b
>>>> Note that b need not be a ck to S, hence 'into', not 'to'. >>>></reference>
>>>>But what exactly is the reference referencing?
>>>I'm sure there is a term for that kind of English phrasing. For myself, >>>the phrase "reference referencing" seems unnecessarily ornamental.
Passive voice. Rephrasing in the active voice, one gets "But what exactly does the reference reference?" or "But what exactly does the reference refer to?"
I think of the passive and reflexive voices as 'weak' but I suppose 'ornamental' works too.
>>Ornamental? I am a non-native speaker of English - maybe a >>native speaker (you are, aren't you?) can put into less words >>than this what I mean with it.
Plenty of native english speakers would use the passive voice just as mAsterdam did. I find continental europeans no more likely to use the passive or reflexive voices than anglophones. South asians on the other hand...
A continental european is much more likely to use a stronger active voice like: "But to what exactly refers the reference?"
>>How would you say: "The stuff referenced is not a tuple in S, >>but a subset of S".
A tuple is a subset of S. I would simply say the value exists in S.
> "What is referred to is not a tuple in S, but a subset of S."
> I am confused by it though. Do you mean "What is referred to is > a subset of S." (emphasis on set) or "What is referred to is a tuple > in a subset of S." (subset definition not specified)?
He wants to emphasize the relative cardinality could be greater than 1.
>>>In ordinary English, one relation references another.
> ^^^^^^^^^^ > "refers to".
Or references. In data management, one more often sees the verb "to reference" than the verb "to refer to". I don't know whether the SQL keyword drives that preference or whether someone chose a less-popular verb to emphasize a precise technical definition.
> paul c wrote: > > mAsterdam wrote: > >> Mp (Marshall/paul) referential integrity =def= > ... > >> (using レ = katakana re for references)
> >> R(a) レ S(b) ≡ > >> ∀R(a): ∃S(b)| a=b
> >> Classic referential integrity (no need, says paul c)
> >> (ル = ru for references unique)
> (ii) > >> R(a) ル S(b) ≡ > >> ∀R(a): ∃!S(b)| a=b
> > ... Congrats.
> Thanks.
> Hmm...
> Note (afterthought): > (ii) doesn't need that b should be /defined/ as ck > for relvar S (which would really be the classic ri), > just that it /could/ be ck in the current relvalue S.
> About the notation: > Note (not afterthought): > 1. that the katakana re, レ for _reference_ could read as 'check' > (it looks like a check mark), > verbose 'check that there is', > and > 2. the katakana ru, ル for _reference_unique_ as 'check one' > (it looks like a check mark with a sloppy 1 before it), > verbose 'check that there is only one'.
> How about that for sugar coating ;-)
The idea of using katakana, esp. with abbreviations in English, to expand the symbol set, is madcap brilliance. Omedeto gozaimasu!
|
