Yes, I was disturbed by erasing into the path too. But I really can't say that it is wrong. The trick of defining the name before erasing is a good solution. Don't know why I came up with a solution that is so much more difficult and slow.
On the returned values. I never check them. Does anybody else check them? On Wed, Sep 17, 2014 at 4:50 PM, Raul Miller <[email protected]> wrote: > That's disturbing. > > Oh well, I'll stand by my other assertion - that if you don't know > whether the name exists you should assign it before erasing it. > > As for the return - it tells you whether the erase succeeded. An erase > of a name which does not exist is a success, correct? I mean, the name > is not there after it's erased. > > On the other hand, you could argue that most return values are > useless. After all, you can't eat them, even with lots of ketchup. > > Seriously, though, what application needs to find out whether or not a > name was erased? I'm still trying to wrap my head around the idea of > that being used for anything practical. > > Thanks, > > -- > Raul > > > On Wed, Sep 17, 2014 at 3:17 PM, Don Guinn <[email protected]> wrote: > > I tried erasing 'list_base_' and list disappeared from z. Also, why > bother > > with a pretty much useless return? > > On Sep 17, 2014 12:55 PM, "Raul Miller" <[email protected]> wrote: > > > >> That's easy to avoid the problem with erasing names in the path. > >> > >> Option 1: assign the name using =. before erasing it. > >> > >> Option 2: use a form of the name which specifies the locale. > >> > >> Put differently, how is it useful for erase to tell you you have made > >> a mistake when what you really want is to not make the mistake in the > >> first place? > >> > >> Thanks, > >> > >> -- > >> Raul > >> > >> On Wed, Sep 17, 2014 at 2:13 PM, Don Guinn <[email protected]> wrote: > >> > It has always bothered me that erase will erase names in the path if > the > >> > name does not exist in the current locale. It kind of makes sense to > do > >> > that, but erasing names from other locales, particularly the z locale > >> does > >> > not seem right either. I created my own erase to only erase from the > >> > current locale but it is not pretty and seems inefficient if used a > lot. > >> > Perhaps adding a dyadic option to 4!:55, values 0 and 1. Zero being > the > >> > current way to erase from the path and the default, and 1 restricting > >> erase > >> > to the current locale. > >> > > >> > The problem with avoiding local names is easily avoidable by creating > >> > another erase verb which is explicit instead of tacit. But if erase is > >> made > >> > dyadic then maybe 2 could mean only erase local names or 3 for only > >> global > >> > names. > >> > > >> > Then there is the problem of erasing a pendent name. This results in a > >> > stack error. Why not make erase return 1 if successful and 0 if not as > >> > Linda expected instead of if the name is legal or not? That makes the > >> > return more useful. > >> > > >> > On Wed, Sep 17, 2014 at 11:42 AM, Raul Miller <[email protected]> > >> wrote: > >> > > >> >> The result from erase is telling you that the name is legal to erase. > >> >> To get a zero, try erase 'i.' > >> >> > >> >> If you want to see whether the operation succeeded, you'll need to do > >> more > >> >> work. > >> >> > >> >> One issue you need to consider is the class of the name. > >> >> > >> >> nameClass=: [: nameclass ;: ::] > >> >> > >> >> Only names with a non-negative class can be removed by erase. > >> >> > >> >> Another issue which might interest you is whether the name is defined > >> >> locally. This needs work (it gives undefined names a definition), but > >> >> is a hint as to how you could test for whether the name is defined > >> >> locally: > >> >> > >> >> nameLocal=: [: {.@".@('0[',],'=:',]) ::1:&> ;: ::] > >> >> > >> >> Another issue which might interest you is what locales the name is > >> defined > >> >> in. > >> >> > >> >> nameLocales=:[: 3 :0 S:0 ;: ::] > >> >> path=. ~.(,18!:2)18!:5'' > >> >> test=.'(p P y)](4!:0<''',y,'__y'')[(''''P y)[p=.(P=.18!:2)y' > >> >> <path#~_1<(3 :test)"0 path > >> >> ) > >> >> > >> >> Example use: > >> >> nameClass 'this is a test' > >> >> nameLocal 'this is a test' > >> >> nameLocales 'this is a test' > >> >> > >> >> nameClass gives you a list of numbers in the range _2 through 3 > >> >> indicating whether the name is illegal, undefined, noun, adverb, > >> >> conjunction or verb. > >> >> > >> >> nameLocal gives you a 1 for names with local definitions (and for > >> >> illegal names). Be careful, though, because it will define the name > if > >> >> it's not already defined. > >> >> > >> >> nameLocale gives you a boxed list of the locales where you can find > >> >> the definition of the name. > >> >> > >> >> Anyways... there's lots of ways things could work. But why would you > >> >> erase a name in the first place, if you don't know that it exists? > >> >> > >> >> Thanks, > >> >> > >> >> -- > >> >> Raul > >> >> > >> >> > >> >> > >> >> On Wed, Sep 17, 2014 at 10:40 AM, Linda Alvord < > [email protected] > >> > > >> >> wrote: > >> >> > For a long time this has puzzled me. > >> >> > > >> >> > > >> >> > > >> >> > A=:2 4$i.8 > >> >> > > >> >> > erase 'A' > >> >> > > >> >> > 1 > >> >> > > >> >> > erase 'A' > >> >> > > >> >> > 1 > >> >> > > >> >> > > >> >> > > >> >> > It seems the second time it tells me it erased A it is lying > because > >> >> there > >> >> > should be no A any longer. > >> >> > > >> >> > > >> >> > > >> >> > Now it is really bothering me. > >> >> > > >> >> > load 'viewmat' > >> >> > > >> >> > ]GRB=:1 0 2{"1 (#:i.8){0 255 > >> >> > > >> >> > ]T=:+/~i.16 > >> >> > > >> >> > GRB viewmat T;'T'GRB viewmat i.16 > >> >> > > >> >> > > >> >> > > >> >> > ]C=:i.12 > >> >> > > >> >> > GRB viewmat C > >> >> > > >> >> > > >> >> > > >> >> > ]D=:3 4$i.12 > >> >> > > >> >> > GRB viewmat D > >> >> > > >> >> > > >> >> > > >> >> > ]M=:5 3$i.15 > >> >> > > >> >> > GRB viewmat M > >> >> > > >> >> > > >> >> > > >> >> > GRB viewmat 7 3$i.21 > >> >> > > >> >> > > >> >> > > >> >> > ]B=:4 4$i.16 > >> >> > > >> >> > GRB viewmat B > >> >> > > >> >> > > >> >> > > >> >> > GRB viewmat |: B > >> >> > > >> >> > > >> >> > > >> >> > GRB viewmat |.|:B > >> >> > > >> >> > > >> >> > > >> >> > If I run a different script with images in 1.ijs and then run > >> >> 2.ijs I > >> >> > get images all mixed up. Even If I remove all png's from the temp > >> >> folder, > >> >> > ghosts of previous images appear. I turn of JHS.bat and the try > >> 2.ijs > >> >> > and old images show up. They seem to be coming from the clipboard > >> >> possibly. > >> >> > Erasing names does not seem to help, but I'd like it better if I > only > >> >> got a > >> >> > 1 when it finds something with the given name and then was not > >> willing > >> >> to > >> >> > erase it abain. > >> >> > > >> >> > > >> >> > > >> >> > However, it is great to see any images! Also, jqt seems to be > >> >> unphased > >> >> > by thses ghosts. > >> >> > > >> >> > > >> >> > > >> >> > Linda > >> >> > > >> >> > > >> >> > > >> >> > > ---------------------------------------------------------------------- > >> >> > For information about J forums see > >> http://www.jsoftware.com/forums.htm > >> >> > ---------------------------------------------------------------------- > >> >> For information about J forums see > http://www.jsoftware.com/forums.htm > >> >> > >> > ---------------------------------------------------------------------- > >> > For information about J forums see > http://www.jsoftware.com/forums.htm > >> ---------------------------------------------------------------------- > >> For information about J forums see http://www.jsoftware.com/forums.htm > >> > > ---------------------------------------------------------------------- > > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
