More people who have converted from static to dynamic typing:
http://www.tbray.org/ongoing/When/200x/2003/05/08/FutureLanguage
http://mindview.net/WebLog/log-0025
Pascal
Pascal Costanza wrote:
> More people who have converted from static to dynamic typing:
>
> http://www.tbray.org/ongoing/When/200x/2003/05/08/FutureLanguage
>
> http://mindview.net/WebLog/log-0025
Astonishing. How long has this static vs dynamic debate been raging? Now
die-hard static advocates are saying "never mind", because they learned
a new QA technique (XP-style test driven development). And they concede
the static strait jacket let's bugs thru (duh) so you have to test
anyway so...
note that these folks Pascal is digging up are C++ Gods. They write
books and edit journals in C++/Java. This revolution is coming from the
top, should go very fast.
one sad thing is Eckel's admission that simply trying Python was enough
to open his eyes to the fact that dynamic typing does not lead to
problems. so during his years of die-hard staticity he simply was
ignorant of the alternative.
I understand, tho, from Eckel's piece how this came to be: because they
experienced so much improvement going from C to C++. ie, They got stuck
in a false minimum. And I have to admit I ignored MCL for months when
searching for a Better Way than C++ back in '95 or so. Blind spots are
tough, I guess.
OK, so our plan is working. Have Steele create Java to turn everyone on
to GC, have Norvig create Python to turn everyone on to dynamic typing,
have Graham make a fortune on a dot com related project using Lisp so
all the geeks will listen to him...
:)
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Everything is a cell." -- Alan Kay
On Sat, May 10, 2003 at 02:35:11PM +0000, Kenny Tilton wrote:
> Pascal Costanza wrote:
> > More people who have converted from static to dynamic typing:
> > http://www.tbray.org/ongoing/When/200x/2003/05/08/FutureLanguage
> > http://mindview.net/WebLog/log-0025
> Astonishing. How long has this static vs dynamic debate been raging? Now
> die-hard static advocates are saying "never mind", because they learned a new
> QA technique (XP-style test driven development). And they concede the static
> strait jacket let's bugs thru (duh) so you have to test anyway so...
>
> note that these folks Pascal is digging up are C++ Gods. They write books and
> edit journals in C++/Java. This revolution is coming from the top, should go
> very fast.
But C++ is rather shitty as far as static-typing goes. I wouldn't exactly
classify C++ers as "die-hard static type advocates", because the true diehards
are to be found elsewhere. I don't think you'll see the top people in the SML
or Haskell communities jumping ship anytime soon. Not that this is altogether
a bad thing; at least they're doing interesting things with their systems.
Even if they're mostly doing academic research into type-systems ;-). And they
are promoting the usage of higher-level languages, a similar goal to ours.
Basically, I'm saying that it's not a static->dynamic trend, it's a
C++->dynamic trend, though it seems that Python is getting the most attention,
for better or for worse. :/
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
Matthew Danish wrote:
> On Sat, May 10, 2003 at 02:35:11PM +0000, Kenny Tilton wrote:
>
>>Pascal Costanza wrote:
>>
>>>More people who have converted from static to dynamic typing:
>>>http://www.tbray.org/ongoing/When/200x/2003/05/08/FutureLanguage
>>>http://mindview.net/WebLog/log-0025
>>
>>Astonishing. How long has this static vs dynamic debate been raging? Now
>>die-hard static advocates are saying "never mind", because they learned a new
>>QA technique (XP-style test driven development). And they concede the static
>>strait jacket let's bugs thru (duh) so you have to test anyway so...
>>
>>note that these folks Pascal is digging up are C++ Gods. They write books and
>>edit journals in C++/Java. This revolution is coming from the top, should go
>>very fast.
>
>
> But C++ is rather shitty as far as static-typing goes. I wouldn't exactly
> classify C++ers as "die-hard static type advocates", because the true diehards
> are to be found elsewhere. I don't think you'll see the top people in the SML
> or Haskell communities jumping ship anytime soon.
Point taken.
>
> Basically, I'm saying that it's not a static->dynamic trend, it's a
> C++->dynamic trend,...
I'll take it, in that all we need is refugees from Java/C++ in order to
grow CL.
> though it seems that Python is getting the most attention,
> for better or for worse. :/
And Smalltalk! We need a new PR agency. :) But as long as folks are on
the move, CL is bound to pick up some fraction of them.
The key is that the Java/C++ gurus are dumping their languages. We here
in CLL know we have a Better Way, but it's tough to keep up ones spirits
with 1% (picked at random) mindshare. Seeing Goliath run up the white
flag is welcome confirmation of our understanding of what things make
development easiest.
Something else I noticed is that the language these guys use to sing the
praises of dynamic languages could have been lifted right out of the
advocacy here on CLL. To be expected, I suppose, but it confirms that
this switch is for all the right reasons, meaning it will likely stick.
Hey, I wonder if Dylan will get a boost out of this? Will their bet on
C-ish syntax finally pay off? Will Dylan be the winner-take-all?
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Everything is a cell." -- Alan Kay
Kenny Tilton <·······@nyc.rr.com> writes:
> Hey, I wonder if Dylan will get a boost out of this? Will their bet on
> C-ish syntax finally pay off? Will Dylan be the winner-take-all?
I don't know about that. In my neck of the woods, it seems like
people go from C++ to Java. Not only that, JBoss is loosing to Sun's
J2EE. Not that there is anything wrong with JBoss or Tomcat. It
seems that inspite of the Open Source movement, people want to go to
some corporate backed standard. Sun owns Java. Who the hell is ANSI?
Perl has many Lisp like features and people are moving from it to
Java.
As for the topic of this thread, if you can do it in assembler,
perhaps you can do it in most other languages to. A language doesn't
have to support a feature for you to use it. It just makes using the
feature easier if it does.
I personally am interested in Lisp because I think it can give me at
least the productivity of Perl with the runtime efficiency of C.
There is no intrinsic reason why a C implementation can't deliver the
REPL effect of Lisp. They just haven't bothered to. I have infact
implemented hot swapable components in C++.
--
(describe 'describe)
David Steuber <·············@verizon.net> writes:
> I personally am interested in Lisp because I think it can give me at
> least the productivity of Perl with the runtime efficiency of C.
> There is no intrinsic reason why a C implementation can't deliver the
> REPL effect of Lisp. They just haven't bothered to. I have infact
> implemented hot swapable components in C++.
This is actually something where Java, as a per-se static language, is
quite strong. The bean shell - more or less a Java REPL - has been
around for some time now, and with tools like Eclipse or IntelliJ, you
get quite a convenient and flexible environment, the
edit-link-compile-debug cycle is way less an annoyance than it used to
be. (Especially when it's a "Keep the bar green to keep the code
clean" style "write test - run test - make test work - write next test"
cycle)
Of course, it's still not Lisp. Then again, the Lisps I know are
not modern Java environments either, both have different strengths and
weaknesses, and the gap is getting smaller due to development on both
sides.
IMHO, it's incredible how nice using Java can be given the right
tools. I can only guess how hard it really was to create such things
while constantly fighting with a language that really doesn't /want/ to
be used productively. And when I imagine what a joy programming would
be if the same effort would have been put in a Lisp IDE, I just want
to cry.
Regards
Henrik
Henrik Motakef <··············@web.de> writes:
> This is actually something where Java, as a per-se static language, is
> quite strong. The bean shell - more or less a Java REPL - has been
It's been quite a while since I used bsh, and I might have missed some
of its features, but to me a REPL in itself wasn't such a great
help. Without the ability to point to a function in the editor and
eval/compile it there isn't much gain in being able to evaluate simple
expressions. Not to mention that Java, with its static typing and
insistence on having to pack everything in some class looks completely
unfit for a true interactive style of development.
> around for some time now, and with tools like Eclipse or IntelliJ, you
> get quite a convenient and flexible environment, the
> edit-link-compile-debug cycle is way less an annoyance than it used to
> be. (Especially when it's a "Keep the bar green to keep the code
> clean" style "write test - run test - make test work - write next test"
> cycle)
>
> Of course, it's still not Lisp. Then again, the Lisps I know are
Not only that, but it never will be, I think. The difference (and I'm
talking about the programmer's experience) is not of degree.
> not modern Java environments either, both have different strengths and
> weaknesses, and the gap is getting smaller due to development on both
> sides.
>
> IMHO, it's incredible how nice using Java can be given the right
> tools. I can only guess how hard it really was to create such things
> while constantly fighting with a language that really doesn't /want/ to
> be used productively. And when I imagine what a joy programming would
> be if the same effort would have been put in a Lisp IDE, I just want
> to cry.
What exactly is it that you miss so much in a Lisp IDE, such as
Emacs/ELI for Allegro? Apart from stuff like an interface builder
(which I think you do have in the Windows version of ACL). Maybe it's
just that I don't feel comfortable with anything that doesn't have
Emacs in it somewhere (and I mean full Emacs, not something like LW's
editor), but even with Java, after trying one or two of the then
popular Java IDE's (this was a year ago or so), and staring at them in
awe, I went back to Emacs/JDE to get some work done.
Andras
David Steuber <·············@verizon.net> wrote in message news:<··············@verizon.net>...
> There is no intrinsic reason why a C implementation can't deliver the
> REPL effect of Lisp.
Paul Graham would beg to differ (from
<http://www.paulgraham.com/desres.html>):
"For example, it is a huge win in developing software to have an
interactive toplevel, what in Lisp is called a read-eval-print loop.
And when you have one this has real effects on the design of the
language. It would not work well for a language where you have to
declare variables before using them, for example. When you're just
typing expressions into the toplevel, you want to be able to set x to
some value and then start doing things to x. You don't want to have
to declare the type of x first. You may dispute either of the
premises, but if a language has to have a toplevel to be convenient,
and mandatory type declarations are incompatible with a toplevel, then
no language that makes type declarations mandatory could be
convenient to program in."
I agree with Paul Graham here, that a REPL is distinctly less useful
when one is forced to declare types in top level forms. I think this
is one of the failings of Dylan - despite it's name, it feels
distinctly less dynamic than Common Lisp because of the need to
declare object types, even in listener/interactor/top-level code.
Raf
·······@mediaone.net (Raffael Cavallaro) writes:
> I agree with Paul Graham here, that a REPL is distinctly less useful
> when one is forced to declare types in top level forms. I think this
> is one of the failings of Dylan - despite it's name, it feels
> distinctly less dynamic than Common Lisp because of the need to
> declare object types, even in listener/interactor/top-level code.
Dylan does have some weak spots (and we're working on eliminating
them), but this is definitely not one of them. Of course you can omit
the type, as you can in CL.
Andreas
--
"Share your knowledge. It's a way to achieve immortality."
-- His Holiness the 14th Dalai Lama Tenzin Gyatso
In article <····························@posting.google.com>,
·······@mediaone.net (Raffael Cavallaro) wrote:
> I agree with Paul Graham here, that a REPL is distinctly less useful
> when one is forced to declare types in top level forms. I think this
> is one of the failings of Dylan - despite it's name, it feels
> distinctly less dynamic than Common Lisp because of the need to
> declare object types, even in listener/interactor/top-level code.
Inconvenient point of fact: Dylan does *NOT* require you to declare the
types of variables, not even at the top level. Any variable/binding
that you don't declare is automatically of type <object>, which means it
can be bound to anything whatsoever.
The only place that Dylan requires you to declare types is if you want
to have more than one method in a generic function, in which case all
but one method must declare types for at least one of the arguments in
order that the methods can be distinguished. This is no different in
CLOS, except that as I understand it CLOS regards these specializers as
not in fact constituting type declarations.
-- Bruce
·······@mediaone.net (Raffael Cavallaro) writes:
> David Steuber <·············@verizon.net> wrote in message news:<··············@verizon.net>...
>
> > There is no intrinsic reason why a C implementation can't deliver the
> > REPL effect of Lisp.
>
> Paul Graham would beg to differ (from
> <http://www.paulgraham.com/desres.html>):
[elided]
> I agree with Paul Graham here, that a REPL is distinctly less useful
> when one is forced to declare types in top level forms.
I am only claiming it is possible. Certainly C prefers the
code-compile-debug cycle. C is after all just a high level
assembler.
Even high level scripting languages like Perl are limited to C's
code-compile-debug cycle. They (well Perl at anyrate) just compile
the script immediatly before execution.
As far as I can tell, the REPL simply compiles each form on the fly,
giving immediate feedback regarding syntax errors (and some other
errors). Presumably you can immediatly test the form once it has been
entered.
Having tools and a language work together the way Lisp does seems
pretty darn cool to me. I only know code-compile-debug. REPL should
be very nice to me once I get used to the idea that I don't have to
build entire compilation units to do any testing.
--
(describe 'describe)
In article <··············@verizon.net>,
David Steuber <·····@david-steuber.com> wrote:
>Even high level scripting languages like Perl are limited to C's
>code-compile-debug cycle. They (well Perl at anyrate) just compile
>the script immediatly before execution.
The perl debugger (the -d option to the perl command) is close enough to an
REPL. It's actually just an REL, but you can type "p <expression>" to get
the P.
--
Barry Margolin, ··············@level3.com
Genuity Managed Services, a Level(3) Company, Woburn, 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.
In article <··············@verizon.net>,
David Steuber <·············@verizon.net> wrote:
> Even high level scripting languages like Perl are limited to C's
> code-compile-debug cycle. They (well Perl at anyrate) just compile
> the script immediatly before execution.
Well that's false as well.
Perl has an "eval", and it can add global variables and functions just
as Lisp can. In fact the IRC client I normally use (SIRC) is
implemented in Perl and if I type "/eval <something>" then it executes
<something> as Perl instead of sending it to the other users and I have
a REPL right there. e.g.
/eval sub steuber {print shift() + 10}
/eval steuber(7)
17
/eval sub steuber {print shift() + 100}
/eval steuber(7)
107
Not a terribly *nice* REPL, but then it's an IRC client, not a REPL :-)
-- Bruce
David Steuber <·············@verizon.net> writes:
> There is no intrinsic reason why a C implementation can't deliver the
> REPL effect of Lisp. They just haven't bothered to.
http://root.cern.ch/root/Cint.html
http://softintegration.com/
Not sure whether the latter has a REPL, the former does. It's still a
huge PITA compared to Lisp.
On Sat, 10 May 2003 15:45:51 GMT, Kenny Tilton <·······@nyc.rr.com>
wrote:
>> Basically, I'm saying that it's not a static->dynamic trend, it's a
>> C++->dynamic trend,...
>
>I'll take it, in that all we need is refugees from Java/C++ in order to
>grow CL.
>
>> though it seems that Python is getting the most attention,
>> for better or for worse. :/
>
>And Smalltalk! We need a new PR agency. :) But as long as folks are on
>the move, CL is bound to pick up some fraction of them.
And of course we know why Smalltalk. They let you learn on *free*
implementations.
--------------------------------------------------
Thaddeus L. Olczyk, PhD
Think twice, code once.
In article <······························@news.netcologne.de>, Pascal
Costanza wrote:
> More people who have converted from static to dynamic typing:
>
> http://www.tbray.org/ongoing/When/200x/2003/05/08/FutureLanguage
>
> http://mindview.net/WebLog/log-0025
>
>
One interesting point is that some of these articles still confuse dynamic
and weak typing, which kind of misses the whole point.
Now these dynamic typing converts need to be pointed towards CL, which
has the nice feature of allowing (some) compile-time type checking _when
you ask for it_.
--
Eric Daniel
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
In article <············@corp.newsgroups.com>,
Eric Daniel <···········@barberic.vancouver.wa.us> wrote:
> In article <······························@news.netcologne.de>, Pascal
> Costanza wrote:
> > More people who have converted from static to dynamic typing:
> >
> > http://www.tbray.org/ongoing/When/200x/2003/05/08/FutureLanguage
> >
> > http://mindview.net/WebLog/log-0025
> >
> >
>
> One interesting point is that some of these articles still confuse dynamic
> and weak typing, which kind of misses the whole point.
Give them some time. ;)
> Now these dynamic typing converts need to be pointed towards CL, which
> has the nice feature of allowing (some) compile-time type checking _when
> you ask for it_.
My guess is that they will rather convert to Smalltalk.
Pascal
"Pascal Costanza" <········@web.de> wrote in message
···································@news.netcologne.de...
> In article <············@corp.newsgroups.com>,
> Eric Daniel <···········@barberic.vancouver.wa.us> wrote:
>
> > In article <······························@news.netcologne.de>, Pascal
> > Costanza wrote:
> > > More people who have converted from static to dynamic typing:
> > >
> > > http://www.tbray.org/ongoing/When/200x/2003/05/08/FutureLanguage
> > >
> > > http://mindview.net/WebLog/log-0025
> > >
> > >
> >
> > One interesting point is that some of these articles still confuse
dynamic
> > and weak typing, which kind of misses the whole point.
>
> Give them some time. ;)
>
> > Now these dynamic typing converts need to be pointed towards CL, which
> > has the nice feature of allowing (some) compile-time type checking _when
> > you ask for it_.
>
> My guess is that they will rather convert to Smalltalk.
>
>
> Pascal
I once tried to learn Smalltalk about 7 years ago--
the high prices of the Smalltalk system aided my
choice to use Lisp, (I chose Star Shappire CL about $100 for
MS-DOS.)
Smalltalk was a lang. used in AI back then.
Now most AI in done in Lisp, Prolog (NLP, Expert Systems) and
C++ (NuralNetworks, CelluarAutomata)
I guess dynamic lang. makes AI easier to code.
"Franz Kafka" <Symbolics _ XL1201 _ Sebek _ Budo _ Kafka @ hotmail . com> writes:
> "Pascal Costanza" <········@web.de> wrote in message
> > > Now these dynamic typing converts need to be pointed towards CL, which
> > > has the nice feature of allowing (some) compile-time type checking _when
> > > you ask for it_.
> >
> > My guess is that they will rather convert to Smalltalk.
> >
> >
> > Pascal
>
> I once tried to learn Smalltalk about 7 years ago--
> the high prices of the Smalltalk system aided my
> choice to use Lisp, (I chose Star Shappire CL about $100 for
> MS-DOS.)
>
> Smalltalk was a lang. used in AI back then.
Try Squeak http://www.squeak.org/
> Now most AI in done in Lisp, Prolog (NLP, Expert Systems) and
> C++ (NuralNetworks, CelluarAutomata)
>
> I guess dynamic lang. makes AI easier to code.
--
__Pascal_Bourguignon__ http://www.informatimago.com/
----------------------------------------------------------------------
Do not adjust your mind, there is a fault in reality.
Pascal Costanza wrote:
> In article <············@corp.newsgroups.com>,
> Eric Daniel <···········@barberic.vancouver.wa.us> wrote:
>
>>Now these dynamic typing converts need to be pointed towards CL, which
>>has the nice feature of allowing (some) compile-time type checking _when
>>you ask for it_.
>
>
> My guess is that they will rather convert to Smalltalk.
>
That would make sense since Smalltalk and Java both lack multiple
inheritance and macros and... and... and.... so if Javans go looking for
the least dissimilar, least powerful alternative as they did when moving
from C to Java, ST might be it
otoh, the barn door is open and the freed animals are stepping onto a
slippery slope which leads ineluctably to the most powerful, expressive,
dynamic, introspective programming language. That language is not
Smalltalk.
Anyway, we don't need all the refugees, just 10% of the best (and Lisp
will select for that).
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Everything is a cell." -- Alan Kay
In article <··············@nyc.rr.com>,
Kenny Tilton <·······@nyc.rr.com> wrote:
> Pascal Costanza wrote:
> > In article <············@corp.newsgroups.com>,
> > Eric Daniel <···········@barberic.vancouver.wa.us> wrote:
> >
> >>Now these dynamic typing converts need to be pointed towards CL, which
> >>has the nice feature of allowing (some) compile-time type checking _when
> >>you ask for it_.
> >
> >
> > My guess is that they will rather convert to Smalltalk.
> >
>
> That would make sense since Smalltalk and Java both lack multiple
> inheritance and macros and... and... and.... so if Javans go looking for
> the least dissimilar, least powerful alternative as they did when moving
> from C to Java, ST might be it
Another reason I can think of is that many of the proponents of Extreme
Programming and Test-Driven Development (I mean the buzzwords, not the
practices) are Smalltalkers.
> otoh, the barn door is open and the freed animals are stepping onto a
> slippery slope which leads ineluctably to the most powerful, expressive,
> dynamic, introspective programming language. That language is not
> Smalltalk.
>
> Anyway, we don't need all the refugees, just 10% of the best (and Lisp
> will select for that).
:-)
Pascal
Kenny Tilton wrote:
>
> Pascal Costanza wrote:
> > In article <············@corp.newsgroups.com>,
> > Eric Daniel <···········@barberic.vancouver.wa.us> wrote:
> >
> >>Now these dynamic typing converts need to be pointed towards CL, which
> >>has the nice feature of allowing (some) compile-time type checking _when
> >>you ask for it_.
> >
> >
> > My guess is that they will rather convert to Smalltalk.
What's actually happened, I suspect, is that Smalltalk programmers
have converted to Java in order to get jobs, and then kept their
heads down.
> That would make sense since Smalltalk and Java both lack multiple
> inheritance and macros and... and... and.... so if Javans go looking for
> the least dissimilar, least powerful alternative as they did when moving
> from C to Java, ST might be it
Smalltalk doesn't need macros. Control structures in Smalltalk,
both built-in and user-defined, are implemented as ordinary methods
(and use blocks, Smalltalk's lambda expressions). None of this
applies to Java, of course, which inherits its control structures
from C.
It doesn't look to me as if Smalltalk implementations lack power
either -- the Squeak libraries are rather impressive (e.g. MIDI,
speech synthesis, 3d, networking). And if it's raw speed you
mean, there is currently work being done on a native-code
compiler.
> kenny tilton
Le Hibou
--
"I'm outta here. Python people are much nicer."
-- Erik Naggum (out of context)
Donald Fisk <················@enterprise.net> wrote in message news:<·················@enterprise.net>...
> Smalltalk doesn't need macros. Control structures in Smalltalk,
> both built-in and user-defined, are implemented as ordinary methods
There are other uses for macros. Suppose for example
that I want to write a function to parse a roman numeral
from a string, and suppose that I discover that it will
work best (fastest or whatever) for my application if I
use a table of constants such as the following:
1000 M
900 CM 800 DCCC 700 DCC 600 DC 500 D
400 CD 300 CCC 200 CC 100 C
90 XC 80 LXXX 70 LXX 60 LX 50 L
40 XL 30 XXX 20 XX 10 X
9 IX 8 VIII 7 VII 6 VI 5 V
4 IV 3 III 2 II 1 I
Suppose at run time I want the table to be a compound
list, e.g. ((1000 "M") (900 "CM") (800 "DCCC") etc.)
and don't want in in the global namespace of my program
because it's only used in that one function. I could
of course just write that compound list with full
punctuation, and the problem would be solved. But this
is just a small example of a more general problem. I
don't want to write it as a compound list because I
want it to be neater, easier to maintain, and better
organized to make bugs more visible. I want it to
be laid out as an unpunctuated table whose contents
are easy to follow by their layout in the table.
It just so happens that I have a macro which will do
exactly what I want, and if I didn't have it, I could
write it easily. I simply give the above table as
arguments to my macro, and it creates the compound
list I want at macro expansion time, so there is no
extra time consumed at run time. I have found that
particular macro and others like it to be useful in
a lot of applications. Any time you need a table of
constants of some kind which is only useful to a
particular function, you can just take such a macro
out of your toolbag and stick it in there, solving
the problem in a few seconds, plus however much time
it takes to input the table, or cut and paste it from
some external source of information about your
application.
And this is just one of a large number of uses for
macros. So nobody should think macros are just for
control structures. And even for control structures
there is an advantage in having a lot of the work done
at macro expansion time so the runtime code will be
faster. And also the control structures can be made
neater by designing the macros for neatness.
Eric Smith wrote:
>
> Donald Fisk <················@enterprise.net> wrote in message news:<·················@enterprise.net>...
>
> > Smalltalk doesn't need macros. Control structures in Smalltalk,
> > both built-in and user-defined, are implemented as ordinary methods
>
> There are other uses for macros. Suppose for example
> that I want to write a function to parse a roman numeral
> from a string, and suppose that I discover that it will
> work best (fastest or whatever) for my application if I
> use a table of constants such as the following:
>
> 1000 M
> 900 CM 800 DCCC 700 DCC 600 DC 500 D
> 400 CD 300 CCC 200 CC 100 C
> 90 XC 80 LXXX 70 LXX 60 LX 50 L
> 40 XL 30 XXX 20 XX 10 X
> 9 IX 8 VIII 7 VII 6 VI 5 V
> 4 IV 3 III 2 II 1 I
>
> Suppose at run time I want the table to be a compound
> list, e.g. ((1000 "M") (900 "CM") (800 "DCCC") etc.)
> and don't want in in the global namespace of my program
> because it's only used in that one function. I could
> of course just write that compound list with full
> punctuation, and the problem would be solved. But this
> is just a small example of a more general problem. I
> don't want to write it as a compound list because I
> want it to be neater, easier to maintain, and better
> organized to make bugs more visible. I want it to
> be laid out as an unpunctuated table whose contents
> are easy to follow by their layout in the table.
>
> It just so happens that I have a macro which will do
> exactly what I want, and if I didn't have it, I could
> write it easily. I simply give the above table as
> arguments to my macro, and it creates the compound
> list I want at macro expansion time, so there is no
> extra time consumed at run time. I have found that
> particular macro and others like it to be useful in
> a lot of applications. Any time you need a table of
> constants of some kind which is only useful to a
> particular function, you can just take such a macro
> out of your toolbag and stick it in there, solving
> the problem in a few seconds, plus however much time
> it takes to input the table, or cut and paste it from
> some external source of information about your
> application.
>
> And this is just one of a large number of uses for
> macros. So nobody should think macros are just for
> control structures. And even for control structures
> there is an advantage in having a lot of the work done
> at macro expansion time so the runtime code will be
> faster. And also the control structures can be made
> neater by designing the macros for neatness.
You can do the above /without macros/ too, in Smalltalk
and, for that matter, Java, e.g. by creating a
RomanNumeralParser class which does the preprocessing
when an instance of it is created, and assigns the
compound list to a field of the instance. This is
then used by a parse method belonging to the class.
The difference between Smalltalk/Java and Lisp is that
Lisp gives you one more choice.
However, what cannot be done is extend the Java
language except by adding classes and methods, and
(unlike in Smalltalk) I know of no way these can
be used to implement new control structures. (You
could write a preprocessor, but that's cheating.)
Le Hibou
--
"I'm outta here. Python people are much nicer."
-- Erik Naggum (out of context)
In article <·················@enterprise.net>,
Donald Fisk <················@enterprise.net> wrote:
> However, what cannot be done is extend the Java
> language except by adding classes and methods, and
> (unlike in Smalltalk) I know of no way these can
> be used to implement new control structures. (You
> could write a preprocessor, but that's cheating.)
>
In Java, inner classes can be used to have closures to a certain degree.
Here is an implementation of a while loop in Java.
interface Test {
boolean execute();
}
interface VoidBlock {
void execute();
}
class Control {
static void _while (Test test, VoidBlock voidBlock) {
if (test.execute()) {
voidBlock.execute();
_while(test, voidBlock);
}
}
}
...
_while(new Test() {
boolean execute() {
return ...;
}
},
new VoidBlock() {
void execute() {
...;
}
});
[not tested!]
This already looks very tedious. It gets really annoying because of the
fact that inner classes only close over final variables.
Pascal
Pascal Costanza wrote:
> In article <·················@enterprise.net>,
> Donald Fisk <················@enterprise.net> wrote:
>
>
>>However, what cannot be done is extend the Java
>>language except by adding classes and methods, and
>>(unlike in Smalltalk) I know of no way these can
>>be used to implement new control structures. (You
>>could write a preprocessor, but that's cheating.)
>>
>
>
> In Java, inner classes can be used to have closures to a certain degree.
> Here is an implementation of a while loop in Java.
>
> interface Test {
> boolean execute();
> }
>
> interface VoidBlock {
> void execute();
> }
>
> class Control {
>
> static void _while (Test test, VoidBlock voidBlock) {
> if (test.execute()) {
> voidBlock.execute();
> _while(test, voidBlock);
> }
> }
> }
>
> ...
>
> _while(new Test() {
> boolean execute() {
> return ...;
> }
> },
> new VoidBlock() {
> void execute() {
> ...;
> }
> });
>
>
> [not tested!]
>
> This already looks very tedious.
Yeah, but you can just write a macro to expand Just Enough Code(tm) into
all that. Uh, hang on...
:)
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Everything is a cell." -- Alan Kay
In article <················@nyc.rr.com>,
Kenny Tilton <·······@nyc.rr.com> wrote:
> Yeah, but you can just write a macro to expand Just Enough Code(tm) into
> all that. Uh, hang on...
>
> :)
Well, there are even macro systems available for Java - but, uhm, what
was the point again? ;)
Pascal
Pascal Costanza <········@web.de> writes:
> In Java, inner classes can be used to have closures to a certain degree.
> Here is an implementation of a while loop in Java.
>
> _while(new Test() {
> boolean execute() {
> return ...;
> }
> },
> new VoidBlock() {
> void execute() {
> ...;
> }});
Good thing this is java. If this were done with Lisp we'd have all
these unreadable parenthesis all over the place.
Pascal Costanza wrote:
> In Java, inner classes can be used to have closures to a certain degree.
> Here is an implementation of a while loop in Java.
>
> interface Test {
> boolean execute();
> }
>
> interface VoidBlock {
> void execute();
> }
>
> class Control {
>
> static void _while (Test test, VoidBlock voidBlock) {
> if (test.execute()) {
> voidBlock.execute();
> _while(test, voidBlock);
> }
> }
> }
>
> ...
>
> _while(new Test() {
> boolean execute() {
> return ...;
> }
> },
> new VoidBlock() {
> void execute() {
> ...;
> }
> });
>
> [not tested!]
>
> This already looks very tedious. It gets really annoying because of the
> fact that inner classes only close over final variables.
Thanks for enlightening me. If it's all the same with you,
I think I'll stick to Lisp.
> Pascal
:ugah179
--
"I'm outta here. Python people are much nicer."
-- Erik Naggum (out of context)