Bruce Hoult <br...@hoult.org> writes: > In article <3C06D038.5050...@bomberlan.net>, Dave Morse > <dm-...@bomberlan.net> wrote:
> > Bruce Hoult wrote:
> > > I think that data structure lookup and function application should be > > > differentiated from each other, of only because the data structure > > > lookup denotes a "place" that you can setf, while the function > > > application doesn't.
> > You're right most of the time, but of course some function calls are > > invertible:
> Hmm. I'm looking at the package-nicknames entry in the hyperspec. How > am I supposed to tell that you can setf it?
You can't (portably). it would say "Accessor" instead of "Function" at the top of the entry if you could SETF it. I think it's not conforming for an implementation to extend this to allow SETF, btw, though I didn't check to be sure. That would be enumerated in the concepts section of the package chapter.
You have to use RENAME-PACKAGE to change the package nicknames, which means giving it a bunch of args you probably don't care about.
Kent M Pitman wrote: > Bruce Hoult <br...@hoult.org> writes:
>>In article <3C06D038.5050...@bomberlan.net>, Dave Morse >><dm-...@bomberlan.net> wrote:
>>>Bruce Hoult wrote:
>>>>I think that data structure lookup and function application should be >>>>differentiated from each other, of only because the data structure >>>>lookup denotes a "place" that you can setf, while the function >>>>application doesn't.
>>>You're right most of the time, but of course some function calls are >>>invertible:
>>Hmm. I'm looking at the package-nicknames entry in the hyperspec. How >>am I supposed to tell that you can setf it?
Doh, I didn't actually bother to check my facts. Please replace package-nicknames in the above example with something else invertible, for example: get. Sorry.
cbbro...@acm.org writes: > There certainly are misfeatures out there that could result in "severe > mischief," adding in the _possibility_ of "Oh, my stars! We went to a > subdirectory! Oh, the humanity..." does not seem like massive > disaster.
What if there is a public_html binary in the path[1]? Your common Unix/Linux system contains several thousand binaries in the default path directories. People will _not_ remember them all, and invoking some random command (even if you do it without arguments), when you were expecting a cd is not a good thing.
Throw in the usual common typing mistakes, including spaces where they shouldn't be, and things start to look even worse.
And now add some other common stupidities, like having directories in your path that are not solely under the control of people you trust (i.e. root on Unix machines), and we are nearly entering Microsoft Outlook teritory.
Regs, Pierre.
Footnotes: [1] All the more likely for some of the more common directory names.
-- Pierre R. Mai <p...@acm.org> http://www.pmsf.de/pmai/ The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents. -- Nathaniel Borenstein
> Hmm. I'm looking at the package-nicknames entry in the hyperspec. How > am I supposed to tell that you can setf it?
You aren't, because you can't. Bad or non-portable example on the OPs part.
Regs, Pierre.
-- Pierre R. Mai <p...@acm.org> http://www.pmsf.de/pmai/ The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents. -- Nathaniel Borenstein
Marco Antoniotti <marc...@cs.nyu.edu> writes: > t...@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> > Whether it's a good idea or a bad one, I think depends on how you're > > viewing your tables. A lot of languages *do* make the two look very > > different, but should they? It's nice that if I just want to deal > > with sequences, and not think about exactly what kind, I can. If I > > decide to change from a list of characters to a string, I don't need > > to change my consuming code. Well, what if I want to change from > > using a function that computes results to looking them up in a table? > > Functions and tables aren't really different from the consumer's point > > of view.
> I believe it is a trade off. In Ada95 if you see something like
> foo(42)
> you may be looking either at a function call or at an array index > (alas, not to a hash table lookup).
> But yes, all in all you are right. In CL we are stuck with a > separation that allows for clarity and efficiency (there I said the > E-word :) ) in many other cases.
I don't think it would actually be an efficiency problem. If FLET[*] bound the function value of a variable to an arbitrary value, and there was some way of associating a FUNCALL-like function for types, you could do something like:
Now, presumably CMUCL would be able to figure out that TABLE and FN are an array and a function, and would compile in the specific machinery, not the generic check-and-dispatch. Lesser compilers would probably require type declarations :-). All in all, I don't think it's any different than normal type issues.
> All in all, I would just settel for some macrology unifying array and > hash-table references, but then again, why bother?
I have a generic function REF:
(defgeneric ref (thing &rest subscripts))
This should theoretically be a really handy thing, allowing me to use hash tables, a-lists, arrays, etc, uniformly. I say theoretically, because I always forget to remember it. If I could only remember it's there, I think I'd enjoy using it.
As to "why bother", I think I agree with Kent that if you're using a lot of arrays, this would be worth the bother. And the fact that I didn't think of that shows that I haven't been doing scientific computations for a while :-(
[*] My fictional FLET would make it a little more difficult to create a local function, but there'd still be LABELS.
-- /|_ .-----------------------. ,' .\ / | No to Imperialist war | ,--' _,' | Wage class war! | / / `-----------------------' ( -. | | ) | (`-. '--.) `. )----'
* cbbro...@acm.org | This is NOT a case where there's significant chance of anything | "seriously damaging."
Are you kidding me?
| All we're talking about is the possibility of typing in: | | % public_html | | and having the shell figure out that: | - Since there aren't any programs in $PATH by that name, and | - Since there _is_ a directory under $PWD called public_html, | it would be slick to transform that into: | % cd public_html
What if this was the case yesterday, but today, somebody put a program in one of the directories in PATH named "public_html" which did something that you did not want at all?
| There certainly are misfeatures out there that could result in "severe | mischief," adding in the _possibility_ of "Oh, my stars! We went to a | subdirectory! Oh, the humanity..." does not seem like massive disaster.
If you want to achieve system security, you have to stop ridiculing the professional paranoia that security people have to engage in.
/// -- The past is not more important than the future, despite what your culture has taught you. Your future observations, conclusions, and beliefs are more important to you than those in your past ever will be. The world is changing so fast the balance between the past and the future has shifted.
Erik Naggum <e...@naggum.net> writes: > * cbbro...@acm.org ... > | All we're talking about is the possibility of typing in: > | > | % public_html > | > | and having the shell figure out that: > | - Since there aren't any programs in $PATH by that name, and > | - Since there _is_ a directory under $PWD called public_html, > | it would be slick to transform that into: > | % cd public_html
> What if this was the case yesterday, but today, somebody put a program in > one of the directories in PATH named "public_html" which did something > that you did not want at all?
If they can change binaries that are in your path, then your system is toast anyway.
The main problem I see with the feature is that you might name a directory something like "reboot" or some other no-argument command that does something you don't want.
* Ed L Cashin | If they can change binaries that are in your path, then your system is | toast anyway.
Huh? Are you guys for real?
Systems are upgraded by their system administrator, new software packages are installed by the system administrator, sanctioned or even requested by their owners and/or users. There is no security breech here at all! It is the _normal_ operation that is a threat to the stupid design to conflate directory names with executable names.
No wonder people design software with built-in security flaws when you guys cannot even read a description of the problem.
| The main problem I see with the feature is that you might name a | directory something like "reboot" or some other no-argument command that | does something you don't want.
Since I already covered this case (sans examples, because examples cause even worse reading comprehension), you are just annoying me with Dylan- freak-like reading comprehension problems, right?
/// -- The past is not more important than the future, despite what your culture has taught you. Your future observations, conclusions, and beliefs are more important to you than those in your past ever will be. The world is changing so fast the balance between the past and the future has shifted.
In article <m3y9kozu52....@terry.uga.edu>, Ed L Cashin wrote: > Erik Naggum <e...@naggum.net> writes:
>> * cbbro...@acm.org > ... >> | All we're talking about is the possibility of typing in: >> | >> | % public_html >> | >> | and having the shell figure out that: >> | - Since there aren't any programs in $PATH by that name, and >> | - Since there _is_ a directory under $PWD called public_html, >> | it would be slick to transform that into: >> | % cd public_html
>> What if this was the case yesterday, but today, somebody put a program in >> one of the directories in PATH named "public_html" which did something >> that you did not want at all?
> If they can change binaries that are in your path, then your system is > toast anyway.
> The main problem I see with the feature is that you might name a > directory something like "reboot" or some other no-argument command > that does something you don't want.
A rough gage of security on a unix system is: security = 1/convenience And you seem to want a large value for convenience. Here is a simple example of why your idea needs to be reconsidered IMO. I have a directory called partitions or formats and as uid 0(aka root, but not limited to root). I type formats(or partitions) but the s does not take so instead of changing directories in invoke the command. Now it depends on the unix you are on and what else you typed before you realized you screwed up how badly you have just fucked your self and your employer.
You are also setting your self up for name clashes down the road. And realy unhappy management when the users who you support do the EXACT SAME THING they did yesterday but now they have given you a reason to finally see if your backup policy is as good as you thought it was. If you were an SysAdmin that installed such a potentially distructive piece of software, solely because some users wanted it, you probably would not work there by the end of the day that the problem happened if I had anything to do with it.
Some tmes good admin is as simple as saying "no way in hell is that going on my systems", good security also.
> The main problem I see with the feature is that you might name a > directory something like "reboot" or some other no-argument command > that does something you don't want.
How many people still write programs called "test" and scratch their heads in puzzlement?
> There certainly are misfeatures out there that could result in "severe > mischief," adding in the _possibility_ of "Oh, my stars! We went to a > subdirectory! Oh, the humanity..." does not seem like massive > disaster.
tfb+goo...@tfeb.org (Tim Bradshaw) writes: > cbbro...@acm.org wrote in message <news:ZWAN7.21576$cC5.2579900@news20.bellglobal.com>... > > There certainly are misfeatures out there that could result in "severe > > mischief," adding in the _possibility_ of "Oh, my stars! We went to a > > subdirectory! Oh, the humanity..." does not seem like massive > > disaster.
> $ public_html > $ rm *.html
.. And what _other_ result would you have been expecting than for a pile of html files to go away? -- (reverse (concatenate 'string "moc.enworbbc@" "sirhc")) http://www.cbbrowne.com/info/languages.html "The wrath of Holloway is nothing compared to the wrath of Moon." -- Fred Drenckhahn
coh...@mindspring.com (David Cohen) writes: > For those of you, like myself, who were wondering what Paul Graham > (author of "ANSI Lisp" and "On Lisp") has been up to lately, the > answer is: he's been devising a new Lisp dialect called "Arc".
I havn't read the whole thing, but I've read enough. This ain't no good.
In fact, I am in shock after reading some of the things in there:
-------------- example --------------
14. Strings Work Like Lists
> (car "abc") \a > (cons \a "bc")
"abc"
Contagion as with ints and floats
> (+ "abc" '(d e)) (\a \b \c D E)
Should we allow nonchars in strings?
-------------- end here --------------
Who wants this? _why_ would anyone want this?
Someone compared this in some way to Dylan. But one thing that Dylan did at least try to preserve was sensibility. I don't think that Arc is going anywhere, anytime. The emphasis on abbreviation and some C-like loop macros won't get anyone using this thing, and it doesn't matter who wrote it. I can't believe that this language is supposed to embody "What programmers _secretly_ want". Since when have programmers been secretive?
writing x.y instead of (x . y) or whatever is _not_ what people want. It almost seems as if Arc was designed by someone who wanted to make a Lispy Perl, and even me, being one of the few Lisp guys who also likes and uses Perl, I just can't see Arc as having value.
> How many people still write programs called "test" and > scratch their heads in puzzlement?
Heh. This was the first mistake I ever made on Unix. I *still* call all my test programs `ts' because of this. Even though I haven't had . in my path for 15 years or something, so I'd have to say ./test anyway...
* cbbro...@acm.org | .. And what _other_ result would you have been expecting than for a | pile of html files to go away?
A different pile of html files?
/// -- The past is not more important than the future, despite what your culture has taught you. Your future observations, conclusions, and beliefs are more important to you than those in your past ever will be. The world is changing so fast the balance between the past and the future has shifted.
> > > There certainly are misfeatures out there that could result in "severe > > > mischief," adding in the _possibility_ of "Oh, my stars! We went to a > > > subdirectory! Oh, the humanity..." does not seem like massive > > > disaster.
> > $ public_html > > $ rm *.html
> .. And what _other_ result would you have been expecting than for a > pile of html files to go away? > --
and one pile is as good as the next, eh? :-/ -- Coby (remove #\space "coby . beck @ opentechgroup . com")
cbbro...@acm.org wrote in message news:<7rLN7.24385$> > .. And what _other_ result would you have been expecting than for a > pile of html files to go away?
I was expecting a different pile to go away. In particular I was not expecting the ones in my public_html directory to go away. I care about which files I delete.
tfb+goo...@tfeb.org (Tim Bradshaw) writes: > cbbro...@acm.org wrote in message news:<7rLN7.24385$> > > .. And what _other_ result would you have been expecting than for a > > pile of html files to go away?
> I was expecting a different pile to go away. In particular I was not > expecting the ones in my public_html directory to go away. I care > about which files I delete.
And you typed "public_html" first because... -- (concatenate 'string "chris" "@cbbrowne.com") http://www.cbbrowne.com/info/lsf.html Black holes are where God divided by zero.
cbbro...@acm.org writes: > tfb+goo...@tfeb.org (Tim Bradshaw) writes: > > cbbro...@acm.org wrote in message news:<7rLN7.24385$> > > > .. And what _other_ result would you have been expecting than for a > > > pile of html files to go away?
> > I was expecting a different pile to go away. In particular I was not > > expecting the ones in my public_html directory to go away. I care > > about which files I delete.
> And you typed "public_html" first because...
Actually, it wasn't public_html that was typed. It was just p* and it accidentally expanded to just one item, so was taken as if public_html was typed... or perhaps he meant to type ls public_html but made a typo... or perhaps it was a paste-o ... or perhaps completion was used and he typed p<TAB><ENTER> without realizing the context, getting a completely different item than intended ... or ....
> > tfb+goo...@tfeb.org (Tim Bradshaw) writes: > > > cbbro...@acm.org wrote in message news:<7rLN7.24385$> > > > > .. And what _other_ result would you have been expecting than for a > > > > pile of html files to go away?
> > > I was expecting a different pile to go away. In particular I was not > > > expecting the ones in my public_html directory to go away. I care > > > about which files I delete.
> > And you typed "public_html" first because...
> Actually, it wasn't public_html that was typed. It was just p* and it > accidentally expanded to just one item, so was taken as if public_html > was typed... or perhaps he meant to type ls public_html but made a typo... > or perhaps it was a paste-o ... or perhaps completion was used and > he typed p<TAB><ENTER> without realizing the context, getting a completely > different item than intended ... or ....
Of course, some of these (particularly the paste-o) are possible without that aweful misfeature. Which is why I consider it a safety issue to have at least the current working directory in the shell prompt, if not the entire path to it (which I always use for root). Ob Lisp: I really like how CLISP puts the name of the current package in the prompt. I use ILISP, so even using CMUCL, it's on the mode line, but I think that was a good design choice on the part of CLISP. Yuck, imagine if typing a symbol at the toplevel, if it had no value as a variable, but there was a package of the same name, was the same as typing (in-package ...).
-- /|_ .-----------------------. ,' .\ / | No to Imperialist war | ,--' _,' | Wage class war! | / / `-----------------------' ( -. | | ) | (`-. '--.) `. )----'
t...@whirlwind.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> Ob Lisp: I really like how CLISP puts the name of the current package > in the prompt. I use ILISP, so even using CMUCL, it's on the mode > line, but I think that was a good design choice on the part of CLISP.
In CMUCL, you can set *prompt* to a function that returns any string of your choice. See http://ww.telent.net/cliki/CMUCL%20Hints for a tip courtesy of Paul Foley that uses this to get the current package into the prompt.
> writing x.y instead of (x . y) or whatever is _not_ what people want.
Wait just a second, is 1.2 now a cons? Or perhaps just a float? Maybe it's a symbol! Who knows? After all, this is a language designed for the "good" programmers!
Carl Shapiro <cshap...@panix.com> writes: > Dave Bakhash <ca...@alum.mit.edu> writes:
> [...]
> > writing x.y instead of (x . y) or whatever is _not_ what people want.
> Wait just a second, is 1.2 now a cons? Or perhaps just a float? > Maybe it's a symbol! Who knows? After all, this is a language > designed for the "good" programmers!
1.2 is a FLOAT. The rules are very simple. That is because in CL spaces are meaningful as separators (something we should all be gratuful for) and - to some extent - because you do not have infix operators)
Cheers
-- Marco Antoniotti ======================================================== NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488 719 Broadway 12th Floor fax +1 - 212 - 995 4122 New York, NY 10003, USA http://bioinformatics.cat.nyu.edu "Hello New York! We'll do what we can!" Bill Murray in `Ghostbusters'.
Marco Antoniotti <marc...@cs.nyu.edu> writes: > 1.2 is a FLOAT. The rules are very simple. That is because in CL > spaces are meaningful as separators (something we should all be > gratuful for) and - to some extent - because you do not have infix > operators)
In Common Lisp, certainly! But, this new-fangled something.something syntax as short hand for dotted pairs (thankfully) isn't part of Common Lisp. As such, you cannot necessarily use Common Lisp's rules to disambiguate the expression.
