From: Lars Rune Nøstdal
Subject: Re: Lexical closures - difference between Common Lisp and Scheme
Date:
Message-ID: <1224921312.7962.322.camel@blackbox>
On Sat, 2008-10-25 at 00:25 -0700, Eli Bendersky wrote:
> In Common Lisp, the same:
>
> (defvar *flist* '())
>
> (dotimes (i 3 t)
> (setf *flist*
> (cons (lambda (x) (* x i)) *flist*)))
>
> (dolist (f *flist*)
> (format t "~a~%" (funcall f 2)))
>
> Prints "6 6 6".
Maybe it's the "DOTIMES thing":
(let ((flist nil))
(dotimes (i 3)
(push (lambda (x) (* x i))
flist))
(loop :for f :in flist
:collect (funcall f 2)))
=> (6 6 6)
(let ((flist nil))
(dotimes (i 3)
(let ((i i))
(push (lambda (x) (* x i))
flist)))
(loop :for f :in flist
:collect (funcall f 2)))
=> (4 2 0)
Quote from the HyperSpec:
It is implementation-dependent whether dotimes establishes a new
binding of var on each iteration or whether it establishes a
binding for var once at the beginning and then assigns it on any
subsequent iterations.
http://www.lispworks.com/documentation/HyperSpec/Body/m_dotime.htm
--
Lars Rune Nøstdal || AJAX/Comet GUI type stuff for Common Lisp
http://nostdal.org/ || http://groups.google.com/group/symbolicweb
From: William James
Subject: Re: Lexical closures - difference between Common Lisp and Scheme
Date:
Message-ID: <gdv93k01o80@enews2.newsguy.com>
Lars Rune Nstdal wrote:
> On Sat, 2008-10-25 at 00:25 -0700, Eli Bendersky wrote:
> > In Common Lisp, the same:
> >
> > (defvar flist '())
> >
> > (dotimes (i 3 t)
> > (setf flist
> > (cons (lambda (x) (* x i)) flist)))
> >
> > (dolist (f flist)
> > (format t "~a~%" (funcall f 2)))
> >
> > Prints "6 6 6".
>
>
> Maybe it's the "DOTIMES thing":
>
> (let ((flist nil))
> (dotimes (i 3)
> (push (lambda (x) (* x i))
> flist))
>
> (loop :for f :in flist
> :collect (funcall f 2)))
>
> => (6 6 6)
>
>
> (let ((flist nil))
> (dotimes (i 3)
> (let ((i i))
> (push (lambda (x) (* x i))
> flist)))
>
> (loop :for f :in flist
> :collect (funcall f 2)))
>
> => (4 2 0)
>
>
> Quote from the HyperSpec:
>
> It is implementation-dependent whether dotimes establishes a
> new binding of var on each iteration or whether it
> establishes a binding for var once at the beginning and then
> assigns it on any subsequent iterations.
Ruby:
flist = []
3.times{|i| flist << proc{|x| x * i}}
flist.map{|pr| pr[2]}
==> [0, 2, 4]
From: Pascal Costanza
Subject: Re: Lexical closures - difference between Common Lisp and Scheme
Date:
Message-ID: <6mgorcFgpffdU1@mid.individual.net>
William James wrote:
> Lars Rune Nstdal wrote:
>
>> On Sat, 2008-10-25 at 00:25 -0700, Eli Bendersky wrote:
>>> In Common Lisp, the same:
>>>
>>> (defvar flist '())
>>>
>>> (dotimes (i 3 t)
>>> (setf flist
>>> (cons (lambda (x) (* x i)) flist)))
>>>
>>> (dolist (f flist)
>>> (format t "~a~%" (funcall f 2)))
>>>
>>> Prints "6 6 6".
>>
>> Maybe it's the "DOTIMES thing":
>>
>> (let ((flist nil))
>> (dotimes (i 3)
>> (push (lambda (x) (* x i))
>> flist))
>>
>> (loop :for f :in flist
>> :collect (funcall f 2)))
>>
>> => (6 6 6)
>>
>>
>> (let ((flist nil))
>> (dotimes (i 3)
>> (let ((i i))
>> (push (lambda (x) (* x i))
>> flist)))
>>
>> (loop :for f :in flist
>> :collect (funcall f 2)))
>>
>> => (4 2 0)
>>
>>
>> Quote from the HyperSpec:
>>
>> It is implementation-dependent whether dotimes establishes a
>> new binding of var on each iteration or whether it
>> establishes a binding for var once at the beginning and then
>> assigns it on any subsequent iterations.
>
> Ruby:
>
> flist = []
> 3.times{|i| flist << proc{|x| x * i}}
> flist.map{|pr| pr[2]}
> ==> [0, 2, 4]
The original version counted from 1, not from 0.
(loop for i from 1 to 3
collect (let ((i i)) (lambda (x) (* x i))) into flist
finally (return (loop for f in flist collect (funcall f 2))))
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Lars Rune Nøstdal
Subject: Re: Lexical closures - difference between Common Lisp and Scheme
Date:
Message-ID: <1224954814.7962.362.camel@blackbox>
On Sat, 2008-10-25 at 14:05 +0000, William James wrote:
> Lars Rune Nstdal wrote:
>
> > On Sat, 2008-10-25 at 00:25 -0700, Eli Bendersky wrote:
> > > In Common Lisp, the same:
> > >
> > > (defvar flist '())
> > >
> > > (dotimes (i 3 t)
> > > (setf flist
> > > (cons (lambda (x) (* x i)) flist)))
> > >
> > > (dolist (f flist)
> > > (format t "~a~%" (funcall f 2)))
> > >
> > > Prints "6 6 6".
> >
> >
> > Maybe it's the "DOTIMES thing":
> >
> > (let ((flist nil))
> > (dotimes (i 3)
> > (push (lambda (x) (* x i))
> > flist))
> >
> > (loop :for f :in flist
> > :collect (funcall f 2)))
> >
> > => (6 6 6)
> >
> >
> > (let ((flist nil))
> > (dotimes (i 3)
> > (let ((i i))
> > (push (lambda (x) (* x i))
> > flist)))
> >
> > (loop :for f :in flist
> > :collect (funcall f 2)))
> >
> > => (4 2 0)
> >
> >
> > Quote from the HyperSpec:
> >
> > It is implementation-dependent whether dotimes establishes a
> > new binding of var on each iteration or whether it
> > establishes a binding for var once at the beginning and then
> > assigns it on any subsequent iterations.
>
> Ruby:
>
> flist = []
> 3.times{|i| flist << proc{|x| x * i}}
> flist.map{|pr| pr[2]}
> ==> [0, 2, 4]
Brain damage:
You have it.
On Oct 25, 10:13 am, Lars Rune Nøstdal <···········@gmail.com> wrote:
> On Sat, 2008-10-25 at 14:05 +0000, William James wrote:
> > Ruby:
>
> > flist = []
> > 3.times{|i| flist << proc{|x| x * i}}
> > flist.map{|pr| pr[2]}
> > ==> [0, 2, 4]
>
> Brain damage:
> You have it.
*Shrug* I don't mind seeing Ruby examples. The attitude I could do
without, but the examples by themselves are fine -- and that's all he
posted this time.
-- Scott
On Mon, 2008-10-27 at 11:13 -0700, Scott Burson wrote:
> On Oct 25, 10:13 am, Lars Rune Nøstdal <···········@gmail.com> wrote:
> > On Sat, 2008-10-25 at 14:05 +0000, William James wrote:
> > > Ruby:
> >
> > > flist = []
> > > 3.times{|i| flist << proc{|x| x * i}}
> > > flist.map{|pr| pr[2]}
> > > ==> [0, 2, 4]
> >
> > Brain damage:
> > You have it.
>
> *Shrug* I don't mind seeing Ruby examples. The attitude I could do
> without,
..it's there.
> but the examples by themselves are fine
No, they do not show anything of real interest/value. See the "it's
there" part mentioned above.
> -- and that's all he posted this time.
From: Javier
Subject: Re: Lexical closures - difference between Common Lisp and Scheme
Date:
Message-ID: <ge4auc$hn$1@aioe.org>
On Sat, 25 Oct 2008 19:13:34 +0200, Lars Rune Nøstdal wrote:
>> Ruby:
>>
>> flist = []
>> 3.times{|i| flist << proc{|x| x * i}} flist.map{|pr| pr[2]}
>> ==> [0, 2, 4]
>
> Brain damage:
> You have it.
The true is that for this kind of things, Ruby is more concise and easier.
Anyway, it is off topic here. ;)
Javier wrote:
> On Sat, 25 Oct 2008 19:13:34 +0200, Lars Rune Nøstdal wrote:
>
>>> Ruby:
>>>
>>> flist = []
>>> 3.times{|i| flist << proc{|x| x * i}} flist.map{|pr| pr[2]}
>>> ==> [0, 2, 4]
>> Brain damage:
>> You have it.
>
> The true is that for this kind of things, Ruby is more concise and easier.
Ruby makes trivial operations cryptic (what you call "more concise"),
and serrious programming harder.
Try for example to pass two or more anonymous functions to the same
function.
(defun compute-and-report (seq compute report)
(map nil (lambda (x) (let ((r (funcall compute x)))
(funcall report x)
r)) seq))
(compute-and-report '(1 2 3)
(lambda (x) (* x x))
(lambda (x) (princ x) (terpri)))
Ruby?
> Anyway, it is off topic here. ;)
--
__Pascal Bourguignon__
http://www.informatimago.com
From: Javier
Subject: Re: Lexical closures - difference between Common Lisp and Scheme
Date:
Message-ID: <ge4sog$93i$1@aioe.org>
Pascal Bourguignon escribió:
> Ruby makes trivial operations cryptic (what you call "more concise"),
> and serrious programming harder.
>
> Try for example to pass two or more anonymous functions to the same
> function.
>
> (defun compute-and-report (seq compute report)
> (map nil (lambda (x) (let ((r (funcall compute x)))
> (funcall report x)
> r)) seq))
>
> (compute-and-report '(1 2 3)
> (lambda (x) (* x x))
> (lambda (x) (princ x) (terpri)))
>
> Ruby?
def compute_and_report seq, compute, report
seq.map { |x|
compute.call(x)
report.call(x)
}
end
compute_and_report [1,2,3], lambda {|x| x*x}, lambda {|x| puts x}
Very nice, isn't it? :-)
From: Pascal Bourguignon
Subject: Re: Lexical closures - difference between Common Lisp and Scheme
Date:
Message-ID: <49061726$0$6840$426a74cc@news.free.fr>
Javier wrote:
> Pascal Bourguignon escribió:
>
>> Ruby makes trivial operations cryptic (what you call "more concise"),
>> and serrious programming harder.
>>
>> Try for example to pass two or more anonymous functions to the same
>> function.
>>
>> (defun compute-and-report (seq compute report)
>> (map nil (lambda (x) (let ((r (funcall compute x)))
>> (funcall report x)
>> r)) seq))
>>
>> (compute-and-report '(1 2 3)
>> (lambda (x) (* x x))
>> (lambda (x) (princ x) (terpri)))
>>
>> Ruby?
>
>
> def compute_and_report seq, compute, report
> seq.map { |x|
> compute.call(x)
> report.call(x)
> }
> end
>
> compute_and_report [1,2,3], lambda {|x| x*x}, lambda {|x| puts x}
Ok. I only knew block passing. I'm happy to learn there's also lambda.
> Very nice, isn't it? :-)
No, it's not nice. Having to use different characters for the same thing
(grouping) is barbaric. Why use [], {}, ||, and () when just () is
enough? Having to use commas is barbaric! OO is nice but it is not the
only paradigm, so having to use always (o . m(p)) syntax is barbaric,
compared to the more general (m o p) syntax. Etc.
It's not MatzLisp, it's Matzacred Lisp!
--
__Pascal Bourguignon__
http://www.informatimago.com
From: Javier
Subject: Re: Lexical closures - difference between Common Lisp and Ruby
Date:
Message-ID: <ge58a7$nq7$1@aioe.org>
Pascal Bourguignon escribió:
>> def compute_and_report seq, compute, report
>> seq.map { |x|
>> compute.call(x)
>> report.call(x)
>> }
>> end
>>
>> compute_and_report [1,2,3], lambda {|x| x*x}, lambda {|x| puts x}
>
> Ok. I only knew block passing. I'm happy to learn there's also lambda.
>
>
>> Very nice, isn't it? :-)
>
> No, it's not nice. Having to use different characters for the same thing
> (grouping) is barbaric.
You're exaggerating a bit, don't you? Barbaric?
> Why use [], {}, ||, and () when just () is
> enough?
There are two ways: using differents symbols, and then the code is
clean, or constantly repeat (), so you need to learn not only when to
correctly insert (), but also its order, indentation, and more, for example:
(defun foo (param1 param2)
(lambda (x)
(let ((r (* (car param1) (car param2))))
....)))
compared to:
def foo param1, param2
lambda do |x|
r=param1*param2
...
end
end
It is clearer to sight, and clearer to read.
> Having to use commas is barbaric!
why?
> OO is nice but it is not the
> only paradigm, so having to use always (o . m(p)) syntax is barbaric,
o.m p
very simple ;)
> compared to the more general (m o p) syntax. Etc.
You can get used to (m o p), but it is not natural. Human language has
not been evolutioned that way.
Again, you can get used, but is not natural.
An evidence of this, is that it is difficult to read a program in Lisp
if it is not correctly indexed, for example:
(defun foo (param1 param2) (lambda (x) (let ((r (* (car param1) (car
param2)))))))
def foo param1, param2; lambda {|x| r=param1*param2}; end
As you can see, it is much more verbose in Lisp, even writing exactly
the same symbol names.
And this is just a very simple example...
> It's not MatzLisp, it's Matzacred Lisp!
From: Kaz Kylheku
Subject: Re: Lexical closures - difference between Common Lisp and Ruby
Date:
Message-ID: <20081027203534.964@gmail.com>
On 2008-10-27, Javier <······@askmyadress.com> wrote:
> (defun foo (param1 param2)
> (lambda (x)
> (let ((r (* (car param1) (car param2))))
> ....)))
>
> compared to:
>
> def foo param1, param2
This is wrong, because the comma has tighter binding than symbol justaposition,
which flies in the face of how comma is used in plain writing, in mathematics
and in most sanely designed programming languages.
> lambda do |x|
> r=param1*param2
> ...
> end
> end
The designer was groping for this:
def foo (param1, param2) {
lambda do (x) {
r = param1 * param2
}
}
Ah, that's waaaaay better! Problem is, it's not ``different''.
This kind of syntax won't attract people who think that semantic innovation
rests in novel syntax.
On Mon, 27 Oct 2008 21:28:50 +0100, Javier <······@askmyadress.com>
wrote:
>o.m p
>very simple ;)
>
>> compared to the more general (m o p) syntax. Etc.
>
>You can get used to (m o p), but it is not natural.
Which seems more "natural" likely depends on your native language.
>Human language has not been evolutioned that way.
Wrong. It has repeatedly evolved that way. And judging by your name,
your native language is most likely SVO which would make placing the
verb first seem more natural.
See the series of Wikipedia articles:
http://en.wikipedia.org/wiki/Subject_Verb_Object
http://en.wikipedia.org/wiki/Subject_Object_Verb
:
In any case, computer languages are artificial and are not spoken[*],
so the designers can do whatever they please wrt grammar and syntax.
For users choosing a language, it's a matter of familiarity and
preference.
[*] but occasionally sung. See Steven Levy, "Hackers: Heroes of the
Computer Revolution".
George
From: Matthias Buelow
Subject: Re: Lexical closures - difference between Common Lisp and Ruby
Date:
Message-ID: <6mpa44Fhrnn1U1@mid.dfncis.de>
> (defun foo (param1 param2)
> (lambda (x)
> (let ((r (* (car param1) (car param2))))
> ....)))
>
> compared to:
>
> def foo param1, param2
> lambda do |x|
> r=param1*param2
> ...
> end
> end
>
> It is clearer to sight, and clearer to read.
Without the first snippet, I wouldn't know what the second one is
supposed to mean. For example, what does "do" and |x| mean?
Note: I don't know Ruby.
From: Javier
Subject: Re: Lexical closures - difference between Common Lisp and Ruby
Date:
Message-ID: <ge7tc1$vft$1@aioe.org>
Matthias Buelow escribió:
>> (defun foo (param1 param2)
>> (lambda (x)
>> (let ((r (* (car param1) (car param2))))
>> ....)))
>>
>> compared to:
>>
>> def foo param1, param2
>> lambda do |x|
>> r=param1*param2
>> ...
>> end
>> end
>>
>> It is clearer to sight, and clearer to read.
>
> Without the first snippet, I wouldn't know what the second one is
> supposed to mean. For example, what does "do" and |x| mean?
>
> Note: I don't know Ruby.
do...end means the same as {} it is just a delimiter
|x| means a list of params, x being the only one in this case
From: Kaz Kylheku
Subject: Re: Lexical closures - difference between Common Lisp and Ruby
Date:
Message-ID: <20081028165858.250@gmail.com>
On 2008-10-28, Javier <······@askmyadress.com> wrote:
> Matthias Buelow escribi�:
>>> (defun foo (param1 param2)
>>> (lambda (x)
>>> (let ((r (* (car param1) (car param2))))
>>> ....)))
>>>
>>> compared to:
>>>
>>> def foo param1, param2
>>> lambda do |x|
>>> r=param1*param2
>>> ...
>>> end
>>> end
>>>
>>> It is clearer to sight, and clearer to read.
>>
>> Without the first snippet, I wouldn't know what the second one is
>> supposed to mean. For example, what does "do" and |x| mean?
>>
>> Note: I don't know Ruby.
>
> do...end means the same as {} it is just a delimiter
There should only be one way of delimiting, not two.
Can you cite the functional requirement which is served by having
do ... end as well as { } ?
>|x| means a list of params, x being the only one in this case
But lists use square brackets like [1, 2, 3], don't they?
What if I want to operate on a list of params |x, y, z|?
Can I pass |x, y, z| to a list processing function?
If not, how do I convert |x, y, z| to [x, y, z]?
Wont' that evaluate the x, y, and z? I want the symbols x, y, and z themselves
to be in the list, not their values!
From: Brian Adkins
Subject: Re: Lexical closures - difference between Common Lisp and Ruby
Date:
Message-ID: <m2d4hkw8iy.fsf@gmail.com>
Kaz Kylheku <········@gmail.com> writes:
>
> There should only be one way of delimiting, not two.
>
> Can you cite the functional requirement which is served by having
> do ... end as well as { } ?
>
>>|x| means a list of params, x being the only one in this case
>
> But lists use square brackets like [1, 2, 3], don't they?
>
> What if I want to operate on a list of params |x, y, z|?
>
> Can I pass |x, y, z| to a list processing function?
>
> If not, how do I convert |x, y, z| to [x, y, z]?
~$ irb
irb(main):001:0> *t = 1,2,3
=> [1, 2, 3]
irb(main):002:0> t
=> [1, 2, 3]
irb(main):003:0> x,y,z = t
=> [1, 2, 3]
irb(main):004:0> x
=> 1
irb(main):005:0> y
=> 2
irb(main):006:0> z
=> 3
irb(main):007:0> foo = lambda {|*t| t.each {|e| puts e } }
=> #<···············@(irb):7>
irb(main):008:0> foo.call(1,2,3)
1
2
3
=> [1, 2, 3]
>
> Wont' that evaluate the x, y, and z? I want the symbols x, y, and z themselves
> to be in the list, not their values!
Brian Adkins wrote:
> Kaz Kylheku <········@gmail.com> writes:
>>> |x| means a list of params, x being the only one in this case
>> But lists use square brackets like [1, 2, 3], don't they?
>>
>> What if I want to operate on a list of params |x, y, z|?
>>
>> Can I pass |x, y, z| to a list processing function?
>>
>> If not, how do I convert |x, y, z| to [x, y, z]?
>
> ~$ irb
> irb(main):001:0> *t = 1,2,3
> => [1, 2, 3]
You've not answered to the question.
How do we convert |...| to [...] ?
What you wrote is equivalent to:
(multiple-value-setq temp (values 1 2 3))
which has nothing to do with (x y z) in (lambda (x y z) ...).
> irb(main):003:0> x,y,z = t
> => [1, 2, 3]
This is equivalent to (setf (values x y z) (values-list temp))
which agains has nothing to do with (x y z) in (lambda (x y z) ...).
> irb(main):004:0> x
> => 1
This is ludicruluous. You just don't have the neurons to understand
what we are talking about in cll. Please learn about lisp first!
> irb(main):007:0> foo = lambda {|*t| t.each {|e| puts e } }
> => #<···············@(irb):7>
> irb(main):008:0> foo.call(1,2,3)
> 1
> 2
> 3
> => [1, 2, 3]
That is not the question.
>> Wont' that evaluate the x, y, and z? I want the symbols x, y, and z themselves
>> to be in the list, not their values!
Symbols in Ruby are noted as :symbol. It's not homoiconic.
There is a Ruby parser called ParseTree, that will produce a, let's call
it r-exp, arrays of symbols and other atoms:
irb(main):001:0> require 'ParseTree'
LoadError: no such file to load -- ParseTree
from (irb):1:in `require'
from (irb):1
irb(main):002:0> require 'parsetree'
LoadError: no such file to load -- parsetree
from (irb):2:in `require'
from (irb):2
from :0
irb(main):003:0> require 'parse_tree'
true
irb(main):004:0> (ParseTree . translate("(lambda { | x , y , z | ((3 *
x) + (2 * y) + z) })"))
[:iter, [:fcall, :lambda], [:masgn, [:array, [:dasgn_curr, :x],
[:dasgn_curr, :y], [:dasgn_curr, :z]]], [:call, [:call, [:call, [:lit,
3], :*, [:array, [:dvar, :x]]], :+, [:array, [:call, [:lit, 2], :*,
[:array, [:dvar, :y]]]]], :+, [:array, [:dvar, :z]]]]
irb(main):005:0>
This parser is implemented like Ruby in C (it scavenges parts of the
original Ruby parser) and is imported in ruby as an external module.
Of course, theoricaly, it would be possible to implement a Ruby parser
in Ruby, but since there's no standard to specify the syntax of Ruby...
Anyways, using these r-expressions is visibly harder than using
s-expressions, given they're arrays, and given the syntactic baggage of
Ruby, compared to the simple lists of lisp...
And there's no way to get back code from these arrays than to generate a
string containing some Ruby source, and having it parsed again and
executed by Kernel.eval.
Also, you cannot have symbols randomly named, the symbol name must be a
Ruby token, so you cannot write:
[:+-,"Plus or minus"]
since +- is not a Ruby token.
In conclusion, Ruby is basically useless, you will have to Greenspun
100% to do anything interesting.
--
__Pascal Bourguignon__
http://www.informatimago.com
From: Javier
Subject: Re: Lexical closures - difference between Common Lisp and Ruby
Date:
Message-ID: <gea1r9$tmh$1@aioe.org>
Pascal Bourguignon escribi�:
> Brian Adkins wrote:
>> Kaz Kylheku <········@gmail.com> writes:
>>>> |x| means a list of params, x being the only one in this case
>>> But lists use square brackets like [1, 2, 3], don't they?
>>>
>>> What if I want to operate on a list of params |x, y, z|?
>>>
>>> Can I pass |x, y, z| to a list processing function?
>>>
>>> If not, how do I convert |x, y, z| to [x, y, z]?
>>
>> ~$ irb
>> irb(main):001:0> *t = 1,2,3
>> => [1, 2, 3]
>
> You've not answered to the question.
> How do we convert |...| to [...] ?
t = lambda { |x,y,z| [x,y,z] }
which is stupid, because you have to do:
t.call(1,2,3)
=> [1,2,3]
Better doing, directly:
t = [1,2,3]
> What you wrote is equivalent to:
>
> (multiple-value-setq temp (values 1 2 3))
ERROR
Vars is not a list of symbols: TEMP
[Condition of type SIMPLE-ERROR]
Restarts:
0: [ABORT] Return to SLIME's top level.
1: [TERMINATE-THREAD] Terminate this thread (#<THREAD "repl-thread"
RUNNING {BD2A539}>)
Learn Lisp before writing barbaries like that.
> which has nothing to do with (x y z) in (lambda (x y z) ...).
(x y z), in Lisp, means a list of paremters, exactly the same as |x, y,
z| in Ruby. What part yo do not understand?
>> irb(main):003:0> x,y,z = t
>> => [1, 2, 3]
>
> This is equivalent to (setf (values x y z) (values-list temp))
> which agains has nothing to do with (x y z) in (lambda (x y z) ...).
(lambda (x y z) ...) = lambda { |x,y,z| ... }
right?
> This is ludicruluous. You just don't have the neurons to understand
> what we are talking about in cll. Please learn about lisp first!
Do you understan something, anyway?
Look your favorite book for the differences between data and code. In
Lisp, the same as in Ruby, if you want to convert a list params into a
list, you must have first a list of params!!
In Lisp, (x y z) is not the same in these sitiations:
(lambda (x y z) ...) ; (x y z) is a list of parameters
'(x y z) ; (x y z) is a list of symbols
(list 'x 'y 'z) ; another way to construct a list
So, in the first example, (x y z) is a lambda-list, which is
definitivaly not the same as a regular list! Even, it has different
syntax (you have to add ' or use the 'list' form).
>> irb(main):007:0> foo = lambda {|*t| t.each {|e| puts e } }
>> => #<···············@(irb):7>
>> irb(main):008:0> foo.call(1,2,3)
>> 1
>> 2
>> 3
>> => [1, 2, 3]
>
> That is not the question.
You don't even know what the question is.
> There is a Ruby parser called ParseTree, [...]
Better to remove this shit. We will do like if we din't read it.
From: Matthias Buelow
Subject: Re: Lexical closures - difference between Common Lisp and Ruby
Date:
Message-ID: <6mrltvFi4rifU1@mid.dfncis.de>
Javier wrote:
> So, in the first example, (x y z) is a lambda-list, which is
> definitivaly not the same as a regular list! Even, it has different
> syntax (you have to add ' or use the 'list' form).
> (listp (cadr '(lambda (x y z))))
T
From: Javier
Subject: Re: Lexical closures - difference between Common Lisp and Ruby
Date:
Message-ID: <geaabb$2eb$1@aioe.org>
Matthias Buelow escribi�:
> Javier wrote:
>
>> So, in the first example, (x y z) is a lambda-list, which is
>> definitivaly not the same as a regular list! Even, it has different
>> syntax (you have to add ' or use the 'list' form).
>
>> (listp (cadr '(lambda (x y z))))
> T
'(lambda (x y z))
is not
(lambda (x y z))
CL-USER> (listp (cadr (lambda (x y z))))
ERROR
The value #<FUNCTION (LAMBDA #) {AF2C64D}> is not of type LIST.
[Condition of type TYPE-ERROR]
Restarts:
0: [ABORT] Return to SLIME's top level.
1: [TERMINATE-THREAD] Terminate this thread (#<THREAD "repl-thread"
RUNNING {A881D61}>)
No even means equivalent things, although it seems. The small ' makes a
very very big difference.
Equally, in Ruby:
lambda {|x,y,z|}
is absolutely not the same as
"lambda {|x,y,z|}"
On Wed, 2008-10-29 at 19:34 +0100, Javier wrote:
> '(lambda (x y z))
>
> is not
>
> (lambda (x y z))
"1234"
is not
1234
..ET phone home? :}
(defmacro houston-we-have-a-problem (x y)
`(+ ,(parse-integer x)
,(parse-integer y)))
> (houston-we-have-a-problem "1234" "4321")
5555
SW> (macroexpand-1 '(houston-we-have-a-problem "1234" "4321"))
(+ 1234 4321)
T
> (numberp (second (macroexpand-1 '(houston-we-have-a-problem "1234"
"4321"))))
T
> (numberp (third (macroexpand-1 '(houston-we-have-a-problem "1234"
"4321"))))
T
> (numberp (second '(houston-we-have-a-problem "1234" "4321")))
NIL
> (numberp (third '(houston-we-have-a-problem "1234" "4321")))
NIL
..how did this happen? Can we do this with lists also? What are lists?
What is code? What is data? What is functions applied to data (or
code?????).
From: Matthias Buelow
Subject: Re: Lexical closures - difference between Common Lisp and Ruby
Date:
Message-ID: <6mrq5pFif8v7U1@mid.dfncis.de>
Javier wrote:
> Matthias Buelow escribi�:
>> Javier wrote:
>>
>>> So, in the first example, (x y z) is a lambda-list, which is
>>> definitivaly not the same as a regular list! Even, it has different
>>> syntax (you have to add ' or use the 'list' form).
>>
>>> (listp (cadr '(lambda (x y z))))
>> T
>
> '(lambda (x y z))
>
> is not
>
> (lambda (x y z))
No?
(equal '(lambda (x y z))
(read-from-string "(lambda (x y z))"))
-> T
What you probably mean is:
(equal (eval '(lambda (x y z)))
(eval ''(lambda (x y z))))
-> NIL
But that is not relevant to the discussion if (x y z) in the lambda
expression above is represented a list (or not, as you claim).
Javier wrote:
> Pascal Bourguignon escribi�:
>> Brian Adkins wrote:
>>> Kaz Kylheku <········@gmail.com> writes:
>>>>> |x| means a list of params, x being the only one in this case
>>>> But lists use square brackets like [1, 2, 3], don't they?
>>>>
>>>> What if I want to operate on a list of params |x, y, z|?
>>>>
>>>> Can I pass |x, y, z| to a list processing function?
>>>>
>>>> If not, how do I convert |x, y, z| to [x, y, z]?
>>>
>>> ~$ irb
>>> irb(main):001:0> *t = 1,2,3
>>> => [1, 2, 3]
>>
>> You've not answered to the question.
>> How do we convert |...| to [...] ?
>
> t = lambda { |x,y,z| [x,y,z] }
You still don't understand. What you write here is equivalent to:
(setf temp (lambda (x y z) (vector x y z)))
It has nothing to do with what was asked.
What we want, is to some how get |x, y, z| in some source, and process
it as some data.
For example, in Lisp, we could define this function:
(defun complexify (lambda-form)
(destructuring-bind (lambda arguments expression) lambda-form
(let* ((pairs (mapcar (lambda (arg)
(list arg (intern (format nil "~A*"
arg))))
arguments))
(complexes (mapcar (lambda (pair) (cons 'complex pair))
pairs))
(complexargs (reduce (function append) pairs))
(bindings (mapcar (lambda (pair complex)
(list (first pair) complex)) pairs
complexes)))
`(lambda ,complexargs (let ,bindings ,expression)))))
C/USER[8]> (complexify '(lambda (x y z) (+ (* 3 x) (* 2 y) z)))
(LAMBDA (X X* Y Y* Z Z*)
(LET ((X (COMPLEX X X*))
(Y (COMPLEX Y Y*))
(Z (COMPLEX Z Z*)))
(+ (* 3 X) (* 2 Y) Z)))
C/USER[9]> (funcall (compile nil (complexify '(lambda (x y z)
(+ (* 3 x) (* 2 y) z))))
1 10 2 20 3 30)
#C(10 100)
C/USER[10]>
Notice how (lambda (x y z) (+ (* 3 x) (* 2 y) z)) is both code and data.
>> What you wrote is equivalent to:
>>
>> (multiple-value-setq temp (values 1 2 3))
>
> ERROR
> [...]
> Learn Lisp before writing barbaries like that.
Yes, sorry, I typed without checking in the REPL.
I meant:
(setf temp (multiple-value-list (values 1 2 3)))
>> which has nothing to do with (x y z) in (lambda (x y z) ...).
>
> (x y z), in Lisp, means a list of paremters, exactly the same as |x, y,
> z| in Ruby. What part yo do not understand?
It's you who is not understanding. Yes, (x y z) is a list of
parameters. But it is also a list of three symbols that can be
processed by lisp programs. |x y y| cannot be processed by Ruby
programs. Se the example above!
>>> irb(main):003:0> x,y,z = t
>>> => [1, 2, 3]
>>
>> This is equivalent to (setf (values x y z) (values-list temp))
>> which agains has nothing to do with (x y z) in (lambda (x y z) ...).
>
> (lambda (x y z) ...) = lambda { |x,y,z| ... }
>
> right?
No, wrong.
You are forgetting half of what (lambda (x y z) ...) is.
See the example above.
>> This is ludicruluous. You just don't have the neurons to understand
>> what we are talking about in cll. Please learn about lisp first!
>
> Do you understan something, anyway?
> Look your favorite book for the differences between data and code. In
> Lisp, the same as in Ruby, if you want to convert a list params into a
> list, you must have first a list of params!!
This is not what we're discussing.
> In Lisp, (x y z) is not the same in these sitiations:
>
> (lambda (x y z) ...) ; (x y z) is a list of parameters
> '(x y z) ; (x y z) is a list of symbols
> (list 'x 'y 'z) ; another way to construct a list
A list of parameter is a list of symbol (without taking into
consideration the complex forms of lambda lists).
C/USER[21]> (with-open-file (out "/tmp/file.lisp" :direction :output)
(print '(setf f (lambda (x y z) (list x x y y z z))) out))
(SETF F (LAMBDA (X Y Z) (LIST X X Y Y Z Z)))
C/USER[22]> (load "/tmp/file.lisp")
;; Loading file /tmp/file.lisp ...
;; Loaded file /tmp/file.lisp
T
C/USER[23]> (funcall f 1 2 3)
(1 1 2 2 3 3)
C/USER[24]> (setf f (with-open-file (in "/tmp/file.lisp") (read in)))
(SETF F (LAMBDA (X Y Z) (LIST X X Y Y Z Z)))
C/USER[25]> (second (third f))
(X Y Z)
> So, in the first example, (x y z) is a lambda-list, which is
> definitivaly not the same as a regular list! Even, it has different
> syntax (you have to add ' or use the 'list' form).
C/USER[29]> (second (function-lambda-expression (lambda (x y z) (vector
x y z))))
(X Y Z)
C/USER[30]> (second (second (function-lambda-expression (lambda (x y z)
(vector x y z)))))
Y
C/USER[31]>
>> There is a Ruby parser called ParseTree, [...]
>
> Better to remove this shit. We will do like if we din't read it.
I agree, Ruby is full of what you say.
--
__Pascal Bourguignon__
http://www.informatimago.com
From: Javier
Subject: Re: Lexical closures - difference between Common Lisp and Ruby
Date:
Message-ID: <geadal$f3g$1@aioe.org>
Pascal Bourguignon escribi�:
>>> You've not answered to the question.
>>> How do we convert |...| to [...] ?
>>
>> t = lambda { |x,y,z| [x,y,z] }
>
> You still don't understand. What you write here is equivalent to:
>
> (setf temp (lambda (x y z) (vector x y z)))
>
> It has nothing to do with what was asked.
>
> What we want, is to some how get |x, y, z| in some source, and process
> it as some data.
No, you asked exactly:
>>> How do we convert |...| to [...] ?
That is, how to convert a list of params into a list of data. And my
answer was correct.
> For example, in Lisp, we could define this function:
>
> (defun complexify (lambda-form)
> (destructuring-bind (lambda arguments expression) lambda-form
> (let* ((pairs (mapcar (lambda (arg)
> (list arg (intern (format nil "~A*"
> arg))))
> arguments))
> (complexes (mapcar (lambda (pair) (cons 'complex pair))
> pairs))
> (complexargs (reduce (function append) pairs))
> (bindings (mapcar (lambda (pair complex)
> (list (first pair) complex)) pairs
> complexes)))
> `(lambda ,complexargs (let ,bindings ,expression)))))
I'm not going to convert this into Ruby, but look at the example bellow.
The only difference is that you convert a quoted list:
> C/USER[8]> (complexify '(lambda (x y z) (+ (* 3 x) (* 2 y) z)))
do you see that '?
and I do convert it using a string.
> Notice how (lambda (x y z) (+ (* 3 x) (* 2 y) z)) is both code and data.
def your_stupid_code_as_data_in_ruby my_arg_list
eval "$a = lambda {|" + my_arg_list + "|}"
end
your_stupid_code_as_data_in_ruby "x,y,z"
puts $a
=> #<··············@(eval):1 (lambda)>
Note how |x,y,z| can be both data and code, and fucked up until your
brain exploits. I don't actually want to do such a thing, because I
DON'T NEED TO. What I'm trying to say you is that Ruby already has all
the constructors you need. There is no need to fuck up the language to
create some new weird language.
But even if you want to create that new weird language, you use the ruby
parser. The Ruby parser is intended for that, not for tweaking the language.
>> (x y z), in Lisp, means a list of paremters, exactly the same as |x,
>> y, z| in Ruby. What part yo do not understand?
>
> It's you who is not understanding. Yes, (x y z) is a list of
> parameters. But it is also a list of three symbols that can be
> processed by lisp programs. |x y y| cannot be processed by Ruby
> programs. Se the example above!
No,
(x y z)
is not the same as
'(x y z)
And no,
|x,y,z|
CAN be processed by Ruby programs.
>>>> irb(main):003:0> x,y,z = t
>>>> => [1, 2, 3]
>>>
>>> This is equivalent to (setf (values x y z) (values-list temp))
>>> which agains has nothing to do with (x y z) in (lambda (x y z) ...).
>>
>> (lambda (x y z) ...) = lambda { |x,y,z| ... }
>>
>> right?
>
> No, wrong.
>
> You are forgetting half of what (lambda (x y z) ...) is.
> See the example above.
Again, no.
'(lambda (x y z))
is not the same as
(lambda (x y z))
In fact, '(lambda (x y z)) is more similar to '(I am tired of this shit)
than to (lambda (x y z)).
> A list of parameter is a list of symbol (without taking into
> consideration the complex forms of lambda lists).
No. A list of parameters is a list of parameters.
A list of symbols is a list of symbols.
And this, regardless of the fact that you can transform a list of
symbols into code.
>>> There is a Ruby parser called ParseTree, [...]
>>
>> Better to remove this shit. We will do like if we din't read it.
>
> I agree, Ruby is full of what you say.
You can create code in real time and execute with eval.
The shit you have put, is for creating new languages. It is a full
featured parser. Note that you have to program your own parser in Lisp
if you pretend to use any other syntax that is very different to the
Lisp one.
But we are entering into the world of macros. Don't do that. Ruby is not
intended to have macros.
Just get the job done.
From: Matthias Buelow
Subject: Re: Lexical closures - difference between Common Lisp and Ruby
Date:
Message-ID: <6mrvk8Fip14eU1@mid.dfncis.de>
Javier wrote:
> No. A list of parameters is a list of parameters.
> A list of symbols is a list of symbols.
Ah, by now you admit already it's a list? You've been denying that so
far. Well, almost there. Now type into your favourite Lisp prompt
(actually cut&paste should work, too, if you're using something like xterm):
(listp (cadr (read)))
(lambda (x y z))
and look at the result. Fine, it's a list, all right, you just said so
yourself. Ok, next:
(symbolp (caadr (read)))
(lambda (x y z))
There is no such thing as a "list of parameters", it's symbols all the
way down.
From: Javier
Subject: Re: Lexical closures - difference between Common Lisp and Ruby
Date:
Message-ID: <geahri$vf8$1@aioe.org>
Matthias Buelow escribi�:
> Javier wrote:
>
>> No. A list of parameters is a list of parameters.
>> A list of symbols is a list of symbols.
>
> Ah, by now you admit already it's a list? You've been denying that so
> far. Well, almost there. Now type into your favourite Lisp prompt
> (actually cut&paste should work, too, if you're using something like xterm):
>
> (listp (cadr (read)))
> (lambda (x y z))
>
> and look at the result. Fine, it's a list, all right, you just said so
> yourself. Ok, next:
>
> (symbolp (caadr (read)))
> (lambda (x y z))
>
> There is no such thing as a "list of parameters", it's symbols all the
> way down.
Why don't you do
(cadr (lambda(x y z))
(symbolp (lambda (x y z)))
From: Matthias Buelow
Subject: Re: Lexical closures - difference between Common Lisp and Ruby
Date:
Message-ID: <6mtj5uFis80gU1@mid.dfncis.de>
Javier wrote:
> Why don't you do
>
> (cadr (lambda(x y z))
>
> (symbolp (lambda (x y z)))
'cause lisp is using call-by-value and cadr and symbolp are functions
and thus get the closure constructed from evaluating the lambda
expression, whereas we're interested in the actual expression, not what
it transforms to if you shove it through eval.
It's like saying (+ 1 2) isn't a list but 3. If you type (+ 1 2) into
read, it returns a list. Same with (lambda (x y z)).
Javier wrote:
> You can create code in real time and execute with eval.
But it's harder and much more dangerous to do with strings than with
s-exprs.
> The shit you have put, is for creating new languages.
Indeed. That's what we do with Lisp.
> It is a full featured parser.
> Note that you have to program your own parser in Lisp
> if you pretend to use any other syntax that is very different to the
> Lisp one.
You still have to learn. For example, the difference between a scanner
and a parser.
We didn't write any bit of a parser, just code to manipulate an already
parsed syntactic tree (represented as s-exprs), and if we needed to
introduce a slightly different syntax, we could implement it with reader
macros.
> But we are entering into the world of macros. Don't do that.
Yes, this is what we do in lisp and what we discuss in c.l.l.
> Ruby is not intended to have macros.
Thank you. That's all you had to say.
> Just get the job done.
Small toys.
--
__Pascal Bourguignon__
http://www.informatimago.com
From: Kaz Kylheku
Subject: Re: Lexical closures - difference between Common Lisp and Ruby
Date:
Message-ID: <20081029123527.361@gmail.com>
On 2008-10-29, Javier <······@askmyadress.com> wrote:
> Pascal Bourguignon escribi�:
>> Brian Adkins wrote:
>>> Kaz Kylheku <········@gmail.com> writes:
>>>>> |x| means a list of params, x being the only one in this case
>>>> But lists use square brackets like [1, 2, 3], don't they?
>>>>
>>>> What if I want to operate on a list of params |x, y, z|?
>>>>
>>>> Can I pass |x, y, z| to a list processing function?
>>>>
>>>> If not, how do I convert |x, y, z| to [x, y, z]?
>>>
>>> ~$ irb
>>> irb(main):001:0> *t = 1,2,3
>>> => [1, 2, 3]
>>
>> You've not answered to the question.
>> How do we convert |...| to [...] ?
>
> t = lambda { |x,y,z| [x,y,z] }
That's not a conversion of the argument list itself. You're using the argument
list to capture values.
> which is stupid, because you have to do:
No, you're stupid. You don't even understand the question!
> t.call(1,2,3)
>=> [1,2,3]
>
> Better doing, directly:
>
> t = [1,2,3]
No, I think what we want is to take this lambda object:
lambda { |x, y, z| ... }
(Are you following this so far? We have a lambda entity, and this entity has
something called a parameter list).
Now I want to retrieve the parameter list.
Something like:
lambda { |x, y, z| ... }.quote.param_list
-> |x, y, z|
quote gives me the syntax tree of the lambda, instead of the function-object,
and param_list accesses the param list part of it.
And I don't want to see it printed like this [:x, :y, :z]!
If that'st he case, then I also expect the reverse consistency:
lambda { [:x, :y, :z] ... ]
does this work in Ruby? It should! Because a parameter list is a list of
symbols, and [ :x, :y, :z ] is how you write a list of symbols.
>
> (lambda (x y z) ...) = lambda { |x,y,z| ... }
>
> right?
Right. Okay, so now:
(first '(lambda (x y z) ...)) -> (X Y Z)
(first (first '(lambda (x y z) ...))) -> X
>
>> This is ludicruluous. You just don't have the neurons to understand
>> what we are talking about in cll. Please learn about lisp first!
>
> Do you understan something, anyway?
> Look your favorite book for the differences between data and code. In
> Lisp, the same as in Ruby, if you want to convert a list params into a
> list, you must have first a list of params!!
> In Lisp, (x y z) is not the same in these sitiations:
>
> (lambda (x y z) ...) ; (x y z) is a list of parameters
> '(x y z) ; (x y z) is a list of symbols
> (list 'x 'y 'z) ; another way to construct a list
It's the same in all these situations. Lisp itself confirms it:
(equal (first '(lambda (x y z))) '(x y z)) -> T
(equal (list 'x 'y 'z) '(x y z)) -> T
> So, in the first example, (x y z) is a lambda-list, which is
> definitivaly not the same as a regular list!
Idiot, it's defintely the same as a regular list. Lisp terminology doesn't lie.
A lambda list is definitely a list. It's either NIL, or a CONS cell, etc.
> syntax (you have to add ' or use the 'list' form).
'X is just a shorthand for (QUOTE X). The apostrophe isn't part of the list
syntax, and can be applied to any object:
'4 -> 4
'"abc" -> "abc"
'(X Y Z) means (QUOTE (X Y Z)).
So you're saying that the (X Y Z) is somehow different in (QUOTE (X Y Z)) and
(LAMBDA (X Y Z)).
That's just stupid. Like you don't know the first thing about Lisp.
It would be a more productive use of comp.lang.lisp for you if you
were to ask for some kind of newbie help.
Of course, (X Y Z) has different semantics under evaluation in those two
constructs. That's something else; of course lists have all kinds of different
semantics under evaluation.
(defclass foo (x y z) ...) ;; list of superclasses
(quote (x y z)) ;; literal object
(let (x y z) ...) ;; list of variables
But the list (x y z) itself which denotes all these meanings is the same. It
has the same printed syntax in all situations, and the same internal
representation.
From: Javier
Subject: Re: Lexical closures - difference between Common Lisp and Ruby
Date:
Message-ID: <geaidm$3ds$1@aioe.org>
You are not right. Lists are not code, even if you can manipulate and
convert them into code.
Is this code? :
'(Kaz is a mother fucker)
No it is not. It is data.
And, in english, a fact.
Kaz Kylheku escribi�:
> Idiot,
Fuck you.
On 29 out, 13:17, Pascal Bourguignon <····@informatimago.com> wrote:
> Brian Adkins wrote:
> > irb(main):003:0> x,y,z = t
> > => [1, 2, 3]
>
> This is equivalent to (setf (values x y z) (values-list temp))
I have to say this example doesn't do much good for CL's side...
> Anyways, using these r-expressions is visibly harder than using
> s-expressions, given they're arrays, and given the syntactic baggage of
> Ruby, compared to the simple lists of lisp...
Your example doesn't really show that. On the contrary...
Ruby and Python have their value. At least on the syntax level...
namekuseijin wrote:
> On 29 out, 13:17, Pascal Bourguignon <····@informatimago.com> wrote:
>> Brian Adkins wrote:
>>> irb(main):003:0> x,y,z = t
>>> => [1, 2, 3]
>> This is equivalent to (setf (values x y z) (values-list temp))
>
> I have to say this example doesn't do much good for CL's side...
What do you mean?
(let ((form '(setf (values x y z) (values-list temp))))
(format t "Assigned variables: ~{~A~^, ~}~%" (rest (second form)))
(format t "List of values variable: ~A~%" (second (third form))))
Assigned variables: X, Y, Z
List of values variable: TEMP
Can you do anything similar as easily in Ruby?
This should make you understand why we like these parentheses and these
verbose operator names. The cake is big, but the icing is delicious!
>> Anyways, using these r-expressions is visibly harder than using
>> s-expressions, given they're arrays, and given the syntactic baggage of
>> Ruby, compared to the simple lists of lisp...
>
> Your example doesn't really show that. On the contrary...
>
> Ruby and Python have their value. At least on the syntax level...
bzip2 is good too.
--
__Pascal Bourguignon__
http://www.informatimago.com
From: Brian Adkins
Subject: Re: Lexical closures - difference between Common Lisp and Ruby
Date:
Message-ID: <m2fxmb1kmx.fsf@gmail.com>
Pascal Bourguignon <···@informatimago.com> writes:
> namekuseijin wrote:
>> On 29 out, 13:17, Pascal Bourguignon <····@informatimago.com> wrote:
>>> Brian Adkins wrote:
>>>> irb(main):003:0> x,y,z = t
>>>> => [1, 2, 3]
>>> This is equivalent to (setf (values x y z) (values-list temp))
>>
>> I have to say this example doesn't do much good for CL's side...
>
> What do you mean?
>
> (let ((form '(setf (values x y z) (values-list temp))))
> (format t "Assigned variables: ~{~A~^, ~}~%" (rest (second form)))
> (format t "List of values variable: ~A~%" (second (third form))))
>
> Assigned variables: X, Y, Z
> List of values variable: TEMP
>
> Can you do anything similar as easily in Ruby?
Nice. The extra power makes up for some verbosity IMO.
BTW - my reply earlier was simply showing the Ruby way to handle
transforming between lists (Array) and scalars in various ways; it
wasn't intended to answer your question which had more to do with
"code is data, data is code" - I should've stated so much, but was too
lazy.
I recognize the power of "code is data, data is code" and is a big
factor in why I'm a (mostly) lurker here and hope to carve out some
time to properly learn CL.
From: Javier
Subject: Re: Lexical closures - difference between Common Lisp and Ruby
Date:
Message-ID: <ge8ddp$s2a$1@aioe.org>
Kaz Kylheku escribi�:
>> do...end means the same as {} it is just a delimiter
>
> There should only be one way of delimiting, not two.
Why?
Please don't tell me because you don't want to remember it. For
everything you don't want to remember in Ruby, I can tell you at least
two I'm not able to remember in Lisp.
> Can you cite the functional requirement which is served by having
> do ... end as well as { } ?
Syntactic sugar. A perfect functional requirement.
>> |x| means a list of params, x being the only one in this case
>
> But lists use square brackets like [1, 2, 3], don't they?
Maybe, and maybe not. These expresions are equivalent:
*m = 7, "hello", :symbol
m = [7, "hello", :symbol]
> What if I want to operate on a list of params |x, y, z|?
Perfectly possible:
def my_proc *params
params.each { |p| puts p }
end
params 1,2,3,4,5,6, "hello", :symbol, 34343, 8.6
# => prints the argument passed
> Can I pass |x, y, z| to a list processing function?
Yes, as |x, y, z| is just [x,y,z] outside param declarations.
> If not, how do I convert |x, y, z| to [x, y, z]?
You don't need to.
> Wont' that evaluate the x, y, and z? I want the symbols x, y, and z themselves
> to be in the list, not their values!
Here you got the symbols, not their values:
[:x, :y, :z]
> puts [:x,:y,:z]
x
y
z
=> nil
As you can see, apart from macros and speed, it is hard to find anything
that Ruby can't do that Lisp can.
From: Raffael Cavallaro
Subject: Re: Lexical closures - difference between Common Lisp and Ruby
Date:
Message-ID: <ge8m65$oc1$1@aioe.org>
On 2008-10-28 21:14:28 -0400, Javier <······@askmyadress.com> said:
> As you can see, apart from macros and speed, it is hard to find
> anything that Ruby can't do that Lisp can.
So apart from being slow and profoundly crippled its a great language?
From: Kaz Kylheku
Subject: Re: Lexical closures - difference between Common Lisp and Ruby
Date:
Message-ID: <20081029013359.59@gmail.com>
On 2008-10-29, Raffael Cavallaro
<················@pas-d'espam-s'il-vous-plait-mac.com> wrote:
> On 2008-10-28 21:14:28 -0400, Javier <······@askmyadress.com> said:
>
>> As you can see, apart from macros and speed, it is hard to find
>> anything that Ruby can't do that Lisp can.
>
> So apart from being slow and profoundly crippled its a great language?
For a good laugh, check this out:
http://glyphobet.net/blog/essay/228
This is Ruby criticisms from a Python programmer's point of view.
Common Lisp doesn't have any of those issues:
Random snippets:
``Ruby did not have any support for Unicode character strings when it was
originally released in 1996. This is only slightly silly for a language that
was invented after Unicode 1.0 was released in 1992. It is inexcusably
shortsighted that Ruby has not added Unicode objects over the last twelve
years.''
I cannot believe that a Japanese hacker would put together a programming
language without Unicode support. If my Common Lisp Kanji Drill were to be
reimplemented in Ruby, I can see there would be annoying difficulties there,
including this:
``Ruby's Regular expressions also match only ASCII and a small set of
encodings, including UTF-8 and the Japanese encodings EUC and SJIS. Want to
write a regular expression that matches UTF-16, Latin-1, or raw Unicode?
You'll have to use the third-party Oniguruma package or a different
programming language. You can't use pure Ruby. ''
I've had no problem regex'ing over strings containing international characters
with CL-PPCRE.
``Some documents indicate that Ruby 2.0 is going to be different in ways that
will break existing Ruby 1.x programs severely. They also contain disturbing
statements like this one about the new garbage collector: "It will be
(mostly) thread safe." Being (mostly) thread safe is like being mostly
pregnant. You either are, or you aren't''.
``It's difficult to precisely evaluate the difference in execution time
between different languages. However, The Computer Language Benchmark Game
gives a pretty strong indication that Ruby is slow. On its tests, Python is
3x-4x as fast as Ruby. Ruby is slower than TCL, a language that is
twenty years old. Ruby is about the same speed as JavaScript (in Mozilla's
SpiderMonkey interpreter). The only thing slower than Ruby is Prolog.''
Oh my ...
From: Brian Adkins
Subject: Re: Lexical closures - difference between Common Lisp and Ruby
Date:
Message-ID: <m28ws7wiz2.fsf@gmail.com>
Kaz Kylheku <········@gmail.com> writes:
> For a good laugh, check this out:
Definitely a good laugh ;)
> http://glyphobet.net/blog/essay/228
>
> [...]
>
> Random snippets:
Better random snippets:
"A few weeks ago, I learned Ruby and Ruby on Rails..."
I respectfully suggest that it may take him more than a few weeks to
master the language and framework.
"The best tool for the job is Python & Pylons. While Rails and Pylons
are similar, shortcomings in Ruby compared to Python make Python &
Pylons the clear choice."
'best tool', 'clear choice' ? So much for being "as objective as
humanly possible"
"Why have Ruby and Ruby on Rails gained so much traction, despite
these issues?"
That is a good question :)
I don't think he answered that question very well. Yes, there are many
disadvantages to Ruby and Rails; however, for a large set of problems,
the advantages outweigh the disadvantages enough to make Ruby/Rails a
good solution; hence, they have gained much traction.
It's my impression that most Python web developers prefer Django to
Pylons and that the pros/cons of Python/Django compared to Ruby/Rails
are such that personal preference, developer experience, etc. will tip
the balance.
From: Javier
Subject: Re: Lexical closures - difference between Common Lisp and Ruby
Date:
Message-ID: <ge9vfi$j8l$1@aioe.org>
Kaz Kylheku escribi�:
> ``Ruby did not have any support for Unicode character strings
Oh nice, because you don't have any more arguments against Ruby, you now
go to the specific and less important.
Anyway, SBCL is not very good at Unicode, internationalization, and so
on. I would say that it is much worse than Ruby. I have to take a lot of
care when writing my function names not having �,�,� and similar
characters, because it always returns me with an error. It even give me
an error when inserting spanish characters in comments!!
In Ruby, at least I can insert that characters in comments.
> ``It's difficult to precisely evaluate the difference in execution time
> between different languages. However, The Computer Language Benchmark Game
> gives a pretty strong indication that Ruby is slow.
Not anymore. Ruby 1.9 is nearly as fast as Python is:
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=yarv&lang2=python
On Wed, 2008-10-29 at 16:28 +0100, Javier wrote:
> I have to take a lot of
> care when writing my function names not having á,é,ñ and similar
> characters, because it always returns me with an error. It even give
> me an error when inserting spanish characters in comments!!
> (defun áéñ ()
;; I have to take a lot of care when writing my function names not having á,é,ñ and similar characters
(write-line "I have to take a lot of care when writing my function names not having á,é,ñ and similar characters"))
> (áéñ)
I have to take a lot of care when writing my function names not having á,é,ñ and similar characters
..?
Also, from your first post:
Javier wrote:
> The true is that for this kind of things, Ruby is more concise and easier.
No.
Javier wrote:
> Anyway, it is off topic here. ;)
Yes.
From: Javier
Subject: Re: Lexical closures - difference between Common Lisp and Ruby
Date:
Message-ID: <gea3sm$5ha$2@aioe.org>
Lars Rune Nøstdal escribió:
>> (defun áéñ ()
> ;; I have to take a lot of care when writing my function names not having á,é,ñ and similar characters
> (write-line "I have to take a lot of care when writing my function names not having á,é,ñ and similar characters"))
>
>> (áéñ)
> I have to take a lot of care when writing my function names not having á,é,ñ and similar characters
>
>
> ..?
It doesn't work in Aquamacs in OS X.
> Also, from your first post:
>
> Javier wrote:
>> The true is that for this kind of things, Ruby is more concise and easier.
>
> No.
Yes.
> Javier wrote:
>> Anyway, it is off topic here. ;)
>
> Yes.
Not anymore. We're comparing Lisp and Ruby.
On Wed, 2008-10-29 at 17:44 +0100, Javier wrote:
> Lars Rune Nøstdal escribió:
>
> >> (defun áéñ ()
> > ;; I have to take a lot of care when writing my function names not having á,é,ñ and similar characters
> > (write-line "I have to take a lot of care when writing my function names not having á,é,ñ and similar characters"))
> >
> >> (áéñ)
> > I have to take a lot of care when writing my function names not having á,é,ñ and similar characters
> >
> >
> > ..?
>
> It doesn't work in Aquamacs in OS X.
Hum, maybe Aquamacs is what's having/causing the problem then. I have
this in my .emacs-file:
(setq current-language-environment "UTF-8")
(setq slime-net-coding-system 'utf-8-unix)
> > Also, from your first post:
> >
> > Javier wrote:
> >> The true is that for this kind of things, Ruby is more concise and easier.
> >
> > No.
>
> Yes.
You're a moron. Piss off.
> > Javier wrote:
> >> Anyway, it is off topic here. ;)
> >
> > Yes.
>
> Not anymore. We're comparing Lisp and Ruby.
Whatever.
From: Javier
Subject: Re: Lexical closures - difference between Common Lisp and Ruby
Date:
Message-ID: <gea5ml$esn$1@aioe.org>
Lars Rune Nøstdal escribió:
> You're a moron. Piss off.
You are.
>>>> Anyway, it is off topic here. ;)
>>> Yes.
>> Not anymore. We're comparing Lisp and Ruby.
>
> Whatever.
Do you feel superior because of your brevity?
Oh, how cool you are.
Fuck you.
On Wed, 2008-10-29 at 18:14 +0100, Javier wrote:
> Do you feel superior
Yes.
From: Javier
Subject: Re: Lexical closures - difference between Common Lisp and Ruby
Date:
Message-ID: <gea6ea$ic6$1@aioe.org>
Lars Rune N�stdal escribi�:
> On Wed, 2008-10-29 at 18:14 +0100, Javier wrote:
>> Do you feel superior
>
> Yes.
Are you so breve when fucking girls?
I mean, if you ever manage to fuck them.
On Wed, 2008-10-29 at 18:27 +0100, Javier wrote:
> Lars Rune Nøstdal escribió:
> > On Wed, 2008-10-29 at 18:14 +0100, Javier wrote:
> >> Do you feel superior
> >
> > Yes.
>
> Are you so breve when fucking girls?
> I mean, if you ever manage to fuck them.
rofl..
..did you get utf-8 to work in Aquaemacs or not? Let's start with that.
On 27 out, 18:28, Javier <······@askmyadress.com> wrote:
> Pascal Bourguignon escribió:
> > compared to the more general (m o p) syntax. Etc.
>
> You can get used to (m o p), but it is not natural. Human language has
> not been evolutioned that way.
That's a lie. "Take the hammer" is far more natural than "Hammer,
take"
From: Kaz Kylheku
Subject: Re: Lexical closures - difference between Common Lisp and Scheme
Date:
Message-ID: <20081027201904.221@gmail.com>
On 2008-10-27, Javier <······@askmyadress.com> wrote:
> Pascal Bourguignon escribi�:
>
>> Ruby makes trivial operations cryptic (what you call "more concise"),
>> and serrious programming harder.
>>
>> Try for example to pass two or more anonymous functions to the same
>> function.
>>
>> (defun compute-and-report (seq compute report)
>> (map nil (lambda (x) (let ((r (funcall compute x)))
>> (funcall report x)
>> r)) seq))
>>
>> (compute-and-report '(1 2 3)
>> (lambda (x) (* x x))
>> (lambda (x) (princ x) (terpri)))
>>
>> Ruby?
>
>
> def compute_and_report seq, compute, report
> seq.map { |x|
> compute.call(x)
> report.call(x)
> }
> end
> compute_and_report [1,2,3], lambda {|x| x*x}, lambda {|x| puts x}
That is just:
(defun compute-and-report (seq compute report)
(mapc (lambda (x)
(funcall compute x)
(funcall report x))
seq))
(compute-and-report '(1 2 3) (lambda (x) (* x x)) #'print)
But, guys, shouldn't the report be on the result of the computation?
(funcall report (funcall compute x))
report.call(compute.call(x))
Why compute, throw away the result, and report the original value?
Also, doesn't the ruby code use puts directly? lambda {|x| puts x} looks
like a useless wrapper.
Maybe you don't have 5K lines of Ruby under your belt?
From: Javier
Subject: Re: Lexical closures - difference between Common Lisp and Scheme
Date:
Message-ID: <ge72fe$920$1@aioe.org>
Kaz Kylheku escribi�:
>
> But, guys, shouldn't the report be on the result of the computation?
>
> (funcall report (funcall compute x))
>
> report.call(compute.call(x))
I prefer not using ():
report.call compute.call x
> Why compute, throw away the result, and report the original value?
It's the example Pascal put.
His intention was to demonstrate that passing two anonymous functions in
Ruby was a mess, but he was wrong. The result doesn't matter in this
case, not even if it contains some imprecisions
> Also, doesn't the ruby code use puts directly? lambda {|x| puts x} looks
> like a useless wrapper.
>
> Maybe you don't have 5K lines of Ruby under your belt?
I don't have neither 5k lines of Ruby or 5k lines of Lisp. I have in
other languages.
Javier wrote:
> Kaz Kylheku escribi�:
>
>>
>> But, guys, shouldn't the report be on the result of the computation?
>>
>> (funcall report (funcall compute x))
>>
>> report.call(compute.call(x))
>
> I prefer not using ():
>
> report.call compute.call x
>
>
>> Why compute, throw away the result, and report the original value?
>
> It's the example Pascal put.
No. My example computed a value, reported it and returned it. The
argument was used only once.
But I understand that without parentheses things are less obvious.
report.call compute.call x
Is it
(report.call (compute.call x))
or
(report.call compute.call x)
or
((report.call compute.call) x)
?
> His intention was to demonstrate that passing two anonymous functions in
> Ruby was a mess, but he was wrong.
More exactly, I didn't knew that lambda existed and I knew that one can
pass only one block to a method.
But Ruby is still a mess, there's no need for a demonstration.
For example, you have two syntaxes: o.m { |...| ...}
and: o.m lambda { |...| ...}
Another example, in Ruby, the lambdas are all evaluated at run-time,
they cannot be compiled, because lambda is actually a method on the
Object class to build, at run-time, an object of class Proc with a block.
> The result doesn't matter in this
> case, not even if it contains some imprecisions
Admited.
--
__Pascal Bourguignon__
http://www.informatimago.com
From: Kaz Kylheku
Subject: Re: Lexical closures - difference between Common Lisp and Scheme
Date:
Message-ID: <20081028091722.120@gmail.com>
On 2008-10-28, Javier <······@askmyadress.com> wrote:
> Kaz Kylheku escribi�:
>
>>
>> But, guys, shouldn't the report be on the result of the computation?
>>
>> (funcall report (funcall compute x))
>>
>> report.call(compute.call(x))
>
> I prefer not using ():
I don't believe in removing parentheses from expressions just to prove that I
have memorized the precedence table.
Time and time again, you demonstrate your programming puberty.
> report.call compute.call x
But isn't this:
report.call(compute.call, x)
?
I.e. pass the call function, and X.
This interpertation makes Ruby consistent with Perl and the Unix shell command
line.
From: Javier
Subject: Re: Lexical closures - difference between Common Lisp and Scheme
Date:
Message-ID: <gea08l$ml4$1@aioe.org>
Kaz Kylheku escribi�:
> I don't believe in removing parentheses from expressions just to prove that I
> have memorized the precedence table.
No, it is not because I want to prove nothing. It is because I see the
code clearer.
> Time and time again, you demonstrate your programming puberty.
Because I prefer not using ()?
That is a lispy thought, not the demonstration of nothing (except,
perhaps, that I am more open minded than you).
>> report.call compute.call x
>
> But isn't this:
>
> report.call(compute.call, x)
>
> ?
>
> I.e. pass the call function, and X.
>
> This interpertation makes Ruby consistent with Perl and the Unix shell command
> line.
If Perl and Bash would have the object system that Ruby has, they would
be consistent with Ruby. But they don't.
On Mon, 2008-10-27 at 13:07 +0100, Javier wrote:
> On Sat, 25 Oct 2008 19:13:34 +0200, Lars Rune Nøstdal wrote:
>
> >> Ruby:
> >>
> >> flist = []
> >> 3.times{|i| flist << proc{|x| x * i}} flist.map{|pr| pr[2]}
> >> ==> [0, 2, 4]
> >
> > Brain damage:
> > You have it.
>
> The true is that for this kind of things, Ruby is more concise and easier.
No.
> Anyway, it is off topic here. ;)
Yes.
From: Tamas K Papp
Subject: Re: Lexical closures - difference between Common Lisp and Scheme
Date:
Message-ID: <6mrm4bFig111U1@mid.individual.net>
On Tue, 28 Oct 2008 06:26:46 +0100, Lars Rune Nøstdal wrote:
> On Mon, 2008-10-27 at 13:07 +0100, Javier wrote:
>> On Sat, 25 Oct 2008 19:13:34 +0200, Lars Rune Nøstdal wrote:
>>
>> >> Ruby:
>> >>
>> >> flist = []
>> >> 3.times{|i| flist << proc{|x| x * i}} flist.map{|pr| pr[2]}
>> >> ==> [0, 2, 4]
>> >
>> > Brain damage:
>> > You have it.
>>
>> The true is that for this kind of things, Ruby is more concise and
>> easier.
>
> No.
Dear Lars, Pascal, Kaz and others,
I appreciate your efforts to educate Javier, but discussing programming
languages with him is comparable to discussing abstract algebra with
someone who needs to take his shoes off to count above 10. Lately he
also realized this, and is taking refuge in cheap insults.
I admire how level-headed your responses are despite his lack of manners,
but please realize that you are still feeding a relentless troll. Maybe
if you didn't respond to him he would go away.
Thanks,
Tamas
From: Duane Rettig
Subject: Re: Lexical closures - difference between Common Lisp and Scheme
Date:
Message-ID: <o0abcn9s89.fsf@gemini.franz.com>
Tamas K Papp <······@gmail.com> writes:
> On Tue, 28 Oct 2008 06:26:46 +0100, Lars Rune N�stdal wrote:
>
>> On Mon, 2008-10-27 at 13:07 +0100, Javier wrote:
>>> On Sat, 25 Oct 2008 19:13:34 +0200, Lars Rune N�stdal wrote:
>>>
>>> >> Ruby:
>>> >>
>>> >> flist = []
>>> >> 3.times{|i| flist << proc{|x| x * i}} flist.map{|pr| pr[2]}
>>> >> ==> [0, 2, 4]
>>> >
>>> > Brain damage:
>>> > You have it.
>>>
>>> The true is that for this kind of things, Ruby is more concise and
>>> easier.
>>
>> No.
>
> Dear Lars, Pascal, Kaz and others,
>
> I appreciate your efforts to educate Javier, but discussing programming
> languages with him is comparable to discussing abstract algebra with
> someone who needs to take his shoes off to count above 10. Lately he
> also realized this, and is taking refuge in cheap insults.
>
> I admire how level-headed your responses are despite his lack of manners,
> but please realize that you are still feeding a relentless troll. Maybe
> if you didn't respond to him he would go away.
Yes, that's possible, but it would only work if and when everybody
stops answering him completely. Unfortunately, I think several people
are just having too much fun with him, so I don't see that happening
soon. I've personally been fascinated by his cluelessness about how
others are having so much fun at his expense, and until recently (when
the cheap insults started) I was having fun myself just watching the
spectacle.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450, Oakland, Ca. 94607
From: Javier
Subject: Re: Lexical closures - difference between Common Lisp and Scheme
Date:
Message-ID: <geaeks$jqe$1@aioe.org>
Duane Rettig escribi�:
> Tamas K Papp <······@gmail.com> writes:
>
>> On Tue, 28 Oct 2008 06:26:46 +0100, Lars Rune N�stdal wrote:
>>
>>> On Mon, 2008-10-27 at 13:07 +0100, Javier wrote:
>>>> On Sat, 25 Oct 2008 19:13:34 +0200, Lars Rune N�stdal wrote:
>>>>
>>>>>> Ruby:
>>>>>>
>>>>>> flist = []
>>>>>> 3.times{|i| flist << proc{|x| x * i}} flist.map{|pr| pr[2]}
>>>>>> ==> [0, 2, 4]
>>>>> Brain damage:
>>>>> You have it.
>>>> The true is that for this kind of things, Ruby is more concise and
>>>> easier.
>>> No.
>> Dear Lars, Pascal, Kaz and others,
>>
>> I appreciate your efforts to educate Javier, but discussing programming
>> languages with him is comparable to discussing abstract algebra with
>> someone who needs to take his shoes off to count above 10. Lately he
>> also realized this, and is taking refuge in cheap insults.
>>
>> I admire how level-headed your responses are despite his lack of manners,
>> but please realize that you are still feeding a relentless troll. Maybe
>> if you didn't respond to him he would go away.
>
> Yes, that's possible, but it would only work if and when everybody
> stops answering him completely. Unfortunately, I think several people
> are just having too much fun with him, so I don't see that happening
> soon. I've personally been fascinated by his cluelessness about how
> others are having so much fun at his expense, and until recently (when
> the cheap insults started) I was having fun myself just watching the
> spectacle.
Some things:
- I love Lisp. It's my favorite language. I'm just having fun, if you
didn't realize.
- It's not true that I don't realize that everybody is having fun.
- It is not at my expense.
- Lars insulted me in the first time. And I have some dignity. Apart
from this, I don't insult anybody.
- Without people like me, I think that c.l.l is really boring. You
underestimate our job.
But, if you want me to leave, and give a good reason, I can leave. After
all, like you, I'm feeling that fun is going down. This happens when
people stop respecting others.
Ah, and I also understand that, because you are working for Franz, and I
don't like commercial software, you might be afraid. ;-)
From: Duane Rettig
Subject: Re: Lexical closures - difference between Common Lisp and Scheme
Date:
Message-ID: <o063nb9hbv.fsf@gemini.franz.com>
Javier <······@askmyadress.com> writes:
> Duane Rettig escribi�:
>> Tamas K Papp <······@gmail.com> writes:
>>
>>> On Tue, 28 Oct 2008 06:26:46 +0100, Lars Rune N�stdal wrote:
>>>
>>>> On Mon, 2008-10-27 at 13:07 +0100, Javier wrote:
>>>>> On Sat, 25 Oct 2008 19:13:34 +0200, Lars Rune N�stdal wrote:
>>>>>
>>>>>>> Ruby:
>>>>>>>
>>>>>>> flist = []
>>>>>>> 3.times{|i| flist << proc{|x| x * i}} flist.map{|pr| pr[2]}
>>>>>>> ==> [0, 2, 4]
>>>>>> Brain damage:
>>>>>> You have it.
>>>>> The true is that for this kind of things, Ruby is more concise and
>>>>> easier.
>>>> No.
>>> Dear Lars, Pascal, Kaz and others,
>>>
>>> I appreciate your efforts to educate Javier, but discussing
>>> programming languages with him is comparable to discussing abstract
>>> algebra with someone who needs to take his shoes off to count above
>>> 10. Lately he also realized this, and is taking refuge in cheap
>>> insults.
>>>
>>> I admire how level-headed your responses are despite his lack of
>>> manners, but please realize that you are still feeding a relentless
>>> troll. Maybe if you didn't respond to him he would go away.
>> Yes, that's possible, but it would only work if and when everybody
>> stops answering him completely. Unfortunately, I think several people
>> are just having too much fun with him, so I don't see that happening
>> soon. I've personally been fascinated by his cluelessness about how
>> others are having so much fun at his expense, and until recently (when
>> the cheap insults started) I was having fun myself just watching the
>> spectacle.
>
> Some things:
>
> - I love Lisp. It's my favorite language. I'm just having fun, if you
> didn't realize.
Well, I thought so, until you started the insults. (and no, don't
start up with how others really started it - if you were truly having
fun you would let others' insults roll of your back).
> - It's not true that I don't realize that everybody is having fun.
> - It is not at my expense.
Believe as you wish.
> - Lars insulted me in the first time. And I have some dignity. Apart
> from this, I don't insult anybody.
That's hilarious! Excellent joke!
> - Without people like me, I think that c.l.l is really boring. You
> underestimate our job.
You overestimate how much I care about your "job".
> But, if you want me to leave, and give a good reason, I can
> leave. After all, like you, I'm feeling that fun is going down. This
> happens when people stop respecting others.
Come or go as you like; as I implied above, I simply don't care.
> Ah, and I also understand that, because you are working for Franz, and
> I don't like commercial software, you might be afraid. ;-)
Ah, as I suspected, you overestmate your importance to this ng, and
how much I care. For fun, take some time and read through the many
years of conversations on c.l.l and figure out how many insults there
have been from various trolls, both degrading lisp and degrading
commercial software. Then you might be able to laugh at yourself for
thinking (even jokingly) that your little quips have any effect on
people like me.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450, Oakland, Ca. 94607
From: Javier
Subject: Re: Lexical closures - difference between Common Lisp and Scheme
Date:
Message-ID: <geag3q$pph$1@aioe.org>
Tamas K Papp wrote:
> you are still feeding a relentless troll.
Dear Tamas, if you read this, or at least read as a response to this:
What is a troll: a Usenet user.
Don't belive that you are not one just because you are in line with the
tastes of the group.
You pretend to gain attention like the most. Will you stay here if
nobody would answer your questions?
The difference between you and me is that, while you come here to hide
your insecurity, I come here to reveal who the fuck you are, and why you
feel so bad... and because I'm bored and want some fun, too. ;-)
Have fun.