language-dev archive @ ASPN

Re: Iterator Syntax

On Wednesday 08 May
2002 06:11 am, Pixel wrote:

> I don't know if you have anonymous functions, but you may consider using
> real anonymous functions instead of "blocks".
>

Under the covers my blocks *are* anonymous functions. Currently they are not 
truly first class, for example I can't say:

y = {|x| print(x)}
y.call(1) => 1

But that is mostly due to a parser that is inadequate as all of the necessary 
plumbing is in the class libraries and VM to handle this.

> Usually programming languages have:

> - ruby: blocks are a special beast allowing arguments, and are first class.
> There is a distinction between functions and parameter blocks. Anonymous
> functions are emulated with blocks. You can't have default-value (?) on
> blocks, blocks must use "block.call(args)" instead of "func(args)".

When I first began work on Samson it was an experiment to clean up JavaScript 
syntax and to come up with a fast and tight JS VM. Since then things have 
morphed greatly, and Ruby is responsible for a good deal of that. (However, I 
am still trying to come up with the best unification of a prototype-based 
system and an inheritence based system... the code under the covers is pretty 
icky at the moment)

> > iterate(a,b,c,d).each() { block}
> >
> > that would call the each method of each object in the chain. However, I
> > couldn't think of a good use of that to save my life, so removed it.
>
> well, this is used quite a lot in functional programming languages. If you
> want to allow functional programming style... :)

I think my syntax is convoluted enough at the moment, thanks. Besides, I look 
at OCaml and it makes my sick to my stomach... ;-)

Re: Iterator Syntax

Glen Starchman
 On Tuesday 07 May 2002 02:47 am, Donal K. Fellows wrote:
> >   "hello".each(x) {
> >	  print(x)
> >   }
> >
> > Problem with this is probably that the first x looks like an argument
> > to each(); I suppose it is, but not in quite the normal sense in that
> > it is a sort-of output-argument.  If you have local function closures
> > you should probably use those, especially if they are introspectable
> > in the number of arguments[*].  OTOH, I don't know enough about the
> > syntax of your language to know how well that'd work (Java does this
> > sort of thing, except with classes not functions, and it produces code
> > that doesn't win awards for extreme syntactic elegance.)  :^/
> 
> Hm... originally, I had something that looked like this:
> 
> iterator_function() (block_arg,...) { block_body}
> 
> That turned out to be rather hard to debug, IMO.

I don't know if you have anonymous functions, but you may consider using real
anonymous functions instead of "blocks".

Usually programming languages have:

- blocks like { ... } which are not first class (you can't pass them to
functions), allowed only for builtin constructs

- anonymous functions (lambda) which are first class constructs, but usually
less sugared and harder to use.

Solutions in various languages:

- perl: blocks and anonymous functions are nearly the same, the "sub" can be
removed when the callee declares the type (and is the first parameter)
  -> very concise, but no sugar for arguments (only the ugly @...
  -> no distinction between parameter-less and parameter blocks
  -> blocks allow lazy evaluation of the block

  sample: map { $_[0] * 2 } (1, 2)
	  mapn { $_[0] + $_[1] } [1, 2], [3, 4]
	  
	  sub my_or { my ($a, $b) = @... $a || &$b }
	  $v = my_or(1, sub { print "foo" ; 2 });

- python: blocks are reserved for builtins. "lambda" is used for
parameter-using blocks. No special sugar for having the block separated from
the arguments
  -> parameter-less blocks can be achieved with lambda *but* lambda only allow
     expressions, not statements

  sample: map(lambda e: e * 2, [1, 2])
	  map(lambda a,b: a+b, [1, 2], [3, 4])

	  # lambda only allow expressions. "print" being a statement, this
	  # can't be done

	  # with a special print_then:
	  def print_then(s, v): print s ; return v
	  def my_or(a, b): return a or b()
	  v = my_or(1, lambda: print_then("foo", 2))

- ruby: blocks are a special beast allowing arguments, and are first class.
There is a distinction between functions and parameter blocks. Anonymous
functions are emulated with blocks. You can't have default-value (?) on
blocks, blocks must use "block.call(args)" instead of "func(args)". 

  sample: [1, 2].map{|e| e * 2}
	  mapn([1, 2], [3, 4]){|a,b| a+b}

	  def my_or(a) a || yield end
	  v = my_or(1){ print "foo" ; 2 }

	  def my_or(a,b) a || b.call end
	  v = my_or(1, proc{print "foo" ; 2})


- haskell: due to lazy evaluation, parameter-less blocks are not evaluated, so
no special sugar is needed for them. All is simple :)
Also note that the sugar for anonymous functions is quite terse.

  sample: map (\e -> e * 2) [1, 2]  or	map (* 2) [1, 2]
	  zipWith (+) [1, 2] [3, 4]	  

	  my_or a b = if a then 1 else b
	  v = my_or True (trace "foo" 2)

- ocaml: parameter-less blocks must be packed in an anonymous function.

  sample: map (fun e -> e * 2) [ 1 ; 2 ]  or  map (( * ) 2) [ 1 ; 2 ]
	  map2 (+) [ 1 ; 2 ] [ 3 ; 4 ]

	  let my_or a b = if a then 1 else b()
	  let v = my_or true (fun () -> print_string "foo" ; 2)

- merd [*]: parameter-less blocks can be achieved with the magic Lazy in
arguments. The result is alike haskell

  sample: (1, 2).map(e -> e * 2)  or  (1, 2).map(* 2)
	  ((1, 2), (3, 4)).map2(+)

	  my_or(a, Lazy(b)) = a ||| b
	  v = my_or(1, ("foo".print ; 2))


- for more syntax for anonymous functions, look "anonymous functions" in
  http://merd.net/pixel/language-study/syntax-across-languages.html

[...]

> But the iteration over multiple values would be a big tougher to intergate, 
> although I did look at a top-level iterator function:
> 
> iterate(a,b,c,d).each() { block}
> 
> that would call the each method of each object in the chain. However, I 
> couldn't think of a good use of that to save my life, so removed it.

well, this is used quite a lot in functional programming languages. If you
want to allow functional programming style... :)


[*] http://merd.net, my programming language

Re: Iterator Syntax

On Wednesday 08 May
2002 05:57, Mathieu Bouchard wrote:
> On Wed, 8 May 2002, Buggs wrote:
> > On Tuesday 07 May 2002 16:24, Glen Starchman wrote:
> > > On Tuesday 07 May 2002 02:47 am, Donal K. Fellows wrote:
> > > "hello".each(3) { |x| print ("chars=%s", x)
> >
> > what about
> > "hello".each(3)->x	{print ("chars=%s", x)}
> > if you still have "->" spare
> > think
> > x <-"hello".each(3) {print ("chars=%s", x)}
> > is funny
>
> putting the block parameters at the beginning of the block syntax like
> {|x| ... } is well-justified: those parameters belong to the block, not to
> the call. This is why the same kind of syntax was chosen in languages like
> Smalltalk, Self, and Ruby.
>
> The params belong to the block because it makes it easier to pass the
> blocks around from call to call, or store them in variables.

Well of course that is a fine point,
but how does one explain from an aesthetic view
how the parameter gets its values ?
And also there is the isomorphy with methods' parameters being outside
of the block (at least in Ruby i think).

Buggs

Re: Iterator Syntax

On Wed, 8 May 2002, Buggs wrote:
> On Tuesday 07 May 2002 16:24, Glen Starchman wrote:
> > On Tuesday 07 May 2002 02:47 am, Donal K. Fellows wrote:
> > "hello".each(3) { |x| print ("chars=%s", x)
> what about
> "hello".each(3)->x  {print ("chars=%s", x)}
> if you still have "->" spare
> think
> x <-"hello".each(3) {print ("chars=%s", x)}
> is funny

putting the block parameters at the beginning of the block syntax like
{|x| ... } is well-justified: those parameters belong to the block, not to
the call. This is why the same kind of syntax was chosen in languages like
Smalltalk, Self, and Ruby.

The params belong to the block because it makes it easier to pass the
blocks around from call to call, or store them in variables.

________________________________________________________________
Mathieu Bouchard		   http://hostname.2y.net/~matju

Re: Iterator Syntax

On Tuesday 07 May
2002 16:24, Glen Starchman wrote:
> On Tuesday 07 May 2002 02:47 am, Donal K. Fellows wrote:
[...]
> Hm... originally, I had something that looked like this:
>
> iterator_function() (block_arg,...) { block_body}
>
> That turned out to be rather hard to debug, IMO.

ya IMO too

[...]
> > [* Just one value at a time from the iteratable entity?  Nah.  But then
> >    I'd go for iterating over more than one iteratable object at a time
> > too. ]
>
> Some iterators return multiple values, if that's what you mean. It would be
> rather trivial, for example, to create a String method that returned an
> arbitrary number of chars per iteration:
>
> "hello".each(3) { |x| print ("chars=%s", x)
>
> => hel
> => lo

what about
"hello".each(3)->x  {print ("chars=%s", x)}
if you still have "->" spare

think
x <-"hello".each(3) {print ("chars=%s", x)}
is funny

And hey is that all you let us know about your language ;P
come on give us an URL


Buggs

Attention all Gamblers, GUARANTEED Winnings from Horse Racing.

ATTENTION ALL SERIOUS
GAMBLERS.

How would you like to be "A GUARANTEED WINNER" when you bet
on a Horse Race?

Now you can be. We are that confident that we can make you a profit 
from Horse Racing THAT WE MAKE YOU THIS GUARANTEE,

IF YOU DON'T TREBLE YOUR STAKE WE WILL DOUBLE IT 
OURSELVES OUT OF OUR OWN MONEY.

With a guarantee like that it would be hard for any serious gambler to
refuse, and we mean what we say if you lose your stake, we will give you
double your stake back. 

For full details of this offer, and to see how it all works,
all you have to do is email me back, press reply and put "MORE DETAILS" in 
the subject box, and I shall send you further details. 
You have nothing to lose yet everything to gain.

And don't worry if you don't live in the UK this applies no matter where you 
live in the World.









This is a Esquires Ltd mailing!  This mail is never sent unsolicited.  To 
unsubscribe from our Special Deal Newsletters press reply, and 
put"unsubscribe" in the subject box. 





Your details are from our own opt-in lists or have been 
passed to us by a recognised firm who specialise in email lists, however 
if the information they have passed to us is wrong then please accept 
my deepest apologies, if you feel you shouldn't be on a list it may be a 
case of somebody else adding your details for their own gain, if you
feel this is the case press reply and put "remove" in the subject box, and 
I shall pass your details on to the firms who supply us with our lists,and 
ensure that you never receive another mailing from us.

Re: Iterator Syntax

On Tuesday 07 May
2002 02:47 am, Donal K. Fellows wrote:
>   "hello".each(x) {
>	print(x)
>   }
>
> Problem with this is probably that the first x looks like an argument
> to each(); I suppose it is, but not in quite the normal sense in that
> it is a sort-of output-argument.  If you have local function closures
> you should probably use those, especially if they are introspectable
> in the number of arguments[*].  OTOH, I don't know enough about the
> syntax of your language to know how well that'd work (Java does this
> sort of thing, except with classes not functions, and it produces code
> that doesn't win awards for extreme syntactic elegance.)  :^/
>

Hm... originally, I had something that looked like this:

iterator_function() (block_arg,...) { block_body}

That turned out to be rather hard to debug, IMO.

I also considered using brackets instead of braces to differentiate between 
normal blocks and the anonymous iterator blocks, but then had the obvious 
problem of:

iterator_function()[|x| block]
versus
function_returning_an_array[index]

The parser is relatively simple (and perhaps that is part of my problem). It 
simply looks for the closing paren of a method's args, and parses everything 
up to a closing 'end' or right brace as an anonymous block.  

> If you like 3, go for that.  Your tastes are as good a metric here as
> any other I can think of, and better than many.
>

Thanks... I think.

> Donal.
> [* Just one value at a time from the iteratable entity?  Nah.  But then
>    I'd go for iterating over more than one iteratable object at a time too.
> ]

Some iterators return multiple values, if that's what you mean. It would be 
rather trivial, for example, to create a String method that returned an 
arbitrary number of chars per iteration:

"hello".each(3) { |x| print ("chars=%s", x)

=> hel
=> lo

But the iteration over multiple values would be a big tougher to intergate, 
although I did look at a top-level iterator function:

iterate(a,b,c,d).each() { block}

that would call the each method of each object in the chain. However, I 
couldn't think of a good use of that to save my life, so removed it.

Re: Iterator Syntax

Glen Starchman
 I am working on my language again after a long haitus and have a
> question for the group in regards to readability of my iterator
> functionality. Currently, I am looking at 3 different forms:
> 
> 1. "hello".each() 
>	{ |x|
>		print (x)
>	}
> 2. "hello".each()
>	begin
>		print (x)
>	end
> 3. "hello".each()
>	|x|
>		print(x)
>	end
> 
> I am rather fond of number 3, but am uncertain as to which is the
> most readable for maintainers and intuitive for the developer.

Hmm.  Option 2 is definitely not a good idea (magic names tend to
cause trouble in my experience) and option 1 has the problem of
looking like the "|x|" is a command in the body (it looks to me like a
mathematical modulus operator too, which doesn't help me!)  But option
3 isn't balancing "begin" and "end" which is not brilliant either.
What about this (I'm a Tcler, I keep braces on the same line :^)

  "hello".each(x) {
      print(x)
  }

Problem with this is probably that the first x looks like an argument
to each(); I suppose it is, but not in quite the normal sense in that
it is a sort-of output-argument.  If you have local function closures
you should probably use those, especially if they are introspectable
in the number of arguments[*].	OTOH, I don't know enough about the
syntax of your language to know how well that'd work (Java does this
sort of thing, except with classes not functions, and it produces code
that doesn't win awards for extreme syntactic elegance.)  :^/

If you like 3, go for that.  Your tastes are as good a metric here as
any other I can think of, and better than many.

Donal.
[* Just one value at a time from the iteratable entity?  Nah.  But then
   I'd go for iterating over more than one iteratable object at a time too. ]
-- 
Donal K. Fellows, Department of Computer Science, University of Manchester, UK.
(work) fellowsd@...	Tel: +44-161-275-6137  (preferred email addr.)
(home) donal@...  Tel: +44-1274-401017	 Mobile: +44-7957-298955
http://www.cs.man.ac.uk/~fellowsd/  (Don't quote my .sig; I've seen it before!)

Guncelleme H.

------=_NextPart_000_00A0_86A60D5C.C6860C87
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: base64


PEhUTUw+PEhFQUQ+PFRJVExFPkVrbGVuZW5sZXIgZWZmMzQgZWYgPC9USVRM
RT48L0hFQUQ+PEJPRFk+DQo8dGFibGUgV0lEVEg9IjQzMCIgSEVJR0hUPSIx
MDAiIEFMSUdOPUNFTlRFUj4NCjx0cj4NCjx0ZCBDT0xTUEFOPSIyIj48L3Rk
Pg0KPC90cj4NCjx0cj4NCjx0ZCBDT0xTUEFOPSIyIiBIRUlHSFQ9IjEzIj4N
Cjx0YWJsZSBCT1JERVI9MCBDRUxMU1BBQ0lORz0wIENFTExQQURESU5HPTAg
V0lEVEg9IjEwMCUiID4NCjx0cj4NCjx0ZCBWQUxJR049VE9QPg0KPHRhYmxl
IEFMSUdOPUxFRlQgQk9SREVSPTAgQ0VMTFNQQUNJTkc9MCBDRUxMUEFERElO
Rz0wIFdJRFRIPSIyNzgiIEhFSUdIVD0iMTAwJSIgPg0KPHRyPg0KPHRkIEhF
SUdIVD0iNCI+PGltZyBTUkM9InBpeGVsdG9wLmdpZiIgaGVpZ2h0PTggd2lk
dGg9LTE+PC90ZD4NCjwvdHI+DQoNCjx0cj4NCjx0ZD48Yj48Zm9udCBmYWNl
PSJWZXJkYW5hLCBBcmlhbCwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmIj48Zm9u
dCBzaXplPSsxPjxGT05UIENPTE9SPSIjNjYwMEZGIj5Xb3JsZA0KTXV6aWsg
VG9wIDY8L0ZPTlQ+PC9mb250PjwvZm9udD48L2I+PC90ZD4NCjwvdHI+DQoN
Cjx0ciBCR0NPTE9SPSIjMzMzMzk5Ij4NCjx0ZCBCR0NPTE9SPSIjMDA5OTAw
Ij48aW1nIFNSQz0icGl4ZWx0b3AuZ2lmIiBoZWlnaHQ9MiB3aWR0aD0yPjwv
dGQ+DQo8L3RyPg0KDQo8dHI+DQo8dGQgV0lEVEg9IjI4MCI+DQo8dGFibGUg
Qk9SREVSPTAgQ0VMTFNQQUNJTkc9MCBDRUxMUEFERElORz0wIFdJRFRIPSIx
MDAlIiA+DQo8dHI+DQo8dGQgSEVJR0hUPSIyMyI+PGltZyBTUkM9InB1bnRh
dG9yZWxpbmtzLmdpZiIgSFNQQUNFPTIgVlNQQUNFPTQgaGVpZ2h0PTExIHdp
ZHRoPTExIGFsaWduPUFCU0NFTlRFUj48QSBIUkVGPSJodHRwOi8vd3d3LjNt
cDMubmV0Ij48Yj48Zm9udCBmYWNlPSJWZXJkYW5hIj48Zm9udCBzaXplPS0x
PlNoYWtpcmENCi0gV2hlbmV2ZXIgV2hlbmV2ZXI8L2ZvbnQ+PC9mb250Pjwv
Yj48L0E+PC90ZD4NCjwvdHI+DQoNCjx0cj4NCjx0ZCBIRUlHSFQ9IjIzIj48
aW1nIFNSQz0icHVudGF0b3JlbGlua3MuZ2lmIiBIU1BBQ0U9MiBWU1BBQ0U9
NCBoZWlnaHQ9MTEgd2lkdGg9MTEgYWxpZ249QUJTQ0VOVEVSPjxBIEhSRUY9
Imh0dHA6Ly93d3cuM21wMy5uZXQiPjxiPjxmb250IGZhY2U9IlZlcmRhbmEi
Pjxmb250IHNpemU9LTE+SmVubmlmZXINCkxvcGV6IC0gYWluJ3QgaXQgZnVu
bnk8L2ZvbnQ+PC9mb250PjwvYj48L0E+PC90ZD4NCjwvdHI+DQoNCjx0cj4N
Cjx0ZCBIRUlHSFQ9IjIzIj48aW1nIFNSQz0icHVudGF0b3JlbGlua3MuZ2lm
IiBIU1BBQ0U9MiBWU1BBQ0U9NCBoZWlnaHQ9MTEgd2lkdGg9MTEgYWxpZ249
QUJTQ0VOVEVSPjxBIEhSRUY9Imh0dHA6Ly93d3cuM21wMy5uZXQiPjxiPjxm
b250IGZhY2U9IlZlcmRhbmEiPjxmb250IHNpemU9LTE+RW5yaXF1ZQ0KSWds
YXNpYXMgLSBIZXJvPC9mb250PjwvZm9udD48L2I+PC9BPjwvdGQ+DQo8L3Ry
Pg0KDQo8dHI+DQo8dGQgSEVJR0hUPSIyMyI+PGltZyBTUkM9InB1bnRhdG9y
ZWxpbmtzLmdpZiIgSFNQQUNFPTIgVlNQQUNFPTQgaGVpZ2h0PTExIHdpZHRo
PTExIGFsaWduPUFCU0NFTlRFUj48QSBIUkVGPSJodHRwOi8vd3d3LjNtcDMu
bmV0Ij48Yj48Zm9udCBmYWNlPSJWZXJkYW5hIj48Zm9udCBzaXplPS0xPlRo
YWxpYQ0KLSBBbW9yIGEgbGEgbWV4aWNhbmE8L2ZvbnQ+PC9mb250PjwvYj48
L0E+PC90ZD4NCjwvdHI+DQoNCjx0cj4NCjx0ZCBIRUlHSFQ9IjIzIj48aW1n
IFNSQz0icHVudGF0b3JlbGlua3MuZ2lmIiBIU1BBQ0U9MiBWU1BBQ0U9NCBo
ZWlnaHQ9MTEgd2lkdGg9MTEgYWxpZ249QUJTQ0VOVEVSPjxBIEhSRUY9Imh0
dHA6Ly93d3cuM21wMy5uZXQiPjxiPjxmb250IGZhY2U9IlZlcmRhbmEiPjxm
b250IHNpemU9LTE+QnJpdG5leQ0KU3BlYXJzIC0gTHVja3k8L2ZvbnQ+PC9m
b250PjwvYj48L0E+PC90ZD4NCjwvdHI+DQoNCjx0ciBWQUxJR049Q0VOVEVS
Pg0KPHRkIFZBTElHTj1DRU5URVIgSEVJR0hUPSIyMyI+PGltZyBTUkM9InB1
bnRhdG9yZWxpbmtzLmdpZiIgSFNQQUNFPTIgVlNQQUNFPTQgaGVpZ2h0PTEx
IHdpZHRoPTExIGFsaWduPUFCU0NFTlRFUj48QSBIUkVGPSJodHRwOi8vd3d3
LjNtcDMubmV0Ij48Yj48Zm9udCBmYWNlPSJWZXJkYW5hIj48Zm9udCBzaXpl
PS0xPk1vZGpvDQotIExhZHk8L2ZvbnQ+PC9mb250PjwvYj48L0E+PC90ZD4N
CjwvdHI+DQo8L3RhYmxlPg0KPC90ZD4NCjwvdHI+DQoNCjx0ciBCR0NPTE9S
PSIjMzMzMzk5Ij4NCjx0ZCBIRUlHSFQ9IjExIiBCR0NPTE9SPSIjMDA5OTAw
Ij4NCjxkaXYgYWxpZ249cmlnaHQ+PGI+PGZvbnQgZmFjZT0iVmVyZGFuYSwg
QXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZiI+PGZvbnQgY29sb3I9IiNG
RkZGRkYiPjxmb250IHNpemU9LTI+PGEgaHJlZj0iaHR0cDovL3d3dy4zbXAz
Lm5ldCIgY2xhc3M9ImxpbmsiPkRpZ2VyDQptcDNsZXIgPj48L2E+PC9mb250
PjwvZm9udD48L2ZvbnQ+PC9iPjwvZGl2Pg0KPC90ZD4NCjwvdHI+DQoNCjx0
ciBCR0NPTE9SPSIjMzMzMzk5Ij4NCjx0ZCBIRUlHSFQ9IjExIiBCR0NPTE9S
PSIjRkZGRkZGIj48L3RkPg0KPC90cj4NCg0KPHRyIEJHQ09MT1I9IiMzMzMz
OTkiPg0KPHRkIEhFSUdIVD0iMTEiIEJHQ09MT1I9IiNGRkZGRkYiPg0KPGNl
bnRlcj48Yj48Zm9udCBmYWNlPSJWZXJkYW5hLCBBcmlhbCwgSGVsdmV0aWNh
LCBzYW5zLXNlcmlmIj48Zm9udCBzaXplPS0yPlRFT01BTklODQpZRU5JIEFM
QtxN3CDHT0sgS09OVVNVTERVICEhITwvZm9udD48L2ZvbnQ+PC9iPjwvY2Vu
dGVyPg0KPC90ZD4NCjwvdHI+DQoNCjx0ciBCR0NPTE9SPSIjMzMzMzk5Ij4N
Cjx0ZCBIRUlHSFQ9IjExIiBCR0NPTE9SPSIjRkZGRkZGIj4NCjx0YWJsZSBC
T1JERVI9MCBDRUxMU1BBQ0lORz00IFdJRFRIPSIxMDAlIiA+DQo8dHI+DQo8
dGQ+PEEgSFJFRj0iaHR0cDovL3d3dy4zbXAzLm5ldCI+PGltZyBTUkM9Imh0
dHA6Ly93d3cuM21wMy5uZXQvdGVvbWFuLmpwZyIgQk9SREVSPTEgaGVpZ2h0
PTE3MCB3aWR0aD0xNzA+PC9BPjwvdGQ+DQoNCjx0ZD48Zm9udCBmYWNlPSJW
ZXJkYW5hIj48Zm9udCBzaXplPS0yPktpc2EgYmlyIHNlc2l6IGxpZ2luIGFy
ZGluZGFuICJH9m78bOdlbGVuIg0KYWRsaSBhbGL8bfwgaWxlIGFyYW1pemEg
Z2VyaSBk9m5lbiBUZW9tYW4sIGJ1IGFsYvxt/CBpbGUgaXlpIGJpciBiYXNh
cml5YQ0KaW16YSBhdG1hayBpc3RpeW9yLiBCYXNhcmlsaSBzYXlpbGEgYmls
ZWNlayBidSBhbGL8bfwgdPxtIFRlb21hbiBzZXZlcg0KbGVyZSB0YXZzaXll
IGVkaXlvcnV6Li4uPC9mb250PjwvZm9udD48L3RkPg0KPC90cj4NCjwvdGFi
bGU+DQo8L3RkPg0KPC90cj4NCg0KPHRyIEJHQ09MT1I9IiMzMzMzOTkiPg0K
PHRkIEhFSUdIVD0iMTEiIEJHQ09MT1I9IiMwMDgwODAiPjxpbWcgU1JDPSJw
aXhlbHRvcC5naWYiIEhTUEFDRT0xMSBoZWlnaHQ9MSB3aWR0aD0xPjwvdGQ+
DQo8L3RyPg0KPC90YWJsZT4NCjwvdGQ+DQoNCjx0ZCBWQUxJR049VE9QIFdJ
RFRIPSIyMTYiPg0KPHRhYmxlIEFMSUdOPVJJR0hUIEJPUkRFUj00IENFTExT
UEFDSU5HPTAgQ0VMTFBBRERJTkc9MCBXSURUSD0iOTklIiBIRUlHSFQ9IjEw
MCUiIEJHQ09MT1I9IiNGRkZGRkYiIGJvcmRlckNvbG9yPSIjZmZmZmZmIiA+
DQo8dHI+DQo8dGQgVkFMSUdOPVRPUCBIRUlHSFQ9IjE2MCI+DQo8dGFibGUg
Qk9SREVSIENFTExTUEFDSU5HPTAgQ0VMTFBBRERJTkc9MiBXSURUSD0iMTAw
JSIgYm9yZGVyQ29sb3I9IiMwMDk5MDAiID4NCjx0cj4NCjx0ZCBCR0NPTE9S
PSIjMDA5OTAwIj4NCjxjZW50ZXI+PGI+PGZvbnQgZmFjZT0iVmVyZGFuYSwg
QXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZiI+PGZvbnQgY29sb3I9IiNG
RkZGRkYiPjxmb250IHNpemU9LTE+SGl0IEJveCAhITwvZm9udD48L2ZvbnQ+
PC9mb250PjwvYj48L2NlbnRlcj4NCjwvdGQ+DQo8L3RyPg0KDQo8dHI+DQo8
dGQ+DQo8dGFibGUgQk9SREVSPTAgQ0VMTFNQQUNJTkc9MCBDRUxMUEFERElO
Rz0wIFdJRFRIPSIxMDAlIiA+DQo8dHI+DQo8dGQgSEVJR0hUPSIwIj4NCjxj
ZW50ZXI+PGEgaHJlZj0iaHR0cDovL3d3dy4zbXAzLm5ldCIgY2xhc3M9Imxp
bmsiPjxpbWcgU1JDPSJodHRwOi8vd3d3LjNtcDMubmV0L2dva2hhbl9vemVu
LmpwZyIgQk9SREVSPTAgaGVpZ2h0PTkwIHdpZHRoPTEyMj48L2E+PC9jZW50
ZXI+DQo8L3RkPg0KPC90cj4NCg0KPHRyPg0KPHRkPjxmb250IGZhY2U9IlZl
cmRhbmEiPjxmb250IHNpemU9LTI+PGI+PGZvbnQgY29sb3I9IiNGRjAwMDAi
Pkf2a2hhbg0K1nplbjwvZm9udD48L2I+J2luIHllcHllbmkgYWxi/G38bmRl
a2kgPGI+PGZvbnQgY29sb3I9IiNGRjAwMDAiPiJUYWJpcmkNCkNhaXpzZSI8
L2ZvbnQ+PC9iPiBhZGxpIHBhcudhIGnnaW4g52VrdGlnaSB2aWRlbyBrbGli
aSBidXJhZGEgPEEgSFJFRj0iaHR0cDovL3d3dy4zbXAzLm5ldCI+PGZvbnQg
Y29sb3I9IiNGRjAwMDAiPjxiPklaTEVZSU48L2I+Li4uPC9mb250PjwvQT48
L2ZvbnQ+PC9mb250PjwvdGQ+DQo8L3RyPg0KPC90YWJsZT4NCg0KPHRhYmxl
IEJPUkRFUj0wIENFTExTUEFDSU5HPTAgQ0VMTFBBRERJTkc9MCBXSURUSD0i
MTAwJSIgPg0KPHRyPg0KPHRkIEhFSUdIVD0iMCI+DQo8Y2VudGVyPjxhIGhy
ZWY9Imh0dHA6Ly93d3cuM21wMy5uZXQiIGNsYXNzPSJsaW5rIj48aW1nIFNS
Qz0iaHR0cDovL3d3dy4zbXAzLm5ldC9iZW5kZW5pejMuanBnIiBCT1JERVI9
MCBoZWlnaHQ9OTAgd2lkdGg9MTIyPjwvYT48L2NlbnRlcj4NCjwvdGQ+DQo8
L3RyPg0KDQo8dHI+DQo8dGQ+PGZvbnQgZmFjZT0iVmVyZGFuYSI+PGZvbnQg
c2l6ZT0tMj48Yj48Zm9udCBjb2xvcj0iI0ZGMDAwMCI+QmVuZGVuaXo8L2Zv
bnQ+PC9iPidpbg0KPGI+PGZvbnQgY29sb3I9IiNGRjAwMDAiPiJCZW5kZW5p
emRlbiI8L2ZvbnQ+PC9iPg0KaXNpbWxpIGFsYvxt/CBidSBoYWZ0YSBQbGF5
bGlzdCAyMDAwIHNheWZhbGFyaW5hIGVrbGVuZGkuIEJ1IGFsYvxt/G78IDxB
IEhSRUY9Imh0dHA6Ly93d3cuM21wMy5uZXQiPjxiPjxmb250IGNvbG9yPSIj
RkYwMDAwIj5ESU5MRU1FSw0KaedpbiB0aWtsYXlpbi4uPC9mb250PjwvYj48
L0E+PC9mb250PjwvZm9udD48L3RkPg0KPC90cj4NCjwvdGFibGU+DQo8L3Rk
Pg0KPC90cj4NCg0KPHRyPg0KPHRkIEJHQ09MT1I9IiMwMDk5MDAiPg0KPGRp
diBhbGlnbj1yaWdodD48Yj48Zm9udCBmYWNlPSJWZXJkYW5hLCBBcmlhbCwg
SGVsdmV0aWNhLCBzYW5zLXNlcmlmIj48Zm9udCBjb2xvcj0iI0ZGRkZGRiI+
PGZvbnQgc2l6ZT0tMj48YSBocmVmPSJodHRwOi8vd3d3LjNtcDMubmV0IiBj
bGFzcz0ibGluayI+SGFiZXJsZXJpbg0KRGV2YW1pIC0+PC9hPjwvZm9udD48
L2ZvbnQ+PC9mb250PjwvYj48L2Rpdj4NCjwvdGQ+DQo8L3RyPg0KPC90YWJs
ZT4NCjwvdGQ+DQo8L3RyPg0KPC90YWJsZT4NCjwvdGQ+DQo8L3RyPg0KPC90
YWJsZT4NCjxmb250IGZhY2U9IlRhaG9tYSI+PGZvbnQgY29sb3I9IiMwMDAw
MDAiPjxmb250IHNpemU9LTI+PEI+QXJ0aWsgQmlyIHRlayBNUDMNCicg/CDH
ZWttZWsgaedpbiBTYWF0bGVyY2UgVWdyYXNtYXlhIHNvbiBWZXJkaWsuLi4g
U2lzdGVtaW1pemUgYmFnbGFuaXAsIGlzdGVkaWdpbml6IFNhbmF052luaW4g
YWxi/G38bvwgeWFkYSBzZedlY2VnaW5peiBrYXJpc2lrDQpNUDMgbGVyaSBC
aXJrYecgRGFraWthIGnnaW5kZSBCaWxnaXNheWFyaW5pemEgaW5kaXJpcCBo
ZW1lbiBkaW5sZW1leWUgYmFzbGF5YWJpbGlyc2luaXouLg0KPGEgaHJlZj0i
aHR0cDovL3d3dy4zbXAzLm5ldCIgY2xhc3M9ImxpbmsiPlNpdGV5ZSBHaXJp
cyA+Pj48L0I+PC9hPjwvZm9udD48L2ZvbnQ+PC9mb250PjwvdGQ+DQo8L3Ry
Pg0KPC90YWJsZT4NCjxCUj48QlI+PEJSPjxCUj48QlI+PEJSPjxCUj4NCjxk
aXYgYWxpZ249ImNlbnRlciI+PGZvbnQgc2l6ZT0iLTYiIGZhY2U9IkFyaWFs
LCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWYiPjxmb250IGNvbG9yPSIjMDAwMDAw
Ij5DbGljayBvbiB0aGUgbGluayBiZWxvdyB0byBiZSByZW1vdmVkIGZyb20g
b3VyIG1haWxpbmcgbGlzdC4gLSBNYWlsIGxpc3RlbWl6ZGVuIGNpa21hayBp
Y2luOjxCUj48YSBocmVmPSJodHRwOi8vd3d3LjNtcDMubmV0L3Vuc3Vicy5o
dG1sIiB0YXJnZXQ9Il9ibGFuayI+PGZvbnQgY29sb3I9IiMwMDAwMDAiIHNp
emU9Ii02Ij5VTlNVQlNDUklCRTwvZm9udD48L2ZvbnQ+PC9hPjwvZm9udD48
L2Rpdj4NCjwvQk9EWT4NCjwvSFRNTD4=

Son cikan videolar

------=_NextPart_000_00A7_41C82C1E.E7862B44
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: base64


PEhUTUw+PEhFQUQ+PFRJVExFPlllbmkgWWFwaW1sYXIgcjMyd2R3ICA8L1RJ
VExFPjwvSEVBRD4NCjxCT0RZPjxCUj4NCjxESVYgQUxJR049ImNlbnRlciI+
PEZPTlQgRkFDRT0iVmVyZGFuYSwgQXJpYWwiIFNJWkU9KzEgQ09MT1I9IiNG
RjAwMDAiPjxCPjxCSUc+MjAwMiBZQVBJTUkgWWVuaSBWaWRlb2xhcjwvQklH
PjwvQj48L0ZPTlQ+DQo8QlI+PEJSPjxUQUJMRSBXSURUSD0xNTA+DQogIDxU
Uj4NCiAgICA8VEQgV0lEVEg9IjUwJSI+PEEgSFJFRj0iaHR0cDovL3d3dy5u
b3Nla3MuY29tIj48SU1HIFNSQz0iaHR0cDovL3d3dy5ub3Nla3MuY29tL3R1
cmswMi5qcGciIEJPUkRFUj0wIFdJRFRIPTgwIEhFSUdIVD0xMjA+PC9BPjxC
Uj48QSBIUkVGPSJodHRwOi8vd3d3Lm5vc2Vrcy5jb20iPjxJTUcgU1JDPSJo
dHRwOi8vd3d3Lm5vc2Vrcy5jb20vdHVyazAzLmpwZyIgQk9SREVSPTAgV0lE
VEg9ODAgSEVJR0hUPTEyMD48L0E+PEJSPjxBIEhSRUY9Imh0dHA6Ly93d3cu
bm9zZWtzLmNvbSI+PElNRyBTUkM9Imh0dHA6Ly93d3cubm9zZWtzLmNvbS90
dXJrMDQuanBnIiBCT1JERVI9MCBXSURUSD04MCBIRUlHSFQ9MTIwPjwvQT48
L1REPg0KICAgIDxURCBXSURUSD0iNTAlIj48RElWIEFMSUdOPSJsZWZ0Ij48
VUwgVFlQRT1ESVNDPg0KICA8TEk+PEEgSFJFRj0iaHR0cDovL3d3dy5ub3Nl
a3MuY29tIj5BTUFURVVSPC9BPg0KICA8TEk+PEEgSFJFRj0iaHR0cDovL3d3
dy5ub3Nla3MuY29tIj5BTkFMPC9BPg0KICA8TEk+PEEgSFJFRj0iaHR0cDov
L3d3dy5ub3Nla3MuY29tIj5BU0lBTjwvQT4NCiAgPExJPjxBIEhSRUY9Imh0
dHA6Ly93d3cubm9zZWtzLmNvbSI+QklHIFRJVFM8L0E+DQogIDxMST48QSBI
UkVGPSJodHRwOi8vd3d3Lm5vc2Vrcy5jb20iPkJMQUNLPC9BPg0KICA8TEk+
PEEgSFJFRj0iaHR0cDovL3d3dy5ub3Nla3MuY29tIj5DVU1TSE9UPC9BPg0K
ICA8TEk+PEEgSFJFRj0iaHR0cDovL3d3dy5ub3Nla3MuY29tIj5GQVQ8L0E+
DQogIDxMST48QSBIUkVGPSJodHRwOi8vd3d3Lm5vc2Vrcy5jb20iPkZFVElT
SDwvQT4NCiAgPExJPjxBIEhSRUY9Imh0dHA6Ly93d3cubm9zZWtzLmNvbSI+
SU5URVJSQUNJQUw8L0E+DQogIDxMST48QSBIUkVGPSJodHRwOi8vd3d3Lm5v
c2Vrcy5jb20iPkxFU0JJQU48L0E+DQogIDxMST48QSBIUkVGPSJodHRwOi8v
d3d3Lm5vc2Vrcy5jb20iPk1BVFVSRTwvQT4NCiAgPExJPjxBIEhSRUY9Imh0
dHA6Ly93d3cubm9zZWtzLmNvbSI+T1JBTDwvQT4NCiAgPExJPjxBIEhSRUY9
Imh0dHA6Ly93d3cubm9zZWtzLmNvbSI+UElTU0lORzwvQT4NCiAgPExJPjxB
IEhSRUY9Imh0dHA6Ly93d3cubm9zZWtzLmNvbSI+UFJFR05BTlQ8L0E+DQog
IDxMST48QSBIUkVGPSJodHRwOi8vd3d3Lm5vc2Vrcy5jb20iPlNIRU1BTEU8
L0E+DQogIDxMST48QSBIUkVGPSJodHRwOi8vd3d3Lm5vc2Vrcy5jb20iPlZP
WUVVUjwvQT4NCjwvVUw+PC9ESVY+PC9URD48L1RSPjwvVEFCTEU+DQo8Qj48
QlI+PEJSPlR1bSB2aWRlb2xhcmkgc2l0ZW1pemUgZ2lyZXJlayBvbmxpbmUg
b2xhcmFrIG9sYXJhayBpemxleWViaWxpcnNpbml6LjxCUj4gWWVuaSBzaXN0
ZW1pbWl6IHNheWVzaW5kZSBoaXpsaSB2ZSBrYWxpdGVsaSBlcmlzaW0gaW1r
YW5pIHN1bm1ha3RheWl6LjxCUj4NCjxGT05UIEZBQ0U9IlRpbWVzIE5ldyBS
b21hbiwgQXJpYWwiIFNJWkU9KzIgQ09MT1I9IiNhYTg4OTkiPjxBIEhSRUY9
Imh0dHA6Ly93d3cubm9zZWtzLmNvbSI+QnVyYXlhIFRJS0xBWUlOPC9BPjwv
Rk9OVD4NCjwvQj48QlI+PEJSPjxCUj48QlI+PEJSPjxCUj4NCjxGT05UIEZB
Q0U9IlZlcmRhbmEsIEFyaWFsIiBTSVpFPTE+UmVwbHkgd2l0aCBhIGJsYW5r
IGVtYWlsIGZvciBSZW1vdmVkIGZyb20gb3VyIG1haWxsaXN0LjxCUj4NCkxp
c3RlbWl6ZGVuIGNpa21hayBpY2luIGJvcyBiaXIgbWFpbCB5b2xsYW1hbml6
IHlldGVybGlkaXIuPEJSPg0KPC9GT05UPjwvRElWPjwvQk9EWT48L0hUTUw+