* Barry Margolin <bar...@genuity.net> | But it's unlikely that much code is currently written this way, so it | would have to be found and fixed. I suspect there's also code out | there that reads user input using things like READ-LINE, and then | calls STRING-UPCASE before calling INTERN or FIND-SYMBOL, to ensure | that it will find the right symbol.
The obvious solution to this problem is _not_ to make an irreversible global change, but to retain upper-case access to symbols even while you have lower-case access to them. Franz Inc's solution is wrong, and causes lots or problems in transitioning between upper-case and lower-case "modes". Such global mode switches are generally not the best kind of solution, anyway. I truly wonder why they didn't look further when it has so many obvious drawbacks, apart from breaking code that relies on the old upper-case behavior, which is considered something that _shouldn't_ work by some Franz people. I can't believe the argument that any such code is so easy to change there's no cost to it. How do you know you've caught them all? How is that easier to prove than not to break the thing in the first place while allowing people the choice? And he's never seen find-symbol! That is _not_ comforting. The sheer arrogance here is too much, just too much.
#:Erik -- ALGORITHM: a procedure for solving a mathematical problem in a finite number of steps that frequently involves repetition of an operation. ALGOREISM: a procedure for solving an electoral problem in a finite number of steps that frequently involves repetition of an operation.
John Foderaro <j...@unspamx.franz.com> wrote: >In article <owYO5.64$sG1.794@burlma1-snr2>, bar...@genuity.net says...
>> (intern (if *default-upcase* "CAR" "car"))
>well actually I'd do something like (intern (symbol-name 'car)) >but something as basic as this is something usually not done (I.e why >not just use the symbol car to begin with?)
>> ? Everyone who calls INTERN or FIND-SYMBOL would have to modify their code >> to deal with this new situation, wouldn't they? That seems like a serious >> incompatibility for such little gain.
>I've written a lot of code and converted a lot of code written by others >so that it works in Modern mode (and continues to run in ANSI mode). >I've found calls to intern which >I've had to make work in either mode, but I don't think that I've >ever seen a call to find-symbol, but I may have seen one in the >Orion database system from MCC.
In one legacy application I have found about several ten calls to find-symbol, here is one example:
(defun sub-FM-pull-down-menu-class (&optional (sub-FM-keyword *current-sub-FM*)) (let* ((name (concatenate 'string (symbol-name sub-FM-keyword) "-PULL-DOWN-MENU")) (class (find-symbol name :cl-user))) (if class class 'pull-down-menu)))
>I can only say that in practice it really isn't a problem.
Maybe
-- Francis Leboutte www.algo.be +32-(0)4.388.39.19
John Foderaro <j...@unspamx.franz.com> writes: > In article <m31ywl2h6y....@localhost.localdomain>, m...@bewoner.dma.be > says... > > Technically, this is correct, but it gives the novice the impression > > that if he has a class Box he can't name a variable box.
> ok that wasn't clear. The idea was that you would store in the variable > Box the class object for a box and in the variable box an instance of > that class. So if both are variables then there is a clash.
I understood although I've never wanted to do this. But what the CL novice is going to retain from it is that he can't do
(defmethod foo ((box Box)) nil)
which is false.
> Keeping two pointers to the same thing makes things hard to manage (if > you've ever used soft or hard links in the Unix you know that you often > end up following pointers to old or non existent files.).
It would certainly be feasible. Take the print name out of the current struct and make a symbol a cons of the printname and a struct with the remaining members.
> Pascal's descendents Modula-2 and Modula-3 are modern and are case > sensitive (even though Pascal is case insensitive).
I've written a fair amount of code in Modula-3, it's a fine language and Java didn't steal enough from it, but it's a weird argument for your case. Sure, it's case sensitive but they chose to make the keywords UPPER CASE and don't give you any choice about it ;-)
-- Lieven Marchand <m...@bewoner.dma.be> Lambda calculus - Call us a mad club
Barry Margolin <bar...@genuity.net> writes: > But I think I can understand why the designers of Edinburgh syntax went > that way. Mathematicians and logicians make heavy use of case distinctions > in their formulas (since just about all their variables are single letters, > all they have to play with is case and font, and they use them > excessively), so they probably felt that this would be more acceptable to > the logic community.
And alphabet. The Greek and Hebrew alphabets are nearly exhausted so the Cyrillic seems to next. The Tate-Shafarevich group is commonly denoted by the Cyrillic letter Sha. Since most modern languages seem to take Unicode as alphabet, programmers can start to take advantage of this also.
Perhaps we need to revive the extended character functions for when we have to interface with the java class ru.big-bussiness.RussianParser?
-- Lieven Marchand <m...@bewoner.dma.be> Lambda calculus - Call us a mad club
Erik Naggum <e...@naggum.net> writes: > you have lower-case access to them. Franz Inc's solution is wrong, > and causes lots or problems in transitioning between upper-case and > lower-case "modes". Such global mode switches are generally not the > best kind of solution, anyway. I truly wonder why they didn't look
(wading into the fray)
Hmm. I'm fairly early in my Lisp programming journey, and curious: wouldn't something like a WITH-LOWER-CASE-READER macro be much more effective than a global setting?
-- vsync http://quadium.net/ - last updated Fri Nov 10 03:41:55 PST 2000 (cons (cons (car (cons 'c 'r)) (cdr (cons 'a 'o))) ; Orjner (cons (cons (car (cons 'n 'c)) (cdr (cons nil 's))) nil))
In article <MPG.1476065f80dd16af989...@news.dnai.com>, John Foderaro <j...@unspamx.franz.com> wrote:
>In article <cmZO5.70$sG1.687@burlma1-snr2>, bar...@genuity.net says... >> To make this portable with implementation-dependent case, the simplest fix >> would probably be:
>> (intern (format "%A-%A" 'make structure-name))
>correct, except it would be (intern (format nil "~a-~a" 'make structure-name)) >[it looks like you've just been programming in C]
I knew something didn't feel right when I was writing that! What little programming I do these days is mostly Perl, AWK, or Emacs Lisp, all of which use C's formatting syntax.
>> But it's unlikely that much code is currently written this way, so it would >> have to be found and fixed.
>True but in practice it's not hard. I don't know how to prove it to you >though.
Perhaps true, but is it worth forcing lots of programmers to go through that for such a minor benefit? IMHO, incompatible changes should require more justification than this.
-- Barry Margolin, bar...@genuity.net Genuity, Burlington, MA *** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups. Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
John Foderaro <j...@unspamx.franz.com> writes: > Common Lisp can name things that are case insensitive, like html tags, > domain names, files on DOS, and words in certain written languages.
> To names things with case sensitive names, like xml tags, C identifiers, > and Java identifiers you have to use escapes to turn off the > normal reader behavior or else change the reader behavior wholesale > with readtable-case and deal with the consequences when > naming Common Lisp functions and variables.
> It can be done though. Definitely.
I'm wondering why symbols are considered to be so important. Most of these things seem to be more suited to strings, or, as in the case of filenames, objects such as LOGICAL-PATHNAME, which are constructed from strings.
-- vsync http://quadium.net/ - last updated Fri Nov 10 03:41:55 PST 2000 (cons (cons (car (cons 'c 'r)) (cdr (cons 'a 'o))) ; Orjner (cons (cons (car (cons 'n 'c)) (cdr (cons nil 's))) nil))
Bob Bane <b...@removeme.gst.com> writes: > Kevin Layer wrote:
> > Getting back to the new XML parser, it is intended to run in Modern > > mode. It works somewhat in ansi mode, but not well. The author and I > > looked at it, and it wouldn't take much to make it work in ansi mode. > > We do give out the source code, so users can even do it themselves. > > Perhaps at some point we'll do the work. I don't know.
> > Even if it is fixed, the parse output will be ugly in ansi mode > > because all the symbols will have | around them. XML is case > > sensitive, after all.
> I personally would put up with ugly printed XML parse output if it meant > I could use the parser alongside ANSI code without having to modify > either one of them. How often do you look at raw XML parse trees, > anyway, except while debugging?
> We all appreciate having a free fast XML parser (at least, I do! I need > to mung XML and was not looking forward to writing a parser or tuning > someone else's. As a customer, thanks!). We're just greedy users who > want both new tools and the benefits of working in a language whose > specification doesn't change weekly.
> If someone made changes to your parser to make it work in ANSI mode, and > submitted them to you, would you accept them and fold them in (assuming > they didn't completely uglify the code)?
Yes, assuming we agreed with the changes. I might even do it myself, in my spare time.
> > First, the version you paid for isn't the version that John was > > talking about. Your version is DOM based.
> > Second, we've delivered the version for the contract, and we haven't > > changed it.
> I take this to simply be that my original point,
> > > which I take to mean that at least the version we have internally > > > will still function in ANSI 6.0.
> is true. However,
> > We decided to start from scratch because one reason: performance. The > > DOM based parser was too slow. I recall from discussions with Franz > > people that you guys we not unhappy with the performance.
> This is simply false. I have the evidence if you really want it. > What was stated quite clearly was that the performance was _not_ good, > but that correct functionality was the _first_ priority, and _then_ > performance would be addressed. I suppose this was another thing that > was lost when Lewis left Franz.
Well, I'm sorry for that. I did ask the question and I've reported the answer I got.
> > The version we have released is easily 20 times faster, and it uses > > a lot less memory in the process. > ... > > I don't see how we've hanged you out to dry. I am very sorry you feel > > this way. > ... > > Given the above explanation, are you happier?
> Not particularly. You have created a new xml parser (which looks to > be significantly better) and which we are not going to be able to use > since it only "works somewhat in ansi mode" and really is intended to > only be run in "modern" mode. Obviously Franz is free to do whatever > it wants as I would have to agree that the contract was (basically) > completed. OTOH, I would've hoped that we would not have been left > out and forgotten wrt requirements for this new version.
> > Getting back to the new XML parser, it is intended to run in Modern > > mode. It works somewhat in ansi mode, but not well. The author and I > > looked at it, and it wouldn't take much to make it work in ansi > > mode. We do give out the source code, so users can even do it > > themselves. Perhaps at some point we'll do the work. I don't know.
> > Even if it is fixed, the parse output will be ugly in ansi mode > > because all the symbols will have | around them. XML is case > > sensitive, after all.
> First, that is subjective. Second, what makes you think the parser > output in Lisp is going to be viewed by anyone? I'm not sure that > makes any sense except for possibly debugging purposes. The whole > idea is that you pull this stuff into a Lisp representation for > _internal_ processing and then squirt the results back out in XML to > be "viewed" or otherwise used by the usual XML tools. That's > certainly how you would typically use it in an ecommerce setting, and > that's true of how its used here.
I wasn't clear. I was thinking that some people might want to create xml by creating the Lisp form of it. We do this for our documentation. We call it lxml. All our documentation for 6.0 (except for a couple of items) is now in lxml. We create documents in this form. Other people might want to do this, too.
In article <wk1ywj7p1v....@441715.i-did-not-set--mail-host-address--so-shoot-me>, cbbro...@hex.net says...
> Not _quite_ irrelevant; if by using a particular Lisp implementation, > the user is _forced_ to go to "MODerN MODe," then even if the benefit > is zero, there is still the cost of porting the code.
But all implementations today support ANSI mode and I would imagine that they would continue to support ANSI mode as long as there were people interested in that mode.
True new implementations could be written that are modern only but as we've seen, new implementations of Common Lisp are rare.
Let me relate an anecdote. Back in 1978 when UC Berkeley got its first VAX computer, they got a copy of the Vax/Unix operating system from Bell Labs and began work on adding a virtual memory system to it.
In this this version of Unix, external identifiers (such as function names) in object files were limited to some small length (12 characters I think). Even with a 12 character limitation for identifiers you can still write any C program. So there was no need to change anything. However the people working on this project (an in particular Bill Joy) recognized that a 12 character limitiation to identifiers harmed their ability to clearly write the system they intended to write. Therefor they wanted no restriction on the length of identifiers. So they made that happen and that meant changing a large number of programs (cc, ld, as, nm, adb) as well as creating a new executable file format and changing the Unix kernel to understand this format. This also meant breaking with the version of Unix at Bell Labs.
So this was a tremendous step just to go from 12 character to unlimited character identifiers. I'm glad they did as it really added to the clarity of long function names and didn't force unnatural abbreviation. (e.g. GetWindowTitle -> GetWinTitle). Since most Unixes in use now are a descendent of this version this change they made is responsible for the fact at we now take for granted that identifiers for functions names can be any length.
I wonder how many of us when faced with the question of whether to make this change would say "We can write everything with 12 character identifiers and we've got to stick with the standard, and Bell Labs sets the standard for C [in 1978]".
And so in a roundabout answer to your question about what the benefit of a Modern lisp, let me say that we can already write everything we would ever want to write in an ANSI lisp. However a Modern lisp does give us 1. more expressibility (without escaping things) 2. the ability to more easily represent objects outside the Lisp world that have case sensitive names.
Thus while Modern mode won't let us write any programs we couldn't write in ANSI mode, it does make writing certain programs easier and clearer. That to me is a huge benefit.
In article <86y9yrs8rd....@piro.quadium.net>, vs...@quadium.net says... .
> I'm wondering why symbols are considered to be so important
Symbols are important (and much better than strings) because 1. symbols can be compared with a fast eq operation (usually one machine instruction) compared to using equal for strings.
2. symbols are stored in packages and there is only one symbol with a given name in a given package.
3. symbols have value cells so you can use them as variables
4. symbols have function bindings so you can call them as functions.
5. symbols have property lists, a great place to store information about the symbol.
strings really can't compare to symbols for representing a foreign object that either has a value or is a function or both.
John Foderaro <j...@unspamx.franz.com> writes: > I agree completely. If you've got a working system then that's great > and there's no reason for you to change. Whenever you do any kind of > porting work you've got to ask what is the cost and what is the benefit. > It sounds like in your case the benefit to going to Modern mode is zero > so the cost is irrelevant.
Not _quite_ irrelevant; if by using a particular Lisp implementation, the user is _forced_ to go to "MODerN MODe," then even if the benefit is zero, there is still the cost of porting the code. -- (concatenate 'string "cbbrowne" "@hex.net") <http://www.ntlug.org/~cbbrowne/> Rules of the Evil Overlord #24. "I will maintain a realistic assessment of my strengths and weaknesses. Even though this takes some of the fun out of the job, at least I will never utter the line "No, this cannot be! I AM INVINCIBLE!!!" (After that, death is usually instantaneous.)" <http://www.eviloverlord.com/>
Tim Bradshaw <t...@tfeb.org> writes: > I have dealt with Franz as a customer for a long time (more than 10 > years) and I don't think I've met anyone who thinks like this, and I > can certainly say from my own experience that some of their > competiitors have been significantly worse to deal with than they > are (including being significantly more arrogant).
Okay. So then we have different experiences. I see where you're coming from, and neither disbelieve nor discount your experience, and actually I'm happy that you're happy.
> Certainly I have never met anyone who *fears* them: why would you > fear them?
First off, I didn't say I feared _them_. I do worry about the impact that they have on the Lisp community, though. But you really want an explaination of fear for a business?
Okay, Tim. Here's a first shot at an example of how Company might come to fear ACL.
Suppose Company was in the business of developing software. Company chose Common Lisp as its primary development language, and Franz's ACL as the specific implementation. Company noticed that ACL provided many of the extensions necessary for Company's development needs, such as networking, multiprocessing, etc. Company understood the basic pricing scheme concepts.
After a few years of development, deliveries of various products, Company suddenly notices that Franz has decided that to run a server application, they will charge _not_ for the single seat, as they used to, but for each person accessing the server, and at the VAR pricing (which is far from cheap). Oh, but unfortunately, Company doesn't know exaclty how many people will access that server. No big deal; Franz will assume a few hundred, if not more. Do you think that's something to at least worry a little about, given that you're already a Franz customer? I'm just happy they changed this pricing thing _before_ I ever purchased anything from them.
As far as I know, Franz is the _only_ Lisp vendor I'm aware of that prices this way, with respect to servers. I get sickened that other vendors might follow along with this pricing approach. Tell me, Tim. Do I have your consent in feeling this way?
As I've said it once before here, some months back. I priced ACL against a competing Common Lisp. The prices were an ORDER OF MAGNITUDE different. In a free market, they can sell it for as much as they want. And in an open forum, i'll openly admit my utter disgust with this pricing, and since I do small jobs for small- and mid-sized companies, I feel that if there's a company out there that's going to potentially change the direction of Common Lisp away from the ANSI Standard, I can better believe that don't want it to be Franz.
David Bakhash wrote: > Tell me this, Kevin. Is it unrelated that companies fear you guys? > Many of them despise you guys, some your very own customers? I can > openly and honestly say, as for your direct compeditors, that the > sentiment of their customers is _exactly_ the opposite?
Your post just proves that usenet bears every kind of messages without a blink. As a self-proclaimed open and honest person, please name the customers you represent (including yourselves). It's NIL, isn't it?
Tim Bradshaw <t...@cley.com> writes: > I don't think I saw the full horror of this until just now. Perhaps I > still do not understand.
Yes. I think that the situation is not as bad as you might have expressed in the choices below.
> If I'm in `modern mode' in acl, and I want to read some stuff in case > insensitive uppercase, then I have a choice of:
> 1. write my own reader;
No. You can definitely avoid this.
> 2. toggle, globally, into ansi mode and back, losing case information > about potentially every symbol in the system in the process.
I think after reading a post from one of the Franz guys, you can do this without fear, and things will work just right.
> 3. don't use modern mode, and live with || where I need > case-sensitivity.
When do you actually _need_ case insensitivity? It's not that often. If it happens, then use the |'s. Or, do what MCL does, and employ a reader macro, such as the #_CallThisInJava, which not only is annotationally expressive, it's more powerful than just interpreting the following symbol as case-sensitive; it can expand that cleverly, depending on what you're really trying to do (like FFI/FLI stuff). Plus, this is just plain, pure Common Lisp. There's no excuse to _not_ use what's already there. Writing the #_ reader macro will certainly involve a bit of work, but SO WHAT! Look what you get, and look what you prevent -- breaking with the standard.
> [choice] 2 potentially breaks things in completely random ways, not > just because I lose just the kind of distinction that > case-sensitivity get me when FOO -> FOO -> foo, but because I might > have other threads in the system which will fall about in ANSI mode, > so I basically have to do a without-interrupts while I sit and wait > for something to come down some network connection for 20 minutes.
No. Someone (from Franz, I think) already explained that the variables involved with case are thread-specific. You definitely hit something that was a possible problem, but they beat you to it, and it's actually kind obvious, considering how *all* multiprocessing-capable Lisps seems to treat the variables set by WITH-STANDARD-IO-SYNTAX as thread-special variables.
> Wouldn't it be possible to split this thing in two -- a part which > controls the readtable case sensitivity of a readtable (which I > think we already have in ANSI CL) and some utility which will change > the case of symbols in one or more packages? That way I could be in > a lower-case lisp (after using the second utility) but I could > control how I read things by adjusting readtable parameters and/or > changing readtables.
I personally wouldn't want that, as it would confuse the hell out of me. We don't need to add complexity to the package system, not to mention that I don't even know that it would work right.
* vsync <vs...@quadium.net> | Hmm. I'm fairly early in my Lisp programming journey, and curious: | wouldn't something like a WITH-LOWER-CASE-READER macro be much more | effective than a global setting?
What would the macro expand to if not a special variable binding, which is a global setting?
#:Erik -- ALGORITHM: a procedure for solving a mathematical problem in a finite number of steps that frequently involves repetition of an operation. ALGOREISM: a procedure for solving an electoral problem in a finite number of steps that frequently involves repetition of an operation.
* David Bakhash <ca...@alum.mit.edu> | After a few years of development, deliveries of various products, | Company suddenly notices that Franz has decided that to run a server | application, they will charge _not_ for the single seat, as they used | to, but for each person accessing the server, and at the VAR pricing | (which is far from cheap). Oh, but unfortunately, Company doesn't | know exaclty how many people will access that server. No big deal; | Franz will assume a few hundred, if not more. Do you think that's | something to at least worry a little about, given that you're already | a Franz customer? I'm just happy they changed this pricing thing | _before_ I ever purchased anything from them.
You're looking at a very strange situation and getting it all wrong. Franz Inc has always demanded royalties for commercial deployment of their software. The developer license terms have always been just that: _developer_ licenses. What happened was that they didn't know what to charge for the evolving server-based applications market, and for a long time didn't charge anything, despite the very clear text in the license agreement that you should pay them for commercial use of their product. Now, did Franz Inc _sue_ you for this violation? Did they become completely unreasonable and irrational when faced with a new condition? No. Neither. Many users (me, included) observed that the license terms had changed for them, but that was only because they were abusing a loop-hole that it wouldn't take a whole lot of work to see was just that: a loop-hole. You could argue until you're blue in the fact that Franz Inc were changing their license conditions, but the facts remain that (1) you were not licensed to do what you did, so got something for free, which they have not demanded back payment for, and (2) when they started to set up a price schedule for this, they made the same "mistake" they have made on many occasions, namely to give you a half-offending price up front and fail to understand why you walk away instead of negotiate.
| As far as I know, Franz is the _only_ Lisp vendor I'm aware of that | prices this way, with respect to servers. I get sickened that other | vendors might follow along with this pricing approach. Tell me, Tim. | Do I have your consent in feeling this way?
You would have had my consent in feeling this way half a year ago, when I was trying to recover from the serious blow that their first demand at unlimited server access would have on my work and on our business. However, despite a very current, very disappointing case, reasoning with people at Franz Inc have been successful, even if time- consuming (we don't fit into any of their models, making the situation hard for us all).
I think Franz Inc have good negotiators. That means you have to look out for #1 and be aware of what you want to do and why. This may not be the ideal situation for Common Lisp, but lots of people make the choice that they would rather stay with Franz Inc and Common Lisp, so it can't be _wrong_, only unsuitable to your current needs. There is nothing wrong with that, either. Sometimes, a product simply isn't for you. Like, at my current target shooting skill level, I'm still not better than my $500 gun, and it would be a waste of money to go for a $1000 gun. If and when I outperform my gun, I would upgrade. If you only produce small tools for small businesses, chances are you aren't making enough of a difference for them to be better than the tools you can get at a lot lower prices. This should not piss you off if you are a rational individual. It should tell you that as your demands increase and the value of the tool increases with them, you have an additional vendor to go to; you're not stuck in the low end of the market, having to change the programming language, which happens all too often to the many inferior languages.
I'm a very big proponent of professional tools for professionals. That's probably because I make such tools, myself, so I know what it takes to succeed in a very small and well-defined area, giving me the opportunity to understand just how much work it is to do it in a large area like confomring to a standard and building an environment around it. (And how easy it is to get lazy and how important it is _not_ to be lazy in the face of such challenges.) When I was but an egg, I thought that the price of a software tool should be proportional to my own value -- except I didn't think of it in those terms then -- and thus wanted free tools because my time was basically free, too. Now that my time very far from free, either for me nor my employer, I can no longer afford to work for free just to lower the price of the tool because it would cost more to do so than to buy an expensive tool.
I'll make a simple statement and claim that the relationship between your own value and the price of your tools will remain fairly constant throughout your carreer, when you look at it in retrospect, mind you.
#:Erik -- ALGORITHM: a procedure for solving a mathematical problem in a finite number of steps that frequently involves repetition of an operation. ALGOREISM: a procedure for solving an electoral problem in a finite number of steps that frequently involves repetition of an operation.
> * David Bakhash <ca...@alum.mit.edu> > | After a few years of development, deliveries of various products, > | Company suddenly notices that Franz has decided that to run a server > | application, they will charge _not_ for the single seat, as they used > | to, but for each person accessing the server, and at the VAR pricing > | (which is far from cheap). Oh, but unfortunately, Company doesn't > | know exaclty how many people will access that server. No big deal; > | Franz will assume a few hundred, if not more.
Amusingly enough (?), this exact scenario happened to my previous company some time ago. We were properly licensed for all our development copies as well as our commercial use. Then we got a big contract; Franz caught a whiff of it, and suddenly tried to force us into a major new pricing model.
Given that we were making a web server application with potentially millions of users, Franz's proposed pricing wound up being _orders_ of magnitude more than our previous arrangement with them. That would have bankrupted us and killed the deal, so under our time pressure Franz consented to merely hijack us for as much as they could get away with, which at least allowed us to continue in business.
But the conclusion at our company was that sole-sourcing Lisp from Franz in a commercial setting was a disaster, given that Franz was more interested in extracting as much blood as possible during our moment of weakness, rather than maintaining long-term relationships. (This, after 10+ years of using Franz lisp by the principals!)
So: as much as I admire their technical accomplishments, in my view it is a serious business mistake to rely on Franz for Common Lisp. Use something like the open source CMUCL instead, which has 95% of Common Lisp, has a much better/faster compiler than Franz, and has no license issues.
On 11 Nov 2000 04:15:33 +0000, Erik Naggum <e...@naggum.net> wrote:
> What happened was that they didn't know > what to charge for the evolving server-based applications market, and > for a long time didn't charge anything, despite the very clear text in > the license agreement that you should pay them for commercial use of > their product.
We had been paying them under the original license terms, which admittedly did not anticipate server-based applications. After basing a whole company on this lisp with this pricing model, Franz changed it from under us the moment they could get away with it, during a critical period when we couldn't afford to switch to an alternate vendor.
> Did they become completely unreasonable and irrational when faced with a > new condition?
In our experience: yes, they did.
> However, despite a very current, very disappointing case, > reasoning with people at Franz Inc have been successful, even if time- > consuming (we don't fit into any of their models, making the situation > hard for us all).
Due to business realities, we couldn't afford the time to negotiate with Franz. Which made us hostage to their unreasonable demands, and they took full advantage of it before we could recover from the shock.
I could not in good faith recommend Franz to any commercial enterprise, and I'd say that if you feel compelled to use it, that you also invest enough resources in being able to quickly switch to an alternate vendor in case Franz attempts to blackmail you.
-- Don ___________________________________________________________________________ ____ Don Geddis http://shop.goto.com ged...@goto.com VP of Technology, GoTo Shopping Phone 650-403-2220 1820 Gateway Drive, Suite 300, San Mateo, CA 94404 Fax 650-403-2201
Erik Naggum <e...@naggum.net> writes: > Second, if you don't want to write symbols literally in upper-case, > you can (setf (readtable-case *readtable*) :invert) and have the > case reverted for mono-case symbols, and retained for mixed case > symbols. This causes a similarly case-sensitive reader, but has the > advantage that symbols whose names are upper-case will read and > print with lower-case.
The problem I see with :invert is that it doesn't exactly solve what Franz was trying to do from the outset. Basically, if you use :invert, then you get a case-sensitive reader for mixed-case (something they want). A symbol like 'remove-duplicates works just great when interfacing with the :common-lisp package (and so if you just make sure your code accessing symbols in the :common-lisp packages is written in lower case, you're still doing good). And even the mixed-case stuff in foreign libraries is good! It's the non-mixed case in foreign libraries that jacks everything up. But the solution is just so simple that it strikes me as crazy that they didn't use it instead of breaking with the standard:
### Use the same :invert rules when reading foreign code ###
Why not? Effectively, there's a symbol table that they create for foreign libraries, right? Only the external symbols of the foreign stuff matters, and if that stuff uses the :invert rules, then we're all happy. In fact, there can be TWO alternatives for people who want to use their Java interface:
1) use :invert on your readtable when using the Java stuff (or, even more simply, just set your *readtable* to theirs when using the Java stuff, or copy theirs, and modify it in acceptable ways that don't break the interface, according to what they specify you can do with the readable. 2) Use a nice, simple reader macro to escape the symbols. Someone suggested #_ because it's used in MCL. I like that. It's not bad at all:
(defun foo (bar baz) (#_createWindow bar (#_size baz)))
Plus, with a reader macro, you can do much more than access the symbol. It can pretty much expand into whatever you want it to.
Please correct me if my analysis is flawed.
> There is nothing _natural_ about the upcasing reader. It is merely > the default setting. As long as we know that Franz Inc argues very > strongly that people "just" have to evaluate a few lines of code to > get an ANSI Common Lisp from the Modern lisp image, it seems rather > disingenuous to argue against changing these other default values, > or as if they cannot be changed as easily as building a new image.
But the other big deal is that the symbol names in the :common-lisp package are upper case, and so it's kinda hard to deal with the case issue while leaving those symbols upper case.
I'm actually interested to know what "Modern" programmers really want in terms of case. I think I'm hapy with:
o readtable-case being set to :invert o *print-case* being set to :downcase o writing in all lower-case, all the while _knowing_ that the symbols in the :common-lisp package are internally uppercase. This means that:
(intern (format nil "~a-ID" fname))
is safer than
(intern (format nil "~a-~a" fname '#:id))
since the *print-case* re-downcases the uppercasing done by the reader. Of course, you can do:
(intern (format nil "~a-~a" fname '#:ID))
This way, we write code in lower case (nice), get case sensetivity (maybe nice, depending on what you want), and can interface well with foreign libraries.
ged...@Goto.Com (Don Geddis) writes: > > * David Bakhash <ca...@alum.mit.edu> > > | After a few years of development, deliveries of various products, > > | Company suddenly notices that Franz has decided that to run a server > > | application, they will charge _not_ for the single seat, as they used > > | to, but for each person accessing the server, and at the VAR pricing > > | (which is far from cheap). Oh, but unfortunately, Company doesn't > > | know exaclty how many people will access that server. No big deal; > > | Franz will assume a few hundred, if not more.
> Amusingly enough (?), this exact scenario happened to my previous > company some time ago. We were properly licensed for all our > development copies as well as our commercial use. Then we got a big > contract; Franz caught a whiff of it, and suddenly tried to force us > into a major new pricing model.
That's very closely in-line with my findings. Probably not a nice place to be, and so if I were, say a VC, and a software or service company were using Lisp, I'd be very impressed. If they said they were using Franz, I'd be very *worried*, unless they somehow managed to get a piece of paper, signed and notarized, which clearly stated that there be some basic, fair pricing controls.
> But the conclusion at our company was that sole-sourcing Lisp from > Franz in a commercial setting was a disaster, given that Franz was > more interested in extracting as much blood as possible during our > moment of weakness, rather than maintaining long-term relationships. > (This, after 10+ years of using Franz lisp by the principals!)
again, this is a bug in their business model. Do they actually think that this information wouldn't come out? How long did they think they could get away with such things! This is probably why John Foderaro prefers one-to-one interactions; it's because eventually, in an open forum people communicate information and the truth comes out.
> So: as much as I admire their technical accomplishments, in my view it is > a serious business mistake to rely on Franz for Common Lisp. Use something > like the open source CMUCL instead, which has 95% of Common Lisp, has a much > better/faster compiler than Franz, and has no license issues.
Yes. I'm not so concerned with speed, as I mostly design database-intensive applications where Lisp or Perl don't really make all that much of a difference. That's why I like the commercial Lisps. Then again, with CLORB and some of the other free CL stuff that's coming out, maybe CMUCL isn't such a bad idea. But (thank god) there are a few good companies out there for Common Lisp that arn't in the business of hanging their customers by their ankles until their pockets are empty.
> I could not in good faith recommend Franz to any commercial > enterprise, and I'd say that if you feel compelled to use it, that > you also invest enough resources in being able to quickly switch to > an alternate vendor in case Franz attempts to blackmail you.
Gosh. I guess that even if you're dealing with the best of companies, it's best to have this stuff pass by your legal department. But with a company that has a reputation of doing this, it's probably best to just concede to the fact that there's a long-term safety vs. short-term efficacy tradeoff, and personally, I tend to lean toward safety. It's part of caring about your company, your co-workers, and your principles.
dave
-- p.s. One thing I can just imagine right now are all the people that feel exactly the way you do, and have similar experiences, but they're so entangled in their current mess that they don't dare speak. I think that while you'll certainly end up taking heat for your openness, a lot of people are feeling vicarious relief.
* David Bakhash wrote: >> 2. toggle, globally, into ansi mode and back, losing case information >> about potentially every symbol in the system in the process. > I think after reading a post from one of the Franz guys, you can do > this without fear, and things will work just right. > [...] > No. Someone (from Franz, I think) already explained that the > variables involved with case are thread-specific. You definitely hit > something that was a possible problem, but they beat you to it, and > it's actually kind obvious, considering how *all* > multiprocessing-capable Lisps seems to treat the variables set by > WITH-STANDARD-IO-SYNTAX as thread-special variables.
I think some other followups in this thread explain why this won't work.
Tim Bradshaw <t...@cley.com> writes: > > No. Someone (from Franz, I think) already explained that the > > variables involved with case are thread-specific. You definitely hit > > something that was a possible problem, but they beat you to it, and > > it's actually kind obvious, considering how *all* > > multiprocessing-capable Lisps seems to treat the variables set by > > WITH-STANDARD-IO-SYNTAX as thread-special variables.
> I think some other followups in this thread explain why this won't > work.
Then I'm still confused, which I guess I already knew.
But I think that between something like a #_ reader macro and the :invert option on readtable-case, the "right" thing can be done without sacrificing the Standard.
Erik Naggum <e...@naggum.net> writes: > * Christopher Browne > | Fortunately, Emacs has a macro called "downcase-region."
> It also downcases literal strings, comments, filenames, etc.
Yes. The Modernist position is that they _should_ be downcased.
Next issue?
:-) -- (concatenate 'string "cbbrowne" "@hex.net") <http://www.ntlug.org/~cbbrowne/> "We're thinking about upgrading from SunOS 4.1.1 to SunOS 3.5." -- Henry Spencer
> Suppose Company was in the business of developing software. Company > chose Common Lisp as its primary development language, and Franz's ACL > as the specific implementation. Company noticed that ACL provided > many of the extensions necessary for Company's development needs, such > as networking, multiprocessing, etc. Company understood the basic > pricing scheme concepts. > After a few years of development, deliveries of various products, > Company suddenly notices that Franz has decided that to run a server > application, they will charge _not_ for the single seat, as they used > to, but for each person accessing the server, and at the VAR pricing > (which is far from cheap). Oh, but unfortunately, Company doesn't > know exaclty how many people will access that server. No big deal; > Franz will assume a few hundred, if not more. Do you think that's > something to at least worry a little about, given that you're already > a Franz customer? I'm just happy they changed this pricing thing > _before_ I ever purchased anything from them.
Well, I don't see why this company *fears* the vendor. It's probably made a mistake in not making sure it has an alternative offering it can move to, but that's not the vendor's fault. I also don't think I understand the licensing. This company signed a license with the vendor for a product. It can continue to use that product under the terms of that license. If the vendor chooses to require a new license with dramatically worse terms for a new version of the product, then the company should sit on the old version, find a different vendor, and move. That happens all the time.
The situation under which I can understand fear is where the vendor has a monopoly. I can understand fearing Microsoft: if they do something bad to the licensing of windows then a lot of people who want to be in the consumer applications marked have no choice but to keep using it.
But I can't see a market where you *have* to use Lisp: there are other languages, and people do develop applications in them. If you choose a language where there is only one realistic vendor, then you should make that decision with open eyes -- at some point the vendor *is* going to try and squeeze as much money out of you as they can without causing you to reimplement. Of *course* they are going to do that, this is capitalism! Why should they not?
