- From: Sandro Hawke <sandro@w3.org>
- Date: Tue, 25 Sep 2007 14:05:19 -0400
- To: Chris Welty <cawelty@gmail.com>
- Cc: Michael Kifer <kifer@cs.sunysb.edu>, Sandro Hawke <sandro@w3.org>, public-rif-wg@w3.org
Chris Welty <cawelty@gmail.com> writes: > > Jeez, I'm sure glad I didn't have Michael for a professor. I'll avoid making any comments about my time having Chris as a teacher (he was a grad student, not a prof), since I dropped the class after a couple of weeks. :-) > The differences are pretty simple, though: > > A signature has a name and a set of expressions. > A signature name is just a symbol used to reference the set of expressions. > A signature expression is the standard sort of thing you might think of as a > signature Right -- that's the part that bugs me. ("Okay, here we have apples and oranges and bananas. Let's call apples, "bananas". Now, hand me a banana.") Here are names that match my intuition: (i) => bool a signature { (i i) => i, (i) => bool } a signature set MySig a signature set name MySig{(i i) => i, (i) => bool} a signature block ? (a signture set with its name) A "signature block" assigns the name to the set and has a "return value" of being the set, right? Is it worthwhile combine them? How about just having assignment, and using the name, later.... MySig = {(i i) => i, (i) => bool} a name assignment My problem with "expression" is that it's usually a general term for any linguistic construct. Those things above are all linguistic expressions in the signature language, so they all seem like "signature expressions". Maybe some of you can keep track of when a banana is a banana and when it's an apple, but that's more work than I want to do unless it's really needed. -- Sandro
Received on Tuesday, 25 September 2007 18:05:52 UTC