Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #15973 > unrolled thread

Using the Python Interpreter as a Reference

Back to article view | Back to comp.lang.python

Contents

  Using the Python Interpreter as a Reference Travis Parks <jehugaleahsa@gmail.com> - 2011-11-20 16:46 -0800
    Re: Using the Python Interpreter as a Reference Chris Angelico <rosuav@gmail.com> - 2011-11-21 13:33 +1100
      Re: Using the Python Interpreter as a Reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-11-21 05:44 +0000
        Re: Using the Python Interpreter as a Reference Chris Angelico <rosuav@gmail.com> - 2011-11-21 17:48 +1100
        Re: Using the Python Interpreter as a Reference Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2011-11-21 10:03 -0800
        Re: Using the Python Interpreter as a Reference Travis Parks <jehugaleahsa@gmail.com> - 2011-11-21 16:07 -0800
    Re: Using the Python Interpreter as a Reference Alan Meyer <ameyer2@yahoo.com> - 2011-11-22 13:37 -0500
      Re: Using the Python Interpreter as a Reference Travis Parks <jehugaleahsa@gmail.com> - 2011-11-25 02:55 -0800
        Re: Using the Python Interpreter as a Reference Chris Angelico <rosuav@gmail.com> - 2011-11-25 22:10 +1100
    Re: Using the Python Interpreter as a Reference rusi <rustompmody@gmail.com> - 2011-11-25 09:11 -0800
      RE: Using the Python Interpreter as a Reference "Sells, Fred" <fred.sells@adventistcare.org> - 2011-11-25 23:22 -0500
      Re: Using the Python Interpreter as a Reference Matt Joiner <anacrolix@gmail.com> - 2011-11-26 23:19 +1100
    Re: Using the Python Interpreter as a Reference Alec Taylor <alec.taylor6@gmail.com> - 2011-11-27 05:46 +1100
    Re: Using the Python Interpreter as a Reference Rick Johnson <rantingrickjohnson@gmail.com> - 2011-11-26 10:53 -0800
      Re: Using the Python Interpreter as a Reference Chris Angelico <rosuav@gmail.com> - 2011-11-27 06:34 +1100
        Re: Using the Python Interpreter as a Reference Rick Johnson <rantingrickjohnson@gmail.com> - 2011-11-26 13:15 -0800
      Re: Using the Python Interpreter as a Reference Travis Parks <jehugaleahsa@gmail.com> - 2011-11-27 14:21 -0800
        Re: Using the Python Interpreter as a Reference Colin Higwell <colinh@somewhere.invalid> - 2011-11-27 23:02 +0000
        Re: Using the Python Interpreter as a Reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-11-27 23:55 +0000
          Re: Using the Python Interpreter as a Reference Chris Angelico <rosuav@gmail.com> - 2011-11-28 11:26 +1100
          Re: Using the Python Interpreter as a Reference Travis Parks <jehugaleahsa@gmail.com> - 2011-11-28 10:03 -0800
          Re: Using the Python Interpreter as a Reference Ian Kelly <ian.g.kelly@gmail.com> - 2011-11-28 12:32 -0700
            Re: Using the Python Interpreter as a Reference Neil Cerutti <neilc@norwich.edu> - 2011-11-28 20:20 +0000
              Re: Using the Python Interpreter as a Reference Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-11-29 09:48 +1300
                Re: Using the Python Interpreter as a Reference Neil Cerutti <neilc@norwich.edu> - 2011-11-28 21:11 +0000
            Re: Using the Python Interpreter as a Reference Travis Parks <jehugaleahsa@gmail.com> - 2011-11-28 13:34 -0800
            Re: Using the Python Interpreter as a Reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-11-28 22:24 +0000
              Re: Using the Python Interpreter as a Reference Chris Angelico <rosuav@gmail.com> - 2011-11-29 09:48 +1100
              Re: Using the Python Interpreter as a Reference Travis Parks <jehugaleahsa@gmail.com> - 2011-11-28 18:42 -0800
                Re: Using the Python Interpreter as a Reference Chris Angelico <rosuav@gmail.com> - 2011-11-29 13:57 +1100
                  Re: Using the Python Interpreter as a Reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-11-29 08:12 +0000
                    Re: Using the Python Interpreter as a Reference Dave Angel <d@davea.name> - 2011-11-29 03:53 -0500
                Re: Using the Python Interpreter as a Reference Ian Kelly <ian.g.kelly@gmail.com> - 2011-11-28 21:56 -0700
          Re: Using the Python Interpreter as a Reference DevPlayer <devplayer@gmail.com> - 2011-11-28 16:54 -0800
            Re: Using the Python Interpreter as a Reference DevPlayer <devplayer@gmail.com> - 2011-11-28 16:59 -0800
            Re: Using the Python Interpreter as a Reference Chris Angelico <rosuav@gmail.com> - 2011-11-29 12:49 +1100
              Re: Using the Python Interpreter as a Reference Travis Parks <jehugaleahsa@gmail.com> - 2011-11-28 19:00 -0800
              Re: Using the Python Interpreter as a Reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-11-29 08:04 +0000
                Re: Using the Python Interpreter as a Reference DevPlayer <devplayer@gmail.com> - 2011-12-01 10:03 -0800
                  Re: Using the Python Interpreter as a Reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-12-02 00:43 +0000
                    Re: Using the Python Interpreter as a Reference Chris Angelico <rosuav@gmail.com> - 2011-12-02 13:02 +1100
                    RE: Using the Python Interpreter as a Reference "Sells, Fred" <fred.sells@adventistcare.org> - 2011-12-02 15:29 -0500
                    Re: Using the Python Interpreter as a Reference Devin Jeanpierre <jeanpierreda@gmail.com> - 2011-12-02 15:58 -0500
        Re: Using the Python Interpreter as a Reference Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-11-29 09:40 +1300
          Re: Using the Python Interpreter as a Reference Travis Parks <jehugaleahsa@gmail.com> - 2011-11-28 13:29 -0800
            Re: Using the Python Interpreter as a Reference Chris Angelico <rosuav@gmail.com> - 2011-11-29 08:57 +1100
            Re: Using the Python Interpreter as a Reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-11-28 22:57 +0000
              Re: Using the Python Interpreter as a Reference Travis Parks <jehugaleahsa@gmail.com> - 2011-11-28 18:57 -0800

Page 1 of 3  [1] 2 3  Next page →

#15973 — Using the Python Interpreter as a Reference

Hello:

I am currently working on designing a new programming language. It is
a compiled language, but I still want to use Python as a reference.
Python has a lot of similarities to my language, such as indentation
for code blocks, lambdas, non-locals and my language will partially
support dynamic programming.

Can anyone list a good introduction to the files found in the source
code? I have been poking around the source code for a little bit and
there is a lot there. So, I was hoping someone could point me to the
"good parts". I am also wondering whether some of the code was
generated because I see state transition tables, which I doubt someone
built by hand.

Any help would be greatly appreciated. It will be cool to see how the
interpreter works internally. I am still wonder whether designing the
language (going on 4 months now) will be harder than implementing it.

Thanks,
Travis Parks

[toc] | [next] | [standalone]

#15977

On Mon, Nov 21, 2011 at 11:46 AM, Travis Parks <jehugaleahsa@gmail.com> wrote:
> I am currently working on designing a new programming language. It is
> a compiled language, but I still want to use Python as a reference.
> Python has a lot of similarities to my language, such as indentation
> for code blocks, lambdas, non-locals and my language will partially
> support dynamic programming.

If you want to use Python as a reference for designing your language,
look at the documentation. It's pretty decent on the subject of
language specs (you may find yourself reading a lot of PEPs as well as
the "normal" docs).

But for actual code - you may want to look at Cython. I've never used
it, but it compiles Python code to C (IIRC); that's more likely to be
what you're after.

What's your language's "special feature"? I like to keep track of
languages using a "slug" - a simple one-sentence (or less) statement
of when it's right to use this language above others. For example,
Python is optimized for 'rapid deployment'.

ChrisA

[toc] | [prev] | [next] | [standalone]

#15982

On Mon, 21 Nov 2011 13:33:21 +1100, Chris Angelico wrote:

> What's your language's "special feature"? I like to keep track of
> languages using a "slug" - a simple one-sentence (or less) statement of
> when it's right to use this language above others. For example, Python
> is optimized for 'rapid deployment'.

"Python will save the world"

http://proyectojuanchacon.blogspot.com/2010/07/saving-world-with-python.html




-- 
Steven

[toc] | [prev] | [next] | [standalone]

#15986

On Mon, Nov 21, 2011 at 4:44 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> On Mon, 21 Nov 2011 13:33:21 +1100, Chris Angelico wrote:
>
>> What's your language's "special feature"? I like to keep track of
>> languages using a "slug" - a simple one-sentence (or less) statement of
>> when it's right to use this language above others. For example, Python
>> is optimized for 'rapid deployment'.
>
> "Python will save the world"
>
> http://proyectojuanchacon.blogspot.com/2010/07/saving-world-with-python.html

I don't think Python has a hard disk big enough to save all of it...

ChrisA

[toc] | [prev] | [next] | [standalone]

#16037

On Mon, 21 Nov 2011 17:48:45 +1100, Chris Angelico <rosuav@gmail.com>
declaimed the following in gmane.comp.python.general:

> On Mon, Nov 21, 2011 at 4:44 PM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> wrote:
> > On Mon, 21 Nov 2011 13:33:21 +1100, Chris Angelico wrote:
> >
> >> What's your language's "special feature"? I like to keep track of
> >> languages using a "slug" - a simple one-sentence (or less) statement of
> >> when it's right to use this language above others. For example, Python
> >> is optimized for 'rapid deployment'.
> >
> > "Python will save the world"
> >
> > http://proyectojuanchacon.blogspot.com/2010/07/saving-world-with-python.html
> 
> I don't think Python has a hard disk big enough to save all of it...
> 
	Since it would, technically, need to save it's own storage in order
to record the state of all the atoms, it becomes a recursive problem.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#16058

On Nov 21, 12:44 am, Steven D'Aprano <steve
+comp.lang.pyt...@pearwood.info> wrote:
> On Mon, 21 Nov 2011 13:33:21 +1100, Chris Angelico wrote:
> > What's your language's "special feature"? I like to keep track of
> > languages using a "slug" - a simple one-sentence (or less) statement of
> > when it's right to use this language above others. For example, Python
> > is optimized for 'rapid deployment'.
>
> "Python will save the world"
>
> http://proyectojuanchacon.blogspot.com/2010/07/saving-world-with-pyth...
>
> --
> Steven

The language, psuedo name Unit, will be a low-level language capable
of replacing C in most contexts. However, it will have integrated
functional programming features (tail-end recursion optimization,
tuples, currying, closures, function objects, etc.) and dynamic
features (prototypical inheritance and late binding).

It is a hybrid between C#, C++, F#, Python and JavaScript. The hope is
that you won't pay for features you don't use, so it will run well on
embedded devices as well as on desktops - that's to be seen. I'm no
master compiler builder, here.

The functional code is pretty basic:

let multiply = function x y: return x * y # automatic generic
arguments (integer here)
let double = multiply _ 2 # short-hand currying - inlined if possible
let doubled = [|0..10|].Apply(double) # double zero through 10

The dynamic code is pretty simple too:

dynamic Prototype = function value: self.Value = value # simulated
ctor
Prototype.Double = function: self.Value * 2 # self refers to instance
new Prototype(5).Double() # 10
new Prototype(6).Double() # 12
dynamic x = 5 # five wrapped with a bag
x.Double = function: self * 2
x.Double() # 10
dynamic y = 6
y.Double = x.Double # member sharing
y.Double() #12

The language also sports OOP features like are found in Java or C#:
single inheritance; multiple interface inheritance; sealed, virtual
and abstract types and members; explicit inheritance; extension
methods and namespaces.

The coolest feature will be its generics-oriented function signatures.
By default everything is generic. You apply constraints to parameters,
rather than specific types. For instance:

let Average = function values:
    where values is ICountable<Integer32> IIterable<Integer32>
    assert values.Count > 0 "The values list cannot be empty."
    throws ArgumentException
    returns Float64
    let sum = 0
    for value in values:
        sum += value
    return sum / values.Count # floating point division

As you can see, the function headers can be larger than the bodies
themselves. They support type constraints, assertions (argument
checking), exceptions enumeration, default parameters and return type
information. All of them can be left out if the type of arguments can
be inferred.

This will not be an overnight project. :-)

[toc] | [prev] | [next] | [standalone]

#16084

On 11/20/2011 7:46 PM, Travis Parks wrote:
> Hello:
>
> I am currently working on designing a new programming language. ...

I have great respect for people who take on projects like this.

Your chances of popularizing the language are small.  There must be 
thousands of projects like this for every one that gets adopted by other 
people.  However your chances of learning a great deal are large, 
including many things that you'll be able to apply to programs and 
projects that, at first glance, wouldn't appear to benefit from this 
kind of experience.  If you get it working you'll have an impressive 
item to add to your resume.

I suspect that you'll also have a lot of fun.

Good luck with it.

     Alan

[toc] | [prev] | [next] | [standalone]

#16213

On Nov 22, 1:37 pm, Alan Meyer <amey...@yahoo.com> wrote:
> On 11/20/2011 7:46 PM, Travis Parks wrote:
>
> > Hello:
>
> > I am currently working on designing a new programming language. ...
>
> I have great respect for people who take on projects like this.
>
> Your chances of popularizing the language are small.  There must be
> thousands of projects like this for every one that gets adopted by other
> people.  However your chances of learning a great deal are large,
> including many things that you'll be able to apply to programs and
> projects that, at first glance, wouldn't appear to benefit from this
> kind of experience.  If you get it working you'll have an impressive
> item to add to your resume.
>
> I suspect that you'll also have a lot of fun.
>
> Good luck with it.
>
>      Alan

I've been learning a lot and having tons of fun just designing the
language. First, I get think about all of the language features that I
find useful. Then I get to learn a little bit how they work
internally.

For instance, functions are first-class citizens in Unit, supporting
closures. To make that happen meant wrapping such functions inside of
types and silently elavating local variables to reference counted
pointers.

Or, I realized that in order to support default arguments, I would
have to silently wrap parameters in types that were either set or not
set. That way calls to the default command could simply be replaced by
an if statement. It was a really subtle implementation detail.

It is also fun thinking about what makes sense. For instance, Unit
will support calling methods with named arguments. Originally, I
thought about using the '=' operator:

Foo(name="bob" age=64)

but, then I realized that the equals sign could be confused with
assignment. Those types of syntactic conflicts occur quite often and
lead to a lot of rethinking. Ultimately, somewhat good ideas get
replaced with much better ideas. I had been contemplating Unit for
months before the final look and feel of the language came into view.
It isn't what I started out imagining, but I think it turned out
better than I had originally planned.


Recently, I rethought how functions looked, since the headers were too
long:

alias Predicate = function<T> (value: & readonly T) throws()
returns(Boolean)
let Any = public function<T>
    (values: & readonly IIterable<T>)
    (?predicate: Predicate<T>)
    throws() # ArgumentNullException inherits from UncheckedException
    returns(Boolean): # this can be on one line
    default predicate = (function value: true)
    assert predicate != null "The predicate cannot be null."
ArgumentNullException
    for value in values:
        if predicate(value):
            return true
    return false

Most of the time, throws clauses, returns clauses and parameter type
constraints can be left off. Plus, now they can all appear on one
line. Assertions and default statements now appear in the body.
Assertions now optionally take a message and the exception type to
throw.

So, yeah, this has been an awesome project so far. I have dozens of
documents and I have been keeping up on a blog. I've even started
implementing a simple recursive descent parser just to make sure the
syntax doesn't conflict. Now it will be a matter of formally defining
a grammer and implementing the backend of the compiler... which I've
never done before. I have been thinking about compiling into a
language like C++ or C instead of assembler for my first time through.

[toc] | [prev] | [next] | [standalone]

#16214

On Fri, Nov 25, 2011 at 9:55 PM, Travis Parks <jehugaleahsa@gmail.com> wrote:
> I have been thinking about compiling into a
> language like C++ or C instead of assembler for my first time through.

Yep, or any other language you feel like using as an intermediate. Or
alternatively, just start with an interpreter - whatever's easiest.
Compiling to C gives you a massive leg-up on portability; so does
writing an interpreter in C, as either way your language is easily
made available on every platform that gcc's been ported to.

As long as you're happy with the idea of building a massively language
that'll never be used by anybody but yourself, you can have immense
fun with this. And hey, Unit might turn out to be a beautiful niche
language, or even go mainstream.

But mainly, you'll have fun doing it. And if you're not having fun,
what's the use of living forever? (Oh wait, you're not a vampire from
Innistrad. Sorry about that.)

ChrisA

[toc] | [prev] | [next] | [standalone]

#16234

On Nov 21, 5:46 am, Travis Parks <jehugalea...@gmail.com> wrote:
> Hello:
>
> I am currently working on designing a new programming language. It is
> a compiled language, but I still want to use Python as a reference.
> Python has a lot of similarities to my language, such as indentation
> for code blocks, lambdas, non-locals and my language will partially
> support dynamic programming.
>
> Can anyone list a good introduction to the files found in the source
> code? I have been poking around the source code for a little bit and
> there is a lot there. So, I was hoping someone could point me to the
> "good parts". I am also wondering whether some of the code was
> generated because I see state transition tables, which I doubt someone
> built by hand.
>
> Any help would be greatly appreciated. It will be cool to see how the
> interpreter works internally. I am still wonder whether designing the
> language (going on 4 months now) will be harder than implementing it.
>
> Thanks,
> Travis Parks

- compiled language
- indentation based
- functional programming features

Looks like a description of Haskell.  You may want to look there.

Back end: LLVM is gaining a lot of traction these days. Seems to give
best of both worlds -- compiling to C and to machine code

[toc] | [prev] | [next] | [standalone]

#16244

I'm looking at a variation on this theme.  I currently use
Flex/ActionScript for client side work, but there is pressure to move
toward HTML5+Javascript and or iOS.  Since I'm an old hand at Python, I
was wondering if there is a way to use it to model client side logic,
then generate the javascript and ActionScript.  I don't see an issue
using custom python objects to render either mxml, xaml or html5 but I'm
not aware if anyone has already solved the problem of converting Python
(byte code?) to these languages?  Any suggestions.

[toc] | [prev] | [next] | [standalone]

#16249

http://pyjs.org/

On Sat, Nov 26, 2011 at 3:22 PM, Sells, Fred
<fred.sells@adventistcare.org> wrote:
> I'm looking at a variation on this theme.  I currently use
> Flex/ActionScript for client side work, but there is pressure to move
> toward HTML5+Javascript and or iOS.  Since I'm an old hand at Python, I
> was wondering if there is a way to use it to model client side logic,
> then generate the javascript and ActionScript.  I don't see an issue
> using custom python objects to render either mxml, xaml or html5 but I'm
> not aware if anyone has already solved the problem of converting Python
> (byte code?) to these languages?  Any suggestions.
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>

[toc] | [prev] | [next] | [standalone]

#16258

Consider implementing OOP, reflection and implement in HLA or C

=]

On Mon, Nov 21, 2011 at 11:46 AM, Travis Parks <jehugaleahsa@gmail.com> wrote:
> Hello:
>
> I am currently working on designing a new programming language. It is
> a compiled language, but I still want to use Python as a reference.
> Python has a lot of similarities to my language, such as indentation
> for code blocks, lambdas, non-locals and my language will partially
> support dynamic programming.
>
> Can anyone list a good introduction to the files found in the source
> code? I have been poking around the source code for a little bit and
> there is a lot there. So, I was hoping someone could point me to the
> "good parts". I am also wondering whether some of the code was
> generated because I see state transition tables, which I doubt someone
> built by hand.
>
> Any help would be greatly appreciated. It will be cool to see how the
> interpreter works internally. I am still wonder whether designing the
> language (going on 4 months now) will be harder than implementing it.
>
> Thanks,
> Travis Parks
> --
> http://mail.python.org/mailman/listinfo/python-list

[toc] | [prev] | [next] | [standalone]

#16259

On Nov 20, 6:46 pm, Travis Parks <jehugalea...@gmail.com> wrote:
> Hello:
>
> I am currently working on designing a new programming language. It is
> a compiled language, but I still want to use Python as a reference.
> Python has a lot of similarities to my language, such as indentation
> for code blocks,

I hope you meant to say "*forced* indention for code blocks"! "Forced"
being the key word here. What about tabs over spaces, have you decided
the worth of one over the other or are you going to repeat Guido's
folly?

And please, i love Python, but the language is a bit asymmetrical. Do
try to bring some symmetry to this new language. You can learn a lot
from GvR's triumphs, however, you can learn even more from his follys.

[toc] | [prev] | [next] | [standalone]

#16260

On Sun, Nov 27, 2011 at 5:53 AM, Rick Johnson
<rantingrickjohnson@gmail.com> wrote:
> I hope you meant to say "*forced* indention for code blocks"! "Forced"
> being the key word here. What about tabs over spaces, have you decided
> the worth of one over the other or are you going to repeat Guido's
> folly?

I recommend demanding that indentation strictly alternate tabs or
spaces in successive non-blank lines. Comment-only lines must be
identical to the immediately-preceding line. A tab is equivalent to
seven spaces.

End the ambiguity!

ChrisA

[toc] | [prev] | [next] | [standalone]

#16261

On Nov 26, 1:34 pm, Chris Angelico <ros...@gmail.com> wrote:
> On Sun, Nov 27, 2011 at 5:53 AM, Rick Johnson
>
> <rantingrickjohn...@gmail.com> wrote:
> > I hope you meant to say "*forced* indention for code blocks"! "Forced"
> > being the key word here. What about tabs over spaces, have you decided
> > the worth of one over the other or are you going to repeat Guido's
> > folly?
>
> I recommend demanding that indentation strictly alternate tabs or
> spaces in successive non-blank lines.

Funny.

> Comment-only lines must be
> identical to the immediately-preceding line.

...as in "indentation" you mean, then yes. OR suffer the syntax error.

> A tab is equivalent to
> seven spaces.

...as for "the litmus test of stdlib code" you mean, then yes. OR
suffer the syntax error.

[toc] | [prev] | [next] | [standalone]

#16299

On Nov 26, 1:53 pm, Rick Johnson <rantingrickjohn...@gmail.com> wrote:
> On Nov 20, 6:46 pm, Travis Parks <jehugalea...@gmail.com> wrote:
>
> > Hello:
>
> > I am currently working on designing a new programming language. It is
> > a compiled language, but I still want to use Python as a reference.
> > Python has a lot of similarities to my language, such as indentation
> > for code blocks,
>
> I hope you meant to say "*forced* indention for code blocks"! "Forced"
> being the key word here. What about tabs over spaces, have you decided
> the worth of one over the other or are you going to repeat Guido's
> folly?
>
> And please, i love Python, but the language is a bit asymmetrical. Do
> try to bring some symmetry to this new language. You can learn a lot
> from GvR's triumphs, however, you can learn even more from his follys.

Personally, I find a lot of good things in Python. I thinking tabs are
out-of-date. Even the MAKE community wishes that the need for tabs
would go away and many implementations have done just that. I have
been seriously debating about whether to force a specific number of
spaces, such as the classic 4, but I am not sure yet. Some times, 2 or
even 8 spaces is appropriate (although I'm not sure when).

I have always found the standard library for Python to be disjoint.
That can be really beneficial where it keeps the learning curve down
and the size of the standard modules down. At the same time, it means
re-learning whenever you use a new module.

My language combines generators and collection initializers, instead
of creating a whole new syntax for comprehensions.

[| for i in 0..10: for j in 0.10: yield return i * j |]

Lambdas and functions are the same thing in my language, so no need
for a special keyword. I also distinguish between initialization and
assignment via the let keyword. Also, non-locals do not need to be
defined explicitly, since the scoping rules in Unit are far more
"anal".

In reality though, it takes a certain level of arrogance to assume
that any language will turn out without bumps. It is like I was told
in college long ago, "Only the smallest programs are bug free." I
think the same thing could be said for a language. The only language
without flaws would be so small that it would be useless.

I love these types of discussions though, because it helps me to be
aware. When designing a language, it is extremely helpful to hear what
language features have led to problems. For instance, C#'s foreach
loops internally reuse a variable, which translates to something like
this:

using (IEnumerator<T> enumerator = enumerable.GetEnumerator())
{
    T current;
    while (enumerator.MoveNext())
    {
        current = enumerator.Current;
        // inner loop code goes here
    }
}

Since the same variable is reused, threads referencing the loop
variable work against whatever value is currently in the variable,
rather than the value when the thread was created. Most of the time,
this means every thread works against the same value, which isn't the
expected outcome. Moving the variable inside the loop _may_ help, but
it would probably be optimized back out of the loop by the compiler.
With the growth of threaded applications, these types of stack-based
optimizations may come to an end. That is why it is important for a
next-gen language to have a smarter stack - one that is context
sensitive. In Unit, the stack grows and shrinks like a dynamic array,
at each scope, rather than at the beginning and end of each function.
Sure, there's a slight cost in performance, but a boost in
consistency. If a programmer really wants the performance, they can
move the variable out of the loop themselves.

In fact, there are a lot of features in Unit that will come with
overhead, such as default arguments, non-locals, function-objects,
etc. However, the game plan is to avoid the overhead if it isn't used.
Some things, such as exception handling, will be hard to provide
without overhead. My belief is that, provided a tool, most developers
will use it and accept the slight runtime overhead.

I think everyone has an idea about what would make for the perfect
language. I am always willing to entertain ideas. I have pulled from
many sources: C#, Java, Python, JavaScript, F#, Lisp and more. The
hope is to provide as much expression with as much consistency as
possible. Just the other day I spent 2 hours trying to determine how
to create a null pointer (yeah, it took that long).

let pi = null as shared * Integer32 # null is always a pointer

Originally, I wanted 'as' to be a safe conversion. However, I decided
to make use of the 'try' keyword to mean a safe conversion.

let nd = try base as shared * Derived
let d = if nd.Succeeded: nd.Value else: null
# or, shorthand
let i = try Integer32.Parse("123") else 0

Of course, the last line could cost performance wise. For that reason,
Unit will allow for "try" versions of methods.

let Parse = public static method (value: String)
throws(FormatException UnderflowException OverflowException)
returns(Integer32): ...
and Parse = public static try method (value: String)
returns(TryResult<Integer32>): ...

Of course, such methods are required to never throw and must return a
specific named tuple type.

Type, type, type. In short, I can only hope my language is useful and
that I dodge as many inconsistencies as possible. The good thing about
an unknown language is that no one gets mad when things change. In
that sense, Python's annoyances are probably an indication of its
quality. :-)

[toc] | [prev] | [next] | [standalone]

#16300

On Sun, 27 Nov 2011 14:21:01 -0800, Travis Parks wrote:

> On Nov 26, 1:53 pm, Rick Johnson <rantingrickjohn...@gmail.com> wrote:
>> On Nov 20, 6:46 pm, Travis Parks <jehugalea...@gmail.com> wrote:
>>
>> > Hello:
>>
>> > I am currently working on designing a new programming language. It is
>> > a compiled language, but I still want to use Python as a reference.
>> > Python has a lot of similarities to my language, such as indentation
>> > for code blocks,
>>
>> I hope you meant to say "*forced* indention for code blocks"! "Forced"
>> being the key word here. What about tabs over spaces, have you decided
>> the worth of one over the other or are you going to repeat Guido's
>> folly?
>>
>> And please, i love Python, but the language is a bit asymmetrical. Do
>> try to bring some symmetry to this new language. You can learn a lot
>> from GvR's triumphs, however, you can learn even more from his follys.
> 
> Personally, I find a lot of good things in Python. I thinking tabs are
> out-of-date. Even the MAKE community wishes that the need for tabs would
> go away and many implementations have done just that. I have been
> seriously debating about whether to force a specific number of spaces,
> such as the classic 4, but I am not sure yet. Some times, 2 or even 8
> spaces is appropriate (although I'm not sure when).
> 
> I have always found the standard library for Python to be disjoint. That
> can be really beneficial where it keeps the learning curve down and the
> size of the standard modules down. At the same time, it means
> re-learning whenever you use a new module.
> 
> My language combines generators and collection initializers, instead of
> creating a whole new syntax for comprehensions.
> 
> [| for i in 0..10: for j in 0.10: yield return i * j |]
> 
> Lambdas and functions are the same thing in my language, so no need for
> a special keyword. I also distinguish between initialization and
> assignment via the let keyword. Also, non-locals do not need to be
> defined explicitly, since the scoping rules in Unit are far more "anal".
> 
> In reality though, it takes a certain level of arrogance to assume that
> any language will turn out without bumps. It is like I was told in
> college long ago, "Only the smallest programs are bug free." I think the
> same thing could be said for a language. The only language without flaws
> would be so small that it would be useless.
> 
> I love these types of discussions though, because it helps me to be
> aware. When designing a language, it is extremely helpful to hear what
> language features have led to problems. For instance, C#'s foreach loops
> internally reuse a variable, which translates to something like this:
> 
> using (IEnumerator<T> enumerator = enumerable.GetEnumerator())
> {
>     T current;
>     while (enumerator.MoveNext())
>     {
>         current = enumerator.Current;
>         // inner loop code goes here
>     }
> }
> 
> Since the same variable is reused, threads referencing the loop variable
> work against whatever value is currently in the variable, rather than
> the value when the thread was created. Most of the time, this means
> every thread works against the same value, which isn't the expected
> outcome. Moving the variable inside the loop _may_ help, but it would
> probably be optimized back out of the loop by the compiler. With the
> growth of threaded applications, these types of stack-based
> optimizations may come to an end. That is why it is important for a
> next-gen language to have a smarter stack - one that is context
> sensitive. In Unit, the stack grows and shrinks like a dynamic array, at
> each scope, rather than at the beginning and end of each function. Sure,
> there's a slight cost in performance, but a boost in consistency. If a
> programmer really wants the performance, they can move the variable out
> of the loop themselves.
> 
> In fact, there are a lot of features in Unit that will come with
> overhead, such as default arguments, non-locals, function-objects, etc.
> However, the game plan is to avoid the overhead if it isn't used. Some
> things, such as exception handling, will be hard to provide without
> overhead. My belief is that, provided a tool, most developers will use
> it and accept the slight runtime overhead.
> 
> I think everyone has an idea about what would make for the perfect
> language. I am always willing to entertain ideas. I have pulled from
> many sources: C#, Java, Python, JavaScript, F#, Lisp and more. The hope
> is to provide as much expression with as much consistency as possible.
> Just the other day I spent 2 hours trying to determine how to create a
> null pointer (yeah, it took that long).
> 
> let pi = null as shared * Integer32 # null is always a pointer
> 
> Originally, I wanted 'as' to be a safe conversion. However, I decided to
> make use of the 'try' keyword to mean a safe conversion.
> 
> let nd = try base as shared * Derived let d = if nd.Succeeded: nd.Value
> else: null # or, shorthand let i = try Integer32.Parse("123") else 0
> 
> Of course, the last line could cost performance wise. For that reason,
> Unit will allow for "try" versions of methods.
> 
> let Parse = public static method (value: String) throws(FormatException
> UnderflowException OverflowException) returns(Integer32): ...
> and Parse = public static try method (value: String)
> returns(TryResult<Integer32>): ...
> 
> Of course, such methods are required to never throw and must return a
> specific named tuple type.
> 
> Type, type, type. In short, I can only hope my language is useful and
> that I dodge as many inconsistencies as possible. The good thing about
> an unknown language is that no one gets mad when things change. In that
> sense, Python's annoyances are probably an indication of its quality.
> :-)

Most of this is way above my head but FWIW, I am very happy with four 
spaces for indentation. I forget now what I used in BASIC and COBOL, but 
I have always used four spaces in PL/SQL, PL/pgSQL, PL/Tcl, c, ksh, bash 
and Python.

[toc] | [prev] | [next] | [standalone]

#16301

On Sun, 27 Nov 2011 14:21:01 -0800, Travis Parks wrote:

> Personally, I find a lot of good things in Python. I thinking tabs are
> out-of-date. Even the MAKE community wishes that the need for tabs would
> go away and many implementations have done just that.

Tabs have every theoretical advantage and only one practical 
disadvantage: the common toolsets used by Unix programmers are crap in 
their handling of tabs, and instead of fixing the toolsets, they blame 
the tabs.

The use of spaces as indentation is a clear case of a technically worse 
solution winning over a better solution.


> I have been
> seriously debating about whether to force a specific number of spaces,
> such as the classic 4, but I am not sure yet. Some times, 2 or even 8
> spaces is appropriate (although I'm not sure when).

Why on earth should your language dictate the width of an indentation? I 
can understand that you might care that indents are consistent within a 
single source code unit (a file?), but anything more than that is just 
obnoxious.


> I have always found the standard library for Python to be disjoint. That
> can be really beneficial where it keeps the learning curve down and the
> size of the standard modules down. At the same time, it means
> re-learning whenever you use a new module.

I know what disjoint means, but I don't understand what you think it 
means for a software library to be disjoint. I don't understand the rest 
of the paragraph.


> My language combines generators and collection initializers, instead of
> creating a whole new syntax for comprehensions.
> 
> [| for i in 0..10: for j in 0.10: yield return i * j |]

Are we supposed to intuit what that means? 

Is | a token, or are the delimiters [| and |] ? 

Is there a difference between iterating over 0..10 and iterating over 
what looks like a float 0.10? 

What is "yield return"?


> Lambdas and functions are the same thing in my language, so no need for
> a special keyword.

That does not follow. Lambdas and def functions are the same thing in 
Python, but Python requires a special keyword.


> I also distinguish between initialization and
> assignment via the let keyword.

What does this mean? I can guess, but I might guess wrong.


> Also, non-locals do not need to be
> defined explicitly, since the scoping rules in Unit are far more "anal".

What does this mean? I can't even guess what you consider more anal 
scoping rules.


> In reality though, it takes a certain level of arrogance to assume that
> any language will turn out without bumps. It is like I was told in
> college long ago, "Only the smallest programs are bug free." I think the
> same thing could be said for a language. The only language without flaws
> would be so small that it would be useless.

I'm pretty sure that being so small that it is useless would count as a 
flaw.

What does it mean to say that a language is "small"?

A Turing Machine is a pretty small language, with only a few 
instructions: step forward, step backwards, erase a cell, write a cell, 
branch on the state of the cell. And yet anything that can be computed, 
anything at all, can be computed by a Turning Machine: a Turing Machine 
can do anything you can do in C, Lisp, Fortran, Python, Java... and very 
probably anything you can (mentally) do, full stop. So what does that 
mean about "small" languages?

On the other hand, take Epigram, a functional programming language:

http://en.wikipedia.org/wiki/Epigram_(programming_language)

It is *less* powerful than a Turing Machine, despite being far more 
complex. Similarly languages like regular expressions, finite automata 
and context-free grammers are more complex, "bigger", possibly with 
dozens or hundreds of instructions, and yet less powerful. Likewise for 
spreadsheets without cycles.

Forth is much smaller than Java, but I would say that Forth is much, much 
more powerful in some sense than Java. You could write a Java compiler in 
Forth more easily than you could write a Forth compiler in Java.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#16302

On Mon, Nov 28, 2011 at 10:55 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> What does it mean to say that a language is "small"?
>
> A Turing Machine is a pretty small language, with only a few
> instructions: step forward, step backwards, erase a cell, write a cell,
> branch on the state of the cell. And yet anything that can be computed,
> anything at all, can be computed by a Turning Machine...

Ook has only three tokens (okay, it's a derivative of BrainF** so it
kinda has eight, but they're implemented on three). It's
Turing-complete, but it is so small as to be useless for any practical
purposes. The ONLY way to use Ook for any useful code would be to
write an interpreter for another language in it, and use that other
language.

However, Ook can be proven to be flawless, as can an Ook interpreter,
much more easily than a full-featured language like Python or C.

ChrisA

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.python

csiph-web