gandreas@umn-d-ub.D.UMN.EDU (Glenn Andreas) (08/09/88)
Since I heard about LSP 2.0 coming out with the ability to compile MacApp, I've been thinking about buying it (I use MPW now). But I was wondering a few things about it: First, how does the editor work? I've never used LSP before but I have used MacPascal, and I understand that it is the same/similar editor. Is this true? That is, does the editor automatically "parse" the code you type (and do things like pretty-print, and make reserved words lowercase and bold?). Can all of that be turned off? I want a editor that keeps things just the way I type them - if I want to indent after an "IF" or put the short bit of code on the same line after the "THEN" it is my business. I write in a certain style for a reason - so I can understand it. If the editor works against me, I won't buy it, no matter how nice everything else is. The rest of the issues are minor in comparison: Does it allow LHS type coersion? (e.g. CursorHandle(h)^^:=c ) Does it allow calculated constants? (e.g. CONST maxPlus1 = max + 1) Does it allow "short circuit" boolean evaluation (e.g. IF h<>NIL & h^^.f > 5 THEN ... ) Does it pack arrays of booleans correctly? (TYPE KeyMap = PACKED ARRAY [0..128] OF BOOLEAN) Does it have conditional compilation? ({$IFC Debug=TRUE} WriteLn(x); {$ENDC}) I guess these last all come down to how close it is to MPW Pascal. The first question is the main one influencing my purchase. Oh, and is it shipping from such places as MacConnection, etc... If so, (and depending on the answers to the above questions) Mr Visa is going to get some exercise (now that my hard disk is almost paid off :-). Email or post. Thanks. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= = "When I was young, all I wanted was to be | - gandreas@ub.d.umn.edu - = = ruler of the universe. Now that isn't | Glenn Andreas = = enough" - Alex P. Keaton | = =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
singer@endor.harvard.edu (Rich Siegel) (08/15/88)
In article <450@umn-d-ub.D.UMN.EDU> gandreas@umn-d-ub.D.UMN.EDU (Glenn Andreas) writes: > >Since I heard about LSP 2.0 coming out with the ability to compile MacApp, >I've been thinking about buying it (I use MPW now). But I was wondering a >few things about it: > > First, how does the editor work? I've never used LSP before but I > have used MacPascal, and I understand that it is the same/similar > editor. Is this true? That is, does the editor automatically > "parse" the code you type (and do things like pretty-print, and make > reserved words lowercase and bold?). Can all of that be turned > off? I want a editor that keeps things just the way I type them - > if I want to indent after an "IF" or put the short bit of code on > the same line after the "THEN" it is my business. I write in a > certain style for a reason - so I can understand it. If the editor > works against me, I won't buy it, no matter how nice everything else > is. Because of the way the prettyprinter is central to Lightspeed Pascal's design, it can't be turned off. However, the version 2 pretty pritnter can be customized, so formatting such as you have described is possible. >The rest of the issues are minor in comparison: > > Does it allow LHS type coersion? (e.g. CursorHandle(h)^^:=c ) Yes > Does it allow calculated constants? (e.g. CONST maxPlus1 = max + 1) Yes. > Does it allow "short circuit" boolean evaluation (e.g. IF h<>NIL & > h^^.f > 5 THEN ... ) Not at present, though if there's time, possibly. > Does it pack arrays of booleans correctly? (TYPE KeyMap = PACKED > ARRAY [0..128] OF BOOLEAN) What is "correctly"? Packing is implementation-dependent. If you mean, "does it pack arrays of booleans to bits?", the answer is no. > Does it have conditional compilation? ({$IFC Debug=TRUE} WriteLn(x); > {$ENDC}) Yes. >I guess these last all come down to how close it is to MPW Pascal. The It's very close. Close enough so that MacApp can be compiled with the changes irequired being limited mostly to source reoranization. Version 2.0 will be shipping in the third quarter. R. Rich Siegel Quality Assurance Technician THINK Technologies Division, Symantec Corp. Internet: singer@endor.harvard.edu UUCP: ..harvard!endor!singer Phone: (617) 275-4800 x305
thecloud@pnet06.cts.com (Ken Mcleod) (08/16/88)
singer@endor.harvard.edu (Rich Siegel) writes: > Because of the way the prettyprinter is central to Lightspeed >Pascal's design, it can't be turned off. However, the version 2 pretty >pritnter can be customized, so formatting such as you have described >is possible. This is not good news. Not being able to turn off automatic formatting, regardless of how customizable it is, seems a serious mistake... in fact, I'm now having second thoughts about ordering the upgrade. I'm resisting the impulse to flame, since I think both LSC and LSP are generally pretty wonderful, and have taken their share of bashing on the net already, But p-p-pleeeeeeease...let it be noted, as an advance response to the questionnaire on the LSP 2.0 order form: I despise LSP's automatic pretty printer. The questions regarding it on the order form seem to imply that it could go away, if enough people voice their dislike... ========== ==================================== ....... =========== Ken McLeod UUCP: {crash uunet}!pnet06!thecloud :. .: "Kenneth, ---------- ARPA: crash!pnet06!thecloud@nosc.mil :::.. ..::: what is the thecloud@pnet06.cts.com | thecloud@dhw68k.cts.com //// frequency?"
vita@lansoar.steinmetz (Mark F. Vita) (08/16/88)
In article <5116@husc6.harvard.edu> singer@endor.UUCP (Rich Siegel) writes: > Because of the way the prettyprinter is central to Lightspeed >Pascal's design, it can't be turned off. I hope you will forgive me for saying so, but this is a pretty piss-poor design. The logical meaning of program text is completely independent of how it is formatted on the screen. I realize that you guys do some lexical and syntactic analysis as program text is being typed in, but I can't see why you couldn't analyze the text without then proceeding to screw up the formatting. Perhaps you could explain this? >However, the version 2 pretty >pritnter can be customized, so formatting such as you have described >is possible. Yes, I saw this demo'ed at the Expo, and it does help a bit. However, there's no way you could allow for all the possible permutations of styles that various people might prefer. I mean, there might some freak out there who prefers one token per line or something equally bizarre. The ultimate "customization" would be the ability to turn the damn thing off and do your own formatting. One thing I don't recall about the customization; will I be able to get more than 1 statement per line? i.e.: i := 1; j := 2; k := 5; m := 12; rather than the ugly way LSP forces this now: i := 1; j := 2; k := 5; m := 12; Sorry if I'm flaming a bit here, but I just *can't believe* that after all the time that LSP had been around, and considering the *huge* amount of bitching and moaning about the editor, that a major upgrade is being released, AND YOU STILL CAN'T TURN OFF THE *&@#%^*@ PRETTY PRINTING!!! If it is indeed central to the design of LSP, I would suggest that you need a redesign, in a big way. Don't get me wrong, I love LSP. I just annoys me that such a powerful product is being crippled by a brain-damaged program editor. >Rich Siegel >Quality Assurance Technician >THINK Technologies Division, Symantec Corp. >Internet: singer@endor.harvard.edu >UUCP: ..harvard!endor!singer >Phone: (617) 275-4800 x305 ---- Mark Vita ARPA: vita@ge-crd.ARPA General Electric Company UUCP: vita@desdemona.steinmetz.UUCP Corporate R & D vita@desdemona.steinmetz.ge.com Schenectady, NY desdemona!vita@steinmetz.UUCP
singer@endor.harvard.edu (Rich Siegel) (08/17/88)
In article <11864@steinmetz.ge.com> desdemona!vita@steinmetz.UUCP (Mark F. Vita) writes: >then proceeding to screw up the formatting. Perhaps you could explain >this? It seems to me what no matter what I say, those who hate the pretty printer will continue to say "It sucks, Lightspeed Pascal needs to be redesigned without the pretty printer, I don't like the way it formats", and so on. But I'll try to explain. The pretty printer is not a central design feature in and of itself. It's merely a reflection of the internals. The program text is not stored as text; instead, there is an internal representation that contains the information that's normally contained textually in the source files. The direct result of this is that the text you see in an editing window isn't text; it's the outward manifestation of this internal representation. As you type the text in, the incremental compiler tokenizes it and translates to this internal form, and the pretty-printer then displays the text. This is why it's impossible to tell the pretty-printer to do nothing. The internal form does have its advantages. Since the text i incrementally tokenized, compilation happens much faster. Also, the debugger relies on the information contained in this internal form. Since you saw Pascal demo'd at MacWorld, I assume you also saw the new LightsBug, right? That would be extremely difficult to do without this internal form. Likewise for the Instant and Observe windows. Part of the reason this is all done tis way is historical: Macintosh Pascal is based on almost exactly the same internal form, and when Lightspeed Pascal was being created, it was a a logical choice to continue to use this form. If it's any comfort, some of us here at THINK consider the internal form to be a pain; it's tough to maintain, for one thing. Sometime in the future, it's going away, but not soon enough to please the people who hate the prettyprinter. Also: based on the people I talked to at MacWorld, more people liked the pretty-printer than hated it, and it's more than an even split - a large majority liked it. It's just that the people who don't like it bitch louder... Now that I've given an explanation of why the pretty-printer is there, I am going to waste no more of my time and no more of the net's bandwidth arguing with people who don't like it. -Rich Rich Siegel Quality Assurance Technician THINK Technologies Division, Symantec Corp. Internet: singer@endor.harvard.edu UUCP: ..harvard!endor!singer Phone: (617) 275-4800 x305
landman%hanami@Sun.COM (Howard A. Landman) (08/18/88)
In article <11864@steinmetz.ge.com> desdemona!vita@steinmetz.UUCP (Mark F. Vita) writes: >One thing I don't recall about the customization; will I be able to >get more than 1 statement per line? i.e.: > > i := 1; j := 2; k := 5; m := 12; > >rather than the ugly way LSP forces this now: > > i := 1; > j := 2; > k := 5; > m := 12; Hmmm. I've worked at two companies where it was part of the coding standards that you never put more than one statement on a line. Of course, in C it's possible to cheat: i = 1, j = 2, k = 5, m = 12; The above is technically one statement. Perhaps it's really the Mac's small default screen that's your problem? I never had a reason to cram statements onto lines when I was using a 48- or 60-line terminal (or emulator), but at 24 lines it's perhaps desirable. "One man's nightmare is another man's wet dream." Howard A. Landman landman@hanami.sun.com UUCP: sun!hanami!landman
kurtzman@pollux.usc.edu (Stephen Kurtzman) (08/19/88)
In article <64658@sun.uucp> landman@sun.UUCP (Howard A. Landman) writes: >Hmmm. I've worked at two companies where it was part of the coding >standards that you never put more than one statement on a line. Of >course, in C it's possible to cheat: > i = 1, j = 2, k = 5, m = 12; >The above is technically one statement. A looser interpretation of the one statement per line rule is one functional unit per line. The variables assignments used in your example is a good example of a single functional unit. Putting these all on one line is not unlike listing all of the arguments to a function together on a single line. That is, in some contexts the variable assignments can be viewed as the initialization of parameters used in the following block of code.
gandreas@umn-d-ub.D.UMN.EDU (Glenn Andreas) (08/20/88)
In article <5131@husc6.harvard.edu> singer@endor.UUCP (Rich Siegel) writes: > > It seems to me what no matter what I say, those who hate the >pretty printer will continue to say "It sucks, Lightspeed Pascal needs >to be redesigned without the pretty printer, I don't like the way >it formats", and so on. > > But I'll try to explain. > [ a very good explaination of the internals of LSP & its editor ] > > Also: based on the people I talked to at MacWorld, more people liked >the pretty-printer than hated it, and it's more than an even split - a >large majority liked it. > > It's just that the people who don't like it bitch louder... > > > Now that I've given an explanation of why the pretty-printer is there, >I am going to waste no more of my time and no more of the net's bandwidth >arguing with people who don't like it. > > > -Rich OK OK OK OK. I unfortunately brought this whole thing about with my question about the editor in LSP 2.0. And with Rich's comment a while ago about being able to customize the format just about any way, I was satisfied. Also, some one from Apple (or was it Claris?) mailed me a comment that it just takes a while to get use to. I was satisfied. So I called MacConnection. One day and $68 later, I had version 1.11. Fine, I'll try it out. At first I was disappointed. I couldn't handle the reserved words being in lowercase and bold. Being bold they stuck out too much, and being in lowercase, I couldn't scan for them (I'm use to uppercase letters for reserved words - I guess that comes from reading the source for MacApp :-). So I fixed that. I used fedit and found the reserve word, changed them to uppercase. I used Macsbug and found where the trap for TextStyle was, and changed it so it always is in plain (this also inhibits the outlining of errors). Now I could stand using it. And I used it. A lot (even crashing it a few times - it sometimes doesn't like clicking on program windows when you are debugging). And while the format isn't the exact way I like it, it isn't terrible. And I got use to not using the return key. And I started to like it. The auto-formatting became a non-issue. The speed and the debugging powers became important. So, in summary, for those of you who won't buy it because of the editor, listen to one who use to be one of you. Buy it. It's not as bad as you imagine. You may even end up liking it (give it a few days). And the other features of the environment way out weigh any bias about the editor. If anything, my complaints about the editor are the lack of an undo, arrow keys, and a zoom box on the window. Not the auto-formatting - it's just fine. Trust me. Buy it, you'll like it. I did. I hope this puts it all to rest. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= = "When I was young, all I wanted was to be | - gandreas@ub.d.umn.edu - = = ruler of the universe. Now that isn't | Glenn Andreas = = enough" - Alex P. Keaton | = =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
florman@randvax.UUCP (Bruce Florman) (08/27/88)
In article <464@umn-d-ub.D.UMN.EDU> gandreas@ub.d.umn.edu.UUCP (Glenn Andreas) writes: >At first I was disappointed. I couldn't handle the reserved words being in >lowercase and bold. Being bold they stuck out too much, and being in >lowercase, I couldn't scan for them (I'm use to uppercase letters for >reserved words - I guess that comes from reading the source for MacApp :-). >So I fixed that. I used fedit and found the reserve word, changed them to >uppercase. I used Macsbug and found where the trap for TextStyle was, and >changed it so it always is in plain (this also inhibits the outlining of >errors). Now I could stand using it. Now why didn't I think of that!?! I too have been bothered by the lowercase bold reserved words, but I never thought about doing anything about it. I applied your patches and I really like the results. However, I wanted to keep the outlining of lexical errors, so I looked a little closer at the code around the TextFace trap, and found the following: 123B 1007 MOVE.B 7(PC,D1.W),D1 ; fetch appropriate style 3F01 MOVE.W D1,-(A7) ; push it onto the stack A888 _TextFace ; call ROM routine 4E75 RTS ; exit 00 DC.B 0 ; plain 08 DC.B 8 ; outline 01 DC.B 1 ; bold Using Fedit I simply changed that last 01 byte to 00. Now the errors are still printed in the outline style, but the keywords are plain. Thanks for the good idea. -- florman@rand-unix.ARPA {decvax,sdcrdcf,trwrb,trwspf,vortex}!rand-unix!gnu!florman "There is no limit to the amount of good that people can accomplish, if they don't care who gets the credit." - Anonymous
g099508030ea@deneb.ucdavis.edu (Jim Deline) (11/30/88)
The ads for Lightspeed Pascal 2.0 say that it produces the tightest, fastest code of all Pascal compilers. Well, I received my upgrade yesterday, and when I compiled a program I had written with version 1.11 it was 7K larger!! The original program compiled to 23K, and the compiled version with 2.0 compiled to 30K...this is hardly smaller. Has anyone else tested version 2.0 to see what the size difference is when they compile old source code? I would be interested in hearing from you. J. Deline UCD Chem. Dept.
siegel@endor.harvard.edu (Rich Siegel) (12/01/88)
In article <3330@ucdavis.ucdavis.edu> jedeline@deneb.ucdavis.edu (Jim Deline) writes: > >received my upgrade yesterday, and when I compiled a program >I had written with version 1.11 it was 7K larger!! The original >program compiled to 23K, and the compiled version with 2.0 >compiled to 30K...this is hardly smaller. Has anyone else Are you comparing the size of your built application, or are you comparing the object size numbers as they appear in the project window? Remember that the final application will have things in it like the runtime libraries; depending on how many Pascal intrinsic routines you use, more of the runtime stuff will be linked in, resulting in a bigger program. Also, are you using overflow and range checking? That will also increase the code size. If you're giving a comparison, give ALL the details. --Rich Rich Siegel Staff Software Developer THINK Technologies Division, Symantec Corp. Internet: siegel@endor.harvard.edu UUCP: ..harvard!endor!siegel Phone: (617) 275-4800 x305 Any opinions stated in this article do not necessarily reflect the views or policies of Symantec Corporation or its employees.
matthews@eleazar.dartmouth.edu (Jim Matthews) (12/01/88)
In article <3330@ucdavis.ucdavis.edu> jedeline@deneb.ucdavis.edu (Jim Deline) writes: > >The ads for Lightspeed Pascal 2.0 say that it produces the >tightest, fastest code of all Pascal compilers. Well, I >received my upgrade yesterday, and when I compiled a program >I had written with version 1.11 it was 7K larger!! A medium-size (110k of object code) program of mine was around 25% larger when compiled by LSP 1.11 compared to MPW Pascal. With LSP 2.0, it is 1% *smaller*. My collegues have also seen dramatic improvements compared to version 1.11, and less dramatic improvements over MPW. So the advertising hype has rung true for us. Jim Matthews Dartmouth Software Development
rdsesq@Jessica.stanford.edu (Rob Snevely) (12/16/88)
I finally got my LSP 20 upgrade. (YEA!!!) After reading some of the postings about possible larger code size, I was sceptical about it. However, that scepticism is rapidly fading. I got it set up and recompiled a very small program. After saving the source as text, I loaded it created a new project, added the file, recompiled, and (TA DA) 30 % smaller. I tried another and almost 40% smaller. So to Rich and THINK, I am impressed. For me it was worth the wait. However, I could use MacApp or its equivalent for LSP. Any idea on when or if this will happen. rob rdsesq@jessica.stanford.edu Disclaimer: I don't work for think or sumantec, I am for the moment atleast a very satisfied customer.