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

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

SnakeScript? (CoffeeScript for Python)

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

Contents

  SnakeScript? (CoffeeScript for Python) Michal Hantl <michal.hantl@gmail.com> - 2012-02-02 06:09 -0800
    Re: SnakeScript? (CoffeeScript for Python) Paul  Moore <p.f.moore@gmail.com> - 2012-02-02 08:30 -0800
      Re: SnakeScript? (CoffeeScript for Python) Devin Jeanpierre <jeanpierreda@gmail.com> - 2012-02-02 12:12 -0500
      Re: SnakeScript? (CoffeeScript for Python) Michal Hantl <michal.hantl@gmail.com> - 2012-02-02 12:23 -0800
        Re: SnakeScript? (CoffeeScript for Python) "bruno.desthuilliers@gmail.com" <bruno.desthuilliers@gmail.com> - 2012-02-03 04:03 -0800
    Re: SnakeScript? (CoffeeScript for Python) andrea crotti <andrea.crotti.0@gmail.com> - 2012-02-02 22:53 +0000
    Re: SnakeScript? (CoffeeScript for Python) Ian Kelly <ian.g.kelly@gmail.com> - 2012-02-02 18:19 -0700
      Re: SnakeScript? (CoffeeScript for Python) Matej Cepl <mcepl@redhat.com> - 2012-02-03 11:42 +0100
        Re: SnakeScript? (CoffeeScript for Python) alex23 <wuwei23@gmail.com> - 2012-02-06 19:52 -0800
    Re: SnakeScript? (CoffeeScript for Python) Chris Angelico <rosuav@gmail.com> - 2012-02-03 13:51 +1100
    Re: SnakeScript? (CoffeeScript for Python) Nathan Rice <nathan.alexander.rice@gmail.com> - 2012-02-03 09:08 -0500
    Re: SnakeScript? (CoffeeScript for Python) Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-02-03 11:20 -0500
    Re: SnakeScript? (CoffeeScript for Python) andrea crotti <andrea.crotti.0@gmail.com> - 2012-02-03 17:24 +0000

#19792 — SnakeScript? (CoffeeScript for Python)

Hello,
 I've been looking for something similar to CoffeeScript, but for python.

Does anyone know of such project? 


So far I haven't found any attempt to do this, so I took few regular expressions and hacked this:
https://plus.google.com/116702779841286800811/posts/56sBdwiZ4fT

Any advice on what parses to use for the CoffeeScript-like syntaxe? I would like to use parser written in Python so I don't introduce dependencies.

Any advice from Python gurus / language experimentators?

[toc] | [next] | [standalone]

#19799

On Feb 2, 2:09 pm, Michal Hantl <michal.ha...@gmail.com> wrote:
>  I've been looking for something similar to CoffeeScript, but for python.
>
> Does anyone know of such project?

Isn't CoffeeScript just a compiler to convert a cleaner syntax into
Javascript? If so, why would you need such a thing for Python, where
the syntax is already clean and simple? :-)

Paul.

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

#19802

On Thu, Feb 2, 2012 at 11:30 AM, Paul  Moore <p.f.moore@gmail.com> wrote:
> Isn't CoffeeScript just a compiler to convert a cleaner syntax into
> Javascript? If so, why would you need such a thing for Python, where
> the syntax is already clean and simple? :-)

Coffeescript is a more functional syntax. On that note, Python isn't
as functional as it could be.

e.g. the "Python Coffeescript" could add pattern matching or TCO or something.

-- Devin

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

#19911

See the link I attached. 
Ruby-like blocks would be nice too.
Implicit returns.
Better strings like """My name is #{name}""".

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

#19915

On Feb 2, 9:23 pm, Michal Hantl <michal.ha...@gmail.com> wrote:
> See the link I attached.
> Ruby-like blocks would be nice too.
> Implicit returns.
> Better strings like """My name is #{name}""".

Uhu... Looks like you want Ruby, not Python <g>

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

#19812

2012/2/2 Amirouche Boubekki <amirouche.boubekki@gmail.com>:
> They are solution to write Python code that translates to javascript see
> this thread
> http://mail.python.org/pipermail/python-list/2011-November/1283110.html
>

Mm I don't think it's what the OP is asking (unless I misunderstood...).
I think he wants to compile some syntax TO Python.
But I don't really see why you would something like this (if not for fun).

Then how are you going to maintain the code? Maintain the compiled
code or the source? And proving that your translator is always correct
I think it's quite a hard task too...

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

#19817

On Thu, Feb 2, 2012 at 3:53 PM, andrea crotti <andrea.crotti.0@gmail.com> wrote:
> 2012/2/2 Amirouche Boubekki <amirouche.boubekki@gmail.com>:
>> They are solution to write Python code that translates to javascript see
>> this thread
>> http://mail.python.org/pipermail/python-list/2011-November/1283110.html
>>
>
> Mm I don't think it's what the OP is asking (unless I misunderstood...).
> I think he wants to compile some syntax TO Python.
> But I don't really see why you would something like this (if not for fun).

Maybe because you think that Python syntax could be improved upon --
for instance, Python with pattern-matching would be freaking awesome
-- but at the same time you want to leverage Python's extensive
ecosystem of libraries.  So instead of creating your own brand-new
language with no third party libraries whatsoever, you create one that
just compiles down to regular Python.

> Then how are you going to maintain the code? Maintain the compiled
> code or the source?

As with all compiled software, you maintain the input, not the output.

> And proving that your translator is always correct

That's what unit tests are for.

Cheers,
Ian

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

#19832

On 3.2.2012 02:19, Ian Kelly wrote:
>> Then how are you going to maintain the code? Maintain the compiled
>> code or the source?
>
> As with all compiled software, you maintain the input, not the output.

I don't think that's what was the question. CoffeeScript is a hopeless 
hack in the hopeless situation of Javascript world where no language 
development is available (meaning, time between filing a bug to the 
moment the change is useful in The Real World™ is many many years).

Ask anybody developing in CoffeeScript/Vala how much they love debugging 
when they have to go through different styles of errors, bugs in the 
intermediate processes, etc. In the end all these languages IMHO either 
develop a new frontend for gcc/clang/PyPy (or fork of CPython) or die, 
because the former is not that much more difficult than writing your 
preprocessor, I believe.

Best,

Matěj

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

#19914

On Feb 3, 8:42 pm, Matej Cepl <mc...@redhat.com> wrote:
> Ask anybody developing in CoffeeScript/Vala how much they love debugging
> when they have to go through different styles of errors, bugs in the
> intermediate processes, etc.

I develop in CoffeeScript. I love debugging it because _it's just
javascript_.

CS doesn't replace JS in any way. It just provides some convenience to
cover a lot of the regular heavy lifting. If you're trying to write CS
without any understanding of JS at all, well, I can see how that might
be a problem, but that's hardly CoffeeScript's failing.

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

#19819

On Fri, Feb 3, 2012 at 9:53 AM, andrea crotti <andrea.crotti.0@gmail.com> wrote:
> Mm I don't think it's what the OP is asking (unless I misunderstood...).
> I think he wants to compile some syntax TO Python.
> But I don't really see why you would something like this (if not for fun).
>
> Then how are you going to maintain the code? Maintain the compiled
> code or the source? And proving that your translator is always correct
> I think it's quite a hard task too...

There's two similar concepts here.

1) Skeleton codegens. You do up some kind of template, run it through
a program, and get a ready-to-fill-in code structure. In this case,
you don't care so much about the translator's quality (if there's
bugs/limitations, you fix 'em after codegenning), and will maintain
the compiled code.

2) Compilation to Python. You write your program in some other
language, run it through a program, and get executable code out of it.
You want the translator to be perfect (so that you don't have to edit
the resulting code), and will maintain the original source.

I think the OP is looking for #2. I've used that sort of technique a
number of times (not with Python specifically, but with other
languages that lack certain handy features); usually the source is
trivially translateable into the output, with 99% of syntax identical
(for instance, one oft-wanted feature is a C-like #include - I've
written .php.m4 files that  get processed through M4 to become PHP
files).

ChrisA

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

#19833

>> Mm I don't think it's what the OP is asking (unless I misunderstood...).
>> I think he wants to compile some syntax TO Python.
>> But I don't really see why you would something like this (if not for fun).
>
> Maybe because you think that Python syntax could be improved upon --
> for instance, Python with pattern-matching would be freaking awesome
> -- but at the same time you want to leverage Python's extensive
> ecosystem of libraries.  So instead of creating your own brand-new
> language with no third party libraries whatsoever, you create one that
> just compiles down to regular Python.

You can generalize the dictionary based dispatch used for "case"
statements to do this.  The main downsides are:

1.) You have to define your functions ahead of time or use lambdas
2.) The syntax is not quite as nice as it could be (e.g.)

foo = DispatchDict({
    Pattern1: f1,
    Pattern2: f2,
    etc...
})

Reminds me more of javascript than I would like.

>> Then how are you going to maintain the code? Maintain the compiled
>> code or the source?
>
> As with all compiled software, you maintain the input, not the output.

I think maintaining the output can be valuable.  There are going to be
things that can be expressed in the more verbose expanded form that
will not be easily expressible in the terse pre-translated macro.
Unfortunately, most macro writers don't put much time into making sure
their macro produces concise code.

>> And proving that your translator is always correct
>
> That's what unit tests are for.

I have a love hate affair with unit tests.  You need them, but I'd
really rather analytically prove that my software is correct under
some set of assumptions.


Cheers,

Nathan

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

#19835

On Thu, 2 Feb 2012 18:19:22 -0700, Ian Kelly <ian.g.kelly@gmail.com>
wrote:

>As with all compiled software, you maintain the input, not the output.
>
	<hah!>

	I spent nearly 20 years having to maintain the /output/ of such a
translator.

	The application had originated via a subcontractor who maintained
ownership of the translator, and my company only inherited the
translated output.

	I had the joy of porting the application from PDP-11 to VAX-11. In
the early days, if any changes were needed to a program I tended to
rewrite the code entirely (the application was many small programs each
doing just one individual task on a common graphics display, and the
"controller" user interface which displayed pages of forms, wrote all
data to a binary file used to populate common blocks used by the
sub-programs). This was mostly to bring it down to manageable sizes --
the output used ASSIGNed GOTOs to implement subroutine calls (no
parameter passing, everything was global!) -- the only good thing was it
was easy to identify translator generated output as it was
right-justified on the lines:
									ASSIGN 1001 TO I123
									GOTO 2200
1001								CONTINUE

{subroutine call -- save return address, jump subroutine...}

	After about 10 years of this, I was able to bloody CODE in that
style, rather than rewriting smaller programs into individual files.
Granted, as much as possible, IF NOT CONDITION GOTO statements were
changed into F77 styel IF CONDITION THEN ... ELSE... ENDIF; but the
local subroutine calls were left in place.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

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

#19837

2012/2/3 Dennis Lee Bieber <wlfraed@ix.netcom.com>:
> On Thu, 2 Feb 2012 18:19:22 -0700, Ian Kelly <ian.g.kelly@gmail.com>
>        <hah!>
>
>        I spent nearly 20 years having to maintain the /output/ of such a
> translator.
>

Yes I think that is the point, if the code you maintain and the code
which you have to debug differ because there is a translator in the
middle you're going to be in trouble before or later.

Moreover, unless you only work alone (which is very unlikely) I think
you should agree with everyone else in such a decision..
And if you really miss so much features that are not in Python at all,
why not just use another programming language which has them then?

[toc] | [prev] | [standalone]

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

csiph-web