Re: Germanic strong verbs class VI

From: tgpedersen
Message: 45744
Date: 2006-08-16

--- In cybalist@yahoogroups.com, Piotr Gasiorowski <gpiotr@...> wrote:
>
> On 2006-08-16 10:49, tgpedersen wrote:
>
> > Check this out:
> > www.angelfire.com/rant/tgpedersen/tw.html
> > I suspect it's a loan.
> > Kortlandt fails to answer why
> > 1) it violates IE root constraints
>
> His reconstruction is *t(e)h2g-, which doesn't
> violate any root constraints.

You're right, I was being too hasty again.
Anyway, I think he should consider the NWBlock option
and reconstruct PIE *tetk- -> NWBlock id. instead.
The Gothic and ProtoGermanic perf.pl. e: of classes
IV and V was explained by Gunnar Møller (I think
it was) as from simplifying the reduplication
syllable C1eC1´V- > C1e:-, where C1´ is a possibly
Verner-affected version of C1, eg **gegbam -> *ge:bam.
The same get-rid-of-reduplication rule would
automatically apply to *tetk- > te:k- in Gothic
(same as with other class IV and V verbs),
without us having to invoke the whole machinery
of preglottalization for voiced unaspirated (and I still
think prenasalization would work too: PIE -Nd- etc >
PGerm. -n.t- ie. -ht-, or -tt-, as required).
Kortlandt:
"
Secondly, the restructuring of the reduplicated preterit
in North and West Germanic is based on the present stem,
e.g. lét < *leæ:t, not **liót, cf. hlióp 'leaped' < *hleaup,
Gothic lailot 'let', aiauk 'added'.
"
That's wrong. Danish de-reduplicates strong verbs using
the root vowel instead of lengthening the reduplication
vowel, in contrast even with Swedish:
holdt, Sw. höll
faldt, Sw. föll
lod, Sw. lät
Therefore in general *le:t- < pl. *lelt-, but
in Danish *lo:t < sg. *lelo:t
A small group of verbs in Dutch have -ie- in the
preterite. That might be from a compensatorily
lengthened reduplication vowel too.
So K.'s objection to Mattausch' proposed
'Neubildung' ON táka from pret. tók is
not valid.


> > 2) how it sneaked itself into class VI
>
> He does answer that (pp. 62-63). One may disagree
> with his explanation, but he certainly doesn't
> _fail_ to address question 2.
>

True too, but he misses a chance to explain the
whole class.


Torsten