Friday, August 08, 2003

Nachamu parsing issue:

The third pasuk in the haftara (Yeshaya 40:3), states, "kol korei bamidbar panu derech hashem, yashru ba'arava mesila lelokeinu." There are two ways of translating this pasuk. The first, and more famous one, is "a voice cries out in the wilderness: clear a path of Hashem..." The second is "a voice cries out: in the wilderness clear a path of Hashem..." The difference is that in the first one, "bamidbar," "in the wilderness," is where the voice calls out, while in the second, it is where they should clear a path.

Doing a search on google for "a voice cries in the wilderness" (quotes included) reveals many results of each (results are skewed differently for searches of "a voice cries out in the wilderness," with the extra word "out"). JPS's translation has the clearing, rather than the crying, happening in the wilderness.

Ibn Ezra *seems* to say that the voice is in the wilderness, for he says in his commentary that the voice calls "panu," "clear," rather that "bamidbar."

I think that the dictates of Biblical poetry strongly recommend that bamidbar is part of the quote. The full pasuk is:
A voice calls:
(In the wilderness) (clear) (the path of Hashem)
(make plain) (in the desert) (a highway of our G-d)

(In the wilderness) (bamidbar) matches (ba'arava) (in the desert)
(clear) (panu) matches (make plain) (yashru)
(the path of Hashem) (derech Hashem) matches (a highway for our G-d) (mesila lelokeinu)

If you take bamidbar outside the quote, you lose the lovely parallelism.

More than this, the trup (cantillation) on the pasuk represents a very ancient tradition of how to parse the psukim, and it has the major dichotomy (the etnachta) by derech Hashem, splitting the pasuk in twain:

(A voice calls) (In the wilderness) (clear) (the path of Hashem) {MAJOR DICHOTOMY}
(make plain) (in the desert) (a highway of our G-d)

Within the first section, the first MINOR DICHOTOMY, in the form of a zakef katon, splits the subsection in twain, again.

(A voice calls) {MINOR DICHOTOMY}
(In the wilderness) (clear) (the path of Hashem) {MAJOR DICHOTOMY}

There are further minor dichotomies, but they simply break up the quote into smaller pieces until none contains three words. So, the trup unambiguosly supports the wilderness being where they clear, rather than where the quote is spoken.

I don't think this means Ibn Ezra would argue. The problem is that it seems that the medieval meforshim only understood the trup to consist of conjunctive (avadim/mesharsim) accents which bind and disjunctive (melachim) accents which split or cause a pause. Some made multiple levels of these accents in terms of power of pause, but they did not seem to see the trup for what it is, a continuous dichotomy, that is, continually splitting subsections in twain, or determining of two disjunctive accents of equal weight, which takes precedence.

Explanation: Warning: very technical, but you might learn something
In this specific case, there are three accents which might serve as the first minor dichotomy. There is a zakef katon on "korei," "calls." There is a zakef gadol on "bamidbar." Finally, there is a tipcha on "panu," "clear."

Let us consider each candidate to be the first minor dichotomy (that is, that which breaks the half-clause of our pasuk in two) in turn.

(First, you must know that specific accents serve to break clauses in two, and those accents are chosen as a function of the accent marking the end of the clause and the number of works the accent stands from the end of the clause it breaks up.)

Can it be the tipcha on "panu?" Absolutely not, because that would form a clause which ends in a tipcha. Such a clause, when it would be broken further in two, would need to be proken by means of the tevir accent, but there is no tevir earlier in the pasuk, but rather two zekefim, which can never break up such a tipcha-ending clause, and are thus completely out of place.

Can it be the zakef gadol on "bamidbar?" Absolutely not, first and formost because a zakef gadol only occurs when it breaks a clause it two and the portion beforehand is only the word on which it stands. That is, if this were the break, it would need to be a zakef katon, rather than a zakef gadol. Further, even were it a zakef katon, it would form a clause ending in zakef katon, and such a clause we would expect to be broken up in two by a pashta or a yetiv, yet it is not. There is a zakef katon beforehand, and that cannot break up a clause ending in zakef katon, and thus it stands out of place.

Now, for the correct candidate. The minor dichotomy is the zakef katon on "korei." The only word before it is "kol," which gets the subservient conjunctive accent munach. (We do not break a clause in twain if it has less than three words.) The second part of the clause is then fairly long, and ends in the etnachta that we had from before. It can nicely be broken in twain by the zakef gadol on bamidbar. Then, we have "panu derech hashem" ending in an etnachta. Again, we break up the clause, this time on "panu," with a tipcha. Finally, we have "derech Hashem," which is two words, so we need to split no more, so derech gets the conjunctive accent mercha.

Why did we sometimes split the etnachta with a zakef katon, sometimes zakef gadol, sometimes with tipcha? As I said earlier, it is a function of the specific accent at the end of the clause AND the amount of words away from the accent. One or two words away merits a tipcha. Three or more merits a zakef. 8 or 9 or more merits a segol (as is munach zarka munach segol), which is a special form of zakef. Further, when only one word will be before the clause and other conditions are met, we use a zakef gadol rather than zakef katon.

End Explanation

Now, Ibn Ezra was not thinking of this, and so he could explain the pasuk either way, since zakef gadol and zakef koton seem to be equal accents. He certainly would never go against the trup except under extreme duress, which does not exist in this case. So, I think this is the correct explanation of this pasuk.

Have a restful shabbos.

No comments:


Blog Widget by LinkWithin