I'll show you mine...

Okay, this is the beginnings of Scheme in Perl6. I'm sure there's stuff I'm getting wrong. I've not written the parser yet for instance and I'm toying with waiting for A5 before I do. Also, I've not yet implemented such important stuff as proper closures/lambda or the environment chain, but the un

Re: Bracekets

On Wed, Apr 10, 2002 at 04:03:29PM +1000, Damian Conway wrote: > My understanding was that perl6 would default to Perl 6 (*not* Perl 5), unless > the first thing it encountered was a: > > package Whatever; > > statement. If so, that's a change, at least from what I gleaned by following th

Re: I'll show you mine...

In message <[EMAIL PROTECTED]>, I wrote: > [ A huge wodge of possible perl 6 code ] I'm getting that Warnock's Dilemma feeling here... Did I stun you all into silence? -- Piers "It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a re

Re: I'll show you mine...

At 3:03 PM +0100 4/10/02, Piers Cawley wrote: >In message <[EMAIL PROTECTED]>, I wrote: >> [ A huge wodge of possible perl 6 code ] > >I'm getting that Warnock's Dilemma feeling here... Did I stun you all >into silence? Nah. You just can't hear the people running away screaming from there. ;-P -

Re: I'll show you mine...

On Wed, 2002-04-10 at 10:03, Piers Cawley wrote: > In message <[EMAIL PROTECTED]>, I wrote: > > [ A huge wodge of possible perl 6 code ] > > I'm getting that Warnock's Dilemma feeling here... Did I stun you all > into silence? On my clock, your original message arrived at 04:23, and your followu

Re: I'll show you mine...

Aaron Sherman <[EMAIL PROTECTED]> writes: > On Wed, 2002-04-10 at 10:03, Piers Cawley wrote: >> In message <[EMAIL PROTECTED]>, I wrote: >> > [ A huge wodge of possible perl 6 code ] >> >> I'm getting that Warnock's Dilemma feeling here... Did I stun you >> all into silence? > > On my clock, you

Re: I'll show you mine...

At 3:49 PM +0100 4/10/02, Piers Cawley wrote: >Aaron Sherman <[EMAIL PROTECTED]> writes: > > Your idea at the end of regugitating the code back out as Parrot or Perl >> is just slightly stunning on its own. > >I thought that was the easy bit. The compiler just (for appropriate >values of 'just'

Re: Unary dot

On Tue, Apr 09, 2002 at 09:56:02PM +0100, Piers Cawley wrote: > Larry Wall <[EMAIL PROTECTED]> writes: > > > We're talking about how to make .foo mean self.foo regardless of the > > current topic. > > Are we? I was looking for a way to unambgiously access the current > object in such a way that

Re: I'll show you mine...

At 09:23 AM 4/10/2002 +0100, Piers Cawley wrote: >Okay, this is the beginnings of Scheme in Perl6. I'm sure there's >stuff I'm getting wrong. I've not written the parser yet for instance Very nice! Quite a sample, maybe Larry/Damian can use this in one of the next $(A,E)'s > my SchemeExpr $.v

Re: Unary dot

Allison Randal wrote: > > On Tue, Apr 09, 2002 at 09:56:02PM +0100, Piers Cawley wrote: > > Larry Wall <[EMAIL PROTECTED]> writes: > > > > > We're talking about how to make .foo mean self.foo regardless of the > > > current topic. > > > > Are we? I was looking for a way to unambgiously access the

Re: Unary dot

On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote: > method m1 > { >m2; # calls method m2 in the same class Yes, but does it call it as an instance method on the current invocant or as a class method with no invocant? If the former, how would you do the latter? >.m2; # sy

RE: Unary dot

Mark J. Reed wrote: > On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote: > > method m1 > > { > >m2; # calls method m2 in the same class > Yes, but does it call it as an instance method on the current invocant > or as a class method with no invocant? If the former, how would you

Re: Unary dot

"Mark J. Reed" wrote: > > On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote: > > method m1 > > { > >m2; # calls method m2 in the same class > Yes, but does it call it as an instance method on the current invocant > or as a class method with no invocant? If the former, how woul

Re: Unary dot

On Wed, Apr 10, 2002 at 10:50:52AM -0700, Glenn Linderman wrote: > > Yes, but does it call it as an instance method on the current invocant > > or as a class method with no invocant? If the former, how would you > > do the latter? > > Should both be allowed to exist? Do both exist? Why do both

Re: Unary dot

David Whipp wrote: > > Mark J. Reed wrote: > > On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote: > > > method m1 > > > { > > >m2; # calls method m2 in the same class > > Yes, but does it call it as an instance method on the current invocant > > or as a class method with no inv

Re: Unary dot

At 10:50 AM 4/10/2002 -0700, Glenn Linderman wrote: >"Mark J. Reed" wrote: > > > > On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote: > > > method m1 > > > { > > >m2; # calls method m2 in the same class > > Yes, but does it call it as an instance method on the current invocant >

Re: I'll show you mine...

Melvin Smith <[EMAIL PROTECTED]> writes: > At 09:23 AM 4/10/2002 +0100, Piers Cawley wrote: >>Okay, this is the beginnings of Scheme in Perl6. I'm sure there's >>stuff I'm getting wrong. I've not written the parser yet for instance > > Very nice! Quite a sample, maybe Larry/Damian can use this >

Re: Unary dot

Melvin Smith <[EMAIL PROTECTED]> writes: > At 10:50 AM 4/10/2002 -0700, Glenn Linderman wrote: >>"Mark J. Reed" wrote: >> > >> > On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote: >> > > method m1 >> > > { >> > >m2; # calls method m2 in the same class >> > Yes, but does it call

Re: Unary dot

On Wed, Apr 10, 2002 at 01:35:22PM -0400, Mark J. Reed wrote: > On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote: > > method m1 > > { > >m2; # calls method m2 in the same class > Yes, but does it call it as an instance method on the current invocant > or as a class method with

Re: Unary dot

Graham Barr wrote: > > On Wed, Apr 10, 2002 at 01:35:22PM -0400, Mark J. Reed wrote: > > On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote: > > > method m1 > > > { > > >m2; # calls method m2 in the same class > > Yes, but does it call it as an instance method on the current inv

Re: Unary dot

Graham Barr <[EMAIL PROTECTED]> writes: > On Wed, Apr 10, 2002 at 01:35:22PM -0400, Mark J. Reed wrote: >> On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote: >> > method m1 >> > { >> >m2; # calls method m2 in the same class >> Yes, but does it call it as an instance method on t

Re: Unary dot

Glenn Linderman <[EMAIL PROTECTED]> writes: > Graham Barr wrote: >> >> On Wed, Apr 10, 2002 at 01:35:22PM -0400, Mark J. Reed wrote: >> > On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote: >> > > method m1 >> > > { >> > >m2; # calls method m2 in the same class >> > Yes, but do

Re: Unary dot

On Wed, Apr 10, 2002 at 07:57:01PM +0100, Piers Cawley wrote: > > ::m2; # calls global subroutine main::m2 > > main::m2; # calls global subroutine main::m2 > > This is looking more and more horrible Glenn. I think we need to back off of unmarked subroutines becoming a method call. That one extr

Re: Unary dot

On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote: > Allison Randal wrote: > > > > Direction 2 moves into the more exciting but scarier realm of alternate > > defaults. > > It could, but how about an alternative? Ah-ha, yet a third Direction! > Need there be a unary dot to speci

Re: Unary dot

On Wed, Apr 10, 2002 at 03:03:45PM -0400, Mark J. Reed wrote: > ..class.m2: # call static m2 within m1's class, regardless of how m1 was called Typo. That should be just .class.m2, only one leading '.'. -- Mark J. REED<[EMAIL PROTECTED]>

RE: Unary dot

Mark J. Reed wrote > On Wed, Apr 10, 2002 at 03:03:45PM -0400, Mark J. Reed wrote: > > ..class.m2: # call static m2 within m1's class, regardless > of how m1 was called > Typo. That should be just .class.m2, only one leading '.'. Wouldn't that be the current topic's class? Dave.

Re: Unary dot

On Wed, Apr 10, 2002 at 12:12:56PM -0700, David Whipp wrote: > Mark J. Reed wrote > > On Wed, Apr 10, 2002 at 03:03:45PM -0400, Mark J. Reed wrote: > > > ..class.m2: # call static m2 within m1's class, regardless > > of how m1 was called > > Typo. That should be just .class.m2, only one leading

Re: Avoiding the deadlands

At 4:54 AM -0400 4/9/02, Michel J Lambert wrote: > > So, I think #2 is the way to go. We'll add a new flag, >> (BUFFER|PMC)_stay_of_execution_FLAG or something, that gets added to >> allocated PMCs and Buffers. It'll be treated the same way as the >> constant/immortal flag is treated for DOD p

Patches, patches, patches...

To forestall potential incidents of Warnock's Dillemma... I'm about to apply a whole heap 'o patches to Parrot. (With appropriate [APPLIED] responses, I hope) If, at the end of the day, I have *not* applied or commented on a patch you've sent, it means I've Officially Missed It, so give anothe

Re: PMC confusion

At 12:47 AM -0500 4/2/02, Will Coleda wrote: >I can't concat strings to a PerlString, I have to assign the constant >string to another PerlString to do the concat... > >Is this just that a suitable entry in perlstring.pmc needs to be >created? Yep. -- Dan

Re: [PATCH] Parrot_(re)allocate_buffer

At 6:52 PM -0500 4/3/02, Bryan C. Warnock wrote: >On Wednesday 03 April 2002 16:55, Michel J Lambert wrote: >> > Why add new functions instead of patching the current ones? >> >> I didn't know if the original functions still had a purpose. Perhaps you >> would want to Parrot_allocate for someth

Re: Patches, patches, patches...

At 12:40 PM 4/10/2002 -0400, Dan Sugalski wrote: >To forestall potential incidents of Warnock's Dillemma... > >I'm about to apply a whole heap 'o patches to Parrot. (With appropriate >[APPLIED] responses, I hope) If, at the end of the day, I have *not* >applied or commented on a patch you've sen

Re: Patches, patches, patches...

At 12:53 PM -0400 4/10/02, Melvin Smith wrote: >At 12:40 PM 4/10/2002 -0400, Dan Sugalski wrote: >>To forestall potential incidents of Warnock's Dillemma... >> >>I'm about to apply a whole heap 'o patches to Parrot. (With >>appropriate [APPLIED] responses, I hope) If, at the end of the day, >>I

Memory allocation changes

Okay, having seen the discussion and now realized that my initial cut was too rough, here are some changes: Parrot_allocate now takes a Buffer pointer and allocates into it, setting the length to what was really allocated. Parrot_reallocate takes a Buffer pointer and a size, and resizes things

[PATCH] PerlString fixes (and tests)

The enclosed patch makes a number of changes to perlstring.pmc, to bring it in line with my understanding of how PMCs are supposed to work. Specifically, unless we _know_ the type of the source and destination PMCs, we should always access them through their get_... and set_... methods. In

Re: Unary dot

On Wed, Apr 10, 2002 at 03:03:45PM -0400, Mark J. Reed wrote: > On Wed, Apr 10, 2002 at 07:57:01PM +0100, Piers Cawley wrote: > > > ::m2; # calls global subroutine main::m2 > > > main::m2; # calls global subroutine main::m2 > > > > This is looking more and more horrible Glenn. > I think we need t

Re: none

Ashley Winters <[EMAIL PROTECTED]> writes: >> Patches welcome. > > Excellent... > > Forgive any formatting errors, I have mail issues. Thanks, applying. With a few caveats. > @@ -62,6 +62,7 @@ > class SchemePair is SchemeExpr { >my $nil //= class is SchemeExpr { > method is_nil {1} >

Re: Unary dot

On Wed, Apr 10, 2002 at 02:42:58PM -0500, Allison Randal wrote: > > I like the following, assumed to be within method m1: > > > > ..m2();# call m2 the same way m1 was called, instance or class > > This has already been semi-rejected. I agree with the reasoning. Not > that it wouldn't be

Re: Unary dot

"Mark J. Reed" <[EMAIL PROTECTED]> writes: > On Wed, Apr 10, 2002 at 07:57:01PM +0100, Piers Cawley wrote: >> > ::m2; # calls global subroutine main::m2 >> > main::m2; # calls global subroutine main::m2 >> >> This is looking more and more horrible Glenn. > I think we need to back off of unmarked

RE: Unary dot

Piers Cawley > > This may be a case of keep up at the back, but if that is a > method call, > > how do I call a subroutine from within a method ? > > [...] > > Yes, I know there's several different ways I could do it, but this > approach feels right. I think this comes does to huffmann encodi

Re: Unary dot

"David Whipp" <[EMAIL PROTECTED]> writes: > Piers Cawley >> > This may be a case of keep up at the back, but if that is a >> method call, >> > how do I call a subroutine from within a method ? >> >> [...] >> >> Yes, I know there's several different ways I could do it, but this >> approach fee

Re: Unary dot

> The following syntaxes have been seen: > > foo() > .foo() > ..foo() ## rejected because ".." is different binary op > class.foo() > FooClass.foo() > ::foo() > Package::foo() > $foo() > $_.foo() With a nod to Piers, and with apologes if this is silly in the context of Perl 6 syntax, wh

Re: Unary dot

On Wed, Apr 10, 2002 at 03:49:44PM -0400, Mark J. Reed wrote: > On Wed, Apr 10, 2002 at 02:42:58PM -0500, Allison Randal wrote: > > > I like the following, assumed to be within method m1: > > > > > > ..m2(); # call m2 the same way m1 was called, instance or class > > > > This has already be

Re: I'll show you mine...

great idea :") I've just tried gnuCash program and think it is very cool (i've enjoyed to take first steps in double-entry accounting, i was always wondering what the hell is this :") )... http://www.ncsysadmin.org/july2001/ncsa-gnucash-talk.html#toc1 (very entertaining intro :") ) Meanw

Re: Unary dot

On Wed, Apr 10, 2002 at 09:23:23PM +0100, Piers Cawley wrote: > "David Whipp" <[EMAIL PROTECTED]> writes: > > > Thus, the perl5 transalations would be: > > > > foo() => $self->foo() > > .foo() => $_->foo() > > &foo() => foo() > > ... > > For reasons that I can't quite put my finger on at

Re: Unary dot

> > "David Whipp" <[EMAIL PROTECTED]> writes: > > > > > Thus, the perl5 transalations would be: > > > > > > foo() => $self->foo() > > > .foo() => $_->foo() > > > &foo() => foo() > > > ... Alternative: $self.foo() => $self->foo() # and can be .foo() when $self is $_ .foo() => $_->f

Re: Unary dot

> > $.foo > > It's already defined as an instance variable. I don't think I like that. Instance variables are far more common that class variables, so why not just $foo, and you could use a compile-time property for class variables. Like C as discussed. That or C. I think the latter mak

Re: Unary dot

Allison wrote: > > > > "David Whipp" <[EMAIL PROTECTED]> writes: > > > > > > > Thus, the perl5 transalations would be: > > > > > > > > foo() => $self->foo() > > > > .foo() => $_->foo() > > > > &foo() => foo() > > > > ... > > Alternative: > >$self.foo() => $self->foo() # and can be .

Re: Unary dot

On Thu, Apr 11, 2002 at 08:04:56AM +1000, Damian Conway wrote: > Allison wrote: > > > >$self.foo() => $self->foo() # and can be .foo() when $self is $_ > >.foo() => $_->foo() # but might be altered by a pragma > >foo() => foo() > > > And welcome back to where we started! ;-) Exact

Non-anchored GC memory?

Can anyone think of a good enough reason to allow unanchored GCable memory? I can see it being useful for really temporary allocations that later get dropped, but that seems horribly error-prone, and I'm not sure I want to set us up for tracking down that sort of thing for the rest of eternity

Re: Worst-case GC Behavior?

At 9:39 AM +0200 4/9/02, Peter Gibbs wrote: >One option might be a >threshold - if, after the DOD run, there is still less than N headers >available, allocate more even though we can satisfy the immediate >requirement. This would improve performance by reducing the number of DOD >runs, but at the

Re: Worst-case GC Behavior?

> >One option might be a > >threshold - if, after the DOD run, there is still less than N headers > >available, allocate more even though we can satisfy the immediate > >requirement. This would improve performance by reducing the number of DOD > >runs, but at the cost of additional memory - a clas

Re: Worst-case GC Behavior?

At 4:38 PM -0400 4/10/02, Michel J Lambert wrote: > > >One option might be a >> >threshold - if, after the DOD run, there is still less than N headers >> >available, allocate more even though we can satisfy the immediate >> >requirement. This would improve performance by reducing the number of

Re: Non-anchored GC memory?

On Wed, Apr 10, 2002 at 03:52:09PM -0400, Dan Sugalski wrote: > Can anyone think of a good enough reason to allow unanchored GCable > memory? I can see it being useful for really temporary allocations > that later get dropped, but that seems horribly error-prone, and I'm > not sure I want to se

I submit for your aproval . . .

Hey guys: Here is what I have so far of the string_nprintf function. As of now it only handles C string backslash escape sequences and regular chars from the format string. My primary concern is whether I am using BUFFER_immobile_FLAG the correct way to protect myself from GC. I also dont kn

Re: I submit for your aproval . . .

At 6:29 PM -0400 4/10/02, Roman Hunt wrote: >Hey guys: > Here is what I have so far of the string_nprintf function. As of now it > only handles C string backslash escape sequences and regular chars >from the format string. My primary concern is whether I am using >BUFFER_immobile_FLAG the cor

Re: I submit for your aproval . . .

In message Dan Sugalski <[EMAIL PROTECTED]> wrote: > At 6:29 PM -0400 4/10/02, Roman Hunt wrote: > > >also I think > >encoding_lookup() should accept an argument of "native". > > Good point, they should. OTOH, that makes some of this interestin

Re: Unary dot

At 07:40 PM 4/10/2002 +0100, Piers Cawley wrote: >Melvin Smith <[EMAIL PROTECTED]> writes: > > > At 10:50 AM 4/10/2002 -0700, Glenn Linderman wrote: > >>"Mark J. Reed" wrote: > >> > > >> > On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote: > >> > > method m1 > >> > > { > >> > >m2

Re: Unary dot

At 07:54 PM 4/10/2002 +0100, Piers Cawley wrote: >Graham Barr <[EMAIL PROTECTED]> writes: > > > On Wed, Apr 10, 2002 at 01:35:22PM -0400, Mark J. Reed wrote: > >> On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote: > >> > method m1 > >> > { > >> >m2; # calls method m2 in the same

Re: Unary dot

At 08:04 AM 4/11/2002 +1000, Damian Conway wrote: >And welcome back to where we started! ;-) Wow there is a lot of blood on the ground here. Must have been messy... :) >Of course, the problem is then: what should the name of this topicalizer >variable be? The main options are: > > $self

RE: Unary dot

Melvin Smith wrote > I think that would be just plain bad design, but I'd be happy > if someone showed me a use for it. :) well, I've been known to do sub UNIVERSAL::debug { my $self = shift; my $msg = "@_"; eval {$self=$self->name} if ref($self); my $timestamp = ...; my

Defaulting params

The current plans indicate that a subroutine's params should be defaulted like this: sub load_data ($filename ; $version / /= 1) {...} (The space between / and / is on purpose, my emailer has problems if they are together.) If that's the technique, how does the caller indicate that the secon

Re: Unary dot

On Thu, Apr 11, 2002 at 08:04:56AM +1000, Damian Conway wrote: > > Reflecting on this, it seems that it would be useful if methods > implicitly did their default topicalization-of-invocant like so: > > -> $self > > rather than just: > > -> $_ > > That is, that as well as aliasing

Re: Unary dot

Allison Randal wrote: > H... this being the case, is there any reason we should ever need to > name the invocant explicitly? Yes. To make it read-writable. Perl makes that much easier than most other languages, because you can pass the invocant by (writable) reference, so you don't need to

Re: Unary dot

On Thu, Apr 11, 2002 at 12:01:58PM +1000, Damian Conway wrote: > Allison Randal wrote: > > > H... this being the case, is there any reason we should ever need to > > name the invocant explicitly? > > Yes. To make it read-writable. Curses! Foiled again! :) > Perl makes that much easier th

Re: Unary dot

At 04:01 PM 4/10/2002 -0600, Luke Palmer wrote: > > > $.foo > > > > It's already defined as an instance variable. > >I don't think I like that. Instance variables are far more common that >class variables, so why not just $foo, and you could use a compile-time >property for class variables. L

Re: Patches, patches, patches...

On Wednesday 10 April 2002 12:53 pm, Melvin Smith wrote: > I think there is at least one outstanding patch from Brian Warnock called: > "stacks.c" Hmmm, looking in my outbox, I see only one recent patch of mine that mentions stacks.c, and its been applied. (Although I don't know when. It could

Re: Patches, patches, patches...

At 10:40 PM 4/10/2002 -0400, Bryan C. Warnock wrote: >On Wednesday 10 April 2002 12:53 pm, Melvin Smith wrote: > > I think there is at least one outstanding patch from Brian Warnock called: > > "stacks.c" > >Hmmm, looking in my outbox, I see only one recent patch of mine >that mentions stacks.c, a

What I'm working on before I go offline for 2 weeks

I'm getting married Saturday and going on honeymoon for 10 days. So I'll just update you guys on what I'm working on just in case I fall of the face of the earth for the next 2 weeks, I have a lot of unflushed stuff. Parrot: 1) Porting to WinCE for PocketPC The first cut will be posted as

Re: Unary dot

Damian Conway <[EMAIL PROTECTED]> writes: [...] > Reflecting on this, it seems that it would be useful if methods > implicitly did their default topicalization-of-invocant like so: > > -> $self > > rather than just: > > -> $_ > > That is, that as well as aliasing the invocant to $_,

Re: Unary dot

Luke Palmer <[EMAIL PROTECTED]> writes: >> > $.foo >> >> It's already defined as an instance variable. > > I don't think I like that. Instance variables are far more common that > class variables, so why not just $foo, and you could use a compile-time > property for class variables. Lik

Re: Defaulting params

"Miko O'Sullivan" <[EMAIL PROTECTED]> writes: > The current plans indicate that a subroutine's params should be defaulted > like this: > >sub load_data ($filename ; $version / /= 1) {...} > > (The space between / and / is on purpose, my emailer has problems if > they are together.) If that's

Re: Unary dot

> Ah, but I think the mnemonic value of the '.' more than earns its keep > here. C is doing a slightly different job > anyway. And instance variables are *not* the same as 'normal' > variables, they hang off a different symbol table (or syte, to use > Damian's oh so clever term from Perl 5+i) and

Re: Defaulting params

On Thu, 11 Apr 2002, Piers Cawley wrote: > "Miko O'Sullivan" <[EMAIL PROTECTED]> writes: > > The current plans indicate that a subroutine's params should be defaulted > > like this: > > > >sub load_data ($filename ; $version / /= 1) {...} > > > > (The space between / and / is on purpose, my e

Re: Defaulting params

Piers wrote: > one could always handle the first case > more explicitly by doing: > >sub load_data ($filename; $version) { > $version = 1 if @_.length < 2; > ... >} Err...no. If you specify named parameters, you don't get @_. It could be handled by overloading though:

Re: Defaulting params

Damian Conway <[EMAIL PROTECTED]> writes: > Piers wrote: > >> one could always handle the first case >> more explicitly by doing: >> >>sub load_data ($filename; $version) { >> $version = 1 if @_.length < 2; >> ... >>} > > Err...no. If you specify named parameters, you don't g

Re: Defaulting params

> Ooh. Multiple dispatch is definitely in then? Not definite yet. That was a subjunctive "could". ;-) But I'm very hopeful, since it's hard to user-implement things like C unless you can give a subroutine several distinct signatures. Damian