Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon.

Pages: 1-4041-8081-120121-160161-200201-

What's bad about Python?

Name: Anonymous 2005-12-21 8:09

Because I'm learning it, almost done through the tutorial, and it looks great.

Name: Anonymous 2005-12-21 9:35

Everything is an expression... well almost. Whoops.
The worlds most broken OO system.
Guido is insane and wishes to remove any semantic resemblance to Lisp.
Zope.

Name: Anonymous 2005-12-21 10:34

(>>1 here)
Everything is an expression... well almost. Whoops.
Yeah, I'm missing C's assignment and conditional operators.

The worlds most broken OO system.
Interesting, could you explain me why is it broken? It looks good in theory. Thanks in advance.

Guido is insane and wishes to remove any semantic resemblance to Lisp.
from MyLispFunctionsLolLol import * ?

Zope.
What about mod_python? (Even so, I'm not so interested on using it for web applications as I am on using it for desktop applications.)

Name: Anonymous 2005-12-21 13:40

>>from MyLispFunctionsLolLol import * ?

you missed the word 'semantic'

Name: Anonymous 2005-12-21 14:20

if you consider namespaces syntax, then python is just perl with another face. all the underlying data structures are exactly the same and the OO stuff is just namespace trickery. it's like guido just decided that perl is too ugly and decided to make it __pretty__.

Name: Anonymous 2005-12-21 16:01

>>5
it's like guido just decided that perl is too ugly and decided to make it __pretty__.
Lol, Perl is ugly indeed (can't stand the syntax, that's why I went for PHP for a scripting language and now giving Python a try), and I did notice __something__ __funny__ about Python.

Name: Anonymous 2005-12-21 21:00

Still wondering what's so bad about Python's OO model

Name: Anonymous 2005-12-22 1:18

Python OO isn't strict OO, basically. That's because Python isn't a very strict language. The three main showstopping errors are typos, type mismatches, and invalid subscripting of a list - all of which happen to be very easy to understand. Errors relating to use of OO almost never occur because the way OO is handled is so lax. It makes one feel at ease to do things considered "outrageous" in other languages because the overhead isn't a major concern. People interested in purity call it a hack, and a slow one. People who Want To Get Things Done Fast generally like Python (eventually).

Name: Anonymous 2005-12-22 5:34

>>8
Thanks for the info! Anonymous appreciates it, it's the exact kind of feedback he was looking for. Yes, it's relaxed, and that's exactly what is looking good to me; I'd rather risk typos in attribute names or stuff like that than cope with an ultra strict, ultra low productivity language like Java (besides the other things I don't like from Java). I'm aware of the fact Python is scripted and it'll be slower, but I'm looking for productivity, both for my personal projects and my work at a company. I want to get it done fast, and well (i.e. easily maintenable), while keeping a reasonable speed (reasonable = ok, it's n times slower, but at least it has the same complexity).

Regarding Python's speed, I think I had seen a benchmark of a few simple things concluding that, out of the big four scripting languages, Python is the fastest followed very closely by Perl, and both of them are considerably faster than PHP and Ruby.

Name: Anonymous 2005-12-22 5:50

def __Many__ (self, Ugly):
    """Symbols"""

Python may get things done quick, but the syntax (and some semantics) is terrible. Worse, it seems to promote dense clusters of horizontal code. After using Ruby, I just don't want to touch Python again.

Except that Ruby is still dog slow. Fuck.

Name: Anonymous 2005-12-22 8:56

>>10
If Python's syntax is terrible, then what about Perl's?

Save for the lack of C = and :?, the __underscores__ (RegularNamesAreFineToo), and the '''stupid quotes''' (quotes in any language and shell should be like Perl's, q{recursive {lol}, to reduce the shitty backslash hell}), I like Python's syntax, it's clean, and I love how it forces you to indent properly. I hate fixing n00b code, so if I'll be doing it, at least it'll be indentated.

Name: Anonymous 2005-12-22 12:19

lol python is fast? please to show me the benchmarks.

Name: Anonymous 2005-12-22 17:48

>>11
Perl's can be pretty bad (worse than Python). That doesn't change that Python's syntax is ugly.

Having said that, I find the perl code I've written looks better than the Python code. Perl is a terse language, while Python decidedly isn't. Python's verbosity is close to Java's, even though its semantics are vastly superior.

>>12
For a scripting language, it's fast:
http://shootout.alioth.debian.org/
http://dada.perl.it/shootout/

Name: ff 2005-12-22 19:01

python is ok for almost everything, but it has some small problems on gui

- wxpython is bloated and not suitable in linux/osx.
- gtk wasn't good in windows.
- pyobjc is prefered in osx.
- No opinion on QT yet, it may involve a rather expensive commercial license in some cases.

Python is a script language w/o solid gui so it's not a good choice on desktop applications. (However, putting osx aside I think pygtk (+py2exe in windows) is OK for small utilities.)

for web development most people will use zope. mod_python is powerhouse but it is VERY BAD for developers, you may end up using other library and plug it to mod_python.

Also take a look for cherrypy and twisted.

My conclusion is that python is very fun to work with, very efficient and flexible. Great when you don't have much time. For bigger size project and desktop thing Java is probably better.

Name: Anonymous 2005-12-22 20:02

Python has no proper typing. It's like even less than Perl for crying out loud.

That's why I don't like it. It feels too much like a child's toy. Also the current standard implementation does not support a properly multi-threaded runtime.

Name: Anonymous 2005-12-22 22:33

Python is for noobs

Name: Anonymous 2005-12-23 7:42

It doesn't matter if it is for noobs. You may not be able to produce commercial quality products, but maintenance is not difficult and it cut development time.

C++ -> commercial products, need some modification for cross platform compatibility
Java -> internal applications, great for cross platform things
Python, perl, ruby -> speed development, cross platform compatibility
Basic -> it suck. However, it's useful only because Microsoft Produces support it

Name: Anonymous 2005-12-23 9:37

n00b or not, you can find plenty of work using Perl and Python. Hopefully Ruby soon too.

So why you'd want to work on a Java or Basic project is beyond me. Let others take the pain, while you work at some smaller 10-30 person company where they're more flexible. You only live once.

Name: Anonymous 2005-12-28 14:23

you can find plenty of work using Perl and Python
Not where I live :(

Name: Anonymous 2005-12-28 15:43

>>19
>_< You live in the Internet! You should have known.

Name: Anonymous 2006-01-06 7:32

Don't forget that Ruby and Python are awesome languages when it comes to wrapping C libraries, you have the speed of C and the usefulness of your favorite programming language.

Name: Anonymous 2006-01-07 19:46

That reminds me of a pet peeve of mine: what is with the Python obsession with embedding other programs in python, and not the other way around?

If I want an embedded language in my app, I want it in my fucking app, not the other way around.

Name: Anonymous 2006-01-07 20:51

Hey guys, first tell us, what league are you programming and then lament about slowness of some language.

Maybe I should have written that in caps..

Name: Anonymous 2006-01-09 9:18

>>22
there are acceptable scenarios for both cases

Name: Anonymous 2006-01-10 6:44

Python is a brilliant language: I love it's flexibility, elegance-yet-practicality, and the way I can get shit done with less code and have more time for other things.

Name: Anonymous 2006-01-11 8:28

It's a decent language, but hardly brilliant. Cool off.

Name: Anonymous 2006-01-11 14:53

>>25
people who say this generally learned python before learning perl (and now they're fucked because they're attached to python's BASIC-esque syntax)

Name: Anonymous 2006-01-11 15:41

>>27
__lol__

Name: Anonymous 2006-01-11 21:01

Python has a fuck ugly syntax, and its verbosity appoaches that of Java, minus the parens. And no, it's not the enforced whitespace (I don't care about that).

__init__()? __call()__? __privateAttribute? """doc string"""? [way too many one-line list hacks, especially with list filtering]? self? u""? lambda x: ? Bizarre and-or hack? _ZOMG__thisMethodIsntReallyPrivate()?

Frankly, Ruby has what Python's syntax should have been, even if it has its own problems.

If you think Python is "elegant", you haven't seen many other languages. It's a decent language, with many nice features, but elegant and brilliant it sure as hell isn't.

Name: Anonymous 2006-01-12 0:16 (sage)

python's list comprehensions are the only feature where i could say "i wish more languages had this"

Name: Anonymous 2006-01-12 10:26 (sage)

>>30
Haskell does. Well, it's more like Python has Haskell's list comprehensions, but still.

Name: Anonymous 2006-01-12 11:16

Haskell can have array comprehensions which is way superior.

Name: Anonymous 2006-02-02 4:14

Approaches the verbosity of Java, wtf?! Nevermind the fact that a Java project will have ten times the lines of code. Python has been around for years, during which developers have really figured out the most practical (not necessarily pure) ways of doing things. As a result of this, IMO it's by far the most readable language of the bunch.

Not that I'm advocating __this__, but at least Python doesn't break old code with every new release. Same reason here. and-or's been around longer than Python and far from perfect, very true. 'self' has spawned great controversies, sure, and there's plenty of good justification for and against it widely available. I've never seen _privateAttributeConvention go wrong in actual code. For that matter, ranting about inconsistencies in the syntax is largely a waste of time; go write your code. Once you get down to that, Python just works.

Name: Anonymous 2006-02-02 5:18

I knew I'd catch someone with that. Took a while, but hook, line, and sinker.

What, have you've tied your identity so much to your favorite language you can't bear to hear criticism? It's just a language.

Name: Anonymous 2006-02-02 6:19

For that matter, ranting about inconsistencies in the syntax is largely a waste of time; go write your code. Once you get down to that, Python just works.

I must say I found the opposite to be true. Looking at Python from a distance it seemed quite nice; once I got into it it gradually started to smell worse until I had to put it in a plastic bag and dump it in the trash.

Name: Anonymous 2006-02-03 14:11

>>33
| Nevermind the fact that a Java project will have ten times the lines of code
Lies. It will only have 5 times the lines of code. Of 3 times the width.

Name: Anonymous 2006-02-03 20:46

I've noticed that python coders write really horizontal code. Things similar to:

self.convertId([(name, uidutil.getId(obj)) for name, obj in container.items() if IContainer.isInstance(obj)])

I see this in pythonic code all the time, and I think it's a really bad idea. On top of that, a lot of python coders seem to think their code doesn't need comments. Maybe they buy into the hype that Python is specially made to be readable (hint: it's about as readable as any other major language).

In general, I find Python is verbose compared to the other scripting languages. It's like the Java of the scripting world: fast (yet with as a long start-up time compared to others), verbose, not pretty, has comprehensive libraries, and with language features made to scale.

Name: Anonymous 2006-02-04 6:19

>>37
That's simply because python relies more on expressions than statements. In my opinion it doesn't take it far enough. "nearly everything is an expression" to me means the same as "this language nearly doesn't suck".

As for readability, I don't like python that much but I have to admit that there's a good reason for not bothering to comment your code. Reading through other people's code after hardly any experience with the language, it was immediately obvious what it did. And I'm not talking about trivial programs here, this was a third party library (PIL in fact).

Perhaps you'd prefer columns of statements. That's cool, just, uh, I dunno stick to BASIC or something.

Name: Anonymous 2006-02-04 7:02

Reading through other people's code after hardly any experience with the language, it was immediately obvious what it did.

If you read every line of code, sure.

What I'd like is sane commenting. You know, a comment that indicates what each paragraph of code does. That way I don't need to get into the minutiae in order to have a general understanding of what is going on.

I couldn't help but have this hammered into my face while writing some adapters between zope3 and a few other third-party python programs. What a waste of my time, all because the authors were too lazy to properly comment. Considering I have deadlines to meet (and a life), it's not appreciated.

Name: Anonymous 2006-02-04 7:06

>>39
Well the problem there is that Zope is insane and tries to make Python into Java. Interfaces? Get out!

Name: Anonymous 2006-02-04 7:13

>>40
I wasn't referring to Zope, although Zope has a mean hump for a learning curve. Zope3 is decently commented in many parts. I was referring to the third-party programs, some of them fairly major. You've heard of Mailman, I presume?

Talking about zope3, did you know that many of the books that are written about it are out of date? Even the ones published just one year ago? It's really fucking annoying wondering why your code doesn't work, to then copy the code straight out of the book and discover that you're not wrong; it's the book.

Name: Anonymous 2006-02-04 13:42

>>37
In general, I find Python is verbose compared to the other scripting languages. It's like the Java of the scripting world: fast (yet with as a long start-up time compared to others), verbose, not pretty, has comprehensive libraries, and with language features made to scale.

It's indeed verbose and I wouldn't use it for quick scripting (I use PHP CLI and Perl for that), but I would use it for applications and prototypes. It's definitely prettier than Java, and way prettier than Perl too. I don't have experience with its libraries, but I hope they won't be overengineered to the point of being useless as Java's.

>>38
Perhaps you'd prefer columns of statements
Look: http://ntsecurity.nu/toolbox/shellcode/win32socketshell.asm

>>39
What I'd like is sane commenting. You know, a comment that indicates what each paragraph of code does. That way I don't need to get into the minutiae in order to have a general understanding of what is going on.
I agree with this too

>>40
Yeah, for what I've heard, Zope sucks. I'll be sure to stay away from it.

Name: Anonymous 2006-02-04 18:08

I hope they won't be overengineered to the point of being useless as Java's.

Ah, Java. I hate that language.

No matter what gripes I have about Python, it's way better than Java. The libraries don't feel overengineered, and you don't need to jump through ten hoops to get something simple done. Even not-simple things are often simple in Python.

And then of course there is the object model. Message passing >>> static class hierarchies.

Name: Anonymous 2009-01-14 5:08

Python is slow,bloated,FIOC and its bad OOP

Name: Anonymous 2009-03-06 12:16


It which is what women do It   is move a   count into e   cx and proceed   cautiously with care   and attention to   what letters would   by typed by   that series of   prelude short scenarios.

Name: Anonymous 2011-02-03 3:14

Name: Anonymous 2011-07-19 19:46

I love >>1-43 consist of intelligent, well thought-out discussion, three years pass, then >>44

lol FIOC

And it pretty much turns to shit from there.

I guess /prog/ used to be good. Oh well.

Name: Anonymous 2011-07-19 20:08

What's bad about Python?

Python is, on average, 35 times slower than equivalent C/C++ code, as much as 150 times slower for certain tasks on single-threaded problems. It get's worse with concurrency, where on threaded benchmarks running on quad-core machines, it can be as much as 450 times slower. The CPython implementation (the main canonical implementation of Python) has no thread-scalability except with asynchronous I/O, due to the global interpreter lock.

http://shootout.alioth.debian.org/u64q/which-programming-languages-are-fastest.php

Name: Anonymous 2011-07-19 20:15

>>49
That's CPython's fault (and by extension, that of its partly braindead designer).  But yes, CPython's performance and lack of proper multithreading are sickening.  Let's not even mention the retarded GC.

Name: Anonymous 2011-07-19 20:19

Python has too many non-orthogonal features. Principally is dictionaries and objects. Why have both? It's object model is silly: why have both types and duck-typing? What the fuck is that for? It's as if all its used for is isInstance and friends, since the way Python does inheritance, it's easy to do just as well with functions that insert methods into dictionaries. If it's just gonna hash a string anyway, then why bother carrying around a type? This isn't CLOS for fuck's sake -- it's not actually dispatching methods on types.

I also don't like the relationship between Python's syntax and semantics. Little things like the way generators work (put this keyword here and it drastically changes the meaning of the surrounding code!) and the way self is magically passed to methods and the way class bodies are pseudo-closures but not really.

Speaking of generators: fuck em! they are coroutine's retarded cousin, which are continuation's retarded brother.

I also don't like the gimped anonymous functions. the fuck is that.

I also don't like auto-local scope and the "nonlocal" keyword or whatever that nonsense is. Just have lexical scope like JavaScript and Lua, fuck.

In general I don't like the syntax. Big single-liners that can't be broken up are annoying. Why is there ":" in the syntax if it almost always has a newline after it?


There are things I like about Python, but not enough to make me want to use it for anything.

tl;dr: if it ain't Lisp, it's crap.

Name: Anonymous 2011-07-19 20:31

Python is poorly designed and has no excuse.

Name: Anonymous 2011-07-19 20:37

>>51
tl;dr: if it ain't Lisp, it's crap.
What if it's Scala or Haskell?

Name: Anonymous 2011-07-19 20:52

>>51
they are coroutine's retarded cousin, which are continuation's retarded brother.
Continuations that aren't limited to one shot often result in excessive stack copying (because even if it already fired, you still have to keep around a clean copy of the entire fucking stack in case someone decides to fire it again). You don't want that now, do you?

I agree with everything else in your post, except for
tl;dr: if it ain't Lisp, it's crap.
Will you please fuck off and die already you piece of shit spammer.

Name: Anonymous 2011-07-19 21:38

python is __ugly__. I would rather use Lua or Ruby.

Name: Anonymous 2011-07-19 22:56

>>54
u mad

Name: Anonymous 2011-07-19 23:02

>>34
What, have you've tied your identity so much to your favorite language you can't bear to hear criticism? It's just a language.
Programmers do this with everything.  I don't understand why.

Name: Anonymous 2011-07-19 23:21

>>54
Will you please fuck off and die already you piece of shit spammer.

If it ain't a joke, you're getting it.

Name: Anonymous 2011-07-19 23:40

>>51
Principally is dictionaries and objects. Why have both?
JS got that right.
I also don't like the gimped anonymous functions. the fuck is that.
That also breaks the ``def f(...1): ...2 is sugar for f = lambda ...1: ...2'', which simplifies the language and the implementation.

>>54
Continuations that aren't limited to one shot often result in excessive stack copying (because even if it already fired, you still have to keep around a clean copy of the entire fucking stack in case someone decides to fire it again). You don't want that now, do you?
That's one way to implement them. There are better ways, and delimited continuations can be less expensive to implement because it just partially copies ``the stack'', and they're more expressive than undelimited continuations.

Name: Anonymous 2011-07-20 1:11

If you're using Python, you're using shit.

Name: Anonymous 2011-07-20 2:58

FORCED INSERTION OF COCK anyone?

Name: Anonymous 2011-07-20 3:04

I'm going to rip your dick off and rape everybody in your family with it.

Name: Anonymous 2011-07-20 3:05

I'm going to rip your dick off and rape everybody in your family with it.

Name: Anonymous 2011-07-20 3:05

I'm going to rip your dick off and rape everybody in your family with it.

Name: Anonymous 2011-07-20 3:05

I'm going to rip your dick off and rape everybody in your family with it.

Name: Anonymous 2011-07-20 3:05

I'm going to rip your dick off and rape everybody in your family with it.

Name: Anonymous 2011-07-20 5:07

>>59
Ooh, very interesting.  I wonder how far one can go in implementing control flow (and exception handling) using only delimited exceptions.

Name: Anonymous 2011-07-20 6:20

>>49-67

still shit

Name: Anonymous 2011-07-20 6:46

>>68 is still a huge fag

Name: Anonymous 2011-07-20 7:00

NASA uses Python faggots.

Name: Anonymous 2011-07-20 7:30

>>70
Yes, it uses Python faggots.

Name: Anonymous 2011-07-20 7:35

Homosexuals use Lisp faggots.

Name: Anonymous 2011-07-20 7:50

>>67
You can do pretty much everything with them: generators, resumable exceptions, dynamic state, zippers, threads, ...

See also: http://okmij.org/ftp/continuations/undelimited.html#delim-vs-undelim

Name: >>67 2011-07-20 8:29

The last word of my post should be ``continuations''. Damn.

>>73
Would you mind explaining what ``zippers'' are to an idiot who knows C, Javascript, Lua, Pascal, and Python?

Name: Anonymous 2011-07-20 8:32

>>34
Emile Juanita impeccable compartment confer. Chlorine deodorant mung dobson... Naivete Herr Jan Waldo flippant ratify?

Name: Anonymous 2011-07-20 8:47

Winch arbitrate emolument.

Name: Anonymous 2011-07-20 8:55

Squishy Brownian hologram aqueous fritillary sensible apocalyptic.

Name: Anonymous 2011-07-20 9:04

Colombia salivate killdeer veneer couldn't primate detriment problem mudsling!

Name: Anonymous 2011-07-20 9:10

Nathaniel trainmen bartend Honda spheroid veridic Taurus grab. Similitude gallonage runneth caddy barricade Cumberland.

Name: Anonymous 2011-07-20 9:47

>>74
Basically, they're a cursor (or iterator) of a traversable data structure that lets you change the nodes in a purely functional way.
They're useful for obvious reasons when you have to move around in a complex tree-like data structure, like a representation of a file system (see ZipperFS, you also get transactions for free)

Example implementation using delimited continuations:

;; version of `map' that shares as much state as it can with the original list.
(define (map/share f xs)
  (if (null? xs) xs
      (let ((a (car xs))
            (d (cdr xs)))
        (let ((a1 (f a))
              (d1 (map/share f d)))
          (if (and (eq? a a1) (eq? d d1)) xs
              (cons a1 d1))))))

(struct zipper (cont value))

(define (list->zipper xs)
  (reset (map/share (lambda (x)
                      (let-values (((change-node? new-val)
                                    (shift k (zipper k x))))
                        (if change-node? new-val x)))
                    xs)))

(define (zipper-next z)
  ((zipper-cont z) #f #f))
(define (zipper-set z x)
  ((zipper-cont z) #t x))

(define (zipper-unzip z)
  (if (zipper? z) (zipper-unzip (zipper-next z)) z))

(define lst '(1 2 3 4 5 6 7 8 9))
(define z (list->zipper lst))

(let* ((z (zipper-next z)) ; go to the second node.
       (z (zipper-set z 10))  ; set it to 10.
       (z (zipper-set z 100)) ; and set the third node to 100.
       (xs (zipper-unzip z))) ; we're done, get the list.
  (values xs           ; '(1 10 100 4 5 6 7 8 9)
          lst          ; '(1 2 3 4 5 6 7 8 9)
          (eq? xs lst) ; #f
          (eq? (cdddr xs)
               (cdddr lst)) ; #t, these nodes are shared with the original list
          ))

Name: Anonymous 2011-07-20 9:52

>>80
Fuck you Shiichan.

Name: Anonymous 2011-07-20 9:55

>>81 That will teach you how to be a faggot with your quotes. You didn't even use then ``properly''!!

Name: Anonymous 2011-07-20 10:06

>>82
you didn't use "then" properly

Name: Anonymous 2011-07-20 10:34

>>82,83
*than

Name: Anonymous 2011-07-20 10:37

>>82
`' for to delimit code/identifiers/characters, ``'' for the rest.

Name: Anonymous 2011-07-20 10:52

>>85
s/for to/to/

Name: Anonymous 2011-07-20 13:24

>>73
what i read from that is "if you're language doesn't have set!, it better have delimited continuations."

Name: Anonymous 2011-07-20 14:19

>>87
Even with mutable state, they're more convenient and easier to use.

Name: Anonymous 2011-07-20 17:13

>>27
Quibble summary hydrophobia Copernicus kern!

Name: Anonymous 2011-07-20 17:20

Particle determinate monarchic off trilogy tog omelet oases necessary.

Name: Anonymous 2011-07-20 17:29

Solstice. Floppy parabolic.

Name: Anonymous 2011-07-20 17:35

Wriggle hydrofluoric selenate clip slingshot grip ninth peddle.

Name: Anonymous 2011-07-20 18:47

>>88
so how would it work in Scheme? How would it be different from call/cc?

Name: kodak_gallery_programmer !!M8okqD4wRfs+xmp 2011-07-20 19:10

Friends don't let friends use Scheme.

Name: Anonymous 2011-07-20 21:11

>>94
People who use Scheme don't have friends.

Name: Anonymous 2011-07-20 22:58

>>95
People who use C++ have friends but never use them because it's "bad practice"

Name: Anonymous 2011-07-21 3:43

>>93
call/cc captures the whole continuation, not part of it. This means that if you're writing a continuation-based green threads library using call/cc, it will not only capture the current continuation of the thread, but also the scheduler's. This is easily fixed by delimiting the captured continuation with (prompt (next-thread-cont)). Usually, call/cc is affected by prompts (like in the usual CPS implementation of single prompt shift/reset), but its interface remains horrible and useful only for early returns and few other things (IMHO).

There are four control operator (called *F* operators) that act all almost the same, but differ when you nest them (note: prompt and reset are the same thing, I'll be using prompt here)
(prompt E[(control0 k expr)]) (-F-) captures the continuation E[], and reifies it as (λ (x) E[x]), it is then passed to a procedure (λ (k) expr), reducing to: ((λ (k) expr) (λ (x) E[x])).
(prompt E[(shift0 k expr)]) (-F+) is the same thing, but the captured continuation is reified as (λ (x) (prompt E[x]), reducing to ((λ (k) expr) (λ (x) (prompt E[x])).
(prompt E[(control k expr)]) (+F-) reifies the continuation the same as control0, but it introduces a prompt at the bottom, reducing to (prompt ((λ (k) expr) (λ (x) E[x]))).
(prompt E[(shift k expr)]) (+F+), logically, does the same thing as shift0, introducing a prompt at the bottom: (prompt ((λ (k) expr) (λ (x) (prompt E[x])))).

How to implement them? For plain shift and reset, it's really simple, in CPS:
(reset E) => (λ (cc) (cc (E (λ (x) x))))
(shift E) => (λ (cc) (E (λ (retval) (λ (kk) (kk (cc retval)))) (λ (x) x)))
So, reset sets the continuation of E (a thunk) to the empty continuation λx.x, and applies its return value to the old continuation cc. shift reifies the current continuation cc into a function that takes one argument retval and a continuation kk, and applies cc to retval and its result to kk, and sets the continuation of E (an unary function) to the empty continuation, so that it will immediately return to the nearest reset.
As you can see, shift's reified continuation has a nested application in it, and CPS taught us that it is wrong and evil, so we transform that application in standard CPS: (cc x kk). kk is acting as a continuation for cc, which is a continuation, so it is a continuation to a continuation, or a metacontinuation. And as you can see, there's one in reset too! (the transformation is left as an exercise for the reader)
The shift/reset implementation in terms of call/cc and set! uses the same approach, storing the metacontinuation in some mc variable.
So, how is call/cc affected by this? The usual CPS transformation is
(call/cc E) => (λ (cc) (E (λ (x) (λ (kk) (cc x))) cc))
or, it disregards the new continuation and applies x to the old one, and doesn't change the continuation of E.
But reset resets a continuation to the empty continuation, and uses the old one as metacontinuation for it, so call/cc will only capture the partial continuation to the nearest reset.

This is cool and all, but what about control, and their 0 variants? And wouldn't various applications of reset interfere with each other? Yes, they would. The solution is prompt tags. A prompt tag is just a mark in a continuation frame, and this definition is as useful as saying that monads are monoids in the category of endofunctors, so let's make an example of how they're implemented in non-CPS:

Let's assume that the implementation uses a chain of activation records,
(prompt-at *tag* ...) marks the activation record with *tag*, (control0-at *tag* k ...) starts copying the activation records and it stops right before a record marked with *tag*, possibly raising an exception of some sort when it can't find one, and reifies it as above. The end.
control-at and shift-at stop right after the tag, shift0-at and shift-at introduce one in the captured continuation. The end. (Yes, it's that simple)

The CPS implementation of them is longer, and it's all about masturbation over metacontinuations and sequences of continuations, which is better explained here: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.72.8645&rep=rep1&type=pdf (hint: ignore the monads part if you're not interested in them)

This post is too long.

Name: Anonymous 2011-07-22 1:28

>>97
Thanks for the effort but it didn't help...

My understanding is that delimited continuation let you capture a small amount of future rather than all the future. Is that right? If so, what is that useful for?

Name: Anonymous 2011-07-22 2:11

>>97
Maybe I'm stupid or didn't pay enough attention to your post -- is each of the control/prompt and reset/shift pairs able to implement the other one?

Name: Anonymous 2011-07-22 3:10

>>51
It's object model is silly: why have both types and duck-typing?
Python has dynamic typing, how is that different than duck typing?

I also don't like auto-local scope and the "nonlocal" keyword or whatever that nonsense is. Just have lexical scope like JavaScript and Lua, fuck.
auto-local scope? isnt that just lexical scope? If Lua has lexical scope than why do you have to explicity declare variables as local to scope?

Name: Anonymous 2011-07-22 3:12

>>99
Maybe I'm stupid
Oh, no, you're not. That's a legitimate question, instead, I dind't mention that.

Yes, they can, but for some pairs it's a bit tricky:
control0 can easily implement all of them, and that's what the paper I linked basically does, using a control operator with control0-like semantics.
shift0 and control can easily implement shift.
For many years, many believed that shift couldn't implement control, but it was disproved in Shift to control, also proving that any control operator can implement each other (this is my logical conclusion, it is known that they can, but I'm not sure that this is the why)

>>98
If so, what is that useful for?
Nothing, you can do anything delimited continuations do with call/cc and set!, but if you remove set!, call/cc becomes helpless. And delimited continuations can express mutable state, or any computational effect.

So, nothing, really, if you've got mutable state, you can just drop delimited continuations, the only advantages are efficiency, readability, ease of use, theoretical beauty, and the lack of need of harmful mutable state.
Also, most of the time you don't need to capture the whole continuation.
When you see some strange nested call/cc application with set!, that code is just emulating delimited continuations.

Name: Anonymous 2011-07-22 3:15

>>100
Python has dynamic typing, how is that different than duck typing?
Duck typing is a bad rediscovery of Smalltalk-style message passing, for me.

And Python is known to always have got scoping wrong.

Name: Anonymous 2011-07-22 3:20

>>102
>And Python is known to always have got scoping wrong.
but in Perl and Lua you have to explicitly declare variables as local, that has to be wrong

Name: Anonymous 2011-07-22 3:43

>>103
Any language with at least one statement has got several things wrong.

Name: Anonymous 2011-07-22 3:56

>>104
what are you talking about? most every high level language is made up of statements and expressions

Name: Anonymous 2011-07-22 3:59

>>105
In most Lisps, there are no statements, only expressions. HIBT?

Name: Anonymous 2011-07-22 4:07

>>105
Exactly. With this new acquired knowledge, you can infer that ``most every high level language has got several things wrong''.

Name: Anonymous 2011-07-22 4:37

>>107
You're trying very hard to be funny but you're not.

Name: Anonymous 2011-07-22 4:49

>>108
It can't be helped.

Name: Anonymous 2011-07-22 6:17

>>101
So, nothing, really, if you've got mutable state, you can just drop delimited continuations, the only advantages are efficiency, readability, ease of use, theoretical beauty, and the lack of need of harmful mutable state.
While I do not particularly feel like arguing whether mutable state is indeed that harmful, I would like to know why you said delimited continuations are more efficient than mutable state. An example of a case where delimited continuations are more efficient than set!ting things around would be really nice too, if you don't mind.

I would also like to argue whether delimited continuations, when used to hack around mutable state, make the code more readable. Implementing things like generators and restartable exceptions does cause code to be a lot cleaner and more readable, but I can't see much uses past that maybe except implementing yet another version of the amb operator.

Name: Anonymous 2011-07-22 7:49

>>39
Ironically, I think they were thinking the same way when they wrote the code without comments.  Deadlines to meet (and a life). 

Never keeps me from wanting to ring their necks though..

Name: Anonymous 2011-07-22 8:59

>>110
I never said you should use them instead of set!, but instead of call/cc+set!.
The mutable state considered harmful part was more a joke than serious, what's bad about call/cc+set! are the excessive calls to call/cc, which is a costly operation in most non-CPS implementations.
Are two (or more) full stack copies less expensive than a single, partial stack copy?
You can get some comparisons and timings here: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.11.3425

I would also like to argue whether delimited continuations, when used to hack around mutable state, make the code more readable.
Well, I still have to see something more complicated than a non-local return or amb written using call/cc that doesn't look like absolute spaghetti code. Most applications of delimited continuations I've seen were pretty straightforward.
I don't have any example of how awesome delimited continuations can be at the moment, mostly because I lack imagination. Maybe lexers/parsers?

Name: Anonymous 2011-07-22 10:17

>>100
>>103

I think you do not understand a couple of things.

Pyuthon is duck types and has types. What this means is that you can call isInstance(someobject) and get its class. This means that Python objects carry around information about their "type" despite the fact that they really don't need to since it's a msg-passing language where it's just going to hash a string anyway. Inheritance is not requires, or, rather, it wouldn't be required if Python did scoping right and closures were actually easy to use. If this were the case, you could just make "classes" functions that insert closures into dictionaries. This is how both JS and Lua do things most of the time, although Lua also has metatables, which are nearly CLOS-like in power.

The reason Python does scoping wrong is simple if you actually understand lexical scope and closures and realize how undeniably useful they are (basically, if you are not Guido.) Nothign about Python is designed for using closures, not even the way the scope of loops works.

Name: Anonymous 2011-07-22 10:20

>>112
pretend Scheme has shift and reset instead of call/cc. will you implement call/cc for me?

Name: Anonymous 2011-07-22 10:29

>>114
(define (call/cc f)
 (shift k (f k)))

Name: Anonymous 2011-07-22 10:35

>>115
Disregard that,
(define (call/cc f)
 (f (lambda xs (shift _ (apply values xs)))))

Name: Anonymous 2011-07-22 11:09

>>116
Oh, fuck me. It's in the paper I linked in >>97.

Name: Anonymous 2011-07-22 11:11

>>115
>>116
>>117
thanks

Name: Anonymous 2011-07-22 11:18

>>118
That's an approximation and it's potentially wrong (I'm sure it is), the working version is in the paper.

Name: Anonymous 2011-07-22 11:56

- Everything you write will be open source. No FASLs, DLLs or EXEs. There may be some very important instances where a business wouldn't want anybody to see the internal implementation of their modules and having strict control over levels of access are necessary. Python third-party library licensing is overly complex. Licenses like MIT allow you to create derived works as long as you maintain attrubution; GNU GPL, or other 'copyleft' licenses don't allow derived works without inheriting the same license (viral licensing). To inherit the benefits of an open source culture you also inherit the complexities of the licensing hell.
- Installation mentality, Python has inherited the idea that libraries should be installed, so it infact is designed to work inside unix package management, which basically contains a fair amount of baggage (library version issues) and reduced portability. Of course it must be possible to package libraries with your application, but its not conventional and can be hard to deploy as a desktop app due to cross platform issues, language version, etc. Open Source projects generally don't care about Windows, most open source developers use Linux because "Windows sucks".
- Python (like most other scripting languages) does not require variables to be declared, as (let (x 123) ...) in Lisp or int x = 123 in C/C++. This means that Python can't even detect a trivial typo - it will produce a program, which will continue working for hours until it reaches the typo - THEN go boom and you lost all unsaved data. Local and global scopes are unintuitive. Having variables leak after a for-loop can definitely be confusing. Worse, binding of loop indices can be very confusing; e.g. "for a in list: result.append(lambda: fcn(a))" probably won't do what you think it would.
- Probably the biggest practical problem with Python is that there's no well-defined API that doesn't change. This make life easier for Guido and tough on everybody else. That's the real cause of Python's "version hell".
- Python's garbage collection uses naive reference counting, which is slow and doesn't handle circular references, meaning you can't use arbitrary graphs as your data.
- Problems with arithmetic: no Numerical Tower (or even rational numbers or complex numbers), meaning 1/2 would produce 0, instead of 0.5, leading to various hard to notice errors.
- No switch (why not??)
- Expressions in default arguments are calculated when the function is defined, not when it’s called.
- Poor UTF support and unicode string handling is somewhat awkward
- No outstanding feature, that makes the language, like the brevity of APL or macros of Lisp.
- Python's lambda doesn't allow conditionals, a side effect of Python making a distinction between expressions and statements. Nor does Python have a useful form lambda. Python's implementation of lambda is limited to a single expression, virtually crippling it.
- No tail call optimization. "I don't like reading code that was written by someone trying to use tail recursion. It's the ultimate code obfuscation." --Guido Van Rossum
- Assignments are not expressions
- self everywhere can make you feel like OO was bolted on, even though it wasn't.
- Quite quirky e.g. __init__. Triple-quoted strings seem like a syntax-decision from a David Lynch movie, and double-underscores seem appropriate in C, but not in a language that provides list comprehensions. There has to be a better way to mark certain features as internal or special than just calling it __feature__.

Name: Anonymous 2011-07-22 12:19

>>120
And you left out the Global Interpreter Lock. Come on.

Also,
>>> {[]: "why not, why can't references be used as keys?"}
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unhashable type: 'list'

Name: Anonymous 2011-07-22 12:30

>>121
Ok.

Global Interpreter Lock (GIL) can be a significant barrier to concurrency. Due to signaling with a CPU-bound thread, it can cause a significant slowdown, even on single processors. Reason for employing GIL in Python is to easy the integration of C/C++ libraries that usually are not thread-safe.

Name: Anonymous 2011-07-22 12:59

>>120
Python (like most other scripting languages) does not require variables to be declared, as (let (x 123) ...) in Lisp or int x = 123 in C/C++. This means that Python can't even detect a trivial typo - it will produce a program, which will continue working for hours until it reaches the typo - THEN go boom and you lost all unsaved data. Local and global scopes are unintuitive.

This isn't that big a deal. Just stop making typos. (not kidding.) Python's loop scoping is retarded though. I agree with that.

Assignments are not expressions
I actually like this. Side effects always being "called out" with statements can help draw attention to them. I like assignment being an expression in C only because you do everything with side effects in C.

Quite quirky e.g. __init__. Triple-quoted strings seem like a syntax-decision from a David Lynch movie, and double-underscores seem appropriate in C, but not in a language that provides list comprehensions. There has to be a better way to mark certain features as internal or special than just calling it __feature__.

Lua's metatables. They still use underscores though O_o

Name: Anonymous 2011-07-22 13:02

>>122
Reason for employing GIL in Python is to easy the integration of C/C++ libraries that usually are not thread-safe.
Wrong.  It's actually the other way around.  CPython's interpreter code is not thread-safe, so the only way other threads can do useful work is if they are in some C/C++ routine, which, you guessed it, must be thread-safe.

Name: Anonymous 2011-07-22 13:08

>>123
There has to be a better way to mark certain features as internal or special than just calling it __feature__.
Please, suggest a better solution (no, seriously).

Name: Anonymous 2011-07-22 13:45

>>30
This isn't that big a deal. Just stop making typos. (not kidding.)
This isn't that big a deal. Just stop using Python. (not kidding.)

python's list comprehensions are the only feature where i could say "i wish more languages had this"
Ain't it's just a set-theory wannaby be hack? Guido has PhD in mathematics set theory (ABC language, anyone?), so he reused this ugly math syntax, instead of uniform map and fold, real programmers use.

I actually like this.
You like non-uniform behaviour and ugly hacks? Good for you.

Name: Anonymous 2011-07-22 13:46

>>125
Please, suggest a better solution (no, seriously).

(special feature-name)

Name: Anonymous 2011-07-22 13:53

>>127
Too verbose. Try again.

Name: Anonymous 2011-07-22 13:56

>>127
Your code should be:



Notice how yours is verbose and mine is not!

Name: Anonymous 2011-07-22 14:13

It's inferior to Perl.

Name: Anonymous 2011-07-22 14:16

Python's syntax, based on SETL language and mathematical Set Theory, is non-uniform, hard to understand and parse, compared to simplier languages, like Lisp, Smalltalk, Nial and Factor. Instead of usual "fold" and "map" functions, Python uses "set comprehension" syntax, which has an overhelmingly large collection of underlying linguistic and notational conventions, each with it's own variable binding semantics. To complicate things even more, Python uses the so called "off-side" indentation rule, also taken from a math-intensive Haskell language. This, in effect, makes Python look like an overengineered toy for math geeks.

Name: Anonymous 2011-07-22 14:16

>>128
Try APL or J.

Name: Anonymous 2011-07-22 14:17

>>128
Do we need special features and hacks? Also, go back to APL.

Name: Anonymous 2011-07-22 14:18

>>131
Oh God, you again. Haskellers hate list comprehensions as much as you do, and encourage the use of list combinators.

Name: Anonymous 2011-07-22 14:21

>>132
QUICK
WHAT'S A GOOD FREE APL COMPILTER/INTERPRENEUR?

Name: Anonymous 2011-07-22 14:23

>>135
Dyalog APL?

Name: Anonymous 2011-07-22 14:25

>>134
"God" doesn't exist.

Name: Anonymous 2011-07-22 14:29

>>137
We know, can you please fuck off to the imageboards now? Don't ruin the last good /prog/ thread.

Name: Anonymous 2011-07-22 14:46

>>138
This one? Don't delude yourself.

Name: Anonymous 2011-07-22 14:48

>>137
I disagree, but please fuck off to the imageboards now? Don't ruin the last good /prog/ thread.

Name: Anonymous 2011-07-22 14:48

good
/prog/ thread
/0

Name: Anonymous 2011-07-22 15:47

>>126
I think as long as there's a clear separation, that restricting assignment to statements is a god idea from a theoretical standpoint. Side effects should be explicitly sequenced. Sometimes in expressions it is hard to tell what will happen first.

Name: Anonymous 2011-07-22 15:52

>>131
This.

Python's hatred of functional programming
+
Python's goal of being familiar without necessarily making any sense

are my least favorite things about it.

Name: Anonymous 2011-07-22 16:12

>>143
stop talking to yourself and instead check my dubz

Name: Anonymous 2011-07-22 16:25

>>142
You should be using Haskell.

Name: Anonymous 2011-07-22 16:32

>>145
Yes, because the FORCED IMMUTABILITY OF STATE is so much better.

Name: Anonymous 2011-07-22 18:21

>>146
More like controlled mutability of state.

Name: Anonymous 2011-07-22 18:41

>>146
at least HASKAL has some elements of FORCED INDENTATION which gets pythonistas hard

Name: Anonymous 2011-07-22 18:41

>>147
Nah, working around it with monads doesn't count as controlled. The programmer is the one who is controlled by the system, and the manipulation is so powerful that he even thinks that he is in control of the system.

Name: Anonymous 2011-07-22 19:09

>>148
Haskell's got OFIOC, and saner indentation rules.

>>149
Uniqueness types?

Name: Anonymous 2011-07-22 19:31

Another question guys: Which language do you prefer over pyton? And please do say lisp.

Name: Anonymous 2011-07-22 19:36

>>151
Anything but Lisp.

Name: Anonymous 2011-07-22 19:45

>>151
Lisp.

Name: Anonymous 2011-07-22 19:57

>>151
php

Name: Anonymous 2011-07-22 20:57

>>154
not sure if serious

Name: Anonymous 2011-07-22 21:01

>>151
Circumcised Jewish Set Theory Penis Comprehension Infinity.

Name: Anonymous 2011-07-22 21:21

>>151
Javascript

it has syntax that corresponds almost exactly to C. It uses prototype OO which is how OO should be in a scripting language. It does functional programming very well as you can see in this tutorial:
http://www.relisoft.com/web/javascript.html

Name: Anonymous 2011-07-22 21:23

>>143
Python's hatred of functional programming + Python's goal of being familiar without necessarily making any sense are my least favorite things about it.
Python was meant to be the Pascal of scripting languages, always take the most simplified and generic approach, as opposed to TimToady of Perl where syntax follows no standard pattern. The little known motto for Python is that "there is usually one best way to do something"

Name: Anonymous 2011-07-22 21:31

>>157
I remember trying ActionScript implementation of JavaScript. It was a crappy Java wannabe language. Hated it from the first sight. It's full of public class Fuck { private var crap:int = 0; public function moreCrap

Hope Adobe will go bankrupt, like Sun did. Evil corpotations.

Name: Anonymous 2011-07-23 3:25

Python is just "take random familiar language features and stuff them together with a terrible implementation and a pretty syntax"

Name: Anonymous 2011-07-23 4:35

C++ is just "C with classes and an enormous amount of random features from various languages, with a terrible syntax"

Name: Anonymous 2011-07-23 4:48

no, C++ is just "C with a giant pile of useless bullshit"

Name: Anonymous 2011-07-23 4:58

C++ is just "C with classes and an enormous amount of random features from various languages
like what exactly? could you please name a few of these random features as Im sure that the millions of programmers all over the world didnt notice them in the language

with a terrible syntax
whats terrible about it? Im sure programmers all over the world are eagerly awaiting you to specify what is terrible about C++ syntax and want to know what the correct syntax should be

Name: Anonymous 2011-07-23 5:06

>>163
Context-sensitive syntax considered harmful, [&,=](&&*(**(int a[]))[]){return a;} considered horrible.

Name: Anonymous 2011-07-23 5:11

>>164
C is more context sensitive than C++ as C++ has higher abstractions. So basically you are saying C is worse than C++

Name: Anonymous 2011-07-23 5:22

>>165
How is C more context sensitive? (A)*(B) is valid C++ and C code, but in C it can only mean A times B or B dereferenced casted to the type A, in C++ it's also A.operator*(B). And C doesn't have template<... > > > (which is gone in Sepplesox)
So basically you are saying C is worse than C++
Yes, and C++ is worse than C.

Name: Anonymous 2011-07-23 5:22

>>165
Also, higher abstractions my anus.

Name: Anonymous 2011-07-23 5:28

>>164
[&,=](&&*(**(int a[]))[]){return a;} considered horrible.
Oh yeah, rewrite it in sexprs, baby, so we could something to compare with.

Name: Anonymous 2011-07-23 5:38

>>168
that code is valid in both C and C++

>>164 makes a valid point that C++ overloads everything from C, but that begs the question as to whether you want the verbosity of a language that breaks with C to become its own separate OO syntax

Name: Anonymous 2011-07-23 6:55

>>168
(lambda (a) a)

Name: Anonymous 2011-07-23 8:49

that's nice, and all; but can CL do this:
guile> (((lambda (x) x) +) 3 4)
7

?

Name: Anonymous 2011-07-23 9:03

>>171
that's nice, and all; but can Scheme do this:
(defmacro ...)

Name: Anonymous 2011-07-23 9:14

>>172
who needs that? sexps are already perfect!
also, how could it possibly make up for a lambda calculus inconsistency?

Name: Anonymous 2011-07-23 9:38

>>172
Yes:
(define-syntax ...)

Name: Anonymous 2011-07-23 11:04

>>171
Constant fold that shit.

Name: Anonymous 2011-07-23 11:08

>>175
Lisps are interpreted, ``faggot''.

Name: Anonymous 2011-07-23 11:12

>>176
Low level troll.

Name: Anonymous 2011-07-23 11:55

>>177
High level troll.

Name: Anonymous 2011-07-23 15:22

>>162
no, C++ is just "C with a giant pile of useless bullshit"
C++ classes can be used as poor-man's lambda, while destructors is the only way for reference counting garbage collection.

Name: Anonymous 2011-07-23 15:33

>>179
Both are bad.

Name: Anonymous 2011-07-23 15:44

>>179
C++ classes can be used as poor-man's lambda
function pointer + struct works fine. All C++ does is give some syntactic sugar.

destructors is the only way for reference counting garbage collection.

no... this is not a good way to do it. Nobody in practice uses shared_pointer or smart_pointer because they simply aren't smart enough. Overloading the meaning of "}" in explicit and important ways is not a good idea. If I'm writing C, it's because I want control over my memory.


C++ just lets you pretend you aren't writing C with nerdy syntactic sugar.

Name: Anonymous 2011-07-23 15:50

If I understand this thread correctly, C++ is terrible for low-level tasks and inadequate for high-level tasks. Therefore it sucks and should be replaced by C and a Lisp.

Name: Anonymous 2011-07-23 15:50

go back cat-v faggot

Name: Anonymous 2011-07-23 15:55

>>182
Actually, C can also be replaced with Lisp.

Name: Anonymous 2011-07-23 15:56

>>182
C sucks as much as C++ at low level tasks.

Name: Anonymous 2011-07-23 16:11

>>184,185
I fail to see how one could program an OS kernel or a non-immediate-mode OpenGL program with decent performance in Lisp. Or does there exist a Lisp with static types and pointer?

Name: Anonymous 2011-07-23 16:19

>>186
*facepalm*

Name: Anonymous 2011-07-23 16:22

>>187
Instead of mocking me through mockable imageboardesque attitudes, could you please enlighten me, ``faggot''?

Name: Anonymous 2011-07-23 16:29

aah fuck, this thread really turned to shit after the continuations discussion

Name: Anonymous 2011-07-23 16:30

>>188
Lisp is in many ways a DSL for dealing with heap allocated cons cells. A cons cell is a struct with 2 pointers in it. So yes, Lisp has pointers. Even though a cons cell itself may be passed by value, what it points to does not. Regardless, what you use pointers for in C basically is to manipulate the heap. In Lisp, there is no practical difference between the stack and the heap anyway. 

And I'm not sure what you mean by "static types." If what you want is the ability to dispatch functionality based on the types of arguments, then Common Lisp includes the most dynamic and powerful means of doing this ever devised: the Common Lisp Object System. It is not static typing, but this is a powerful feature -- you can change something's type at run time, for instance.

Name: Not >>188 2011-07-23 16:54

>>190
CLOS is a bloated piece of shit and you know it.

Name: Anonymous 2011-07-23 17:31

>>186
One can write an OS in Python, if he wants.

Name: Anonymous 2011-07-23 18:17

>>191
a bloated piece of shit that does something no other similar thing does. Kind of like C++.

Name: Anonymous 2011-07-23 23:02

>>190
What if you implement lists using finger trees? Will it still be lisp?

Name: Anonymous 2011-07-23 23:17

>>194
I'm about to finger your anus. Bend over, faggot.

Name: Anonymous 2011-07-23 23:24

>>195
gb2b

Name: Anonymous 2011-07-24 6:09

>>196
fuck you faggot

Name: Anonymous 2011-07-24 16:30

>>190

ooc does all that and more.

Name: Anonymous 2011-07-26 22:55

>>101,112
Sorry for bothering you again (and for bumping this awful thread), but I would like to ask you something.  If given the shift/reset primitives in your Lispy language of choice, how would you implement (make-generator f) such that:

(define g
    (make-generator
        (lambda (yield)
            (map yield '(1 2 3 4 5)))))

(g) ; should print 1
(g) ; should print 2
(g) ; should print 3


It's been haunting me for days now.

Name: Anonymous 2011-07-27 0:06

>>199
you can do that with regular call/cc

Name: Anonymous 2011-07-27 0:10

>>200
Implementing call/cc requires writing a full-blown codewalker.

Name: Anonymous 2011-07-27 0:12

>>200
actually you can implement it quite easily with macros over lambda.

Name: Anonymous 2011-07-27 0:12

>>199
You can't in CL; you need Scheme and its realized continuations for that. Here's how you might do it:

(define (make-generator fun)
  (let ((current #f))
    (lambda ()
      (call-with-current-continuation
       (lambda (outer)
     (if current
         (begin (current))
         (begin (fun (lambda (value)
               (call-with-current-continuation
                (lambda (inner)
                  (set! current inner)
                  (outer value)))))
            (call-with-current-continuation
             (lambda (end)
               (set! current end)))
            (throw 'no-more))))))))

Name: Anonymous 2011-07-27 0:17

>>203
You can, but it wont be CL anymore.

Name: Anonymous 2011-07-27 0:29

>>204
So in other words, you can't in CL.

Name: Anonymous 2011-07-27 0:40

>>205
Consider (mapcar #'F Xs).
If F uses call/cc (it's common to use AMB during map), mapcar would crash, because it doesn't support continuations.
So one have to rewrite every high-order CL function and macros, like LET and PROGN.

Name: Anonymous 2011-07-27 1:26

>>206
There's nothing intrinsic about mapcar, let or progn that make them "not support continuations". If anything, you speak of some specific implementation of CL, which is a different thing altogether.

CL (the standard) doesn't support continuations at all, however.

Name: Anonymous 2011-07-27 1:33

>>207
I have (defun F (K ...) ...)
How can I force MAPCAR to pass F it's continuation as the first argument?

Name: Anonymous 2011-07-27 1:34

>>207
CL (the standard) doesn't support continuations at all, however.
It supports. Internally. It's called "return address", which is pushed onto stack.

Name: Anonymous 2011-07-27 1:38

Basically, one can't implement TCO, SIGNAL, BLOCK and RETURN-FROM without access to continuations. It must already be there.

Name: Anonymous 2011-07-27 2:34

>>203
I know how to do it using regular call/cc.  I was asking for how to do it using delimited continuations, more specifically, using shift/reset.  Since delimited continuations may be used to implement call/cc, it comes as no surprise that (make-generator f) may be implemented using delimited continuations.  However, I would like to know the most natural way of doing it, preferably without wrapping the code in a reset (which would amount to emulating call/cc, which involves an unfortunate copying of the entire stack).

Name: >>112 2011-07-27 3:13

>>199,211
I find it cleaner to define a yield procedure, instead of passing it as an argument, but that's doable too.

(define (yield . xs)
  (shift k (cons k xs)))

(define ((generator f) . xs)
  (reset (apply f xs) #f))

(define ((generator/yield-arg f) . xs)
  (reset (f yield) #f))

(define ((fioc-generator-of gen) f)
  (let ((g (gen f)))
    (lambda ()
      (let ((next (g)))
        (set! g (car next))
        (apply values (cdr next))))))

(define fioc-generator (fioc-generator-of generator))
(define fioc-generator/yield-arg (fioc-generator-of generator/yield-arg))

(define g
  (fioc-generator
   (lambda ()
     (for-each yield '(1 2 3 4)))))

(g) ; 1
(g) ; 2
(g) ; 3

(define g2
  (generator/yield-arg
   (lambda (yield)
     (for-each yield '(1 2 3 4)))))

(g2) ; (cont . (1))
((car (g2))) ; (cont . (2))
((car ((car (g2))))) ; (cont . (3))
((car (g2))) ; (cont . (2))

(define g3
  (fioc-generator/yield-arg
   (lambda (yield)
     (for-each yield '(1 2 3 4)))))

(g3) ; 1
(g3) ; 2
(g3) ; 3

Name: Anonymous 2011-07-27 3:16

>>209
It supports one-shot third class escape continuations with return-from too.

Name: Anonymous 2011-07-27 10:46

>>212
I find it cleaner to define a yield procedure, instead of passing it as an argument, but that's doable too.
I can explain.  The idea is that you can use the (f yield) directly, without wrapping it using (make-generator f), in order to call (yield x) on every generated element of f.  Whether this is actually useful is arguable.

Name: Anonymous 2011-07-27 11:54

>>214
If the yield escapes its generator procedures' dynamic extent, bad things can happen:
- It may capture and abort the current continuation up to the nearest reset, returning '(cont . args).
- In a multi-prompt implementation, it may interrupt whatever generator it is invoked within, or raise an error when you're not inside the dynamic extent of a generator.
- In a multi-prompt implementation, with every generator having a distinct prompt tag, it probably just raises an exception, but it does the right thing while still inside the original generator's extent.

Name: Anonymous 2011-08-15 0:59

>>115-117
Just wanted to correct myself, for future reference and archival purpose:

Let # be an unique continuation prompt delimiting the bottom of the metacontinuation
Let (C p k E) be a control operator that either captures a continuation up to the nearest active prompt tag p, or to the tag #, reinstantiating it, reified and bound to x

Call/cc is:

(define (call/cc f)
  (C # k (prompt p (f (lambda xs (C p _ (apply k xs)))))))


This should work.

Name: Anonymous 2011-12-22 14:14

python is shit

Name: Anonymous 2011-12-22 14:49

madoka a shit

Don't change these.
Name: Email:
Entire Thread Thread List