Perl 6 - the future is here, just unevenly distributed

IRC log for #perl6, 2006-01-04

Perl 6 | Reference Documentation | Rakudo

| Channels | #perl6 index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:19 luqui Ha!  I've got it!  Schweet!
00:22 stevan joined perl6
00:23 * stevan wonders what luqui has "got"
00:24 luqui The solution to the reference problem
00:24 luqui Er, I at least have the idea that will lead to the solution
00:24 * Debolaz almost feels bad using a VCS written in python.
00:25 luqui The idea is that a "true" Any type doesn't exist.  Every type is either Singular or Plural, and they have no common supertype.
00:25 luqui (tagged union)
00:25 luqui but let me finish writing...
00:28 Juerd_ joined perl6
00:29 Juerd_ luqui: Sounds much like my view of things. Unfortunately, I'm continuously unable to express the structure that exists in my mind.
00:30 * luqui felt the same way, took a long walk, and got it 1/4 of the way figured out
00:30 Juerd_ Hmm. pugs.blogs.com says that Scalar does Ref
00:30 Juerd_ Is that actually true?
00:30 luqui for *some* definition of "true", yes
00:31 Juerd_ I've always thought that Scalar did not do Ref, and neither would Num, Int and Str
00:31 luqui nobody really knows what's going on with the type hierarchy yet
00:31 luqui stevan+ is trying to get that sorted out
00:31 Juerd_ That is: Num, Str and Ref below Scalar
00:31 luqui er, stevan++
00:31 Juerd_ Int below Num
00:31 Juerd_ Hash, Array, Dog, Foo under Ref
00:31 Juerd_ etc
00:32 Juerd_ i.e. "real" values and "referenced" values, the latter being true objects, the former being usable via OO syntax, but not really objects.
00:33 luqui hmm, I agree with that
00:33 Juerd_ A reference itself would be a real value
00:33 luqui Ref (or something, at least) should be reserved for things with referential semantics
00:33 luqui maybe there's a Ref/Value distinction
00:33 Juerd_ And implicit copying (as with assignment) copies only real values
00:33 luqui though if List is a Value, we have a problem with the exclusivity of Singular/Plural
00:33 Juerd_ i.e. $foo = $bar copies over $bar's value to $foo, but if $bar is any kind of Ref, the reference is copied, not the referencee
00:34 * luqui is aware of implicit copying
00:34 Juerd_ I'm not teaching, I'm explaining the distinction as I think of it
00:34 luqui ah
00:34 Juerd_ Because I know that some people, like TSa heavily disagree that this is a good way to do things.
00:35 Juerd_ Lists as objects really hurt my mind
00:35 Juerd_ That is: lists.
00:35 Juerd_ We badly need new terminology.
00:35 joepurl joined perl6
00:35 luqui see, that's why you get muddied up easily
00:35 luqui you say things like "lists as objects", when the thing you need to define is "object", not "list"
00:35 Juerd_ Currently, Lists and lists are RADICALLY different things :(
00:36 perlbot joined perl6
00:36 Juerd_ The distinction between Array and array is finally clear, and only a little one: in general, an array is @foo, and an Array is $foo
00:36 luqui In the proposal I'm writing (which covers this distinction), I'm using object loosely as a "thing that has a type"
00:36 luqui although there is no "type of all objects"
00:36 Juerd_ Where @foo in scalar context is as Array as $foo, but that's a different story
00:37 Juerd_ I think it's wise to keep "object" as its Perl 5 meaning.
00:37 luqui blessed reference?
00:37 Juerd_ Well, reference
00:37 luqui perhaps I should change it to "thingy" and define "thingy" at the top
00:37 Juerd_ OO and objects are not fully related, confusingly
00:37 Juerd_ $foo.bar is OO, but $foo isn't necessarily an object (reference)
00:37 kakos joined perl6
00:38 Juerd_ I've noticed that numbers and strings are generally not called object.
00:38 Juerd_ As values
00:38 luqui Perl calls them objects
00:38 luqui er...
00:38 Juerd_ That's confusing.
00:38 luqui well, I think you just need to redefine how you think of object to match how Larry thinks of it
00:38 stevan Juerd_: I prefer to look at it as; everything is an object,.. but you can safely ignore that fact in many cases
00:39 luqui which is how Larry wants us to think about it :-)
00:39 Juerd_ That's fine with me, but then we just still need to have a distinction between referenced and pure objects.
00:39 Juerd_ And terminology for that.
00:39 luqui Juerd_, we do
00:39 luqui you just never use it
00:39 luqui reference types and value types
00:39 Juerd_ Or to decide that everything is an object in equal ways, and make $foo = $bar always copy reference.
00:39 Juerd_ "value" is so broad :(
00:39 luqui it's like mathematics
00:40 luqui or at least, I speak of them like mathematics
00:40 Juerd_ I think very specific words are needed, because this is SO fundamental to Perl.
00:40 luqui some of the names may seem vague from an English perspective, but I'm using them with a very presice definition
00:40 Juerd_ I've used "pure" versus "referenced" for years, but they're not generally accepted words.
00:40 luqui Juerd_, yes, vocabulary is important
00:40 luqui "referenced" is fairly straightforward
00:40 luqui "pure" is quite ambiguous
00:40 luqui the rest of the world uses "reference" and "value"
00:40 Juerd_ My point is that we need a negation of referenced
00:41 Juerd_ That isn't "unreferenced" because that word sucks.
00:41 luqui sometimes you just have to put up with the bullshit and accept the term that everyone else uses
00:41 Juerd_ Too long, and focusses on something that isn't the fundament.
00:41 Juerd_ The problem with "value" is that it exists in every level of language AND implementation
00:41 luqui and use language to disambiguate when you're talking about "value" in general, and when you're talking about "value" as opposed to "reference"
00:42 stevan Juerd_: there maybe a lot of desugaring going on too, to translate the (somewhat insane at times) surface syntax into a (slightly saner, and easier to work with) "runtime-engine" syntax
00:42 Juerd_ $foo *is* a value, but also *has* a value. Its "value" can be multiple values, and it may evaluate to a value that isn't in it.
00:42 luqui yeah, I know
00:42 stevan $foo is a Scalar,.. which is just a container for a value
00:42 Juerd_ Also, an object is generally a value, or a set of values too.
00:42 luqui I'm not terribly happy with the word
00:42 luqui but people have been using it for ages
00:42 luqui and "value type" is very ambiguous
00:42 Juerd_ luqui: I haven't noticed people using it in Perl context for ages.
00:42 luqui er, unambiguous
00:43 luqui Juerd_, that's because most people don't understand the difference
00:43 Juerd_ value type is all the more ambiguous, because people don't mind saying Array is a value type.
00:43 luqui but you will see it in overload.pm
00:43 * stevan thinks that if *everything* is an object, it makes more sense,.. at least to him
00:43 luqui Juerd_, I've never heard anyone say that
00:43 Juerd_ Although array values don't quite exist, if values are non-referenced.
00:43 Juerd_ luqui: Scan old Perl 1..5.0 documents for "array value" :(
00:43 luqui but not "array value type"
00:43 luqui the *phrase* "value type" is unambiguous
00:44 Juerd_ I'm not so sure.
00:44 luqui you can't take it apart
00:44 Juerd_ Also, I'm not at all convinced that continuing using the historical names is a good idea.
00:44 Juerd_ If the entire language is changed, then shouldn't we reconsider some jargon too?
00:44 luqui I'm not saying we have to.  If you come up with better ones, *propose them* and make sure everybody knows WTH you are talking about
00:44 Juerd_ We've been doing that for the less fundamental parts of the jargon too.
00:45 frodo72 left perl6
00:45 luqui Larry, Chip, and I use "value type"
00:45 Juerd_ Well, "pure". :)
00:45 luqui pure is no better
00:45 Juerd_ Agreed
00:45 Juerd_ However, less ambiguous.
00:45 stevan pure means side-effect free to me
00:45 Juerd_ Simply because it's not used much.
00:45 luqui it's actually worse, because it doesn't have history
00:45 Juerd_ luqui: I disgree that history makes anything good or bad.
00:45 luqui I'm defining "good" to mean "highest chance of being understood"
00:45 Juerd_ stevan: Good point; however, values are very clearly not functions.
00:46 luqui Juerd_, but functions are values ;-)
00:46 stevan Juerd_: what luqui said :)
00:46 Juerd_ Maybe just "basic" values?
00:46 Juerd_ Java IIRC calls them "native types" :(
00:46 luqui yuck
00:46 Juerd_ But that's as bad as it gets.
00:46 luqui well, that's because you can't overload them
00:47 luqui in perl, you can tell it that your special object is a "value type"
00:47 luqui by overloading "="
00:47 Juerd_ Overloading is mostly a language thing. It's not exactly important for terminology.
00:47 luqui java doesn't let you do that; all user types are reference types
00:47 luqui well, it's a good reason that it's a good term in java and a bad term in perl
00:47 Juerd_ Does Perl 6 have any way to create a user type that isn't a ref type?
00:47 Juerd_ If so, how on earth?
00:47 luqui Juerd_, class Foo is value {...}
00:47 luqui but if you come up with a better name, we'll use that instead
00:47 Juerd_ Where's the value stored then?
00:47 Juerd_ The actual value, that is
00:47 luqui Juerd_, what do you mean?
00:48 luqui what actual value?
00:48 Juerd_ The number itself
00:48 Juerd_ Or the bytestring
00:48 luqui Juerd_, "is value" just refers to when "clone" is called
00:48 luqui that's the only difference
00:48 luqui (er, copy)
00:48 stevan Juerd_: in self (if I understand your questions correctly)
00:48 Juerd_ What's self?
00:49 luqui programming language
00:49 Juerd_ Self isn't a reference...
00:49 stevan an opaque wrapper around the value type,...
00:49 * stevan thinks he is not paying enough attention maybe to contribute effectively
00:49 stevan so I will shut up and go back to reading the Ada 95 standard library reference :)
00:50 Juerd_ We have two levels of boxing.
00:50 stevan which are?
00:50 Juerd_ That, I currently think, is the basis of the lingual confusion
00:50 Juerd_ One is from native type to full blown scalar
00:50 Juerd_ i.e. str to Str
00:51 Juerd_ And the other is what is Perl 5's autoboxing: "foo"->bar must reference "foo" before any bar can be called.
00:51 stevan I don't understand the second one,.. is that where a string can be a class name?
00:52 Juerd_ No, where a string can be an object.
00:52 Juerd_ This is not standard Perl 5, but requires a patch.
00:52 stevan oh yes, the autoboxing module
00:52 Juerd_ It will be standard Perl 6, but "boxing" has already been given another meaning.
00:52 stevan Juerd_: that is just sugar
00:53 stevan "foo".subtr(...) is really Str.new("foo").substr(...)
00:53 Juerd_ There's a major bootstrapping problem there, tohugh
00:53 stevan why?
00:53 Juerd_ What's the "foo" in the new call?
00:53 stevan it is a str
00:53 Juerd_ Is that also Str.new("foo")?
00:54 stevan nope
00:54 stevan it is an unboxed str
00:54 Juerd_ If so, is "foo" actually Str.new(Str.new(Str.new(Str.new(...
00:54 stevan no no no
00:54 stevan "foo" is a str
00:54 luqui little s
00:54 Juerd_ When it's boxed to be a Str, is it a reference then?
00:54 luqui no
00:54 stevan but when you attempt to call a method on that str, it gets boxed into a Str
00:54 luqui Str is still a "value type"
00:55 Juerd_ i.e., is self in substr, a reference to "foo", or "foo" itself?
00:55 stevan foo itself
00:55 stevan well not exactly
00:55 luqui stevan, no
00:55 luqui it's the Str object
00:55 luqui however it's layed out
00:55 Juerd_ Object being what?
00:55 luqui instance of class
00:56 stevan wait wait
00:56 Juerd_ Is it referenced, then?
00:56 stevan luqui: not exactly, but sort of
00:56 luqui Juerd_, what do you mean by referenced?
00:56 Juerd_ Is the actual string, the underlying \lstr, in some kind of self.value?
00:56 luqui and what do you mean by "it" :-)
00:56 luqui yes
00:56 luqui (according to me)
00:56 Juerd_ luqui: self.ref ?? "referenced" !! "not"
00:57 stevan in the PIL2 runtime we have a opaque type which can wrap any "native" or "unboxed" type
00:57 luqui Juerd_, .ref is always true now
00:57 Juerd_ Oh god.
00:57 luqui it just returns the class of the object
00:57 stevan eak, thats a bad name
00:57 Juerd_ So actually, every $foo is an object, and considered a reference, but REGARDLESS, it may implicitly copy value in assignment?
00:57 luqui basically, Str contains a *reference* to the native str
00:58 * luqui agrees about .ref being a bad name
00:58 stevan .class.name() is what I would prefer :)
00:58 luqui but because Str is a value type, its "clone" gets called to make it behave as if it were native
00:58 luqui stevan, or ~.class
00:58 Juerd_ No matter what the name, an attribute that has the same value for every object is absolutely redundant and should be factored out of the language
00:58 stevan luqui: reference in that context is ambigious I think
00:58 Juerd_ So if .ref is always true, get rid of .ref :)
00:58 luqui Juerd_, it's boolean value is always true
00:59 stevan Juerd_: it is always true, but not always the same value
00:59 Juerd_ Then make it .type?
00:59 Juerd_ Or .class?
00:59 pasteling joined perl6
00:59 luqui yeah, names, names
00:59 luqui .ref is terrible
00:59 Juerd_ Names are probably the most important thing at this stage.
00:59 * luqui thinks Juerd_ should post to p6l about all the places where things are incorrectly named
00:59 stevan you say toMato I say tOmato ...
00:59 luqui I say grapefruit.
00:59 Juerd_ I can't stress it more. The current jargon is very ambiguous and inconsistently applied.
01:00 luqui Juerd_, the thing about vocabulary
01:00 Juerd_ And my impression is that it hurts understanding
01:00 luqui every word represents a concept
01:00 luqui and you have to understand the concepts to use vocabulary correctly
01:00 Juerd_ Agreed
01:00 luqui Juerd_, you know the difference between "argument" and "parameter"?
01:00 Juerd_ Yes.
01:00 luqui good.  many people don't.
01:00 luqui that's why they get confused.
01:00 Juerd_ Arguments are passed, parameters expected (terribly abstracted, and thus no longer entirely true)
01:01 stevan one starts with an "a", and the other with a "p" ,... duh!
01:01 luqui many new programmers aren't aware of the concepts they represent
01:01 Juerd_ We already have an important difference between array and ist
01:01 Juerd_ list
01:01 luqui they don't see the difference between arguments and parameters as concepts, irrespective of words
01:01 Juerd_ This has been fixed somewhere in the perl 5 development.
01:01 luqui so the terms get abused and muddled
01:01 Juerd_ All "array context" and "array value" were transliterated to "list context" and "list"
01:01 Juerd_ Which was very good.
01:01 luqui hooray!
01:02 * stevan thinks a Perl6::Glossary is probably a good idea
01:02 Juerd_ Now, we have the same mistake again, having lists and lists
01:02 Juerd_ Where a List object does not represent a list, and a list cannot be encapsulated in a List object
01:02 luqui Juerd_, yes.  but the differences are yet more subtle in perl 6's object mode
01:02 Juerd_ Because they're very different stuff.
01:02 luqui model
01:02 luqui so we have to know what they are before we name them
01:02 luqui and that's the hardest part
01:02 Juerd_ List has nothing to do with list context, for example.
01:02 luqui that's because we don't know what List is
01:02 Juerd_ Right
01:03 Juerd_ But in any case, if it's an object, it's singular
01:03 luqui that's why I'm writing this fricking proposal!
01:03 Juerd_ While a list, by definition, is plural
01:03 Juerd_ So rename one of them
01:03 luqui List is Plural
01:03 luqui and you can't put a List into a scalar variable
01:03 luqui List is a "thingy", but it's not Singular for sure
01:03 Juerd_ Every object can be in a scalar variable.
01:03 Juerd_ Because it's referenced
01:03 luqui so then it's not an object
01:03 Juerd_ A list, historically, can not be referenced
01:03 Juerd_ Or re-used
01:03 luqui (you're using those vague words again)
01:04 Juerd_ Or stored
01:04 Juerd_ A list is, in Perl 5, and hopefully still in Perl 6, whatever is in list context.
01:04 luqui they're not exactly equivalent in my proposal
01:04 Juerd_ With in Perl 5 the exception of a paren-expression on ='s lhs.
01:04 luqui but they're close
01:05 Juerd_ So, in @foo = @bar,
01:05 Juerd_ @foo is an array
01:05 Juerd_ @bar is an array
01:05 Juerd_ @bar evaluates to a list
01:05 Juerd_ @foo is assigned a list
01:05 luqui yep
01:05 Juerd_ None of these are (can be) List though
01:05 Juerd_ And if it can, I ask you why that would make sense :)
01:05 Juerd_ If lists start to be objects, a very simple thing in the language gets turned into something wildly complex.
01:05 luqui they can be List
01:06 luqui see, the thing that's confusing you
01:06 Juerd_ Without doubt :)
01:06 luqui is that I'm giving a formal, language-level definition for List
01:06 Juerd_ Let me put it differently. Why are Lists needed?
01:06 luqui whereas you seem to think there can't be one
01:06 luqui to give a formal definition to them
01:06 Juerd_ What purpose do they serve?
01:06 Juerd_ No, in the language
01:06 luqui so we know what the heck we're talking about
01:06 Juerd_ We have a good reason to have arrays, we have a good reason to have lists
01:06 luqui they serve as the thing that you assign to an array
01:06 Juerd_ What is a List, and why is it needed?
01:06 luqui List is a list
01:06 luqui that's the whole idea
01:07 Juerd_ Why would a list ever be an object?
01:07 luqui there's no subtle difference.  the "list" you've been talking about is List
01:07 luqui Juerd_, by your definition, it's not
01:07 Juerd_ And have a \utypename
01:07 luqui because Lists have types
01:07 Juerd_ Why is List itself a type?
01:07 luqui it's the type of a list
01:07 luqui but List.does(Object) is not true!
01:07 Juerd_ No, why does list have to be a class?
01:07 luqui I didn't say it was a class.
01:08 Juerd_ I thought List.does implied that
01:08 luqui there's that subtle distinction again, between "type" and "class"
01:08 Juerd_ Why do we write both with a capital?
01:08 luqui because every class has a type
01:08 luqui and it's okay to confuse them in that respect
01:09 Juerd_ And, note, that your List, if it is the same as list, is not the same as Larry's List.
01:09 luqui but there are types that aren't classes
01:09 * luqui knows
01:09 Juerd_ Okay, that helps. I had been assuming you meant Larry's List.
01:09 luqui ahh
01:09 luqui my proposals have a tendency to throw out anything that doesn't agree with them
01:09 Juerd_ Be sure to make that explicit :)
01:09 luqui thanks :-)
01:10 Juerd_ We may have been agreeing all this time
01:10 stevan which sort algorithm should I use for ::Array.sort?
01:10 Juerd_ Although I don't quite understand why we would ever talk about Lists instead of lists.
01:10 stevan any preference?
01:10 Juerd_ The capital L makes it feel like an object(type)
01:10 luqui stevan, quicksort is nice
01:10 luqui yeah, that's the problem with capitals.
01:11 stevan luqui: thanks
01:11 Juerd_ Also, I don't know why it's relevant to have a type for them :)
01:11 f0rth joined perl6
01:12 luqui Juerd_, you need types for stuff if you want to do type analysis
01:12 Juerd_ I think of a list of Dogs as "multiple Dog-s"
01:12 Juerd_ And I think of a single dog as "one Dog"
01:12 luqui i.e., when you say map {...}  @foo,  the type inferencer has to be able to type @foo
01:12 luqui otherwise the expression would not be well-typed
01:12 luqui which implies an error
01:13 luqui the other reason is that it's a good idea to make your concepts explicit in your code
01:13 Juerd_ Yes, lists have type, but that should be the type of the elements, not the type of the list itself
01:13 sri_ joined perl6
01:13 luqui Juerd_, but there's a difference between a list of A's and an A
01:13 luqui so there has to be a difference somewhere
01:13 Juerd_ Why?
01:13 luqui because there is one
01:13 Juerd_ Why not just the plurality?
01:13 luqui it is just the plurality
01:14 luqui the type of plural things is Plural
01:14 luqui making concepts explicit
01:14 Juerd_ Alternatively, can't we abstract things so far that we end up with only arrays?
01:14 luqui probably not
01:14 Juerd_ Other languages have succeeded...
01:14 Juerd_ Though they do not have list context.
01:14 luqui example?
01:14 Juerd_ Eh, ruby, javascript, php, ...
01:14 luqui oh, only arrays, I get it
01:15 luqui that's pretty much what I'm trying to do... except I'm keeping the same semantics as perl
01:15 luqui giving List a formal type, that's what it takes
01:15 luqui and that seems like it's trivial, but it's actually very difficult
01:15 Juerd_ I'm not convinced, but I think it'd be a good idea to just wait for your document and not judge too early.
01:15 luqui what exactly does the List type do, and how does it interact with the rest of the language
01:16 Juerd_ I think it's difficult because lists are a concept rather than a type comparable to other types in Perl.
01:16 luqui and it interacts with the language in a *very* different way from most types
01:16 Juerd_ Yes, but have you considered that this may be because it doesn't behave in *any* way like any other *type*?
01:16 luqui Juerd_, precisely
01:16 luqui so I'm growing the definition of type
01:16 luqui it's got to be something
01:16 Juerd_ Because it's on the same level as type, not below it?
01:16 luqui you can't just say it's nothing
01:17 Juerd_ It's not a type, but of the type that type is.
01:17 Juerd_ There are items and lists
01:17 Juerd_ An item has one element, a list has any number of elements.
01:17 Juerd_ Elements have types
01:17 luqui here's the type "tree":  Singular [ Object [ ...stuff... ] ]   Plural [ List ]
01:17 luqui note that it has not root
01:17 Juerd_ item and list are not types, but contexts.
01:17 luqui that's the key point
01:18 Juerd_ I think what I'm saying is that Plural == List
01:18 luqui there is no type that can simultaneously be Singular and Plural
01:18 luqui Juerd_, but why not separate them to allow more plural types if we think of them
01:18 Juerd_ I think item and list have exactly the same subtree.
01:18 Juerd_ And that this subtree describes the *elements*, not the item, not the list.
01:18 Juerd_ We already have more plural types.
01:19 luqui Juerd_, what you're doing is exactly the same thing as the aggregation/inheritance descision in OO design
01:19 Juerd_ In fact, we have plural types that are conceptually singular: junctions.
01:19 luqui I'm taking the aggregation method, you're taking the inheritance method
01:19 luqui Juerd_, junctions suck.
01:19 Juerd_ In general, maybe we have item, list and set.
01:19 luqui they confuse concepts all over the place.
01:20 Juerd_ Where the only difference between set and list is order and multiplicity.
01:20 luqui Juerd_, you'd only have set if sets behave fundamentally different from items
01:20 luqui which they don't.  you can put them in scalars.
01:20 luqui (unless you propose that we can't)
01:20 Juerd_ One can put sets in scalars, the same way one can reference arrays in scalars
01:20 luqui sure
01:20 luqui but you can't put a list in a scalar
01:20 luqui and that's what puts them at the top level of the hierarchy with no supertype
01:20 Juerd_ But we've already discovered in earlier perls that the distinction between runtime and storage methods is useful. That's why we have arrays AND lists.
01:21 luqui I know
01:21 luqui I'm not saying Array doesn't exist
01:21 luqui oh, sets, right
01:21 luqui can you think of a reason to have set be fundamental?
01:21 Juerd_ Many.
01:21 luqui what's that?
01:21 Juerd_ Sets are generally undecided junctions
01:21 Juerd_ I think they should have their own sigil, and their own context.
01:21 luqui Juerd_, don't ever say junction again
01:21 justatheory joined perl6
01:21 Juerd_ Why?
01:22 luqui I've put them out of my mind until we have any idea what they are
01:22 Juerd_ They're a specced part of the language, and hard to implement or easy to implement depending on decisions made these days.
01:22 luqui they are very poorly defined
01:22 Juerd_ Well, I can define them quickly if you want, through sets.
01:22 luqui Juerd_, okay, go
01:22 Juerd_ Because they ARE sets.
01:22 luqui yeah
01:22 luqui well, they're "references to sets" of a certain nature.
01:23 Juerd_ In current spec, sure, but that spec sucks ;)
01:23 luqui or are you saying that $x = 1|2  contains not a junction, but a reference to a junction?
01:23 Juerd_ Sets are lists, but cannot have duplicate items, and do not have order.
01:23 Juerd_ Sets should be storable in array-like things, the way lists are storable in arrays
01:23 Juerd_ We lack jargon, so both are sets.
01:24 luqui set would be Plural, no?
01:24 Juerd_ Set context is like list context, and in all respects the same unless we specifically care
01:24 luqui and it would not be a List, no?
01:24 Juerd_ Yes.
01:24 luqui there's one good reason to separate Plural and List ;-)
01:24 luqui in case we think of set :-)
01:24 Juerd_ Okay, if you want: plural is the parent of list and set.
01:24 luqui uh huh
01:24 Juerd_ (Not literally "parent", but just for hierarchy)
01:25 luqui but it actually is the parent
01:25 Juerd_ A junction is a set that is *used*
01:25 luqui you're just thinking old-style about types...
01:25 luqui anyway
01:25 luqui Juerd_, are you saying that sets have state?
01:25 Juerd_ No?
01:25 luqui okay, explain used
01:25 Juerd_ If the set-array has the S sigil (contrived, for example purposes)
01:25 luqui maybe it should have the % sigil
01:26 luqui keep with S for now
01:26 luqui I'm just brainstorming
01:26 Juerd_ Then I would suggest that 1 | 2 desugar to (Sdummy = (1, 2)).any
01:26 Juerd_ Although without the dummy variable, and storing the .any in a currying-like way
01:26 luqui and what does that .any return?
01:26 Juerd_ So in fact, a junction would be a wrapper around the set.
01:27 Juerd_ .any returns a programmed view of the set.
01:27 luqui programmed?
01:27 Juerd_ tied.
01:27 luqui okay
01:28 Juerd_ If we have fundamental sets (which would enable lots of programming paradigms), junctions can be wrappers around them.
01:28 Juerd_ Which avoids inventing wheels.
01:28 luqui Juerd_, "enable programming paradigms"?
01:28 Juerd_ Sets are useful
01:28 luqui what paradigms would they enable that a set object wouldn't.
01:28 Juerd_ More useful than lists or arrays, when it comes to intersections.
01:29 Juerd_ Sets enable really relational things
01:29 luqui you're not answering my question
01:29 Juerd_ In the database-ish sense of the word.
01:29 luqui that question that I ended with a period :-)
01:29 Juerd_ Oh, sets *can* be objects
01:29 Juerd_ That's not the actual problem
01:29 Juerd_ However, arrays can be objects-only too
01:29 Juerd_ But we have both referenced arrays, and unreferenced ones
01:30 Juerd_ We have $array and @array.
01:30 luqui no, what do you get out of the fact that sets can also not be objects?
01:30 luqui Juerd_, we get list context out of the fact that lists are not objects
01:30 Juerd_ Hm. I had an idea about that, but can't think of it.
01:30 luqui and I argue that's all we get
01:31 Juerd_ I had a good reason to have set context.
01:31 Juerd_ Where set context would be like list context.
01:31 Juerd_ But in fact, I can't think of a good reason right now.
01:31 luqui named parameters?
01:31 luqui that's just unordered though
01:31 luqui more like "hash context"
01:31 luqui anyway, I'll go back to writing
01:31 Juerd_ Nah, it's not anything to do with pairs.
01:32 kanru joined perl6
01:32 SamB joined perl6
01:32 Juerd_ sub unique (Sfoo) { Sfoo } unique(@bar)
01:32 Juerd_ Though not a good reason, it's nice ;)
01:33 luqui that's coersion that can be done with objects :-)
01:33 Juerd_ sub unique (*@foo) { Set.new(@foo).values } unique(@bar)
01:33 Juerd_ Ah, I remember.
01:34 Juerd_ Set context allows Perl to weed out duplicates and store in random order when doing the call
01:34 luqui an optimization argument?
01:34 Juerd_ More or less.
01:34 luqui well, too bad, you lose
01:34 luqui :-)
01:35 luqui that whole "demagicalizing pairs" fiasco was caused by a little premature optimization
01:35 Juerd_ I guess so.
01:35 luqui so no more optimization in language design
01:35 luqui but plenty more overgeneralization
01:35 Juerd_ But that leaves us both with no idea what a second plural context could be.
01:35 Juerd_ Or a second item context, even.
01:35 luqui sure, so let there only be one
01:35 Juerd_ So no reason to have anything above item and list.
01:36 Juerd_ (Which I really do prefer not to call Item and List)
01:36 Juerd_ Maybe even ITEM and LIST would be good.
01:36 luqui Singular, Plural
01:36 luqui dude, I've been through this
01:36 Juerd_ Singular and plural are great, except it's hard to code with them
01:37 Juerd_ "item" and "list" were more or less decided on, not because they're better than s/p, but because they're 4 letter words
01:37 Juerd_ void, item, list
01:37 luqui Singular and Plural will seldom be used
01:37 Juerd_ They map 1:1 to item and list
01:37 luqui they're fundamental, and we have shorthands all over the place for them
01:37 Juerd_ Why not call them that then?
01:37 Juerd_ And skip a level of abstraction
01:37 Juerd_ Levels can be added later on
01:38 luqui because you'd be skipping a level of abstraction
01:38 Juerd_ Skipping abstraction where possible I've always considered a good thing :)
01:38 luqui Item and List, I argue, are different concepts from Singular and Plural
01:38 Juerd_ There's something below Singular too
01:38 luqui ?
01:38 Juerd_ Nully
01:38 luqui ?
01:38 Juerd_ Or whatever a good name would be
01:39 Juerd_ Singular: exactly one, Plural: any number
01:39 Juerd_ (Name me!): exactly zero
01:39 luqui there *are* zero dogs.
01:39 luqui there *is* one dog
01:39 luqui there *are* two dogs
01:39 Juerd_ Then you can map void:(Name me!), item:Singular, list:Plural
01:39 luqui language doesn't make a distinction between exactly zero and any number
01:39 Juerd_ No, void has no type, i.e. no "dog"
01:39 Juerd_ Perl has always done so, in context.
01:40 luqui actually that's bad grammar.
01:40 Juerd_ And since this distinction so far only exists in context...
01:40 Juerd_ Nothingness isn't "no cats". It's nothing.
01:40 luqui math doesn't think that's true either
01:40 Juerd_ It's at the same time "no cats", "no dogs", "no trees" and "no cars", so including the things it's not makes little sense.
01:40 Juerd_ Note that this is not a 0-element plural thing, but a separate concept of nothingnes
01:40 Juerd_ s
01:41 Juerd_ void, in context jargon
01:41 luqui Juerd_, in Haskell, void is singular
01:41 luqui it's the unit type (), which has exactly one value: ()
01:41 luqui i.e. no information
01:41 luqui and I think that's a perfectly fine way to encode nothingness
01:41 Juerd_ But it's fundamentally different (Perl, not Haskell - I don't know H), in that it has no elements, and no knowledge of element types.
01:42 Juerd_ And nothingness is again different from undef, which is singular nothingness.
01:42 luqui Juerd_, Haskell is good to talk about because it has defined everything very well
01:42 luqui you don't get into muddy concepts
01:42 Juerd_ Are lists actually linguistically plural in Haskell?
01:42 luqui nope
01:43 Juerd_ Then it's no good reference for this discussion.
01:43 luqui that's not true
01:43 Juerd_ We have item and list only because of context.
01:43 Juerd_ Without context, we'd have only item.
01:43 Juerd_ Without context, everything we do with lists, can be done with arrays.
01:43 SamB we have [a] and a and all sorts of other types
01:43 luqui Juerd_, basically, what is the language construct that is enabled by having a nothingness type
01:44 luqui aesthetics are nice, but I really need to have something concrete to even think about another top level type
01:44 luqui List is yucky enough as it is
01:44 Juerd_ luqui: Top level statements and their optimizability. This kind of optimization is fundamental to Perl 1..4, and I think would be unwise to consider premature.
01:44 luqui but perl's semantics require it
01:44 luqui Juerd_, there's nothing a "nothing" type can do that a unit type can't
01:45 luqui they're isomorphic
01:45 Juerd_ Void context is *only* about knowing that you don't have to compute return values
01:45 Juerd_ In all respects, if something is programmed well, either item or list context can be assumed instead.
01:45 Juerd_ Programmed well being: the procedure does not have different side effects depending on context.
01:46 luqui Juerd_, context is deeper than just "item" and "list"
01:46 Juerd_ However, every pure function can be optimized away entirely in void context.
01:46 luqui we have numeric context, string context, reference context
01:46 luqui so why not "unit context"
01:46 Juerd_ OTOH, having a pure function in void context makes no sense at all.
01:46 luqui Juerd_, uh oh, you said "pure", and you weren't referring to "value types" :-)
01:46 Juerd_ Context is hierarchical.
01:46 luqui Juerd_, yep
01:47 luqui Void does Item
01:47 Juerd_ luqui: It was specifically adjective to function ;)
01:47 luqui yeah, I know, I was just giving you shit
01:47 Juerd_ The hierarchy for item and list is equal. Rooting them under item and list makes little sense.
01:47 Juerd_ The hierarchy is what types are. item and list are meta that.
01:48 luqui Juerd_, again, I don't think that the hierarchy for item and list are equal
01:48 Juerd_ (And it may or may not be actually hierarchical ;)
01:48 Juerd_ luqui: Why so?
01:48 luqui because I'm choosing aggregation, while you're choosing inheritance
01:48 Juerd_ What's the difference?
01:48 Juerd_ I'm not consciously choosing.
01:48 luqui you're thinking of Item of Str, List of Str, etc.
01:48 Juerd_ Yes, I am
01:48 luqui but you're clumping them into ItemOfStr and ListOfStr
01:49 Juerd_ NAFAIK
01:49 luqui oh, wait
01:49 luqui I'm thinking of Str does Item, and List of Str
01:49 luqui List is parametric, Item isn't
01:49 Juerd_ By the way, as I don't consider item and list types, I think of "str item context" and "str list context"
01:49 luqui and Singular and Plural are neither parametric
01:49 Juerd_ Where "list of foo" is just slang
01:50 luqui Juerd_, that's why we're disagreeing
01:50 luqui because I think that List is a type
01:50 Juerd_ Back at square 1 :)
01:50 luqui it just doesn't behave like you think it does
01:50 luqui because I'm making the concept of "type" big enough to hold List
01:50 luqui which it previously wasn't
01:50 Juerd_ I think that's dangerous.
01:50 luqui I know you do
01:51 luqui many others will to
01:51 luqui but like I said, it has to be something
01:51 Juerd_ Because you have to be careful not to have metamodels in the actual language
01:51 luqui Juerd_, why?
01:51 Juerd_ Because they're hard to grok, and provide little structure.
01:51 luqui Juerd_, nobody has to grok them
01:51 luqui not at first
01:51 Juerd_ They're wonderful in theory, and great when implementing languages
01:51 luqui Juerd_, and they're great for *formalizing ideas*
01:51 luqui that's the whole point, as if I hadn't said that enough
01:51 Juerd_ However, the resulting language should have things set in stone, and not have anything that is extremely broad.
01:52 luqui Juerd_, that's the wrong axis
01:52 luqui it's not broadness that should be avoided, but vagueness
01:52 luqui as long as everything has a real, precise, good definition
01:52 luqui it should work out
01:52 Juerd_ We mustn't be ABLE TO explain how functions relate to arrays. A Perl programmer just thinks of them as different, unrelated, things.
01:53 luqui Juerd_, that's dumb
01:53 Juerd_ I don't think so
01:53 Juerd_ I think this is exactly the difference between theoretical and pragmatic languages.
01:53 luqui I'm sorry, as a Perl programmer myself, I don't accept arguments based on what is possible
01:53 luqui that's like taking away a feature from a language because it is possible to abuse it
01:53 luqui and the fact that Perl doesn't do that makes it pragmatic
01:54 Juerd_ Many Perl users don't have an academic background, and are scared by things that look like they are based on proofed theory.
01:54 luqui Juerd_, so avoid proofs?
01:54 mjl69 joined perl6
01:54 Juerd_ No, have proof only on the meta level.
01:54 luqui many people use mathematics without realizing that it has all been rigorously proven at an abstract level
01:54 Juerd_ But put only chunks of reality in the actual language.
01:54 luqui and most people don't care
01:54 luqui they use math anyway
01:55 luqui ?eval 3*5 + 1  # I don't care that numbers can be represented as sets, or as peano nestings
01:55 evalbot_8568 16
01:55 Juerd_ Not all minds work the same.
01:55 luqui Joe shmoe doesn't have to understand why there is no supertype for Singular and Plural
01:55 Juerd_ And the prolifiration of programming languages is the direct result of this.
01:55 luqui he doesn't have to understand that Plural is a type
01:56 luqui that's why we don't ever make him type it
01:56 Juerd_ People think differently, and thus pick different languages.
01:56 luqui replacing it with notations like *@a
01:56 Juerd_ Perl is chosen by very different people than, for example, Haskell, usually.
01:56 Juerd_ And for different purposes.
01:56 SamB than why is the Evil Mangler written in PERL?
01:56 luqui Juerd_, well, the premise of your argument disagrees with my philosophy
01:56 luqui and so I don't see any reason to argue this anymore
01:57 luqui my proposals are all about abstraction and formalization
01:57 Juerd_ Your philosophy is what I consider quite dangerous.
01:57 Juerd_ In theory, I agree fully.
01:57 luqui and if you argue that that's a bad thing (and you're on of the only people who will)
01:57 Juerd_ But that's the problem. I do not believe that theory is always good.
01:57 luqui then you'll just have to live with being opposed to me
01:57 luqui Juerd_, well, I do.  I don't believe (as Haskell does) that a user has to grok all the theory before he can use the language
01:58 luqui Haskell pretty much requires that you understand monads in order to do any nontrivial I/O
01:58 Juerd_ I am convinced that too much theory and maths behind anything make the anything un-natural and thus less matching human brains.
01:58 luqui perl doesn't require that you understand the concept of a Theory in order to do C++-like object-orientation
01:58 Juerd_ Chaos can be quite comforting
01:58 luqui math came from human brains
01:58 Juerd_ As can exceptions to rules.
01:58 * justatheory sighs
01:58 justatheory Juerd_: WHY CAN'T YOU UNDERSTAND ME?? :-(
01:59 Juerd_ luqui: But do note: very exceptional brains. Note that IQ-wise, most people are MUCH dumber than maths people
01:59 luqui so, I'm going to stop this arguement now, because you're not going to argue me out of my world view
01:59 luqui and I'm not going to argue you out of yours
01:59 Juerd_ Meta levels *are* important
02:00 Juerd_ But should be carefully hidden away from end users, except those who want to find out.
02:00 luqui you're arguing that they shouldn't be *exposed*.  I'm arguing that they shouldn't be *pervasive*
02:00 Juerd_ Which is important when deciding on terminology, our starting point.
02:00 * stevan agrees with that point :)
02:00 stevan everything is open unless explicity closed
02:00 luqui Juerd_, but it doesn't matter, because my proposal is working on the meta levels
02:01 Juerd_ luqui: Okay. Just please make that clear.
02:01 Juerd_ And please, when coining jargon, specify domain.
02:01 Juerd_ Is it Perl 6, the end user language, or higher.
02:01 luqui you mean Singular and Plural?
02:01 Juerd_ Yes, but also item and list, if you use those.
02:01 * luqui isn't even sure how we got into this argument...
02:02 Juerd_ Perhaps this is indeed why your abstraction is needed
02:02 luqui there's nothing inaccessible in there...
02:02 Juerd_ Where Singular is meta, and item is Perl.
02:02 Juerd_ In any case, I need sleep :)
02:02 luqui all the concepts that we're talking about could be in the open and nobody would complain
02:02 Juerd_ 3am here, wake up time 8am :(
02:02 luqui anyway
02:02 luqui yes, get sleep
02:03 Juerd_ Eh, no, nobody would complain, because many would avoid.
02:03 luqui ahh, it all started about here:  <Juerd_> We mustn't be ABLE TO explain how functions relate to arrays
02:03 traecer joined perl6
02:03 luqui Juerd_, which concept?
02:03 luqui we haven't been talking about anything?
02:03 luqui s/\?/./
02:03 Juerd_ People need axioms, at least at first.
02:03 luqui which concept would be avoided
02:04 Juerd_ So if your concepts are out in the open, and too commonly referred to, they start to cloud vision, which is the opposite of their intent.
02:04 luqui Juerd_, which concept?
02:04 Juerd_ 03:09 < luqui> all the concepts that we're talking about could be in the open and nobody would complain
02:04 luqui Juerd_, which concept?
02:04 Juerd_ All, e.g. abstractions of item and list
02:05 luqui I'm talking about singular and plural
02:05 luqui two concepts which should be extremely straightforward
02:05 Juerd_ Singular and plural may be too high level.
02:05 Juerd_ Straightforward, but adding to jargon
02:05 luqui Juerd_, the only thing you were arguing was that they shouldn't be formalized (and then later that they should be formalized but out of sight)
02:05 Juerd_ If people start to use "list" and "plural" for the same thing, there is a problem.
02:05 luqui but it doesn't matter, because I'm not doing anything tricky with them
02:06 Juerd_ luqui: Formalized is great. I don't think I said something to the contrary.
02:06 luqui Juerd_, like you said, list and plural are the same thing until we come up with something that is plural that is not a list
02:06 luqui and we don't have one of those yet
02:06 Juerd_ I'm just a bit frightened that there may be to many levels of abstraction, where we could do with many less.
02:06 luqui people can squeeze them together in their brains
02:06 Juerd_ Abstraction CAN in fact hurt :(
02:06 luqui and then pull them back apart when they're ready
02:07 luqui like parameter and argument
02:07 Juerd_ And in general, when abstraction leads to 1:1 mappings, it's good to factor them out
02:07 luqui Juerd_, I don't know where you came up with that
02:07 Juerd_ It's just my experience.
02:07 luqui Juerd_, I always think of there being a 1:1 correspondence from concepts to abstraction
02:07 luqui regardless of whether one concept is isomorphic to another, they're still different in people's heads
02:08 luqui there are 5 cats   # plural, unordered
02:08 Juerd_ Parameter and argument don't always map 1:1. Commonly, only.
02:08 luqui there is a row of (5 cats)   # plural, ordered   (the cats, not the row)
02:09 luqui Juerd_, I know
02:09 luqui and neither do List and Plural
02:09 luqui but they do as far as we know
02:09 Juerd_ Well, that I have yet to be convinced of.
02:09 Juerd_ But anyway, I'm going to bed :)
02:09 luqui and parameter and argument do as far as n00bs know
02:09 luqui we're just smarter n00bs
02:09 Juerd_ Thanks for the conversation. I have learned new things, which is always good.
02:09 luqui night
02:09 Juerd_ Good night
02:41 petdance joined perl6
02:51 svnbot6 r8569 | stevan++ | PIL/Native/Bootstrap/Container/Array - a skeleton for &sort, no code yet; trying to implement quicksort in PIL^N is annoying me :P
03:00 avar can Perl 6 be considered an array programming language because of the hyperoperators?
03:00 avar ..probably not
03:00 dduncan joined perl6
03:04 luqui what's an "array programming language"?
03:14 petdance left perl6
03:20 tewk stevan: so does PIL^N have recursive functions, if it does I can do the sort for you.
03:22 avar luqui: a language where stuff operates on arrays, i.e. you don't have to explicitly write foreach loops for everything
03:22 avar like J
03:24 avar i.e. you can do @a »++; instead of for @a -> $i is rw { ++$i }
03:24 luqui avar, then I think it does make Perl an array programming language
03:25 luqui I think that was the intent, at least
03:26 avar according to what I'm reading they usually make normal opreators act as hyperoperators
03:26 avar that's a minor syntax difference though
03:26 avar i.e. (pseudocode)@a++ instead of @a »++
03:27 luqui that seems like cosmetics to me
03:27 avar sure are;)
03:29 tewk stevan: is &redo and &?SUB how you do recursion?
04:02 elmex_ joined perl6
04:56 stevan tewk: ping
04:56 meppl guten morgen
04:56 stevan guten morgen meppl
04:58 stevan tewk: PIL^N does not have recursive subs because it cannot do call-by-name
04:58 stevan recursive methods yes
05:00 stevan but using &redo := &?SUB is a kind of built-in fixed-point combinator approach it works quite well
05:02 tewk Well I have a impl of bottom up merge sort, that probably need a recursion replaced with &redo=&?SUB
05:02 stevan tewk: commit it, and I will take a look
05:03 tewk I stole it from  Algorithms A Functional Programming Approach
05:03 stevan I was trying to get the quicksort algorithm working but it gets really messy because all lists are immutable, so storing the intermediate lists of @less and @more items got really messy
05:03 tewk Ok will do
05:03 stevan tewk: I have that book too, I should have checked it :)
05:04 tewk All I need is car and cdr, I used split to impl car and cdr, but that should be pretty easy to change
05:04 meppl good morning stevan
05:05 stevan split(1) works for cdr and fetch(0) for car (if I am not messing the two up, I am more familiar with head/tail)
05:05 stevan I can never keep those weird LISP things straight :)
05:06 beppu joined perl6
05:06 beppu pugs?
05:06 tewk car=head cdr=tail,  I lied I used splice
05:06 beppu how long does pugs usually take to build?
05:06 stevan tewk: ok, that has to be one of the cooler paper titles I have seen "Complex Performance Analysis Through Statistical Experimental Design: An Evaluation of Parameters Associated with Speed in Parallel Phylogenomics", of course I have NO idea what the hell you are talking about :P
05:07 stevan beppu: depends on your CPU
05:07 beppu ghc has been raping my machine for hours.  I have an amd64 going at 2411MHz according to `cat /proc/cpuinfo`
05:07 svnbot6 r8570 | luqui++ | Added a context and coersion proposal.
05:07 beppu pretty soon, it'll almost be a day.
05:08 stevan beppu: it takes me between 30 min and 2 hours, depending on what else I have going on
05:08 beppu seriously?
05:08 stevan beppu: what OS?
05:08 beppu I think my lack of ram must be screwing me over.
05:08 beppu linux
05:08 stevan how much ram?
05:08 beppu sadly, I only have 256MB (don't laugh)
05:08 beppu I'm going to add more soon.
05:08 svnbot6 r8571 | tewk++ | Bottom up merge sort impl
05:08 stevan ouch,.. yeah you are swapping like crazy I am sure
05:09 beppu I'm going put off building pugs until I get more RAM, then.
05:09 beppu thanks.
05:09 beppu ghc needs optimization.
05:10 tewk stevan: that was a previous project of mine, I worked on parallization of phylogenetic algorithms, notice that my name is at the end of the authors list
05:10 tewk I was more of a grunt on that one.
05:10 stevan cool name though :)
05:11 * stevan last paper was freshman year Art History class,.. about 15 years ago :)
05:15 feng123 joined perl6
05:17 luqui beppu, speaking of optimization
05:17 luqui have you tried compiling without it?
05:17 kanru joined perl6
05:20 luqui stevan, see docs/notes/context_coersion.pod
05:20 luqui ?
05:20 * luqui fishes for feedback
05:21 stevan luqui: next on my todo list (first is tewk's mergesort)
05:22 tewk stevan head = splice(0,1) tail = splice(1), but you probably figured that out.
05:22 stevan tewk: yup
05:23 stevan I will have a few questions in a moment, I am reformatting and adding some sigils to help my perl-ish eyes
05:23 lisppaste3 joined perl6
05:24 tewk pg  121-122 in Algorithms, questions welcome
05:25 stevan the book is in a pile downstairs,.. you however are right here :)
05:25 tewk Sound great
05:26 tewk Guess I better start reading :)
05:30 * stevan curses updates to Makefile.PL
05:30 stevan tewk: so merge takes two lists?
05:31 tewk tewk has been responsoble for a few of those
05:31 tewk yes two lists
05:31 stevan with just a single item in each?
05:32 tewk Nope they can have any length
05:32 stevan so this will sort multi-dimensional arrays?
05:33 tewk nope
05:33 svnbot6 r8572 | luqui++ | Change from derivation-only to derivation and "is context".
05:33 luqui stevan, you split the array to sort in two
05:33 * stevan does an svk diff because he thinks he messed something up
05:33 gaal hi folks
05:34 * luqui remembers mergesort now
05:34 luqui it is very simple
05:37 luqui sort(@a) { (@b,@c) = split @a down the middle;  merge(sort(@b), sort(@c)) };  merge(@b,@c) { return @b if !@c;  return @c if !@b;  if @b[0] <= @c[0] { (@b[0], merge(@b[1...], @c) } else { (@c[0], merge(@b, @c[1...]) } }
05:37 luqui that's the recursive definition of merge().  It might be easier and faster to do it iteratively
05:37 luqui sort() of course needs to be recursive
05:38 tewk This is bottom-up mergesort which is suppose to save a little space, but it is basically the same.
05:38 stevan luqui: I need it in PIL^N, not Perl 6 though
05:38 luqui transliterate!
05:39 stevan luqui: yeah,.. sure,.. simple,.. no problem :P
05:39 * luqui isn't aware of the operations available in PIL^N
05:39 tewk Depending on the underlying virtualmachine recursive can be just as fast as iterative.
05:39 * luqui knows
05:39 tewk PIL^N ~= lambda calculus
05:40 * luqui guesses based on the "array" (as opposed to "linked list") nature of arrays
05:40 luqui tewk, really, even arrays?
05:40 stevan luqui: they are immutable sequences
05:40 luqui stevan, oh, then you don't have much choice but to do it recursively :-)
05:40 * stevan knows that :P
05:41 stevan tewk: `splice(2) is "tail (but start at the second element)" right?
05:41 tewk Yes
05:41 tewk or (tail(tail(orig)
05:42 tewk in scheme cddr
05:42 luqui ugh
05:42 luqui caddadr
05:42 stevan luqui: I can get faux-mutable "things" if I stuff then into an opaque, but thats cheating :P
05:42 luqui there's no reason to do that
05:42 stevan caddadadddadadddarrrrarradadadrrr
05:42 luqui recursive is plenty nice
05:42 luqui I'm just wondering how to best split an array down the middle
05:43 luqui once you have that, then you can pretty much transliterate mine, and I imagine that mine is not so different from tewk's
05:44 stevan @a`length()`divide(2) would give you an approx middle index, then it's easy to slice off the end half, the front half is the harder one
05:44 luqui splice doesn't support that?
05:44 gaal do lists in the minilang have backward pointers? if so you can find the middle elemn by going back and forward at the same time. oh, you have length? that's of course much better.
05:45 stevan tewk: I am confused by this "hl1`concat( merge( l1`splice(1)`concat(l2) ) )"
05:45 stevan it seems to be passing a single list to merge, but merge takes two lists
05:45 stevan am I missing something?
05:46 stevan gaal: I just have a basic splice(idx) which gives me a sublist of all past the idx
05:46 stevan I could do some nastiness with reverse though :)
05:46 tewk one minute
05:47 gaal stevan: nooo, going from the end can't be O(1) so forget it
05:47 luqui can I see the algorithm you're using?
05:48 stevan luqui: yes, see src/PIL/Native/Bootstrap/Container/Array.pil,.. look for sort :)
05:48 stevan tewk got it from the Algorithm book
05:48 stevan luqui: it is not valid mini-lang syntax though, I am converting it to be though
05:48 stevan but it is still readable
05:49 tewk bug, those concats should be commas ,
05:50 tewk l1`splice(1), l2
05:50 stevan tewk: ok
05:50 avar joined perl6
05:51 tewk l1, l2`splice(1)
05:51 luqui wait -- you're splitting at position 1 the whole time?
05:51 stevan tewk: ok, compiling,.. crossing fingers
05:52 luqui i.e. split just returns the head and the tail...
05:52 luqui wait, that's even worse
05:52 stevan split(1) returns tail
05:52 stevan fetch(0) is head
05:52 luqui what's splice(0,1)?
05:52 stevan hmm,.. didnt compile,.. I am looking
05:52 tewk also splice(0,1) really isn't head it is [head list] head
05:52 stevan head
05:52 tewk no it isn't I forgot
05:53 tewk head : []
05:53 stevan [ lst`fetch(0) ]
05:53 tewk yep
05:53 luqui tewk, oh, good
05:53 luqui because the way it's written it looks like split is a very expensive identity function
05:53 tewk I cheated and  combined a head with a cons, that slipped through
05:54 audreyt re
05:54 tewk Looks like we all saw it at the same time :)
05:54 stevan morning audreyt
05:54 luqui tewk, so split returns puts each element into a singleton array?
05:55 tewk tewk needed to get the kde world time applet on OS X
05:55 luqui split [1,2,3,4]  === [[1],[2],[3],[4]] ?
05:55 tewk yess
05:55 * gaal uses tzwatch
05:55 tewk that is supposedly the space savings instead of recursively splitting
05:55 luqui since you have length, you could break it in two easier
05:56 * stevan thinks it make be easier to create a Seq prim called "sort" :)
05:56 audreyt luqui, stevan:
05:56 stevan it would be much faster too
05:57 luqui stevan, but then we don't get the portability!
05:57 audreyt http://pugs.blogs.com/pugs/2​006/01/context_and_coe.html
05:57 stevan luqui: there is at least a quicksort available on all platforms
05:58 luqui well, I'll write sort if you're burned out
05:58 luqui it might be a good intro to PIL^N programming
05:58 luqui audreyt, did you see my doc with exactly the same name?
05:58 stevan luqui: not burned out yet, lemme see if I can get this working
05:58 luqui okay
05:58 stevan if not, then I will hand it over to you :)
05:58 audreyt luqui: wow. no.
05:58 audreyt can you quickly summarize the differences?
05:59 luqui contexts are types
05:59 luqui well, let me read yours first
05:59 luqui mine is rather lengthy, but it looks like you came up with most of it yourself
05:59 audreyt except you spelled coercion and coersion and I didn't
05:59 audreyt :)
05:59 gaal audreyt: if context is coersion, doesn't that mean we lose want?
06:00 audreyt s/and/as/
06:00 tewk Using the simpler merge sort may reduce the complexity
06:00 audreyt gaal: no, because function return types are by default polymorphic unless it can be statically inferred.
06:00 audreyt gaal: which is the only place "want" makes sense.
06:01 luqui audreyt, okay, there is some important maths that you're missing
06:01 luqui the minor differences:  contexts are not parameterized
06:01 luqui I didn't have a way to represent RW
06:02 luqui the major difference: all builtins cannot have their own associated context
06:02 audreyt hm, if they are not parameterized, it means we have two separate typesystem.
06:02 luqui audreyt, no, I was thinking that every context is a type
06:02 audreyt i.e. a type inferencer and a conext inferencer
06:03 luqui audreyt, that happens anyway in CLTI at least
06:03 audreyt maybe, but they are not using traits
06:03 luqui but I'm not sure whether parameterization or not is good or bad...
06:03 stevan tewk: I am breaking each function down and it is going ok so far
06:03 audreyt in any case... I'm sure we can work out our differences
06:03 audreyt except I really want to keep Void ;)
06:03 audreyt but I gotta run to $job. bbiab
06:03 audreyt &
06:04 stevan tewk: here is split
06:04 stevan            &split := -> @lst, @acc {
06:04 stevan                &redo := &?SUB;            
06:04 stevan                @lst`length()`eq(0)`cond(
06:04 stevan                    -> { @acc },
06:04 stevan                    -> { &redo`(@lst`splice(1), @acc`push([ @lst`fetch(0) ])) }
06:04 stevan                );
06:05 stevan            };        
06:05 * stevan loves accumulators :)
06:05 Limbic_Region joined perl6
06:05 luqui stevan, you haven't been programming in Haskell long :-)
06:06 luqui Haskellers hate accumulators
06:06 stevan luqui: I dont program in haskell, I have you, gaal and audreyt ;)
06:06 luqui because they kill laziness
06:06 gaal (insert evolution joke)
06:06 stevan luqui: I disagree, I have been lazily learning haskell for a long time now :P
06:06 * gaal lols at seeing himself on that list
06:07 luqui stevan, heh, I mean, of course, accumulators kill laziness, not Haskellers
06:07 stevan :)
06:08 * stevan has fallen in love with fixed-point combinators and accumulators
06:09 stevan who needs laziness,.. Y i ask you Y
06:09 stevan :P
06:09 SamB you mean "Y I say, Y"
06:09 stevan U say Y?
06:10 * stevan has now run out of fixed point combinators :P
06:10 gaal one day I'll corner some real Haskellers and get a confe^W^Hn explanation about how Haskell can infer fix from y f = f (y f)
06:10 * luqui didn't realize that say was a combinator
06:11 * stevan goes off to SKI :P
06:11 gaal say is a combinator!?
06:11 luqui gaal, by "infer" you mean?
06:11 luqui yeah, it's the, um, output combinator...
06:11 gaal luqui: uh, where's the actual combinator in that definition? how can it compile?
06:11 luqui gaal, the combinator is in the recursion
06:12 luqui y = fix (\yy f -> f (yy f))
06:13 gaal luqui: if it'd been the classic Y = λf.(λx.f (x x)) (λx.f (x x))
06:13 gaal then ok
06:13 gaal and there are many equivalent functions
06:13 luqui ahh, but haskell can do better than that
06:13 luqui because it is lazy
06:13 gaal but that one looks like the *spec* of a function, not the function itself
06:13 luqui laziness, laziness
06:14 luqui you can call f, passing it the thunk (y f)
06:14 luqui without evaluating it first
06:14 luqui in a call-by-value language, you'd just evaluate (y f) over and over, without ever calling f
06:15 SamB personally, I don't understand why people trust the compiler to do CSE between the pattern and the "y f" call...
06:15 gaal CSE?
06:15 luqui SamB, do you have to?
06:15 SamB Common Subexpression Elimination
06:15 luqui is that necessary for that definition
06:15 * luqui doesn't think so
06:16 SamB luqui: well I suppose not, but it might have a big impact on speed and memory usage...
06:16 luqui SamB, why?
06:16 luqui what subexpression is it eliminating anyway?
06:17 SamB because if it didn't do the CSE, you'd get lots (y f)s
06:17 luqui no you wouldn't
06:17 luqui because it's lazy!
06:17 gaal so wait. using this definition of y, I call it with (y g)
06:17 SamB luqui: but you might
06:17 luqui SamB, what do you mean?
06:18 SamB luqui: depending on what f does...
06:18 luqui of course you would, if f calls its first argument a lot
06:18 luqui but that's okay, it's recursive, you're supposed to get a lot of (y f)s
06:18 gaal which evaluates to (y g) (y (y g))
06:18 SamB luqui: but if the f is always the same...
06:18 luqui SamB, so?
06:19 gaal how'd that help me?
06:19 luqui gaal, you need to see it with an argument
06:19 SamB I suppose it isn't a problem if y gets inlined...
06:19 SamB then y f becomes a redex...
06:19 SamB well.
06:19 luqui say:  f ff x = if x > 3 then x else ff (x+1)
06:20 gaal say g is my step factorial function
06:20 luqui then what is fix ff 0 ?
06:20 luqui no, say it's this nice simple one
06:20 gaal or ok, yours.
06:20 SamB I suppose thats only if it does CSE after that...
06:20 SamB which is at least a little less incomprehensible...
06:20 luqui fix ff 0 = (if 0 > 3 then 0 else fix ff 1)
06:21 luqui then it evaluates (0 > 3) before evaluating fix ff 1
06:21 gaal sure
06:21 luqui but it's false, so it evaluates fix ff 1
06:22 luqui fix ff 1 = if 1 > 3 then 1 else fix ff 2... etc
06:22 luqui until fix ff 4 = if 4 > 3 then 1 else fix ff 5
06:22 luqui and (4 > 3) is true, so it just returns 4   (heh, not 1)
06:22 luqui and it doesn't ever evaluate fix ff 5
06:22 gaal hold on, for a fix function sure, that's what you want it to generate
06:22 gaal but how does *this* fix generate that?
06:22 luqui I expanded it manually
06:23 luqui fix f = f (fix f)
06:23 gaal yup
06:23 luqui fix ff = ff (fix ff)
06:23 luqui er...
06:23 luqui kill that last lin
06:23 luqui e
06:24 luqui fix \ff x -> if x > 3 then x else ff (x+1)  ==>  (\ff x -> if x > 3 then x else ff (x+1)) (fix ...)
06:24 luqui ==> if x > 3 then x else (fix ...) (+1)
06:24 luqui er, x+1
06:25 luqui with the \x in front
06:25 luqui ==> \x -> if x > 3 then x else (fix ...) (+1)
06:25 luqui that's the first step
06:25 luqui if you evaluate again, then you do the same thing again
06:25 luqui it's hard to see, I know
06:25 luqui the best way to see it is to do it yourself
06:26 gaal I'd done it with explicit Ys
06:26 luqui only expanding when you need to (which is how Haskell does it)
06:26 gaal I guess that's the trick to this version
06:26 luqui explcit Ys?
06:28 gaal like the lambda I quoted above
06:28 gaal where you see the next step
06:30 luqui ahh, the call-by-value fixpoint
06:30 luqui that's not necessary in a lazy language
06:30 luqui because lazy is not call-by-value
06:33 gaal noted. I have the rest of the year to understand what that means. :)
06:33 gaal off to $work, see you! &
06:35 Limbic_Region autrijust - your perlmonks acct rename was just completed
06:45 tewk stevan: you shouldn't need an accumulator for split should you.  You only need an acummulator when you need to accumulate something besides what you are returning.
06:45 stevan tewk: yes, I think you are right
06:46 luqui tewk, right, but accumulators -> tail recursion -> faster
06:46 luqui if you're into premature optimization
06:46 luqui they also -> no lazy ;-)
06:46 stevan luqui: no i think that version of split is wrong,.. based on what I am reading in Algorithms
06:46 * stevan finally had to break open the book
06:46 luqui which version of split
06:47 luqui the one you posted earlier?
06:47 stevan yes
06:48 nothingmuch joined perl6
06:52 stevan oh, I think I might have it
06:52 tewk The split looks pretty good to me.
06:53 stevan yes I think the split works, I added another call to &merge and it seems to be sorting
06:53 stevan but I am getting an error,.. I need to track it down
06:55 tewk Next time I'll try to the PIL^N conversion and add tests before throwing it over the wall :), but you asked for it so I heaved it :)
06:56 stevan tewk: :)
06:59 stevan woot!
07:04 pasteling "stevan" at 67.186.136.119 pasted "bottom-up mergesort in PIL^N" (67 lines, 1.7K) at http://sial.org/pbot/15268
07:04 Cryptic_K joined perl6
07:05 stevan tewk, luqui: it works :)
07:06 tewk congrats
07:06 stevan tewk: thanks for the initial transcription
07:06 tewk once you have single sort, multidimensional shouldn't be to hard
07:06 tewk no problem
07:07 luqui multidimensional sort?
07:07 stevan tewk: well mutli-dim sort is not part of basic container sort IIRC,.. but I will defer to luqui on that
07:07 luqui what is it?
07:07 luqui is there a p5 module that does it?
07:08 tewk you just mentioned it, oh, that was probably when you where trying to figure out the merge arg count bug.
07:09 luqui so what is it?
07:10 azuroth joined perl6
07:11 tewk luqui: don't know.  A 2 dimensional array is effectively a table.  And a table can have a primary, secondary, ... sort criteria.  that is what I would call multidimensional sort.
07:12 luqui oh
07:12 luqui it's just a keyed sort
07:12 tewk That's my guess.
07:12 luqui using a comparator like { $^a[0] <=> $^b[0] || $^a[1] <=> $^b[1] }
07:13 luqui (or, in the p6 sort spec:)  @a.sort: { .[0] }, { .[1] }
07:13 luqui ahh, p6 sort is nice
07:19 GeJ joined perl6
07:20 pasteling "stevan" at 67.186.136.119 pasted "Corrected Bottom-up mergesort" (76 lines, 2.1K) at http://sial.org/pbot/15269
07:21 stevan I forgot that `or() is not lazy
07:21 stevan so I had to nest some more `cond calls
07:21 stevan this should work in all cases now
07:21 * stevan adds it to the ::Array container
07:22 luqui why is not or lazy?
07:22 stevan ask audreyt
07:22 stevan i think cause it was more of a PITA than it was worth
07:23 luqui shouldn't or be sugar anyway for cond?
07:25 stevan no it is a method on bit
07:25 luqui isn't cond a method on bit?
07:25 stevan nope
07:25 luqui what's cond?
07:25 stevan not sure,.. i think it is sugar
07:25 luqui how do you use it?
07:25 stevan check src/PIL/Native/*
07:26 stevan @array`is_empty()`cond(-> { "empty" }, -> { "not empty" });
07:26 svnbot6 r8573 | stevan++ | PIL/Native/Bootstrap/Container/Array.pil
07:26 svnbot6 r8573 | stevan++ | - added &sort, thanks to twek++ for the initial tranlation from
07:26 svnbot6 r8573 | stevan++ |   Haskell to PIL^N (from the Haskell Algorithms book)
07:26 svnbot6 r8573 | stevan++ |     - added minimal test for it (needs more)
07:26 luqui looks like a method on bit to me
07:26 stevan yes, but that is not how it is implemented IIRC
07:27 luqui it's hard-coded into Eval
07:27 luqui yuck
07:27 stevan ask audreyt :)
07:28 * stevan heads to bed
07:28 stevan tewk: thanks again
07:28 stevan luqui: I will read your cotext/corcion stuff tomorrow
07:28 * stevan &
07:29 luqui slacker
07:29 luqui g'night
07:29 tewk stevan: Your Welcome
07:29 tewk luqui: I'm reading but it usually takes me a couple of days to come up to speed :)
07:30 luqui it also has holes...
07:30 luqui audreyt is good about making the holes obvious
07:30 lisppaste3 joined perl6
07:40 dduncan commit pending ...
07:43 luqui thanks for telling us... (?)
07:43 Cryptic_K joined perl6
07:43 dduncan I just do that sometimes since I don't like having to deal with merges when two people commit almost at once
07:44 dduncan I like to pull, then commit and push
07:44 svnbot6 r8574 | Darren_Duncan++ |  r1785@Darren-Duncans-Computer:  darrenduncan | 2006-01-03 23:43:20 -0800
07:44 svnbot6 r8574 | Darren_Duncan++ |  /ext/Rosetta-Incubator : added new section OPERATIONAL CONTEXT to Language.pod, made minor change to Overview.pod
07:44 svnbot6 r8573 | stevan++ | PIL/Native/Bootstrap/Container/Array.pil
07:44 svnbot6 r8573 | stevan++ | - added &sort, thanks to twek++ for the initial tranlation from
07:44 svnbot6 r8573 | stevan++ |   Haskell to PIL^N (from the Haskell Algorithms book)
07:44 svnbot6 r8573 | stevan++ |     - added minimal test for it (needs more)
07:44 luqui oh, you mean like that?
07:44 luqui :-)
07:45 luqui wait, it looks like that was already committed
07:45 tewk stevan committed several minutes ago, yeah svnbot  has some latency
07:45 dduncan actually, my pre-commit pull included 8573
07:45 dduncan so no merging
07:46 luqui look up at minute 26
07:46 dduncan fyi, this new pod update of mine includes some Rosetta features that should be considered very unusual in the database world
07:46 luqui svnbot already reported that commit
07:46 dduncan eg, a schema object can be of *any* data type, not just tables etc
07:47 dduncan since in my retooling of the concept, a schema object is essentially just a global variable namespace
07:48 dduncan Rosetta is a merger of sorts between an rdbms and a programming language
07:48 dduncan I'm not aware of any DBI related projects that have gone that far
07:49 nothingmuch joined perl6
07:50 dduncan hello nothingmuch, goodbye nothingmuch
08:16 iblechbot joined perl6
08:42 kanru joined perl6
08:48 rafl leo: Where are they?
08:59 svnbot6 r8575 | luqui++ | Added the description of the now-blessed Perl 6 multimethod system.  Also added a musing
08:59 svnbot6 r8575 | luqui++ | about smart context picking that isn't so "picky" about conformance.
09:02 xinming joined perl6
09:04 larsen joined perl6
09:07 audreyt luqui: greetings.
09:08 audreyt luqui: got your diff report; I take it you are abandoning the idea of (\@foo).infix:<=> redispatcing to <:=> ?
09:09 audreyt stevan: wow, the .sort is crazy :)
09:09 audreyt stevan++ # craziness
09:11 audreyt luqui: "To create a new context, you derive it from an existing context (and mark it as a context)."
09:11 audreyt luqui: so you are shuffling context into a class trait
09:12 audreyt luqui: and there's also this disambiguoation deriving constraint to make it monomorphic
09:12 audreyt luqui: so anything that does multiple interfaces has to select one interface as the primary derive
09:12 audreyt that sounds very B&D.
09:13 audreyt my contexts are roles, so there are no MI.
09:13 audreyt since roles don't inherit.
09:15 audreyt so the total order you prescribed are still natural, due to the use of parametric roles.
09:15 audreyt and want() is still decidable.
09:15 * audreyt goes reading the mmd spec
09:22 audreyt luqui: nice work. I totally agree.
09:23 audreyt now, if contexts are made into type constraints, I think all MMD properties still hold. if the user introduces circular context relationships, we can check and reject the program, but I think that does not warrant a separate track of context treatment.
09:25 audreyt I'll go ahead and implement my proposal. then we can talk in code and unit tests :)
09:29 svnbot6 r8576 | audreyt++ | * my parallel proposal to luqui's context proposal.
09:31 audreyt stevan: so, hm, you implemented .sort for educational purposes? :) because I thought that the underlying runtime should provide a native `sort
09:31 audreyt all our current runtimes do, so PILN probably should too
09:32 nothingmuch how long is the new mmd spec?
09:33 audreyt 122 lines of pod
09:34 nothingmuch good
09:34 audreyt very simple
09:34 audreyt probably ~~ 30 lines of implementation
09:37 nothingmuch joined perl6
09:44 G2 joined perl6
09:47 audreyt bbiab, nap :) &
10:13 xinming joined perl6
10:40 dada joined perl6
10:42 nothingmuch_ joined perl6
11:15 nothingmuch joined perl6
11:16 nothingmuch luqui++
11:16 nothingmuch audreyt++
11:16 nothingmuch wonderful stuff guys
11:16 nothingmuch exactly what I wanted all along, but haven't been able to say
11:17 nothingmuch btw, given CPS, we return-sane is gone
11:17 nothingmuch this shows that return-sane makes sense
11:22 asavige joined perl6
11:22 gaal where is this spec?
11:26 asavige http://www.perlmonks.org/?node_id=520826
11:26 nothingmuch http://rt.openfoundry.org/Foundry/Proj​ect/Source/index.html/pugs/checkout/do​cs/notes/context_coercion.pod?rev=8576
11:26 nothingmuch http://rt.openfoundry.org/Foundry/Pro​ject/Source/index.html/pugs/checkout/​docs/notes/multimethods.pod?rev=8575
11:27 gaal in subversion, how do I say I want to release a file from source control, but not have "svn up" delete it from other people's working copies?
11:27 gaal that is, things that ought to have never been "svn add"ed but rather ignored
11:27 gaal nothingmuch: thanks
12:01 audreyt stevan: I maimed PILN beyond belif :)
12:01 whiteg joined perl6
12:01 audreyt asavige++ # rpn writeup
12:03 elmex joined perl6
12:03 svnbot6 r8577 | audreyt++ | * Insanity is not only a good idea, it's the law:
12:03 svnbot6 r8577 | audreyt++ |   Adopt $Larry's object model in PIL^N.
12:03 svnbot6 r8577 | audreyt++ |     ::Scalar.isa('Scalar'); # true!
12:03 svnbot6 r8577 | audreyt++ |     ::Scalar.isa('Class');  # not true!
12:03 svnbot6 r8577 | audreyt++ | * The previous ::Scalar metaobject is now available as ::Scalar.meta,
12:03 svnbot6 r8577 | audreyt++ |   which replaces the old ".class" call.
12:03 svnbot6 r8577 | audreyt++ | * In bootstrap code, non-exposed metaobjects now adopts the ^ sigil.
12:03 svnbot6 r8577 | audreyt++ |   So ::Scalar.meta is just ^Scalar.
12:03 svnbot6 r8577 | audreyt++ | * Miraculously, all tests still pass.
12:04 Southen joined perl6
12:08 gaal yes, it is a very nice writeup (I missed his funny style :)
12:13 gaal # "Despite my dubious past"
12:13 audreyt I rofl'ed :)
12:15 asavige now that rpn thing has been done to death I suppose I've run out of excuses to work on p6doc
12:15 audreyt :D
12:16 audreyt how about porting perldoc -q to p6bible?
12:16 audreyt and import synopses from p6bible to p6doc?
12:17 asavige k. i'll investigate (don't know much about p6bible and p6doc yet)
12:19 audreyt p6bible is Perl6-Bible on CPAN
12:19 audreyt p6doc is pugs/docs/p6doc/
12:44 asavige left perl6
12:50 iblechbot joined perl6
12:58 * gaal receives a reply from Simon M re: FFI and is eager to try it out but is at $work
13:00 * audreyt suddenly remembers she has a haskell-unicode proposal due.
13:01 gaal where for?
13:02 audreyt haskell-prime workgroup
13:02 audreyt next version of haskell
13:03 audreyt http://haskell.galois.com/cgi-b​in/haskell-prime/trac.cgi/wiki
13:04 chris2 joined perl6
13:05 Debolaz Eww.. haskell..
13:07 gaal cool!
13:12 orafu joined perl6
13:35 Limbic_Region joined perl6
13:58 r0nny joined perl6
14:17 xinming joined perl6
14:26 Qiang joined perl6
15:08 justatheory joined perl6
15:17 mjl69 joined perl6
15:25 feng joined perl6
15:26 stevan audreyt: ping
15:28 xinming joined perl6
15:30 lisppaste3 joined perl6
15:31 Eimi joined perl6
15:42 vel__ joined perl6
15:43 audreyt stevan: sorry, I'm just about to sleep now
15:43 audreyt going to take this psychological assessment thing tomorrow early morning
15:43 stevan audreyt: no problem
15:43 audreyt so sleep is vital
15:43 stevan gotcha
15:43 stevan sleep then :)
15:43 audreyt good night :) hopefully you can live with the PILN resigiling :)
15:44 stevan thats fine, I really should $work today anyway ;)
15:44 audreyt cool. ciao!
15:44 audreyt &
15:51 nothingmuch joined perl6
15:52 * Debolaz looks at jifty.
16:01 Limbic_Region joined perl6
16:24 marmic joined perl6
16:40 elmex joined perl6
16:42 elmex joined perl6
16:52 Eimi joined perl6
16:55 svnbot6 r8578 | stevan++ | examples/rpn/*
16:55 svnbot6 r8578 | stevan++ | - added a (somewhat broken, not completely tested) PIL^N version
16:55 svnbot6 r8578 | stevan++ |   of asavige++ RPN examples. It needs some more work and a test
16:55 svnbot6 r8578 | stevan++ |   suite built with Test::PIL, I will do some more when I have the tuits.
16:58 luqui re
17:03 Odin-LAP joined perl6
17:06 luqui Hah!  I misspelled coercion.
17:08 luqui audreyt, is there a reason that you're writing:  proto foo(...) --> Return, instead of having --> inside the parens?
17:12 luqui audreyt, how does your context proposal handle MMD on return type?
17:15 luqui audreyt, and I don't see how putting them in parametric roles gives you decidability of want() (assuming that want() would like to respect subtyping)
17:23 luqui infix:<=> can't be a multimethod
17:23 luqui it does not follow subtyping laws
17:23 luqui !!
17:24 luqui no, no, it can!
17:27 luqui but RW isn't good enough.  You need a write-only reference to do it.
17:28 Lartuv joined perl6
17:32 svnbot6 r8579 | luqui++ | Doing type inference with multimethods.  Woot!
17:39 luqui oh, also, I think we can safely revive theory theory now as simple typeclass support
17:39 luqui but the conditional expansion has to go...
17:53 feng123 joined perl6
18:01 stevan joined perl6
18:25 chris2 is there an online copy of perlkwid.kwid ? the one at autrijus.org 404s
18:26 stevan chris2: there should be on in the VCS
18:26 stevan somewhere,.. I cant say for sure where though
18:26 kane_ joined perl6
18:27 aufrank joined perl6
18:28 aufrank hello!
18:29 stevan aufrank: !!!!
18:29 aufrank stevan: I don't suppose you read chinese, do you?
18:30 stevan aufrank: I do, but I have no idea what it means :P
18:30 aufrank chuckle
18:30 aufrank I saw your PIL^N rpn calculator
18:30 stevan aufrank: babelfish will occasionally mangle things into an almost readable form
18:31 stevan yes, it is subtly broken I think, but I didn't have the tuits to figure exactly where
18:31 aufrank I think I'd rather write in perl6 than PIL^N
18:31 aufrank you convinced me ;)
18:31 stevan :)
18:32 stevan aufrank: PIL^N is only for people who are really sick in the head,... but as an alternative to PIR I will take it anyday :)
18:32 aufrank I forget, is PIR the one that uses TGE or PGE?  :P
18:33 iblechbot joined perl6
18:33 stevan it is the one which looks like assembler, smells like assembler, and for the most part is assembler :)
18:33 stevan PIL^N is more the bastard love child of Haskell, Scheme and Perl 5
18:34 aufrank what's the scheme influence?
18:36 stevan the basis for PIL^N was the Perl6::ObjectSpace's version of the object-model bootstrap, and I had "sketched" a Scheme-ish mini-language (aka - S-Expressions) as a possible DSL to write it in  
18:36 stevan audreyt wanted it to look more like p6, and have the purity (immutability) of Haskell
18:38 stevan mix all those ideas together and you get PIL^N
18:38 aufrank how long did you and audrey spend on getting the syntax right?
18:38 stevan :)
18:38 stevan we didnt
18:38 stevan she did most of it in like a few hours
18:39 aufrank yargh
18:39 aufrank scary, that one
18:39 stevan we stole much from perl, pointy subs (-> {}) and array literals [], hash literals {}, numbers and strings
18:39 aufrank those I saw
18:39 stevan thats pretty much it
18:39 stevan oh,.. well the &?SUB is from Perl 6 too
18:40 stevan from there I have just been trying to learn the best way to write it
18:40 aufrank and the idea is to write PIL2 using PIL^N?
18:40 stevan it will never be exposed to the user level, so getting the syntax right is not a big deal really
18:41 aufrank yeah, that much I got :)
18:41 stevan aufrank: no, PIL^N is kind of a subset of PIL2
18:41 stevan PIL2 will have all the stuff needed for representing Perl 6,.. PIL^N doesn't have enough yet
18:42 stevan PIL^N is basically for implementing all the "things" Perl 6 will need
18:42 aufrank so is the idea to add to PIL^N until it does, or to use PIL^N to implement something with enough stuff?
18:42 stevan in a "normal" compiler/interpreter this would be in the runtime, and written in the host language
18:42 aufrank right
18:42 stevan Perl 6 will get compiled down to PIL2, which will use PIL^N "things"
18:43 stevan PIL2 will basically be a desugared Perl 6
18:43 stevan but very very very desugared
18:43 stevan and PIL2 will be much *less* readable/writeable than PIL^N is (if you can beleive that)
18:44 obra seen audrey
18:44 jabbot obra: I havn't seen audrey, obra
18:44 obra seen audreyt
18:44 jabbot obra: audreyt was seen 3 hours 4 seconds ago
18:44 stevan obra: she was taking a nap last I saw
18:44 stevan oh wait,.. no sorry,.. went to sleep
18:44 stevan she had a big day tomorrow
18:45 obra nod. customer stuff?
18:46 stevan [10:42] audreyt : going to take this psychological assessment thing tomorrow early morning
18:48 * stevan has to get back to @customer $stuff himself actually &
18:48 obra nod
18:49 * Debolaz rips out Catalyst.
18:50 obra in favor of?
18:50 Debolaz Not decided yet. :)
18:51 Debolaz I am considering rolling my own system.
18:53 tewk Debolaz: what did you think of Jiffy?
18:54 Debolaz tewk: I'm looking at it, but haven't tried it yet. I like that it's using Mason though, a templating system I am already very familiar with. :)
18:55 Debolaz I guess the main deciding factor for me will simply be: Will it work on my system.
18:55 * tewk thinks he won't be happy with anything until it is written in perl6 :)
18:56 tewk work on your system?
18:56 coumbes joined perl6
18:59 Shachaf joined perl6
19:00 arguile joined perl6
19:06 Debolaz tewk: As in, how much magic glue is neccesary to make it work.
19:10 * stevan sniffs some magic glue and gives it back to Debolaz
19:10 * Debolaz pours himself some magic glue.
19:10 Debolaz Or green fairy.
19:10 * stevan drops a few of $Larry[0]'s blue ice cubes in his Mountain Dew
19:21 Debolaz What does jifty have that catalyst doesn't? Except for the pony?
19:22 stevan continuations
19:22 integral it's only got one of everything
19:22 stevan although mst has been threatening a CPS core for Catalyst for a while
19:24 stevan Debolaz: it also has those form thingies,.. although I don't grok them fully yet
19:35 obra It also has the ajax stuff built in in a way that degrades gracefully with non-ajax browsers
19:35 obra but me -> train to barcelona
19:38 integral seems a lot more usable out the box
20:15 p5evalbot joined perl6
20:18 buu joined perl6
20:20 trym joined perl6
20:51 avar joined perl6
21:29 sapper joined perl6
21:36 vel__ left perl6
21:39 oylenshpeegul joined perl6
21:53 buu joined perl6
21:59 Qiang joined perl6
22:13 mandarin_ joined perl6
22:20 nothingmuch joined perl6
22:21 lisppaste3 joined perl6
22:38 avar joined perl6
22:59 marmic joined perl6
23:02 iblechbot joined perl6
23:16 frederico joined perl6
23:31 lisppaste3 joined perl6
23:43 nothingmuch_ joined perl6

| Channels | #perl6 index | Today | | Search | Google Search | Plain-Text | summary

Perl 6 | Reference Documentation | Rakudo