Favorite function

printf

eval

hax :: MVar Anus -> IO ()

>>3
but it's impure!

id

f <- do { let Just (@:) = Nothing; return (@:); }

Suggested topic change: Favorite print function

Mine would have to be printf as well. Those mongoloid addition-sign wielding proponents of print can rot in ignorance for all I care.

I enjoy echo and puts.

strdupa()
Becase.

socket()

I like format for being able to print Roman numerals.

>>4
is your anus pure? no? i thought so.

substr gets a lot of use from me. pure C string manipulation is something of a mystery

pure C strings are like pure Neanderthals battling pure saber-toothed tigers..

I LOVE PRINTF

>>9
Are you Polish or something? Pole? Polar?

call-with-current-continuation

loeb :: Functor f => f (f a -> a) -> f a

For printing:
C, sprintf
CL, format or formatter
format is probably the most superior formatting function I've seen when it comes to features that it's not even funny, but it's more complex, and thus is slower than just sprintf, which is slower than just manually converting your strings. formatter strikes a good balance as it compiles the format string into real code, which means it's usually much faster than printf-likes (imagine what it would be if your printf statement would convert into strdups, itoa's and the like, at compile time, only you could also add conditionals and more complex expressions!).

If I had to pick some general functions... COMPILE and MULTIPLE-VALUE-CALL would be in my list of favorites, but I barely use them directly, even though most things rely on them invisibly.

In general I find the call-with-* style functions to be extremely useful, but I'd have to give the prize to apply

>>16
I guess you are, if you noticed this.
Also, strrchr. Seems a bit like hrhrhrhrhr

cdr(NULL, NULL, NULL, NULL, NULL);

fact

hehehhehehHEH DICKDICK

For string formatting and output: fmt ( http://synthcode.com/scheme/fmt/ )
In general: reset and shift

f(x)=sin(x)

>>26
f = sin, pointless.

Eeeff is my siiiin!

Sorry.

>>27
Lrn to math...

loeb

>>29
Go back to where you came from and do not pester glorious board of /prog/ with your pestilence.

malloc is the best function, though.

I love strchr

lambda

Eval

apply

(conjure-spirits)

main

>>12
Actually, unlike you, I don't receive anal sex on a daily basis, so my anus is indeed pure.

>>38
How will you do IO with a pure Anus? It doesn't seem very practical to me. In the real world we need impure Anii, and you can fuck off with your ivory tower bullshit.

>>1
COMEFROM

probly malloc. i'd have to think about it more than i care to.

fork()
I like its name.

I always really liked pow()

cin

operator>> and operator>>= because, with overloading, I can almost pretend I'm using Haskell

;_;

Mine has to be lambda (or whatever variant of lambda) or bind. Not to be confused with the socket bind function.

>>46
implying lambda is a function

I like alloca(). It's great for string manipulation, and I don't have to worry about managing memory.

Variable length arrays are a lot better for this since they have proper block scope instead of function scope (e.g. inline a function that uses alloca() into a loop, kaboom), but unfortunately they aren't nearly as widely supported as alloca() (as usual, msvc is the limiting factor).

>>46
lambda is a macro.

>>49
MACRO MY ANUS

lambda is a mobile vagina that outputs anuses

>>51
s/anuses/anii/

SDL_Joystick_NumBalls

Wishful Thinking

[code]Leah();{/code]

new

code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code(code())))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))));

>>57

C:\>code
DICKS

C:\>

frobnicate

foo

GOTO

>>61
Not a function. goto-like statements/operators almost always translate to a jump in the native language of the platform(such as the machine's assembler or vm's bytecode).

>>62
I'm sure our compiler implementors, Haskell nomads and SATORI PROGRAMMERS didn't know that. Thank you for your insightful comment.

jump is a function that modifies the program counter, dickass

Everything is a function! You know that shit you took this morning, yep, it's a function.

Prolog.

>>63
It's unusual to implement it as a function in most languages and language implementations. You can make an interpreted CPU emulator which stores the Instruction Pointer/Program Counter in a memory location and have a function which modifies it, but that's how a certain CPU might be implemented(emulated or real, however in real world situations, it's represented as a register), but that doesn't make it a function in the actual bytecode, unless you want to go ignore abstraction barriers and allow your access to the VM memory from within interpreted code (it would make more sense for the code to use a designated jump instruction to change the IP/PC, but of course some "move ip, addr" could work, but it would be counterintuitive, though there is no real difference between "mov ip, addr" and "jmp addr"). If you really wish to argue about silly semantics, you can't really say that a procedure which causes SIDE-EFFECTS on the program counter can be called a function in the mathemathical sense (you would have to specify a different meaning for the word function than is widely understood). I know you could model state in a purely functional way using monads, but that doesn't mean that there is really no state. In reality, everything will be implemented in a purely imperative way after compilation, and ready to be executed by a real CPU which usually works using memory and registers which are inherently stateful. Even if your system is compiled to a VM, that VM would still have state in some form or the other. One should not confuse CPU implementation with the instruction set and its semantics.

tl;dr: goto will almost always be a statement/special operator in real languages(with the exception of languages which don't have goto at all(except in intermediate compilation phases), or those languages with more "powerful" constructs of control-flow transfer).

call/cc: the ultimate goto

Bew.
This is not really a programing related function.

I find that carefully created(by some macro) lambda's can be used to emulate goto quite well and efficiently(if a good compiler is used).

>>69
How?

>>70
see >>67 and http://en.wikipedia.org/wiki/Continuation-passing_style

>>70
It assumes two things about lambda, first that you have access to the environment in which it's defined(it's a closure), and second that the implementation does TCO(it's not necessary, but otherwise things may stack overflow, and the semantics will be different).

I think those that read SICP would have seen this one already:
you can implement loops using tail-recursion, as TCO means that the compiler can optimize those tail calls into simple jumps(with some possible stack unwinding code as necesarry).

Now how do you use this as arbitrary goto?
Let's say you have broken a body with some GO blocks(see common lisp's [m]TAGBODY[m] and GOoperators which is effectively a goto(but it can't do computed gotos!), you could break down everything into code blocks delimited by the tags and then stuff each of these blocks in a lambda form and append a call(jump) to the next lambda: `(lambda () (let ,@body (,next-lambda)), GO forms could be translated to simple (forced) tail-call to the next lambda form thus interconnecting them all and allowing arbitrary jumping between the forms, just like a real GO operator. This also works right since you can access the lexical (and of course dynamic) bindings available in that function, so it can be done fully transparently. It should work both in Scheme and Common Lisp(as long as you're using a decent implementation capable of TCO). Generally, I wouldn't want to use this in CL as it already has a very capable GO special operator for such low-level tasks(useful in control-flow macros), but there is one thing GO/goto can't do that lambda can, and that's computed GOTO (you can tailcall(jump) to any function you like dynamically)!
Usage scenarios could be for example implementing a very efficient case construct based on hashtables or arrays which allows one to use a "jumptable" to jump to the matching piece of code. Most CL implementations seem to strangely implement this naively(the case construct does manual comparisons for each value), while it could be implemented much more efficiently using a jump table. Here's an example of such an implementation: http://paste.lisp.org/display/83487

Here's another reasonable example of using lambda's in this way to implement call/cc: http://common-lisp.net/project/cl-cont/

postpone

preg_replace_callback

>>39
I know right. Everyone has taken a dicking or two in their life.

>>73
``CL can do x too, all you need is a global transformation and a reimplementation of all primitives!''

>>77
As you can see, it doesn't take that many lines of code, and the effect of the code walker is localized. When I first learned CL I was a bit upset that they didn't tuck in continuations in the standard, given that it does practically support a very large variety of features(just think of CLOS, the type system, arrays, lambda lists, etc which are fairly complex), but now that I know CL decently, and understand its design goals, I can say safely that I'm actually glad they didn't include it. CL tries to include a lot of features, but they make great efforts to make sure you can implement these features in a performant and non-prohibitive way. Supporting continuations natively would have led to various problems:
The way continuations should behave in the presence of some special-operators which deal with the control-flow under exceptional conditions is very hard to define correctly, and you might as well have to make a choice between one of them when defining a language. The issues which can occur in the presence of UNWIND-PROTECT have been discussed and studief in great detail by many Lisers. Dynamic bindings (if present) can cause trouble for a compiler wishing to do TCO in some cases, this could lead to some issues when implementing continuations again (and things like *which* bindings should be used, etc). Implementing continuations naively can be quite an overhead on performance (which goes against CL's goals of making it easy to write implementations which generate performant code), and writing high-performance compilers which implement continuations efficiently is possible, but tricky.

However, one simple way of implementing continuations is recompiling special forms/operators to use CPS and then defining call/cc in that terms is not that hard, and it can be done locally, without penalty to the entire implementation(just local penalty to the code defined in that manner). Besides, CL-CONT(and some other systems which implement continuations and call/cc), aren't that large and hard to implement. In "On Lisp", Graham even gives an implementation for a simple call/cc within a single page of code. His code is mostly fine, except for some slightly abuse of undefined behaviour(which could be easily translated into more proper code... I wonder why didn't he), but it's not an `industrial-strength' call/cc IMO. If you're going to use call/cc as part of some larger system(ex. web based continuations-based frameworks, which allow continuations to persist), you might want to opt for a more global and proper call/cc implementation. Those implementations will of course be larger as they are careful into taking into account the semantics of the entire language and allow your code to interoperate fairly cleanly(as long as you don't use a few conflicting special forms).

If you're curious about the details of some of the technical issues, this paper might be more interesting to you: http://www.nhplace.com/kent/PFAQ/unwind-protect-vs-continuations-original.html

However, one simple way of implementing continuations is recompiling special forms/operators to use CPS and then defining call/cc in that terms is not that hard, and it can be done locally, without penalty to the entire implementation(just local penalty to the code defined in that manner)

This is what Marc Feeley talks about in his lecture "The 90 minute scheme to C compiler" although IIRC he just does a full rewrite of everything into CPS. He also suggests that if your code isn't going to be using a lot of continuations it is probably easier and you'd get better performance if you just to copy the stack. Do any of the CL implementations of continuations do the latter?

>>79
CL-CONT - portable library, code walker, and implements call/cc via CPS
arnesi - portable library, has a code walker, and implements call/cc via CPS
I also see 2-3 other, less serious, more toyish implementations of call/cc floating around.
One problem with stack copying is that it's not enough: symbols can have their own values, which are stored on the heap. It is possible however to use heap copying: there is a SBCL fork which implements a contrib called SB-HEAPDUMP which does just that and can be used to implement such native persistent closures. I suspect it's doable in some other implementations as well, but I haven't looked into it.

Offtopic: "The 90 minute scheme to C compiler" seems like an interesting experiment I'd like to try. It reminds me of that book "Lisp in Small Pieces" by Queinnec.

*native persistent continuations

>>80
Technically, it's 90 minutes to explain the compiler ;) Implementing it will take a little longer. Talk available at http://www.iro.umontreal.ca/~boucherd/mslug/meetings/20041020/minutes-en.html

I should mention that if you already understand how to do CPS transformations and closure conversion, you're not going to get much out of it. But he does provide source code for the compiler for the interested.

>>83
Just finished reading the presentation. I knew how to do closure conversion, and I understand CPS conversion in general terms, but I never actually implemented it on my own, so it'll be an interesting exercise.

>>78
the effect of the code walker is localized
Yes, that's the problem. Continuations are dynamic, so a lexically limited transformation is useless. My biggest problem with CL is that it is riddled with 80% solutions ( http://www.scsh.net/docu/post/sre.html ).

you might as well have to make a choice between [the ways continuations should behave] when defining a language
Most special cases have a right way if you think about it a bit, and if you're not sure you can leave it undefined or make it an error to use continuations in that situation.

UNWIND-PROTECT
Cleaning up a resource after some code has executed indeed breaks down in the presence of continuations, but it is easy to correct by adding a finalizer to the resource and letting the GC do what it does best. See ``More simply addressing the confusion about UNWIND-PROTECT in Scheme'' at http://mumble.net/~campbell/blag.txt . Regrettably this has not yet made it into any Scheme standard.

Dynamic bindings [...] can cause trouble for [...] TCO
A bit, but it's still possible. This does not cause problems with full continuations, only with delimited ones ( http://list.cs.brown.edu/pipermail/plt-scheme/2009-June/033632.html ).

Implementing continuations naively can be quite an overhead on performance
As mentioned, stack copying has almost zero overhead and is quite simple.

one simple way of implementing continuations is recompiling special forms/operators to use CPS
That's not simple at all!

Offtopic: http://www.finalizer.net/

Offtopic, but I'm not starting a thread and here will do
http://vintage-digital.com/hefner/misc/lisp-programmers.jpg

>>33
this one.

force and delay

>>88
delay isn't a function

lol no one knows what >>68 is referring to.

>>88
Don't forget lazy!

>>91
And neither is lazy

>>91
Don't tell me you are lazy, 'cause you're hon-toe nee clazy!

>>93
Everyone who gets this should be very ashamed with themselves especially if they watched the entire season ;_;

>>94
Why should I be ashamed?

"GRUNNUR"

>>94
I haven't watched any episode nor any of the EDs/OPs. Does that make me a good person?

erfleytneikvæð

>>85
Yes, that's the problem. Continuations are dynamic, so a lexically limited transformation is useless. My biggest problem with CL is that it is riddled with 80% solutions ( http://www.scsh.net/docu/post/sre.html ).
You can always get global continuations if you apply them on the whole code, however this will cost you a bit in terms of what features you can use and when it comes to performance(depending on how well the compiler will deal w/ compiling the CPS'd code).
As mentioned, stack copying has almost zero overhead and is quite simple.
Sadly there is only one implementation that does has stack/heap copying support, but it's probably not that hard to add it to others if there is the need.
My biggest problem with CL is that it is riddled with 80% solutions ( http://www.scsh.net/docu/post/sre.html ).
I think CL itself is fairly well done, but it doesn't have standardized FFI, networking, multi-threading support, however the de-facto standards for them are fairly good (there's even multiple such libraries, and they're quite featureful).
I don't think the 80% solution problem is limited to the Lisp world: I see it all over the open source world. I tend to bump into it when picking some unmaintained library for some task and having to learn its internals to extend it to fit my need, but at the same time, I've had the pleasure of using libraries which did exactly what I wanted, so I can't say it's true for all of the cases.

string create_function ( string $args , string $code )

>>97
Lazy?  I found out the phrase "something something lazy" was from some anime just a week or two ago.

>>101
That animu being K-on!?

>>39
Protip: guess why IO a is an opaque type.

108 Name: Anonymous 2010-12-17 1:28

Xarn is a bad boyfriend