Re: 'File permission error' - discussion, question about the parsing..
Re: 'File permission error' - discussion, question about the parsing..
- Subject: Re: 'File permission error' - discussion, question about the parsing..
- From: Jim Witte <email@hidden>
- Date: Mon, 4 Apr 2005 13:24:48 -0500
On Apr 3, 2005, at 10:43 AM, kai wrote:
block? Something like an 'ignoring errors' clause?
Don't think so, Jim.
If iTunes had some filtering mechanism (which it doesn't appear to), the ideal way might be to filter out missing files with something like: < set (volume adjustment of every track of playlist named tPlaylist whose location is not missing value) to 0 >. No go there, though.
I therefore think you may be stuck with a repeat loop - something along the lines of:
John Stewart said to just wrap the "set volume adjustment of every track of playlist to 0" in a try block, which would ignore ALL errors. But your idea is a good one. If I get the scholarship to the WWDC this year, I'll have to mention it to one of the AScript people (although I'm certain there are people on the list who are more well-connected...)
A question though: if I write:
set (volume adjustment of every track of playlist named tPlaylist) to 0
it works, but if I remove the parens to get
set volume adjustment of every track of playlist named tPlaylist to 0
It says expected end of line but found 'to'. How is AS (trying) to parse the second statement. In Enlgish, (I'd think) the appropriate (probably simplified) production rules would be {PP->P+NP, NP-> [Det]+[ADJ]+N+[PP]} where the P class is restricted to {of, whose, with without, having}, but NOT including {to}. This would mean that the parsing of the 'of every track..' PP would stop at the 'to' word (not being in the restricted set of P, and so '[PP, of every track [PP, of playlist [ADJ, named] tPlayList]]' would end there, and then the 'to 0' would hook to a higher node on the parsing tree..
So why is the coercision (or explicit specification of the end of the string of PP's) needed?
Of course, there may very well be a situation where these simplified production rules break down, and something more complication (and probably less deterministic) would have to be used to deal with ambiguities, like a neural net of some kind, which seems a) a BIT to complicated for just AS, and b) prone to errors if it chooses the wrong parse tree.
Jim
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Applescript-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden