[developers] Distinguishing between orthographemic and non-orthographemic rules

[Ann Copestake]

yes, you're right, the conventions are a mess.  I'm on holiday now for 
just over a week but will put this on the todo list to think about after 
I'm back,

All best

Ann


On 01/07/2016 16:30, Woodley Packard wrote:
> Thanks, Ann and Francis.
>
> I agree with Ann’s improved characterization, of course, and also that 
> a warning would be helpful.  I can have ACE do two things:  (1) warn 
> if the STEM value is not constrained to be string or some subtype 
> thereof, and (2) default to the empty string when an unexpected value 
> comes up during actual processing, but print a runtime warning.
>
> I think we ought to take this opportunity to further clarify though 
> the exact mechanism for flagging which category a rule belongs to. 
>  The obvious and nearly status quo convention would be that the 
> non-TFS mechanism is invoked when %prefix or %suffix is present in the 
> specification of the rule.  At the moment we also invite rules into 
> that category when there is an irregular form declared in irregs.tab 
> even if no %prefix and %suffix is declared; arguably it would be more 
> transparent to add a %irregular declaration in-situ before this is 
> legal (and forbid irregs.tab entries for undeclared orthographemic rules).
>
> There may also be vestiges of other conventions laying around, such as 
> flagging by whether or not STEM is reentrant and by ND-AFF.  The 
> latter is or was used by the ERG (see spelling-change-rule-p from 
> user-fns.lsp, reproduced below; I have no sense of whether this is 
> currently coherent since ACE does not appear to heed it).  If there 
> isn’t a clear need for them I propose that any such mechanisms be 
> deprecated in favor of something fully declarative and uniform.
>
> -Woodley
>
> ERG:
> (defun spelling-change-rule-p (rule)
> ;;; a function which is used to prevent the parser
> ;;; trying to apply a rule which affects spelling and
> ;;; which should therefore only be applied by the morphology
> ;;; system.
> ;;; Old test was for something which was a subtype of
> ;;; *morph-rule-type* - this tests for whether needs affix:
> ;;; < ND-AFF > = + (assuming bool-value-true is default value)
> ;;; in the rule
> (let ((affix (get-dag-value (tdfs-indef
> (rule-full-fs rule)) 'nd-aff)))
> (and affix (bool-value-true affix))))
>
> JACY:
> ;;;
> ;;; detect rules that have orthographemic variation associated to 
> them; those
> ;;; who do should only be applied within the morphology system; this 
> version is
> ;;; a little complicated because we change from a full-form set-up to 
> one with
> ;;; on-line morphology during the course.
> ;;;
> (defun spelling-change-rule-p (rule)
> (rule-orthographemicp rule))
>
>> On Jul 1, 2016, at 6:29 AM, Francis Bond <bond at ieee.org 
>> <mailto:bond at ieee.org>> wrote:
>>
>> On Thu, Jun 30, 2016 at 3:17 PM, Woodley Packard
>> <sweaglesw at sweaglesw.org <mailto:sweaglesw at sweaglesw.org>> wrote:
>>> In the case of Jacy, it seems that the rule 
>>> "vbar-monotransitivization-c-lrule" neither declares orthographemic 
>>> changes (by %suffix, %prefix, or entries in the irregulars table) 
>>> nor declares a value for the mother’s STEM.
>>
>> I think it would be ok to push the burden for this onto grammar
>> developers --- no need for the processor to guess.  In this case STEM
>> should be linked, the rule and a couple of others are poorly written
>> and will be fixed.  Perhaps a friendly warning if this case is seen
>> when compiling the grammar could help us avoid the issue in the
>> future?
>>
>>
>> -- 
>> Francis Bond <http://www3.ntu.edu.sg/home/fcbond/>
>> Division of Linguistics and Multilingual Studies
>> Nanyang Technological University
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.delph-in.net/archives/developers/attachments/20160708/77a08b6b/attachment.html>