> > > Barry Margolin <bar...@genuity.net> wrote in message > > > news:uCoO4.101$xb5.3308@burlma1-snr2... > > > > I suspect Smalltalkers would not consider our object model so highly > > > > developed, since CL is not objects all the way down like Smalltalk is. > > > > We're both certainly better than C, though.
> > > But, having used both, I'd say that CLOS has the better MOP. Smalltalk > has > > > too much of its inheritance mechanism hardwired into its VM.
> > Well, I suppose. In most implementations, certainly. It's not hard to > > add multiple inheriance, though. Or prototypes. Given that, which parts > > do you think are problematically hard wired?
> > (I should say that one can add those alternative inheritance mechanisms > > without giving rise to, e.g., terrible performance problems.)
> Unless you had access to and could change the VM code, the added multiple > inheritance stuff was much slower in method dispatch than the one hardwired > into the VM, usually going through the exception handling system and being > interpreted past there.
Ooo. I stand corrected then.
> You're correct that some Smalltalk vendors added > support for the notion (V2.5 of ParcPlace's Smalltalk-80, e.g.), but rolling > your own without VM support meant unacceptable performance hits.
That's interesting. I'll have to think about ways of doing MI. I guess a general optimized delegation mechanism might help.
> > > Multiple > > > inheritance is a big win over double dispatch hacks, too.
> > Surely you mean multiple dispatch (i.e., selecting methods on the basis > > of several or all the arguments rather than just the first)? Otherwise, > > I'm confused.
> You, of course are correct. I meant multi-methods. However, mixins are a > lot slicker and convenient than message forwarding.
I can't say, not having worked with mixins (although they certainly *seem* appealing).
> > Mutiple dispatch is definitely slicker from double dispatch, but I > > believe double dispatch is mostly confined to the arithmetic hierachy. > > Some pain when adding new numeric types, to be sure, but perhaps an > > acceptible compromise if one isn't typically feeling the need for > > multiple dispatch.
> Not only in the arithmetic, but throughout the drawing model, as well. > Shapes and screens have to send quite a few messages between each other to > form a picture. It also leads to inconsistencies when it comes to drawing > to a printer context rather than to a screen.
Ah. I stand corrected again! Thanks.
[snip]
> > I was wondering if you'd mind providing some of the details (e.g., why > > you wanted one, what the heavy issues were, etc.)? I have been pondering > > this question for some time. The major use for a macro expansion phase > > In Smalltalk, as I see it, is to permit more flexiblity with inlining > > various messages.
> The applications I was working on had various rule-based subsystems and > database interfaces that were compiled into methods on the fly for > performance reasons.
Interesting.
> Generation of Smalltalk's heavier syntax was a > relatively big pain, compared to generating code expansions for Lisp.
I'd imagine. But what about going directly to a parse tree and compiling that to bytecode? (I.e., it sounds like you were doing source-to-source transformations. I would have thought that compiling directly to a MethodNode headed tree would have been simpler.)
> Granted, either is a piece of cake compared to doing this for C++ or Java > :-).
But of course! :)
[snip]
> > Of course, > > Self didn't have to go with compiler based inlining, so perhaps this > > should be solved along those lines.)
> It's quite possible, but most Lisp folk seem more comfortable with > declarations and macro expansion and code that is directly compiled.
True. But can't seem to get those Smalltalker's enthused about it ;)
> Self's > approach is more relevant if you're using a JIT'ted VM, have no > declarations, depend heavily on message sends,
Er...Like Smalltalk (which was the context I was considering, which wasn't obvious from what I wrote; sorry).
> and can take the time to make > the JIT compiler more reflective. To do so in Lisp would make most of the > compilers out there generate larger code without much improvement in > performance.
I'll bet. But, I was wondering at the relative advantages and disadvantages of adding a macro facility to Smalltalk rather than taking the Self approach. I suspect that the decision isn't as clear as it is for Lisp.
But now we're *really* just into talking about Smalltalk, and thus somewhat off topic for the newsgroup :)
In article <390AC985.96E8C...@yahoo.com> posted on Saturday, April 29, 2000 6:37 AM, Peaker <GNUPea...@yahoo.com> wrote:
> Rahul Jain wrote:
>> How did you propose to write LOOP as a function and still have it execute >> at a somewhat reasonable speed? Macros are used for transforming code at >> _compile_ time, so that these transformations do not need to be applied >> at run time.
> Note that the fact macros force code to be created at compile-time is a > disadvantage, because function code can be inline'd and partially > evaluated (equivalent to macro-expanding) OR called, while macros are > always expanded.
That's a non-issue. The memory savings from not having to parse the whole LOOP body at runtime surely outweigh the slightly increased code size. (and note that the LOOP body will need to be saved as symbols, not as machine/byte code so it is likely to be even _larger_.)
> I would write a LOOP as a method on a block returning bool, that used a > 'goto' construct that is merely available for the low-level functionality and > implementability of such a concept.
So how does that actually accomplish what LOOP does? Are you saying that we remove LOOP and just use TAGBODY? Or should we just forget about HLLs and program everything in assembly?
>> Macros are what _make_ the language extensible. The alternatives you've >> shown have been tried and discarded.
> Discarded by whom? Note most languages used today, are far from having > macros as powerful as LISP's, or even have no macros. I would not > conclude things about a language according to hope people use it and what > they choose to discard.
So your judgement is better than (probably) hundreds of experts in the field who have actually USED and UNDERSTOOD the language constructs they're analyzing?
-- -> -\-=-=-=-=-=-=-=-=-=-/^\-=-=-=<*><*>=-=-=-/^\-=-=-=-=-=-=-=-=-=-/- <- -> -/-=-=-=-=-=-=-=-=-=/ { Rahul -<>- Jain } \=-=-=-=-=-=-=-=-=-\- <- -> -\- "I never could get the hang of Thursdays." - HHGTTG by DNA -/- <- -> -/- http://photino.sid.rice.edu/ -=- mailto:rahul-j...@usa.net -\- <- |--|--------|--------------|----|-------------|------|---------|-----|-| Version 11.423.999.210020101.23.50110101.042 (c)1996-2000, All rights reserved. Disclaimer available upon request.
> So how does that actually accomplish what LOOP does? Are you saying that we > remove LOOP and just use TAGBODY? Or should we just forget about HLLs and > program everything in assembly?
I'm sure he does not want this as most assemblers are macro-assemblers... In fact the it's interresting that both Lisp and assembly languages are the languages with the more powerful macro capabilities.
In article <C0D4C4CE434E199F.3C272A3AD5E0A2AC.0E83812091C8B...@lp.airnews.net> posted on Saturday, April 29, 2000 4:30 PM, "Marc Battyani" <Marc_Batty...@csi.com> wrote:
> Rahul Jain <ra...@rice.edu> wrote in message > news:8efj1k$3nm$1@joe.rice.edu... >> So how does that actually accomplish what LOOP does? Are you saying that > we >> remove LOOP and just use TAGBODY? Or should we just forget about HLLs and >> program everything in assembly?
> I'm sure he does not want this as most assemblers are macro-assemblers... > In fact the it's interresting that both Lisp and assembly languages are the > languages with the more powerful macro capabilities.
Yeah, I was thinking about that subject while I was writing my post, too... maybe change that to non-macro assemblers and he'll be happy :)
-- -> -\-=-=-=-=-=-=-=-=-=-/^\-=-=-=<*><*>=-=-=-/^\-=-=-=-=-=-=-=-=-=-/- <- -> -/-=-=-=-=-=-=-=-=-=/ { Rahul -<>- Jain } \=-=-=-=-=-=-=-=-=-\- <- -> -\- "I never could get the hang of Thursdays." - HHGTTG by DNA -/- <- -> -/- http://photino.sid.rice.edu/ -=- mailto:rahul-j...@usa.net -\- <- |--|--------|--------------|----|-------------|------|---------|-----|-| Version 11.423.999.210020101.23.50110101.042 (c)1996-2000, All rights reserved. Disclaimer available upon request.
* "Marc Battyani" <Marc_Batty...@csi.com> | In fact it's interresting that both Lisp and assembly languages are | the languages with the more powerful macro capabilities.
especially those popular at the time people were expected to write real code in assembly. I only got really familiar with the PDP-10 and its MACRO-10 language among the great processors of our time, but, boy, what an incredibly powerful macro language! tell this to the kids these days, however, and they just won't believe you.
Peaker <GNUPea...@yahoo.com> writes: > Perhaps you are right. Most of the time I was making > the assumption that everyone else found non-macro means > more clean. I do believe that most people really do > find the non-macro means cleaner, just less powerful.
this is called "projection" is pop-psych circles (like c.l.l!).
> > Generation of Smalltalk's heavier syntax was a > > relatively big pain, compared to generating code expansions for Lisp.
> I'd imagine. But what about going directly to a parse tree and compiling > that to bytecode? (I.e., it sounds like you were doing source-to-source > transformations. I would have thought that compiling directly to a > MethodNode headed tree would have been simpler.)
Yes. If We could have extended our funding, we would have eventually moved that way. We already had a specialized browser for rules.
When I looked at doing macros for Smalltalk, I looked at doing them right (i.e., specialize the browser, so it knew when you were looking at a macro, adding the macro support to the VW compiler, etc.).
The first hurdle would have been what you showed in the macro edit window for the source code. How do you syntactically differentiate the template for the generated code from the expansion-time code? I could never come up with a good syntax that fit into Smalltalk for that. The other problem I had trouble with was how do you go about parsing the arguments to the macro and what representation do you pass in? A string representation of the parameters would make sense at first glance, but it leaves a lot of parsing work for the user. A parse tree representation would be nice to manipulate, but harder to understand, traverse, and would have needed different node-types than the compiler used (mainly because the compiler nodes have a fair amount of contextual referencing - what method am I in, etc. - that would not have been available in the context of parsing a disembodied expression to pass to the expander).
Both of these are non-issues in Lisp. Backquote and comma syntax provide a nice syntactic interface, and the use of S-expressions as inputs gives a representation that's easy to destructure, transform, and, in general, just mess around with.
In the final analysis, I didn't have time to do macros right and so I decided that it was better to let the matter drop. It's probably just as well. Other languages with heavier syntax don't seem to fare too well in the macro department - look at C, C++, Dylan since the syntactic movement away from its Lisp roots, etc.
Who knows, I might try an implementation in Squeak sometime and see what turns up. Other things I'd like to add - functions not attached to objects (Why not? Smalltalk has global variables), better (i.e., more flexible) MOP, optional arguments (I actually had some VW code that did this, but it made heavy use of exceptions), etc. Squeak seems open enough to actually do these things right.
Peaker wrote: > > > I did not say CLOS+MOP was not powerful.
> > Um, I'm re-reading that sentence and it still looks to me like you are.
> What syntax features concerning the object model are there? Can you use > the object model of CLOS to create a Query language as done with the > 'retrieve' macro, and can be done with powerful enough alternative > object-models?
First you make a blanket statement (even worse, you _imply_ things about CLOS capabilities or their lack thereof) without doing research, then deny it, then you ask back if this+that possible with CLOS. Try to be positive: _state_ that CLOS lacks the ability to do this and that, and that you made your conclusion based on studying and trying hard.
There are a lot of misunderstandings about the relationship of OO and Lisp. One of them is that CL is less object-oriented than another language that is object-oriented from head to toe. By the time Smalltalk evolved, Lisp was already powerful and object-oriented even without being called OO. Also, nobody stops you from thinking in terms of classes, depicted this way:
On 28 Apr 2000 20:11:38 -0700, Duane Rettig <du...@franz.com> wrote:
> One prominent Smalltalker, Alan Kay, gave a keynote at OOPSLA '97 > and had some good things to say about AMOP. The tape of the talk is > circulating somewhere around Franz; perhaps I can find it and quote
By the way, what about taping/videotaping the keynote speeches of future Lisp conferences sponsored by Franz? The tapes might be sold together with the proceedings, or separately.
On 29 Apr 2000 21:58:38 +0000, Erik Naggum <e...@naggum.no> wrote:
> real code in assembly. I only got really familiar with the PDP-10 > and its MACRO-10 language among the great processors of our time, > but, boy, what an incredibly powerful macro language! tell this to > the kids these days, however, and they just won't believe you.
I am a kid--technologically wise--but I do believe you :) Could you elaborate on this? What were the most powerful or interesting features of MACRO-10?
>I can't verify this right now (offline), but apparently it quotes Alan >Kay as saying "The Art of the Metaobject Protocol is the best book >written in computing in ten years."
[snip]
since it was published in 1991, it only has a year left before it will be disqualified for this title!
In article <sashank-3004001637130...@129.59.212.53>,
sash...@vuse.vanderbilt.edu (Sashank Varma) wrote: > >I can't verify this right now (offline), but apparently it quotes Alan > >Kay as saying "The Art of the Metaobject Protocol is the best book > >written in computing in ten years." > [snip]
> since it was published in 1991, it only has a year left before it will > be disqualified for this title!
No. If he said it in 1997, he meant 1987-1997 by 'ten years'. He might think AMOP is the best book in 13 years _today_ or he might not. That I don't know.
> In article <LciN4.14$my3.569@burlma1-snr2>, > Barry Margolin <bar...@genuity.net> wrote: > >While I certainly don't consider BASIC to be the epitome of programming > >languages, I don't think I would be where I am today if it weren't for > >BASIC. It allowed me to learn programming on my own pretty easily at a > >time when there weren't many resources (the late 70's).
There was a time when I used to think this too.
Quite recently I understood that in reality, this quote:
kra...@dnaco.net (Kragen Sitaker) writes: > When I was ten, I could write all kinds of graphics stuff in BASIC, so > I thought I was a terrific programmer. Nobody could teach me anything; > I was convinced I knew all there was to know about programming.
> I didn't really grasp the idea of a subroutine, though --- even though > I'd learned to write recursive subroutines in Logo years before, I > never really caught on.
is only too true for me as well. (Well, Pascal rather than Logo)
I did pick up on subroutines for readability reasons, but didn't really get the "a function as an interesting object" concept under my skin before reading SICP last year. (Which is kinda odd, since I knew it well from mathematics)
I still haven't _quite_ gotten it, I think, but at least I'm looking in the right direction now.
I'm quite sure that learning Basic at a young age was better than not touching a computer at all, but one can only wonder how things would have worked out if I my first exposure to computing had been Lisp way back when...
> In article <390a196f$0$...@newsreader.alink.net> posted on > Friday, April 28, 2000 6:11 PM, "Harley Davis" > > Of course, the syntax is a little funny, but there is always the hoary trick > > of:
> unfortunately, that relies on COND being defined, which could > be used in place of IF-FN directly. The point is that a function > takes in parameters and returns a result. A macro takes in some > symbols and returns code transformed into a form that is defined > in terms of the language features existing before that macro was > defined.
In what sense could 'cond' be used in the place of 'if-fn'? 'cond' is not a function. Note that the original example used 'cond' in its expansion of an 'if' macro.
In article <390e1944$0$...@newsreader.alink.net> posted on Monday, May 1, 2000 7:00 PM, "Harley Davis" <nospam_hda...@nospam.museprime.com> wrote: Note that the original example used 'cond' in its expansion of an
> 'if' macro.
exactly my point... just use a cond in the first place :)
-- -> -\-=-=-=-=-=-=-=-=-=-/^\-=-=-=<*><*>=-=-=-/^\-=-=-=-=-=-=-=-=-=-/- <- -> -/-=-=-=-=-=-=-=-=-=/ { Rahul -<>- Jain } \=-=-=-=-=-=-=-=-=-\- <- -> -\- "I never could get the hang of Thursdays." - HHGTTG by DNA -/- <- -> -/- http://photino.sid.rice.edu/ -=- mailto:rahul-j...@usa.net -\- <- |--|--------|--------------|----|-------------|------|---------|-----|-| Version 11.423.999.210020101.23.50110101.042 (c)1996-2000, All rights reserved. Disclaimer available upon request.
I got a total different view of BASIC (and many other programming languages) when I happened to stumble across the proceedinngs from the first HOPL (History Of Programming Languages).
Reading about some of the ideas and thoughts that actually went into the creation of BASIC was an enlightening experience.
---------------------------+----------------------------------------------- --- Christian Lynbech | Ericsson Telebit, Fabrikvej 11, DK-8260 Viby J Fax: +45 8675 6881 | email: c...@ericssontelebit.com Phone: +45 8675 6828 | web: www.ericssontelebit.com ---------------------------+----------------------------------------------- --- Hit the philistines three times over the head with the Elisp reference manual. - peto...@hal.com (Michael A. Petonic)
> In article <390e1944$0$...@newsreader.alink.net> posted on > Monday, May 1, 2000 7:00 PM, "Harley Davis" <nospam_hda...@nospam.museprime.com> wrote: > Note that the original example used 'cond' in its expansion of an > > 'if' macro.
> exactly my point... > just use a cond in the first place :)
Except that the whole point of this subthread was how to write a function that does what cond does.
> Fernando D. Mato Mira <matom...@acm.org> wrote in message > news:3906FBE1.8ADEC22A@acm.org... > > The only reason I learnt BASIC is because I couldn't find a Lisp compiler > > for my Timex/Sinclair 2068 (the early 80's) ;-(
> I had more luck. At that time there were LeLisp 80 on the TRS-80. > It worked well with 48Ko of RAM and a 128Ko floppy disk....
> Marc Battyani
There was also Lisp/80 from Software Toolworks which ran on Heath H89 8 bit systems, cheap but slow, and then muLISP-80, much better, for CP/M and later muLISP-82 for MS-DOS. muLISP-90 is still good if you must target a DOS machine. I learned lisp after frustration trying to write a fairly large program in basic.
In article <Q32R4.52323$MZ2.603...@news1.wwck1.ri.home.com>,
Stanley Schwartz wrote: >There was also Lisp/80 from Software Toolworks which ran on Heath H89 8 bit >systems, >cheap but slow, >and then muLISP-80, much better, for CP/M and later muLISP-82 for MS-DOS. >muLISP-90 is still good if you must target a DOS machine. >I learned lisp after frustration trying to write a fairly large program in >basic.
Just a note for computer historians and Apple ][ fans...
muLISP has a companion package called muMATH, which evolved into Derive for DOS and Windows. There are two Apple ][ versions of muMATH (one for a CP/M card and the other a native program that used a CP/M-like operating system called ADIOS). I believe the situation is the same for muLISP. Both packages were distributed by our old friend Microsoft, who also sold a CP/M card.
*shameless beg* Anyone know where I can get a copy of the native version of muLISP? I already have an original package of the native version of muMATH and I want to expand my collection. :)
Peaker <pea...@makif.omer.k12.il> wrote: > I have been thinking a lot about language design lately. > This has made me doubt the real necessity of macros, as they always seem > to cover up for one or another language deficiency.
It's unlikely you'll define a language with no deficiency, therefore the only question is whether you can cover up the deficiencies that are there or not.
Java is a case in point. I think the key problem with Java is its lack of macros means you're stuck forever after with every complicated wart of syntax in the underlying language. Moreover, it's unlikely that any single syntax suffices to provide appropriate focus in all circumstances. Some of what macros do is to move the "solved problems" out of view and leave the programmer to view the "hard part" that has been left in more plain view. In Java, you can never move the easy or redundant or well-understood parts out of the way, so you can never control focus enough to highlight or zoom in on a specific aspect you want to really see clearly.
> In article <390371F0.36455...@makif.omer.k12.il>, > Peaker <pea...@makif.omer.k12.il> wrote:
> > I have been thinking a lot about language design lately. > > This has made me doubt the real necessity of macros, as they always seem > > to cover up for one or another language deficiency.
> It's unlikely you'll define a language with no deficiency, therefore the > only question is whether you can cover up the deficiencies that are there > or not.
> Java is a case in point. I think the key problem with Java is its lack > of macros means you're stuck forever after with every complicated wart of > syntax in the underlying language. Moreover, it's unlikely that any single > syntax suffices to provide appropriate focus in all circumstances. Some of > what macros do is to move the "solved problems" out of view and leave the > programmer to view the "hard part" that has been left in more plain view. > In Java, you can never move the easy or redundant or well-understood parts > out of the way, so you can never control focus enough to highlight or zoom > in on a specific aspect you want to really see clearly.
In retrospect this is quite obvious, but I have never heard it stated so well!
> It's unlikely you'll define a language with no deficiency, therefore the > only question is whether you can cover up the deficiencies that are there > or not.
> Java is a case in point. I think the key problem with Java is its lack > of macros means you're stuck forever after with every complicated wart of > syntax in the underlying language. Moreover, it's unlikely that any single > syntax suffices to provide appropriate focus in all circumstances. Some of > what macros do is to move the "solved problems" out of view and leave the > programmer to view the "hard part" that has been left in more plain view. > In Java, you can never move the easy or redundant or well-understood parts > out of the way, so you can never control focus enough to highlight or zoom > in on a specific aspect you want to really see clearly.
I agree with your analysis on the important function of macros as a kind of "safety valve". Java's choice may well have been motivated by the experiences with large commercial development projects, where macro abstraction (with all its semantic pitfalls) may cause, or be perceived to cause, more problems than the time it saves in terms of code sharing and reduced tedium.
But there is nothing prohibiting anybody from implementing macros for Java. More and more people, in fact, already use macro preprocessors with Java in the form of literate programming systems. You can also use m4 or other standard preprocessors, and there even some Java-specific ones. Syntax-aware, hygienic macros for Java would, of course, be really nice. Any volunteers? :-)
tom wrote: > But there is nothing prohibiting anybody from implementing macros > for Java...Syntax-aware, hygienic macros for Java > would, of course, be really nice. Any volunteers? :-)
Why reinvent lisp or a lisp-like language in java?
>tom wrote: >> But there is nothing prohibiting anybody from implementing macros >> for Java...Syntax-aware, hygienic macros for Java >> would, of course, be really nice. Any volunteers? :-)
The most interesting macros shadow definitions like defun and require code walkers to rebuild new calls to the original function. At least that is what makes normally written code be reusable in very special circumstances.
That is very hard to do for a language with Algol-like syntax.
William Deakin <wi...@pindar.com> writes: > tom wrote:
> > But there is nothing prohibiting anybody from implementing macros > > for Java...Syntax-aware, hygienic macros for Java > > would, of course, be really nice. Any volunteers? :-)
> Why reinvent lisp or a lisp-like language in java?
well, despite the fact that I tend away from Java, Java has many unique features that Lisp does not. Having macros, as a language feature, is something that is certainly part of Lisp, but not limited to Lisp. Any language can choose to add macros, if the designer had wanted them. Dylan is a good example.
One thing about Lisp though, is that it's macros are especially powerful. The fact that the program is interpreted as data, and each sexp is data, either a list or an atom, and because the language has many list-manipulation facilities, it's more than just a language which provides macros.
Basically, what I'm saying is that while any language can provide macros, Lisp is specially suited. If the next rev of Java had macros, they'd be extremely hard to write, and that's just bad, considering that macros are already very hard to write, even in Lisp.
