RE: Random late night ramblings

Moving this to prothon-user since we decided prothon-user was for discussion
of undecided issues and prothon-dev was for discussion of implementing
decided issues.

1) We decided that a prime directive of Prothon was to use Python as the
basis for the language except for where it conflicted with Prototype
enhancements or where Python was broken to the point the even Python people
admit it.  So changing something as fundamental as the Python indentation is
not really up for discussion.

I need to publish the "prime directives" or "mission statement" for Prothon.
We can even argue up at that meta-level.

2. I haven't considered something like Parrot for out interpreter but that
is definitely something to look into.  I'll put it on the maybe list.  Our
interpreter is at such a high-level right now that I can't imagine using
anyone else's, but that is probably an indicator of my ignorance.

3. Yes, continuations should be trivial.  I'm not too familiar with them and
their usefulness, but the support is definitely there.  When I implemented
yield and generators with our frames it was really easy.  The frame
structure is really self-contained and flexible. (And unfortunately
un-documented for now).

4. Yes, I and a zillion other Python users agree that Guido's lack of
support for the ternary expression is a broken part of Python.  I will put
it on the list.

5. No one is working on the memory leaks now.  It's just a matter of
manpower.  It's more fun to add more features than to plug leaks.

There are two kinds of leaks.  The C leaks and the new kind of DEL_LOCK
leaks.  Prothon has a DEL_LOCK bit that is set on every object when the
object is created to protect the object from the garbage collector until
it's disposition is settled.  The ultimate owner of the object is supposed
to clear the DEL_LOCK bit with a del_unlock(obj) call after storing it in
the container hierarchy or deciding that the object is no longer needed.
This kind of responsibility is the equivalent of the reference counting
responsibility of the Python C code, although it is less stringent.

6. To claim a task just ask on the prothon-dev list if you can work on it.
We don't have any formal scheme in place yet.  We only went public with this
a few days ago.

-----Original Message-----
From: [email protected]
[mailto:[email protected]]On Behalf
Of Leif Hedstrom
Sent: Saturday, March 27, 2004 12:14 AM
To: [email protected]
Subject: [Prothon-dev] Random late night ramblings


Hello,

First off, there's a lot of interesting ideas here, with plenty of
opportunity to create something useful. I've read as much as I could
find on the Prothon pages, and here are a few random thoughts:

   1. I'm a long time python user, in fact, I first used it for
      production quality development back in 1994, for a now defunct
      search engine company. I've always liked python, and it's my
      choice of language if there are no "disqualifying" requirements.
      That much said, I don't think using indentation for syntax is a
      good idea (and I do know why Guido decided to design python that
      way). I think Prothon would make a better choice ditching this
      python legacy entirely, and use some other syntax. Some arguments:
          * Most people are not comfortable with enforced indentation,
            and I know of many a good programmer who decided to not
            learn/use Python for this reason alone. I personally can get
            past this mental obstacle, and it's really not a huge issue
            for me, but nevertheless, I think it limits the usage of an
            otherwise great language.
          * Copying and pasting code from other applications (like,
            browsers, Instant Messenger, IRC clients etc.) is usually
            not easily done. Getting the indentation right is close to
            impossible when pasting it into say Emacs, without manual
            editing (and yes, I know, it's a bad idea to have badly
            indented code pasted in like that, but maybe I'm just trying
            to help someone debug a simple function?)
          * "one liners" are generally hard to write, and what's worse,
            lambdas are seriously limited since you can't really write
            multi-line expressions (afaik).
          * As we all know, the mixing of tabs and spaces is a menace in
            general, and it's particularly bad in Python. I personally
            dislike tabs in source code entirely, although, what I think
            really doesn't matter. But, an "invisible" syntax like
            tabs/spaces makes for some annoying debugging at times (at
            least for me).
   2. Have you considered using Parrot or some other existing virtual
      machine (heck, even JVM? :-)? It seems like it'd save a lot of
      time and effort, if of course it fits with the Prothon language
      design.
   3. Since Prothon is stackless, does that imply that we'll have
      support for continuations ?
   4. How about adding a conditional expression  (ternary) operator,
      like C and perl's '?' operator? I know there was a PEP written for
      that some time ago, dnuno if it'll ever go into Python.
   5. Is anyone working on the memory leaks? I did a very quick run with
      Valgrind on the source, there seems to be a number of very obvious
      leaks we can plug pretty much for "free".
   6. I saw there's a "todo" list, but maybe it'd be useful to see what
      tasks are already worked on, and what is "up for grabs" ?


Cheers,

-- Leif


_______________________________________________
Prothon-dev mailing list
[email protected]
http://lists.prothon.org/mailman/listinfo/prothon-dev