Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Regular expression code implementation review between Tcl vs Python

Reply
Thread Tools

Regular expression code implementation review between Tcl vs Python

 
 
K_Lee
Guest
Posts: n/a
 
      11-12-2003
Alex Martelli <(E-Mail Removed)> wrote in message news:<3fdsb.10497$(E-Mail Removed)>...
> K_Lee wrote:
> ...
> > One aspect I don't understanding about python is that the Python
> > language itself is object oriented and all the internal is implement
> > as C object. Why not C++ object?

>
> Using an OO language doesn't necessarily make implementing another
> OO language any easier, when the object models are mismatched (and
> they almost invariably are). Look at other opensource OO languages,
> such as Ruby, and you'll see they also use C, not C++.
>
> Actually, a small and carefully selected subset of C++ might surely help,
> _if_ there was consensus on what that subset should be and net of
> the work of hashing that consensus out. But C++ just isn't very much
> in the opensource culture -- C is just much more popular. Eric Raymond's
> book "The Art of Unix Programming" doesn't address the issue directly but
> much of what it says about "Unix culture" extends directly to opensource
> (as he notes, too). There are such values as an admiration for simplicity
> (cfr. C's principle, as per the Rationale of the C Standard, "provide only
> one way to perform an operation", and Python's corresponding "there ought
> to be one, and preferably only one, obvious way to do it") which militate in
> favour of C (which may not have reached simplicity everywhere but surely
> did and does always strive for it) and against C++ (which never gave
> language-simplicity a high priority level among its many design goals); even
> in subcultures that overtly reject such principles (e.g., Perl's) they may
> still have some subconscious-level effect.
>
> I used to bemoan this back when I was a C++ not-quite-but-close-guru.
> 3 years later, with little use of C++ in the meantime, I have forgotten more
> about C++ than most of it practitioners will ever learn... but C is just
> never forgotten, like how to swim or how to ride a bicycle. So, I am not
> any longer so sure if my "bemoaning" was warranted.
>
>
> Alex


Alex,

It is sad but true.

One c++ project (was commercial, now open source) I found
that is very interesting to read/browse is the chorus. It is micro-kernel
os where everything is a class/object including threads, pagetable, scheduler.
Very interesting. Unfortunately, it seems to be dying when compare to
BSD, Linux.

http://www.slink-software.com/W/SrcD...s_c5.sdoc/N_59


What's nice about python's internal is that it is very clean
and well structure with object orient mind set.

K Lee
 
Reply With Quote
 
 
 
 
David Gravereaux
Guest
Posts: n/a
 
      11-12-2003
http://www.velocityreviews.com/forums/(E-Mail Removed) (K_Lee) wrote:

>I guess the TCL original goal was also to support
>Win16, DOS, etc.


No it wasn't. Given whatever core an extension is loaded into, the
extension grabs the function table from the core it is loaded into.

Say for example I build all of Tcl statically into my application (kinda
dumb, but let's just say). If I try to load an extension into it, where is
it supposed to get the Tcl functions it needs? Do you see the issue Stubs
solves?

PS. try that setup with BLT and see why Stubs is a life saver for those in
the know.
--
David Gravereaux <(E-Mail Removed)>
[species: human; planet: earth,milkyway(western spiral arm),alpha sector]
 
Reply With Quote
 
 
 
 
Alex Martelli
Guest
Posts: n/a
 
      11-12-2003
Rainer Deyke wrote:

> Alex Martelli wrote:
>> Using an OO language doesn't necessarily make implementing another
>> OO language any easier, when the object models are mismatched (and
>> they almost invariably are).

>
> Using RAII to automate reference count management would certainly help in
> implementing Python, even if it is a feature that Python itself doesn't
> have.


Yes, C++ surely has plenty of features -- including RAII, templates,
etc -- that might come in useful, quite apart from Python and/or C++
"being OO". You can see that in extensions written with "Boost
Python" -- you end up using _FAR_ less boilerplate, both for reference
counting and other housekeeping and interfacing tasks.

However, for the size and speed of the resulting code you end up
somewhat at the mercy of your C++ compiler, and I'm not sure they're
anywhere near as optimized as C compilers, yet -- it IS a MUCH larger
and more complicated language, after all.

The problems that C++'s size and complication give to its compilers
(and may, by now, be overcome in the very best compilers -- I do
believe that after these many years there ARE compilers which do
claim 100% compliance with the standard, for example, though I don't
know about quality of optimization) pair up with those given to its
users -- the price to pay for that wonderful plenty of features, of
course, and the awesome _potential_ for speed (even though there may
be yet some time to wait until the full extent of that potential is
actualized by super optimizers).

There's a long-standing debate on whether big languages can be
effectively subsetted, identifying a set of features that can be
counted on to be solidly and optimally implemented on all the
relevant compilers and ensuring no features outside that set are
ever used -- thus allowing programmers to only learn "half" the
language, or some such fraction. I believe this doesn't work,
except perhaps in a tightly knit group of Extreme Programmers who
are really keen to enforce the group-mandated subsetting rules --
and even then, slight mistakes may end up in "correct" code that
however strays from the blessed subset and produces symptoms which
you need complete knowledge of the language to understand.

So, my opinion is that if an open-source project adopted C++, it
would basically require contributors to make the effort to learn
the whole C++ language, not just half of it. _Some_ OS projects,
such as Mozilla or KDE, appear to thrive on C++, I believe, and
enforce SOME subsetting effectively. I'm not sure exactly what
dynamics are at play there, since I'm not a part of those projects.
Still, C still dominates the opensource scene -- C++ has a much
smaller presence there.


Alex

 
Reply With Quote
 
K_Lee
Guest
Posts: n/a
 
      11-12-2003
David Gravereaux <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>. ..
> (E-Mail Removed) (K_Lee) wrote:
>
> >I guess the TCL original goal was also to support
> >Win16, DOS, etc.

>
> No it wasn't. Given whatever core an extension is loaded into, the
> extension grabs the function table from the core it is loaded into.
>
> Say for example I build all of Tcl statically into my application (kinda
> dumb, but let's just say). If I try to load an extension into it, where is
> it supposed to get the Tcl functions it needs? Do you see the issue Stubs
> solves?
>



Ok, David, I understand better now.

(Putting on my monday morning quarterback hat.)

If the original design specifies that
* If you load extension with .so/dll, you are required
load tcl from .so/dll.
then we can get rid the stub interface, right?

That doesn't sound like an unreasonable requirement for
people who use any tcl + extension.


I still think Tcl'folks did a great jobs, just like to know the
trade off vs. features better.


K Lee
 
Reply With Quote
 
David Gravereaux
Guest
Posts: n/a
 
      11-12-2003
(E-Mail Removed) (K_Lee) wrote:

>David Gravereaux <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>. ..
>> (E-Mail Removed) (K_Lee) wrote:
>>
>> >I guess the TCL original goal was also to support
>> >Win16, DOS, etc.

>>
>> No it wasn't. Given whatever core an extension is loaded into, the
>> extension grabs the function table from the core it is loaded into.
>>
>> Say for example I build all of Tcl statically into my application (kinda
>> dumb, but let's just say). If I try to load an extension into it, where is
>> it supposed to get the Tcl functions it needs? Do you see the issue Stubs
>> solves?
>>

>
>
>Ok, David, I understand better now.
>
>(Putting on my monday morning quarterback hat.)
>
>If the original design specifies that
> * If you load extension with .so/dll, you are required
> load tcl from .so/dll.
>then we can get rid the stub interface, right?


Yes, I think so. But still extensions would get locked to a named shared
library. For example, loading a BLT extension which was linked against
tcl83.lib (implicit) into tclsh84 will breach and crash. Either way with
or without Stubs, implicit linking is still available. The EXTERN macro in
the prototypes exports them all.

>That doesn't sound like an unreasonable requirement for
>people who use any tcl + extension.


It's real easy to use, though.
1) compile with -DUSE_TCL_STUBS and link with tclstub8X.(lib|a)
2) Use this in the extension's exported *_Init as the first call:

#ifdef USE_TCL_STUBS
if (Tcl_InitStubs(interp, TCL_VERSION, 0) == NULL) {
return TCL_ERROR;
}
#endif

Beyond that, you don't need to think about it. You can even extend the
Stubs concept for applications that embed Tcl. Steps would be:

0) same as #1 above.
1) Knowing the path to a certain Tcl dll/so at or greater than the version
you require, dlopen/LoadLibrary it.
2) Get the address for Tcl_CreateInterp from the outside with
dlsym/GetProcAddress
3) make the first interp
4) call Tcl_InitStubs (code from tclstub8x.(lib|a) in us)
5) call Tcl_FindExecutable (very important!)
6) Done, function table loaded. Tcl_DeleteInterp or use it... You have
avoided 880 (or more) GetProcAddress calls to fill your own tables. Before
Stubs came around, I was guilty of doing that

Now you have an application that is upgradable from the outside, given that
the path to the Tcl dll/so is settable or auto-discovered in some manner.

>I still think Tcl'folks did a great jobs, just like to know the
>trade off vs. features better.


It gets even better with extensions that export a Stubs table. You can
build extensions for extensions Witness:

#undef TCL_STORAGE_CLASS
#define TCL_STORAGE_CLASS DLLEXPORT

EXTERN int
Gui_irc_Init (Tcl_Interp *interp)
{
#ifdef USE_TCL_STUBS
if (Tcl_InitStubs(interp, "8.3", 0) == NULL) {
return TCL_ERROR;
}
#endif
#ifdef USE_ITCL_STUBS
if (Itcl_InitStubs(interp, "3.1", 0) == NULL) {
return TCL_ERROR;
}
#endif
new IRCWindowsItclAdapter(interp);
return TCL_OK;
}

Using the services of [Incr Tcl] as well as Tcl, that extension declares
class methods for this script:

itcl::class IRC::ui {
constructor {args} {
_initUI
}
destructor {
_destroyUI
}
public {
method destroy {} {itcl::delete object $this}
method echo {} @irc-ui-echo
method window {} @irc-ui-window
method menu {} @irc-ui-menu
method hotkey {} @irc-ui-hotkey
method alias {} @irc-ui-alias
method channel {} @irc-ui-channel
method query {} @irc-ui-query
method chat {} @irc-ui-chat
method queries {} @irc-ui-queries
method chats {} @irc-ui-chats
method say {} @irc-ui-say
method input {} @irc-ui-input
}
private {
method _initUI {} @irc-ui-construct
method _destroyUI {} @irc-ui-destruct
}
}

The '@irc-ui-*' names refer to Tcl_CmdObjProcs set by the extension with
Itcl_RegisterObjC(). IMO, Stubs does not stop at the core.

>K Lee


--
David Gravereaux <(E-Mail Removed)>
[species: human; planet: earth,milkyway(western spiral arm),alpha sector]
 
Reply With Quote
 
Ro the Muppet
Guest
Posts: n/a
 
      11-12-2003
Ralf Fassel <(E-Mail Removed)> wrote in
news:(E-Mail Removed)-local.de:

> * (E-Mail Removed) (K_Lee)
>| http://www.slink-software.com/W/SrcD...cl8.4.4/tcl8.4.
>| 4.sdoc/N_92
>
> <quote>
> If you still like to use this webbase application,
> please enable the cookie in your browser and try again.
> </quote>
>
> You bet I won't. If you want people to read your stuff,
> let them read it with no obstacles.
>
> R'



i thought 2003 was the year of the cookie

oh wait that was 96
 
Reply With Quote
 
David Gravereaux
Guest
Posts: n/a
 
      11-13-2003
David Gravereaux <(E-Mail Removed)> wrote:

>Say for example I build all of Tcl statically into my application (kinda
>dumb, but let's just say).


Not dumb, sorry. Whoop.

Starpacs do this and for good reason: to be a single file application
distribution without dependencies.
--
David Gravereaux <(E-Mail Removed)>
[species: human; planet: earth,milkyway(western spiral arm),alpha sector]
 
Reply With Quote
 
=?ISO-8859-1?Q?Bernard_Delm=E9e?=
Guest
Posts: n/a
 
      11-13-2003
> _Some_ OS projects, such as Mozilla or KDE, appear to thrive on C++,
> I believe, and enforce SOME subsetting effectively.


In the case of Mozilla, some guidelines are available at
http://www.mozilla.org/hacking/portable-cpp.html
I don't know whether this is still enforced, since this document is 5
years old. And it shows: no templates allowed (hence no STL), no
exceptions, no RTTI... Phew! Must be very frustrating to follow, but if
such is the price of portability...

Also, using C++ for implementing scripting languages complicates
interfacing to extensions in the form of dynamic libraries, because of
the various name-mangling schemes different compilers use. How does
boost solve that problem, btw?

 
Reply With Quote
 
Alex Martelli
Guest
Posts: n/a
 
      11-13-2003
Bernard Delmée wrote:

>> _Some_ OS projects, such as Mozilla or KDE, appear to thrive on C++,
> > I believe, and enforce SOME subsetting effectively.

>
> In the case of Mozilla, some guidelines are available at
> http://www.mozilla.org/hacking/portable-cpp.html
> I don't know whether this is still enforced, since this document is 5
> years old. And it shows: no templates allowed (hence no STL), no
> exceptions, no RTTI... Phew! Must be very frustrating to follow, but if
> such is the price of portability...


Right -- still, it froze me solid of any inkling of joining the
mozilla team (I wouldn't mind "no RTTI", but....


> Also, using C++ for implementing scripting languages complicates
> interfacing to extensions in the form of dynamic libraries, because of
> the various name-mangling schemes different compilers use. How does
> boost solve that problem, btw?


A Python extension module just exposes "initmyname", it's not hard
to define that one as extern "C". And the Python headers are careful
to always wrap extern "C" ( ... } around everything if you use C++.
So, NP.


Alex

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
How to build a loadable tcl dll with visual studio (microsoft C compiler)?[crosspost in comp.lang.tcl and comp.lang.c++] Michael Reichenbach C++ 5 02-08-2010 02:38 PM
Inline::Tcl vs. Inline::Tcl Mumia W. Perl Misc 0 08-23-2006 04:09 PM
Matching abitrary expression in a regular expression =?iso-8859-1?B?bW9vcJk=?= Java 8 12-02-2005 12:51 AM
regular expression for perl, tcl, sed, grep, awk Jay eL Perl Misc 2 12-09-2003 04:23 AM
Dynamically changing the regular expression of Regular Expression validator VSK ASP .Net 2 08-24-2003 02:47 PM



Advertisments