I had to tinker with a small expect script today. Eventually I plan to
rewrite this expect script in python + pexpect. As I was considering
this I observed that it is much clunkier to transform:
# expect code
expect {
-re "pattern1" {} # insert list of code to execute
"pattern2" {} # more code
"pattern3" {} # more code
timeout {} # yet more code.
}
into pexpect. One idiom would be to create a python function:
pexpect.expect-d(**patterndict):
# blah blah blah
where the 'key:value' entries are the 'expect pattern' and 'function to
invoke' respectively. One subtle problem with this approach is that
the user does not have control over the order in which the patterns are
tried against the string data. In the expect code the order is
implicit in the order of the pattern/code pairs in the statement.
while it is possible to come up with a pexpect syntax that is clunkier
than the expect syntax I got to thinking that if python had macros
(suspend disbelief for a moment) it would probably be easy to create a
pexpect syntax as nice as the expect syntax.
So, where is the humor? "Python macros, thats the punchline" you
think? Nope. While the idea of python macros my be amusing to
contemplate that is not what I really found amusing...
So, just for fun I popped over to the python newgroup, googled
"macros" and read on. The amusing thing were the reasons why macros
SHOULD not be added to python:
> I have never written a bunch of python code and then said to myself "I really could
> have used macros there".
This being said by a person who earlier made it clear they have never
used lisp macros before. Well DUH! If you have never used macros to
make code cleaner and simpler how do you expect to recognize when they
would help?
> if macros were allowed in the language, people might write bad macros. This would
> cause the python world to collapse.
Ah, the old "this tool is too powerful for mere mortals" argument.
Classic.
> non-hygenic macros would destroy the ability to use python modules.
Ah, the "people might write bad macros" dressed up in different
clothing
> CL like non-hygenic macros are bad and hygenic macros are too hard to implement
> and write.
Hmm, I'm not knowledgeable enough to express a smugly superior opinion
about the difficulty of implementing and writing hygenic macros.
==================
Obviously since Python is not s-expression based a programmer would not
be able to write powerful macros in python as easily as could be done
in CL, none the less I expect that someone could come up a python macro
system that is far more powerful than C++ templates, if less powerful
that lisp macros.
No doubt python will continue to help all sorts of people get useful
work done without having a macro system but having been exposed to the
lisp ideal of LFSP I find the LFTM philosphy espoused by Pythonistas
annoying.
Still, of the ubiquitous scripting languages (python, perl, bash)
python still seems by far the best.
--fj
"funkyj" <······@gmail.com> writes:
(Summary) no macros in Python.
No disagreement from me on any of your points. The following may be of
interest to you:
* http://livelogix.net/logix/
* http://www.fiber-space.de/EasyExtend/doc/EE.html
Eddie Corns wrote:
> The following may be of
> interest to you:
>
> * http://livelogix.net/logix/
> * http://www.fiber-space.de/EasyExtend/doc/EE.html
Those both look very cool! At work the mandate is that we write all
our code in C. I've sometimes thought about using lisp to create my
own more powerful preprocessor for C so that I could satisfy the
mandate (use C) while getting some of the power of lisp.
--fj
Any language may try to imitate things that make Lisp
unique and claim that their imitation works in the 90% of the
most used cases.
Question is: Why do you need cheap imitation when you can get the real
thing?
My latest experience is passing functional arguments to functions
in C++ by using functors It's possible to some level but it sucks.
funkyj <······@gmail.com> wrote:
+---------------
| At work the mandate is that we write all our code in C.
| I've sometimes thought about using lisp to create my own
| more powerful preprocessor for C so that I could satisfy the
| mandate (use C) while getting some of the power of lisp.
+---------------
Check out Aubrey Jaffer's "Schlep":
http://www.swiss.csail.mit.edu/~jaffer/Docupage/schlep.html
Yes, it's in Scheme, not CL, and uses Hungarian-suffixed variables
rather than real type declarations, but you may find it useful,
at least for study. In particular:
Using Scheme files as source, schlep produces texinfo
documentation and formatted C code preserving comments;
and type, function, and variable names as much as possible.
The output from schlep is human-readable and often forms
the base for further development in C; abandoning the original
Scheme source.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Eddie Corns wrote:
> "funkyj" <······@gmail.com> writes:
>
> (Summary) no macros in Python.
>
> No disagreement from me on any of your points. The following may be of
> interest to you:
>
> * http://livelogix.net/logix/
> * http://www.fiber-space.de/EasyExtend/doc/EE.html
Nice links, but oh god does Logix show up how bad infix operators are!
When you create a new macro, you basically create an infix operator and
you need to specify the binding value, which is basically the
precidence, ick!
Until I used Lisp I never realised how ambiguous infix math could be,
give me nice clear S-expressions any day.
Brad
> Obviously since Python is not s-expression based a programmer would not
> be able to write powerful macros in python as easily as could be done
> in CL, none the less I expect that someone could come up a python macro
> system that is far more powerful than C++ templates, if less powerful
> than lisp macros.
Or, they could just change over to using a simple and uniform syntax
based on some common delimeter, like, say, parens just to choose
something at random ...
········@gmail.com wrote:
> > Obviously since Python is not s-expression based a programmer would not
> > be able to write powerful macros in python as easily as could be done
> > in CL, none the less I expect that someone could come up a python macro
> > system that is far more powerful than C++ templates, if less powerful
> > than lisp macros.
>
> Or, they could just change over to using a simple and uniform syntax
> based on some common delimeter, like, say, parens just to choose
> something at random ...
Right. There are lots of possibilities that are simple and would
result in a macro system much more powerful than C++ templates. The
fact that Python isn't s-expression based doesn't prevent macros, but
it does require the introduction of new syntax (as you suggest above)
and in the absence of s-expressions many fancier macros are not
possible or, at the very least, much more difficult to write.
TANGENT: C++ templates are the only other preprocessing system that I
know of that is more powerful than C macros. Now that I think of it, C
macros, C++ templates and Lisp macros (lumping scheme and CL together
here) are the only macro like facilities I know of. Are there any
others? Is there another preprocessing system that is more powerful
than C++ templates but less powerful than lisp macros?
It appears that conventional wisdom is that the lisp macro system is
the upper limit (or near the upper limit) in terms of macro system
power. I also imagine everyone will agree that
C macros < C++ templates < lisp macros
If you know of other macro systems that may be of interest please
share.
Regards,
--jfc
funkyj wrote:
> If you know of other macro systems that may be of interest please
> share.
Ada's generic packages are very powerful.
--
Darren New / San Diego, CA, USA (PST)
My Bath Fu is strong, as I have
studied under the Showerin' Monks.
Darren New <····@san.rr.com> writes:
> funkyj wrote:
> > If you know of other macro systems that may be of interest please
> > share.
>
> Ada's generic packages are very powerful.
They are definitely less than C++ templates (which, while stupefyingly
clumsy and painful, are Touring complete).
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
jayessay wrote:
> They are definitely less than C++ templates (which, while stupefyingly
> clumsy and painful, are Touring complete).
I understand the Ada packages are also turing complete. Not that I'm an
expert at that.
--
Darren New / San Diego, CA, USA (PST)
My Bath Fu is strong, as I have
studied under the Showerin' Monks.
Darren New <····@san.rr.com> writes:
> jayessay wrote:
> > They are definitely less than C++ templates (which, while stupefyingly
> > clumsy and painful, are Touring complete).
>
> I understand the Ada packages are also turing complete.
No way.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
jayessay wrote:
> No way.
I'd be curious to see how you do something like addition and
conditionals using a C++ template, but this is probably the wrong group
for it. On the other hand, I don't mask my email address, so ...
--
Darren New / San Diego, CA, USA (PST)
My Bath Fu is strong, as I have
studied under the Showerin' Monks.
Darren New <····@san.rr.com> writes:
> I'd be curious to see how you do something like addition and
> conditionals using a C++ template
Once that becomes boring, carry on to Boost MPL:
http://www.boost.org/libs/mpl/doc/index.html
--
Steven E. Harris
Darren New <····@san.rr.com> writes:
> jayessay wrote:
>> No way.
>
> I'd be curious to see how you do something like addition and
> conditionals using a C++ template, but this is probably the wrong
> group for it. On the other hand, I don't mask my email address, so ...
Google for "c++ template primes" and you will get several links.
Calculating primes was one of the first examples that showed the
possibilities of the c++ template system.
Another good source are the boost-libraries, especially BLL (Boost
Lambda Library).
But be aware: knowing how to program C++ has almost nothing to do with
knowing how to program C++ templates!
Regards,
Marco
Marco Gidde wrote:
> Google for "c++ template primes" and you will get several links.
Cool, thanks!
--
Darren New / San Diego, CA, USA (PST)
My Bath Fu is strong, as I have
studied under the Showerin' Monks.
funkyj wrote:
> If you know of other macro systems that may be of interest please
> share.
I don't have any first hand experience with the language but according
to
the link below PL/I has powerful macros. Just scroll down to the
section
titled "Why Not a New Statement".
http://www.uni-muenster.de/ZIV/Mitarbeiter/EberhardSturm/PL1andC.html/
Spiros Bousbouras
funkyj <······@gmail.com> wrote:
+---------------
| TANGENT: C++ templates are the only other preprocessing system that I
| know of that is more powerful than C macros. Now that I think of it, C
| macros, C++ templates and Lisp macros (lumping scheme and CL together
| here) are the only macro like facilities I know of. Are there any
| others? Is there another preprocessing system that is more powerful
| than C++ templates but less powerful than lisp macros?
+---------------
MACRO-10 macros: MACRO-10 is/was the assembler for the DEC PDP-10,
and its macro system included looping [both count-based and looping
over arguments, as well as looping over the characters of an argument!],
branching, concatenation and thus interning of symbols [you could
write GENSYM in it], the assignment/mutation of the compile-time
values of symbols, and arithmetic [including booleans] on those values.
Most importantly, a macro could *define* other macros, whose name(s)
and expansion(s) were computed by the outer macro (at compile-time,
of course). So macros could count the number of times they were called,
and could even accumulate parameter values for use later. [See several
articles I've posted before about using this to implement "byte-strip"
lexical parsing tables for a FOCAL interpreter.]
They were definitely *way* closer to Lisp macros than C macros.
[I can't comment about C++ templates.]
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
"funkyj" <······@gmail.com> wrote in
·····························@c74g2000cwc.googlegroups.com:
> ········@gmail.com wrote:
> It appears that conventional wisdom is that the lisp macro system is
> the upper limit (or near the upper limit) in terms of macro system
> power. I also imagine everyone will agree that
>
> C macros < C++ templates < lisp macros
You can encapsulate flow control with C/C++ macros:
#define FOR(X,MIN,MAX) for(int X=(MIN); x<(MAX); x++)
etc.
Can C++ templates do that?
Can ANYTHING beside Lisp macros and pure text macros do that?
--
YAD
Yet Another Dan <········@vapornet.com> writes:
> Can C++ templates do that?
Take a look at Boost's FOREACH, which implements something similar
with macros and templates.
--
Steven E. Harris
Yet Another Dan wrote:
> Can ANYTHING beside Lisp macros and pure text macros do that?
Tcl. Smalltalk. FORTH. None of which use macros as such.
--
Darren New / San Diego, CA, USA (PST)
My Bath Fu is strong, as I have
studied under the Showerin' Monks.
Darren New <····@san.rr.com> wrote in
························@tornado.socal.rr.com:
> Yet Another Dan wrote:
>> Can ANYTHING beside Lisp macros and pure text macros do that?
>
> Tcl. Smalltalk. FORTH. None of which use macros as such.
Interesting. Of course, everything's a macro in tcl :D
--
YAD
On Sat, 17 Jun 2006 17:38:17 +0200, Yet Another Dan
<········@vapornet.com> wrote:
> "funkyj" <······@gmail.com> wrote in
> ·····························@c74g2000cwc.googlegroups.com:
>
>> ········@gmail.com wrote:
>> It appears that conventional wisdom is that the lisp macro system is
>> the upper limit (or near the upper limit) in terms of macro system
>> power. I also imagine everyone will agree that
>>
>> C macros < C++ templates < lisp macros
>
> You can encapsulate flow control with C/C++ macros:
>
> #define FOR(X,MIN,MAX) for(int X=(MIN); x<(MAX); x++)
>
> etc.
>
> Can C++ templates do that?
> Can ANYTHING beside Lisp macros and pure text macros do that?
>
erm..
FOR(y, start, start += interval)
expands to:
for (int y = (start); y < (start += interval); y++)
Be carefull what you call 'encapsulate'
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
"John Thingstad" <··············@chello.no> wrote in
······················@pandora.upc.no:
>> You can encapsulate flow control with C/C++ macros:
>>
>> #define FOR(X,MIN,MAX) for(int X=(MIN); x<(MAX); x++)
>
> FOR(y, start, start += interval)
>
> expands to:
> for (int y = (start); y < (start += interval); y++)
>
> Be carefull what you call 'encapsulate'
Agreed. Text macros are not safe in the absence of awareness and goodwill.
My argument is that arbitrary substitions are possible in C. These can be
either used or misused. My point is that they exist.
--
YAD
funkyj wrote:
> I had to tinker with a small expect script today. Eventually I plan to
> rewrite this expect script in python + pexpect. As I was considering
> this I observed that it is much clunkier to transform:
>
> # expect code
>
> expect {
> -re "pattern1" {} # insert list of code to execute
> "pattern2" {} # more code
> "pattern3" {} # more code
> timeout {} # yet more code.
> }
>
> into pexpect. One idiom would be to create a python function:
>
> pexpect.expect-d(**patterndict):
> # blah blah blah
>
> where the 'key:value' entries are the 'expect pattern' and 'function to
> invoke' respectively. One subtle problem with this approach is that
> the user does not have control over the order in which the patterns are
> tried against the string data. In the expect code the order is
> implicit in the order of the pattern/code pairs in the statement.
I would create an Expect class which overwrites __setattr__(). When a
new attribute is created the value is also stored in a list with
elements of the form ("pattern1", "some code...") such that you have
multiple access points and the insertion of the sequence is preserved:
class Expect(object):
def __init__(self):
super(Expect,self).__setattr__("_pattern", []) # direct
assignment won't work
# because __setattr__ is redefined
def __setattr__(self, name, value):
self._pattern.append((name,value))
super(Expect,self).__setattr__(name, value)
def __getitem__(self, i):
return self._pattern[i]
def compile(self):
pass
...
expect = Expect()
expect.pattern1 = "some code... "
expect.pattern2 = "some more code.. "
for pattern in expect:
print pattern
--->
('pattern1' ,"some code... ")
('pattern2', "some more code.. ")
> while it is possible to come up with a pexpect syntax that is clunkier
> than the expect syntax I got to thinking that if python had macros
> (suspend disbelief for a moment) it would probably be easy to create a
> pexpect syntax as nice as the expect syntax.
I'm not sure what you find nice about the expect syntax but that's a
matter of taste. Some people love Perl syntax as well and praise it for
its terseness. There is a language for everyone.
> So, where is the humor? "Python macros, thats the punchline" you
> think? Nope. While the idea of python macros my be amusing to
> contemplate that is not what I really found amusing...
>
> So, just for fun I popped over to the python newgroup, googled
> "macros" and read on. The amusing thing were the reasons why macros
> SHOULD not be added to python:
>
> > I have never written a bunch of python code and then said to myself "I really could
> > have used macros there".
>
> This being said by a person who earlier made it clear they have never
> used lisp macros before. Well DUH! If you have never used macros to
> make code cleaner and simpler how do you expect to recognize when they
> would help?
Sometimes it just helps to learn the idioms of the language ;)
Note that I'm obviously not against language transformations in and of
Python since I'm the author of EasyExtend. I just don't find that your
use case is a strong motivation for a language extension because there
are more "pythonic" ways to do it. Using macros here would be
overdesign.
As a side-node. The planned macro-system for Python that is based on
EasyExtend will likely resemble to that of Dylan.