If lithp macros are so cool ...

how the fuck do I use define-syntax and syntax-rules to convert "abc" into (string->list "abc") ?

ANSWER ME THAT, MATH BOYS

seriously though, part of the reason C doesn't suck so much is because strings are a subset of arrays

lisp would be pretty good if they used the concept the language is based around to represent strings, you know, LISTS?

the fact is, scheme isn't a lisp, it's a [s/l]isp

use defcheesemac

seriously, if I want a practical language that's EFFICIENT, I'm not going to use a programming language that's based around LINKED LISTS in the first fucking place. but it would be nice if they actually stuck with linked lists so you don't need two functions to convert back and forth between something that has its tail stuck in its anus and something that doesn't

>>3
seriously seriously seriously seriously

my dog has no name
then how does he smell?
(regcallback 'smell (lambda ...))
for these that failed to understand my high quality joke: no name, a function has a name, anonymous function, function that does not have a name, lambda.

define-syntax isn't Lisp it's Scheme. Scheme is not Lisp.

>>7
lay some of that string->list magic on me anyway boy, I'm sick of this stupid string shit in chicken skeem

Suppose you have a magic implicit syntax rule called shitface that turns "abc" into (string->list "abc")
You have some code that contains "abc" and shitface sees that and dutifully turns it into (string->list "abc")
Then you have some code (string->list "abc") that contains "abc" and shitface sees that and dutifully turns it into (string->list (string->list "abc"))
Then you have some code (string->list (string->list "abc")) that contains "abc" and shitface sees that and dutifully turns it into (string->list (string->list (string->list "abc")))

do you see

>>4
Clojure allows you to treat strings as lists

>>10
some dumb fucks can't even spell closure

>>9
I don't care, writing (string->list) is a waste of bytes

Strings are not lists, and when languages pretend they are it encourages incorrect assumptions and bad performance.

>>13
See: Haskell

>>9,12
Macroexpand to the list literal then, not to (string->list "abc")

>>13
You are right, strings are not lists, they are arrays. And when languages pretend they are not, it encourages incorrect assumptions and bad performance.

lisp macro is cool...........

>>10
Clojure is not a LISP.

define-syntax and syntax-rules

What do they have to do with Lisp macros anyway?

(defmacro (to-list a)
`(coerce ,a 'list))

>>14
You can't have implicit macros that match on reader literals without using something implementation-specific e.g. altering the readtable, and at that point it's not lisp or scheme any more, it's a new language you may describe as "lisp/scheme + your retarded string nuking macro and a bunch of useless string- functions".

>>15
shut the fuck up about performance, that's like showing $ at the end of lines in cat (-E option) and calling it efficient

IF YOU'RE USING SHELL, USEE A FUCKING PIPE, YOU MOTHER FUCKER?

IF YOU'RE USING LISP, USE A FUCKING LIST.

FUCK OFF

>>19
now hy the fukc's there a table

and how the fuck is that not lisp/scheme anymore when you have fifty fucking languages that are described as lisp/scheme

it's lisp or scheme if I say it's lisp or scheme, you cock-sucking donkey fucker

>>19
the goal's to not need that string shit and operate directly on lists which strings are implemented with (string->list) is an easy way of doing that, learn to fucking read

u guys are just upset because you can't patch the flaws in your stupid language, C hardly bothers with syntax you just fuck with the file using external tools and it works. it works better than these stupid scheme 'macros' where you even convert a string literal to a LOCAL representation (i.e. a list) without doing the conversion explicitly. you operate on text (even with #define, you operate on text), not within the rigid confines of some stupid, retarded context-sensitive grammar that you can't do anything useful with (e.g. fix the languages stupid idea of implementing strings with anything other than ordinary lists)

C doesn't have this stupid problem, it has no linked lists or any other retarded container aside from arrays and that's what strings are implemented with. memcpy works on strings, operators that work on pointers work on strings, it all fucking works nad you don't need to write two different versions of a function for operating on two separate containers, you just do everything with arrays.

fucking penis.

yet all you little girls sit there masturbating to your macros. I've never needed to write a fucking macro in my life because I write properly structured code and I write higher order functions and shit like that

I'm just saying, you have a language which has interesting properties and everything is joined rather than segmented (as it is in C), you do everything with lisp. it's like an IDE vs lots of simple tools that do one thing. but the only downside of that is, to really appreciate it, it can't suffer from stupid defects like using two different container types and expecting you to write functions that operate on both fucking containers when you only need one fucking container that works well

and it's an advantageous representation anyway, since you're blowing your memory up the anus by using linked lists, you don't need to care about unicode, the language could just convert UTF-8 sequences into unicode values and store those in lists. dunno why they make this shit so fucking hard and spout bullshit about performance. yeah, nobody's using your fucking programming language, and you worry about PERFORMANCE? how's your PERFORMANCE >>15 when nobody uses any of your shit because it's so fucking painful to use

at least it's quicker than speedy fucking gonzalis, right? at least it's speedier than speedy gonzalis >>15

maybe you could challenge him to a race you fucking moron

WHEN'S RACE DAY WITH SPEEDY GONZALIS >>15 ? IS IT THERE YET IS IT THERE YET IS IT THERE YET

CAN YOU WRITE A PROGRAM THAT SCHEDULES IT 1 NANOSECOND QUICKER THAN CUDDER'S STUPID HAND-OPTIMISED ASSEMBLY BULLSHIT

>>24
stop giving namefags attention

go fuck yourself, 15, you're not even a man, you're a fucking number who's hung up on time

and incorrect assumptions? the only assumption that's incorrect is your assumption that there are any incorrect assumptions, you vibrating giraffe dildo

I'll accept that, cheers >>25

if I cared about your stupid races and your runtime I wouldn't be using scheme >>15 I'd be using your stupid java bullshit or whatever you hip young cocksuckers use to DAZZLE your employers and WOW them with DOUBLY-MICRO-NANO SQUEEZES OF TIME!

why don't you post the output of time when you run it with the program that loads up your hentai for a furious masturbation session >>15 you fucking sissy

how fast does it take you to get from optimising some pathetic useless code, to a dull energy-sapping orgasm that not even a 90 year old male would consider respectable?

how well have you optimised that >>15 you sissy?

>>17
Common Lisp is not a lisp.

you can very easily convert "abc" to (string->list "abc") using a reader macro, you stupid fucks.

>>31,19

checkem

>>32
Too bad >>19 is wrong and a nigger.

>>34
No he isn't.

>>34
Tsk.

Pissing in an ocean of piss, but changing the reader is not "implementation dependent", and therefore >>19 is wrong and a nigger.

Stating that input customizations are antithetical to Lisp implies anti-satorical thinking, and of being wrong, and of having niggers look at you and say "Dam nigga you don't understand Lisp at all!"

anti-satorical

My new favorite word.

>>15

they are arrays.

Not if you plan to support utf8, the one true encoding. Strings are no longer a list of bytes which can easily be indexed in an array, but a list of variable-length codepoints, which can take up to O(N) time to access. It doesn't matter whether characters are stored in a linked list or an array now, they have the same O() for indexing.

>>39
There are other ways, like using 32-bit codepoints and using the extra values for composite characters a la Perl 6.