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

Powered by Cro and the RakuĀ® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!