svn switch --relocate svn.openfoundry.org/pugs svn.pugscode.org/pugs/ | run.pugscode.org | spec.pugscode.org | paste: sial.org/pbot/perl6 | pugs.blogs.com Set by avar on 16 November 2006. |
|||
00:13
weinig is now known as weinig|food
00:42
weinig|food is now known as weinig
|
|||
TimToady | fg | 00:57 | |
oops :) | |||
well, as long as I'm here, anyone have any opinions on the floor vs euclidian divmod debate? | 00:58 | ||
allbery_b has no horse in that race, but notes that Haskell provides both (divMod and quotRem) | 01:00 | ||
01:02
b00t joined
01:16
bcorn joined,
theorbtwo joined
01:28
davidm123 joined
01:44
hexmode joined
02:02
bucky joined
02:03
hexmode joined
02:05
diotalevi left
02:09
hexmode joined
02:13
autark joined
02:47
demy joined,
demy left
02:49
asey joined,
theorbtwo joined
02:51
weinig is now known as weinig|zZz
|
|||
dduncan | TimToady, regarding your question, the only opinions I have in that regard at the moment is that Int/Int should result in an Int result, Num/Num should be num, and those 2 operators should perhaps look different so that users can easily tell what is going on | 02:52 | |
TimToady | Int/Int --> Int doesn't avoid Least Surprise for most people. | 02:54 | |
most people will expect Int/Int --> Num because that's how math works | 02:55 | ||
SamB | yeah. except broken people! | ||
TimToady | well, grade school math... | ||
however, separating out different operators will probably be okay | 02:56 | ||
SamB | well, maybe in elementary school, the answer has to be an integer too, but you never run into any problems where that doesn't happen? | ||
02:57
finchely joined,
mako132_ joined
|
|||
TimToady | true, they teach remainders before they teach fractions... | 02:57 | |
well, gotta decommute & | 02:58 | ||
davidm123 | getting this very same problem in building perl6 under cygwin..aspn.activestate.com/ASPN/Mail/Mess...ls/3364906 . I patched _LIB_VERSION', but miniparrot fails | 02:59 | |
(correction: parrot not perl6) | |||
03:01
Psyche^ joined
03:13
Psyche^ is now known as Patterner
03:22
mako132_ joined,
mbradley joined
03:23
justatheory joined
03:25
GabrielVieira joined
03:35
asey joined
03:39
demy joined,
demy left
03:43
demy joined,
demy left
03:55
frankg joined
03:58
johnjra joined
03:59
b00t joined
04:13
nipra joined,
leed joined
04:47
lyokato joined
04:49
mjk joined
05:33
jdv79 left,
sunnavy joined
05:37
nperez joined
06:15
BooK_ joined
07:00
nipra_ joined
07:04
TimToady_ joined
07:09
bsb left
07:19
dem2 joined
07:20
dem2 left
|
|||
Juerd | feather users: | 07:33 | |
2007-01-10 | |||
Please clean up your home directory, as we're running out of storage | |||
space on the machine that hosts the data backups. If you could remove that 6 | |||
months old Pugs or GHC tree that you no longer touch anyway, that would be | |||
great. Maybe there are things that you can gzip? | |||
07:36
dduncan left
07:41
iblechbot joined
07:44
Aankhen`` joined
|
|||
gaal | Juerd: done (cleared O(128MB)) | 07:46 | |
07:49
marmic joined
07:53
dduncan joined
07:55
Southen joined
08:03
deq` joined
08:12
sunnavy joined
08:23
mj41_ joined
08:24
lisppaste3 joined
08:25
nipra_ is now known as nipra
08:36
devogon joined
08:58
elmex joined
09:08
buetow joined
09:14
andara joined
10:08
chris2 joined
10:18
fglock joined
|
|||
fglock | audreyt: would you send me the graffle file for pugs.blogs.com/photos/visiolization...strap.html - I'll draw one for kp6 | 10:27 | |
10:28
ruoso joined
|
|||
gaal | parser combinators in smalltalk: gbracha.blogspot.com/2007/01/parser...ators.html | 10:32 | |
fglock | why does 'combinator' mean? | 10:35 | |
what | 10:38 | ||
10:38
andara left
|
|||
fglock | ah, the article defines it | 10:43 | |
10:45
yves joined
10:46
seano joined
|
|||
svnbot6 | r15022 | fglock++ | kp6 - added ast transformation engine to spec | 10:50 | |
10:52
andara joined
|
|||
audreyt | fglock: perlcabal.org/~audreyt/tmp/lrep.graffle | 11:00 | |
rgs | hi audreyt | ||
audreyt | greetings rgs | ||
rgs | so you're going to be in Nice starting next week-end ? | ||
audreyt | yes | ||
and stay till the next | |||
are you going to be present on the 2nd weekend as planned? | |||
rgs | no, but I think I can make it on monday and tuesday | 11:01 | |
15, 16 (before the conference iirc) | |||
audreyt | ack | ||
my talk is 17th though | |||
that means I better finish slides before you arrive | |||
otherwise you'll find me in JIT mode :) | |||
rgs | I'll let you know | 11:02 | |
BTW, I just resigned from $work, so things are a bit difficult to plan | |||
audreyt | ah. | ||
svnbot6 | r15023 | fglock++ | mp6 - finished ast-traversal module | ||
audreyt | are you going to be in.tw? | ||
rgs | for OSDC ? no | 11:04 | |
audreyt | k | ||
11:05
sunnavy_ joined
|
|||
andara | hi audreyt! I'm going to Nice too. Looking forward to your talk | 11:05 | |
audreyt | so are your place close to the conf hotel (Plaza)? is that plan that we hack at hotel? | ||
andara: me too, I havn't started thinking about my talk | |||
so I also look forward to it | |||
;) | |||
rgs looks up plaza hotel | |||
andara | audreyt: cool. BTW, could you please point run.pugscode.org to feather.perl6.nl:8080/runpugs/ ? | 11:06 | |
audreyt | andara: sure, will do so now | ||
rgs | it's very close | ||
nice is a small city | |||
audreyt | cool | 11:07 | |
andara | audreyt: great, thanks! | ||
rgs | www.flickr.com/photos/rgarciasuarez74/225906267/ <- my place, an old building which is now an historical monument | 11:08 | |
audreyt | ...wow :) | 11:09 | |
so I arrive at 13th and will start working on slides upon landing | 11:10 | ||
there are conferences too at 15th and 16th | 11:11 | ||
but I'd like to drop by and visit and hack w/ you at timeslots convenient to you, if that's okay | |||
otherwise you can come to the hotel too :) | |||
rgs | I'll have nothing else to do | ||
gaal | audreyt: moose | 11:12 | |
audreyt | gaal: antlr | ||
gaal | fglock: a function that manipulates functions | ||
audreyt: so i had a question about caching compilations | |||
can't persistently memoize parseProgram because what to do with the env? | |||
audreyt | each parseProgram theoretically gets the same clean env | 11:13 | |
gaal | not the case today, I tihnk | ||
audreyt | no, not at all | ||
unless you count Test.pm.yml | |||
we have preliminary "linking" technology | |||
but it's not the case for normal "use" resolution | |||
which is of course wrong... | 11:14 | ||
gaal | so opEval should by rights first construct a clean env, parse onto it, and merge the result to the current env? that will give us a momoization point | ||
audreyt | exactly so | 11:15 | |
aka standard linking | |||
gaal | ok; so in fact Env param should be dropped from parseProgram to ensure this | ||
audreyt | exactly so. | ||
gaal | cool | ||
and mergePads or unionPads (i forget the name) can be wrapped in a reusable new "link" function | 11:17 | ||
audreyt | yup. | ||
we already do that for .pm.yml loading | |||
what we need to do is to convince "use" to always go thru that route | |||
but not neccessarily with .yml | 11:18 | ||
11:18
TimToady joined
|
|||
audreyt | i.e. the .yml part can wait until the merge env thing works | 11:18 | |
gaal | if we hook into opEval it'll always happen | ||
audreyt | then we worry about proper deserialization | ||
aye aye. | |||
gaal | great, i'll resume this after work then | 11:19 | |
audreyt | cool | 11:25 | |
I need to catch some sleep... bbl | |||
11:34
fglock joined
|
|||
fglock | audreyt, gaal: thanks | 11:35 | |
11:35
buetow joined
11:41
seano joined
|
|||
svnbot6 | r15024 | fglock++ | kp6 - rename 'Visitor.pm' to 'Traverse.pm' | 11:45 | |
pasteling | "evalbot_r15023" at 194.145.200.126 pasted "Pugs build failure" (375 lines, 20.9K) at sial.org/pbot/22252 | 11:51 | |
11:54
andara joined
11:56
xpika joined
|
|||
svnbot6 | r15025 | fglock++ | kp6 - added proof-of-concept traverse script | 12:00 | |
12:03
iblechbot joined
|
|||
fglock | ?eval my $s=''; for 1..3 { $s ~= $_; eval ' LEAVE { $s ~= 42 } ' }; $s | 12:27 | |
evalbot_r15025 | \"123" | ||
fglock | ?eval my $s=''; for 1..3 { $s ~= $_; LEAVE { $s ~= 42 } }; $s | ||
evalbot_r15025 | \"142242342" | ||
12:48
weinig|zZz is now known as weinig
|
|||
pasteling | "fglock" at 201.35.169.13 pasted "a possibly saner implementation of BEGIN blocks run-time side-effects" (29 lines, 442B) at sial.org/pbot/22254 | 12:51 | |
fglock | luqui: please see sial.org/pbot/22254 | 12:52 | |
it would be nice to use this, because it has no impact on performance | 12:53 | ||
12:57
luqui joined
|
|||
fglock | luqui: hi :) | 12:57 | |
luqui | hello fglock | 12:58 | |
12:59
kanru joined
13:01
lumi joined
|
|||
fglock | luqui: I found that I can use closures to init lexicals at any pad level - see sial.org/pbot/22254 | 13:03 | |
it's much cleaner | |||
13:04
Limbic_Region joined
|
|||
luqui | hmm, I wonder why we didn't see that before... | 13:06 | |
fglock | it comes from the background refactoring process in the brain - it's a low priority process | 13:13 | |
13:17
sunnavy joined
13:22
elmex joined
|
|||
svnbot6 | r15026 | fglock++ | kp6 - added a note on pad accessors | 13:22 | |
13:51
dduncan left
13:53
gnuvince joined
14:04
vel joined
14:18
[particle] joined
14:25
Steve_p joined
14:29
Alias__ joined
14:36
finchely left
14:45
vel joined
14:51
kanru joined,
weinig is now known as weinig|bbl
14:55
iblechbot joined
14:59
Odin- joined
15:03
ruoso joined
15:08
xpika left
15:21
hexmode joined
15:27
fglock joined
15:37
bonesss joined
|
|||
[particle] | how big (kb, #files) is the pugs test suite? | 15:41 | |
don't have svk, so it's hard for me to measure | |||
allbery_b | 20.5k, 2138 files in my pugs/t | 15:43 | |
that's not excluding .svn though, whoops | |||
[particle] | is that an svn working copy? | ||
allbery_b | 759 files | 15:44 | |
yes | |||
[particle] | thanks | 15:59 | |
gaal | actually it's more like 1.7MB :) | 16:00 | |
allbery_b | hm right, du defaults to 512-blocks on here and I didn't exclude the svn foo etc. | ||
[particle] | gaal: where are BEGIN/END blocks stored in pugs ast? | ||
allbery_b | and probably did other things wrong | ||
[particle] | 627 files? | ||
gaal | [particle]: begin is folded in, and leaves no trace in the ast | 16:01 | |
END gets pushed to a @*END magical | |||
[particle] | same for check/init? | ||
gaal | hm i think so let me look | 16:02 | |
yes indeed. see vcode2checkBlock etc. in Pugs.Parser cicca ln. 1091 | 16:03 | ||
*circa | |||
[particle] | kthanks | ||
gaal | sure | ||
[particle] | we'll soon have that functionality in past | ||
gaal | yay | 16:04 | |
<3 "we will .. in past" | |||
fglock | is p6 supposed to support this: my @a[10] = 20; | 16:06 | |
gaal | sure | ||
16:06
thepler joined
|
|||
gaal | oh, with a my... not sure :) but i think so. :-) | 16:06 | |
fglock | lexiacally 'shadow' a data structure's element | 16:07 | |
lexically | |||
[particle] | gaal: so, the result of begin is converted to ast and injected? | 16:08 | |
nothingmuch | does lexical scoping even make sense here? | 16:09 | |
i mean, pads are shadowed lexically because they are an opaque data structure | |||
gaal | the result of a begin is a value. it might have had other enviromental side effects, but basically yes, it's folded to a context and injected to the compunit's ast | ||
nothingmuch | it has no addressible origin | ||
fglock | ?eval my $s; my @a=1..5; { my @a[2]=42; $s= ~@a; }; $s | ||
evalbot_r15026 | \" 42" | ||
gaal | srry bbiab.. | ||
16:10
tewk joined
|
|||
svnbot6 | r15027 | andara++ | [runpugs] | 16:10 | |
r15027 | andara++ | -release of what was the 'devel' version, v0.3.0 | |||
r15027 | andara++ | -window/tab close now terminates session. Thanks diakopter. | |||
r15027 | andara++ | -for those who didn't use the devel version: it's much faster now | |||
fglock | I need to modify an array element lexically | 16:15 | |
that's for implementing things like: my multi infix:<+> {...} | 16:17 | ||
lexical modifications to the global grammar | |||
hmm - it could be local'ized instead, by resetting to the old value on LEAVE | 16:18 | ||
svnbot6 | r15028 | seano++ | Another "99 problem", perl5-style. | ||
16:19
GabrielVieira joined
|
|||
fglock | GabrielVieira: ola | 16:19 | |
GabrielVieira | fglock flavio my master! :) | 16:20 | |
fglock | heh | ||
kolibrie | fglock: but that is 'temp' - I don't know how 'my' should work in your example, or if it is even legal, because the array was already 'my'-ed | 16:29 | |
fglock | hmm - @P6::Grammar::infix{'+'} needs to dispatch from the caller's pad POV | ||
TimToady | I think it probably parses (my @a)[2] | 16:30 | |
and that hides the outer @a | 16:31 | ||
fglock | yes | ||
I'm now trying to find out how 'my multi infix:<+> is parsed ... {...}' interacts with '@P6::Grammar::infix{'+'}' | 16:32 | ||
TimToady | fglock: yes, you have to keep track of the grammar the user thinks they're using. | ||
fglock | is it a kind of shadow over the global value | 16:33 | |
TimToady | the macro part shadows, but has the same effect of dispatching to a normal multi | 16:34 | |
and a normal "my multi" just hides that "long name" | |||
16:35
mbradley joined
|
|||
TimToady | in other words, my multi infix:<+> doesn't have to do anything to the infix table if it's already there. | 16:35 | |
fglock | got it | 16:36 | |
TimToady | the infix table just turns $a + $b into infix:<+>($a,$b) and then normal multi takes over | ||
fglock | and the parser executes in the current block's compile-time context | ||
TimToady | so don't need to temporize table for that. | ||
as we used to say with P5, a local at compile time is a my at run time | 16:37 | ||
or something like that | |||
if you do add a new infix, then you have to compile-time temporize something | 16:38 | ||
whether it's the whole infix table, or a shadow mask... | |||
or, I suppose, if you change the associativity or precedence of + | 16:39 | ||
course, it does hurt anything except performance to temporize unnecessarily. | 16:40 | ||
(in theory) | |||
s/does/doesn't/ | 16:41 | ||
16:41
buetow joined
|
|||
TimToady | obviously I need my coffee... | 16:41 | |
fglock | thanks - I got the idea | 16:42 | |
16:46
ashleyb joined
16:49
nipra joined
|
|||
GabrielVieira | fglock pvt? | 16:52 | |
16:56
GabrielVieira2 joined
16:59
buetow joined
17:00
Lunchy joined
17:18
andara left,
maquis joined
17:21
fglock joined
17:28
fglock joined
17:37
seano joined
17:56
GabrielVieira joined
18:01
justatheory joined
|
|||
fglock | p6hack + $work is a bit confusing :) | 18:02 | |
18:12
diotalevi joined
|
|||
TimToady | yes, especially if $work->perl5() | 18:15 | |
wolverian | I considered trying to use perl6 for my data structures course project, but perhaps haskell is more realistic at this point | 18:16 | |
(fortunately the graders don't really care that much about the language, so I don't have to use java) | |||
18:18
weinig joined
|
|||
fglock | actually, right now, work = drawing comics for our web page :) | 18:18 | |
luqui | wolverian, haskell might throw them for a thunk | 18:22 | |
data structures in haskell are a little... different :-) | |||
wolverian | true enough. :) | 18:23 | |
luqui | \f -> f 1 2 -- oh yeah, that's just the tuple (1,2) | 18:25 | |
fglock | I've been switching between p6/p5 too often lately - it's no longer a problem | 18:26 | |
18:27
seano joined
|
|||
TimToady | that's the problem with Haskell--you have to say "oh yeah" on just about every line... | 18:33 | |
every function is a brain pretzel | 18:34 | ||
luqui | eh, no, just the fun ones | ||
allbery_b is gradually getting past that point | |||
masak | will computers be doing programming in the future, I wonder | 18:35 | |
luqui | a lot of, say, pugs is pretty everyday code, once you grok the (many) haskell idioms | ||
masak, either no, or they are already | |||
allbery_b | masak: they've been predicting that since the 50s or earlier :) | ||
luqui | (define your terms!) | ||
masak | luqui: I don't mean metaprogramming, or other such things | 18:36 | |
TimToady | computers are doing most of the programming these day; problem is you have to specify the problem for them in a higher level language | ||
masak | I mean the whole thing, from innovation via design to implementation | ||
18:36
jabbot joined
|
|||
masak | TimToady: I don't mean compilation either | 18:36 | |
(seems I'm mostly defining what I _don't_ mean :) | |||
TimToady | my point is that "innovation" is open-ended | 18:37 | |
luqui | innovation is the hard one | ||
masak | TimToady: point taken | ||
TimToady | once computers can do part of it, the def changes | ||
luqui | perhaps someday programming will be something like what automated proof checkers are... | ||
er, proof generator | |||
s | |||
you can tell the computer "prove this" | |||
and it will crank and crank (for many many hours for even the simplest things :-) | |||
and then say "here you go" | |||
but a computer has no idea what is interesting to prove | 18:38 | ||
masak | I think a computer doing large parts of a human's programming project would pass my definition | ||
TimToady | trouble is, for lots of useful problems you need a computer the size of the universe. | ||
luqui | masak, then I think yes | ||
masak | ok, next question: will they have coding standards? will they care? | ||
will the standards be anything like human standards? | |||
will different computers prefer different languages? the same languages as humans? | 18:39 | ||
TimToady | my son Aron is currently off at a conference where they're trying to figure out if the universe has coding standards. :) | ||
masak | probably in 50 years these questions will seem as naive as a person from the year 1900 asking questions about today's programming languages :) | ||
TimToady | well, if we're lucky bitrot will have expunged these irc logs by then... | 18:40 | |
masak | TimToady: the biological part of the universe certainly doesn't, so far as we know anyway | ||
luqui | to be sure :-) | ||
(to the "in 50 years" comment) | |||
TimToady | well, but nothing is better at innovation than biological systems | 18:41 | |
luqui | touche | ||
TimToady | see H5N1 | ||
wolverian | it's so very slow though :) | ||
TimToady | we sincerely hope H5N1 is slow | 18:42 | |
wolverian | I meant biological systems in general, as compared to silicon. | ||
(okay, I've read too much egan.) | |||
TimToady | it's the price of cheating | ||
luqui | hey, a few billion years is no time to wait when comparing how long it takes to break a 4096 bit rsa key | 18:43 | |
18:43
cdfh_ joined
|
|||
TimToady | the fastest way for biology to deal with that is to invent a species that can deal with it. | 18:44 | |
luqui | I wonder if nature could innovate a way to do that faster than brute force could.. | ||
TimToady | unfortunately nature likes to observe its own qubits | 18:45 | |
but nature has provably produced a species that would like to avoid watching 4096 qubits for "long enough" | 18:46 | ||
luqui | provably? which one? | ||
oh | |||
duh | |||
luqui feels smrt | |||
allbery_b | heh | 18:47 | |
TimToady | the sme species tht would like to mke computers smrter thn themselves. | ||
Gothmog_ | luqui: It would take long to brake with the current knowledge, but it's not even proven that prime factoring is NP-hard, let alone the P/NP problem. | 18:48 | |
luqui | details, details | ||
Gothmog_ | Just wanted to quibble a bit. ,-) | 18:49 | |
19:00
ozo_ joined
19:03
elmex joined
|
|||
fglock | just checking - when I say 'my multi infix:<+> {..}' is it 'OUTER' to the parser? | 19:14 | |
awwaiid | isn't factoring np-complete? | ||
awwaiid reads wikipedia to find out that it isn't | 19:15 | ||
19:17
GabrielVieira2 joined
|
|||
wolverian | awwaiid, it is believed to be in NP but not NP-complete | 19:18 | |
masak | I kinda imagine that computers would have the same reasons for wanting to program in HLLs as we humans do | ||
awwaiid | lazy bastards | ||
masak | :) | ||
I mean, it hides complexity for us, it should for them too, right? | |||
awwaiid | yes... but what is our motivation for hiding complexity if it isn't limited ability to hold it all in our minds at once... I imagine a super-brain (smart enough to hold the entire compiler in their mind instantly) would find actually _using_ a compile pointless. | 19:20 | |
we have a mind-body problem, they will have a mind-othersoftware problem | |||
[particle] | i don't find calculators useless | 19:21 | |
masak | awwaiid: they would also have limited ability to hold it all in their minds at once... the limits might be farther away, but they'd be there | 19:22 | |
TimToady | fglock: I don't know what you mean by "OUTER". are you asking what the global ramifications of "my multi" are? | ||
19:22
diakopter joined
|
|||
awwaiid | masak: good point | 19:23 | |
wolverian | just build more computronium. | ||
19:23
mbradley joined
|
|||
wolverian | I wish humans ran on extensible hardware. | 19:24 | |
masak | wolverian: they do | ||
my glasses are an extension to my eyes | |||
wolverian | I meant human minds. | ||
but, point. :) | |||
masak | well, my mind uses my eyes as hardware... | 19:25 | |
wolverian | right. | ||
fglock | TimToady: I mean, the parser sees the lexical declaration | ||
wolverian | it's like buying a new webcam versus buying a better CPU | ||
TimToady | leaving aside the infixness, any "my multi" is used only within dispatches originating from that lexical scope. | 19:26 | |
the scope of the infix "macro" is the same. | |||
masak | wolverian: what is like buying a new webcam versus buying a better CPU? | 19:27 | |
[particle] | hrmm, will @?BEGIN, @?END be available? | 19:28 | |
wolverian | masak, getting glasses versus mind-augmentation. | ||
TimToady | when you're building the candidate list for a particular multi dispatch, it goes outward in the scopes and finds any candidates whose long name is not hidden by an inner scope | ||
fglock | I think what I mean is, the whole grammar is inside the scope | ||
TimToady | finally it adds in all the global multies | ||
wolverian | (the latter is what I meant with "extensible hardware") | ||
TimToady | logically, yes | ||
wolverian | although I wonder what psychedelics are analogous to. | ||
TimToady | reverts to previous grammar at } | ||
fglock | rather than being a simple external module | ||
masak | wolverian: ah. ... yes. | 19:29 | |
TimToady | yes, you generally have to construct an anonymous grammar | ||
and that anon grammar may well be based on the OUTER:: anonymous grammar | |||
the current grammar is also passed to eval, i think. | |||
but not to require | 19:30 | ||
so in the case of eval you need to remember the current grammar in $?GRAMMAR till run time | |||
that anonymous grammar is where you probably want to store the modified infix etc. tables | 19:31 | ||
fglock | ok! | ||
TimToady | rather than just temporizing, or in addition to temporizing | ||
masak | wolverian: I don't think psychedelics necessarily have an equivalent in the computer world, though that's quite a bland answer, admittedly. the thing that psychedelics disturb (something along the lines of "a consistent conscious experience") doesn't have an analogue in the software world. | 19:32 | |
TimToady | basically a GC problem; if anything refers to $?GRAMMAR you keep it around. | ||
wolverian | masak, right. yet, anyway. :) | ||
TimToady | multithreading seems to be related. :) | 19:33 | |
if this conversation is any clue | |||
masak | TimToady: :) | 19:35 | |
allbery_b | <mike> I conjecture it is similar to a slight overvoltage </mike> | ||
TimToady | more like changing the damping characteristics of back-and-forth interactions, I suspect | 19:37 | |
maybe when computers can have epileptic fits, they can go psychedelic | |||
anyway, moving from hard locking to STM may get us closer | 19:38 | ||
next is PTM, psychedelic transcendental memory | 19:39 | ||
masak | *lol* | ||
masak would like to see an SPJ paper on that | |||
probably, there will never really be a stage where we'd say "well, now it seems that computers really program themselves" | 19:41 | ||
either it'll never happen or it already happened, depending on one's definitions | |||
fglock | is a BEGIN block compiled, and then executed - or is it compiled/executed a statement at a time | 19:42 | |
masak | but what we'll probably see increasingly is computers hooking up to each other and telling each other what to to, in increasingly complex and seemingly aware ways | 19:43 | |
PerlJam | fglock: what an odd question. | ||
masak | fglock: is the difference noticeable in any way? do you have a code example? | ||
PerlJam | fglock: I've always thought it the former. I guess thinking about the other is what strikes me as odd. | 19:44 | |
fglock | PerlJam: I'm just checking - because I'm working on it right now... | ||
TimToady | BEGIN just compiles like a normal closure, but executes after final } | 19:45 | |
fglock | it can have a BEGIN inside it, right? | ||
[particle] | executes as soon as possible | ||
TimToady | yes | 19:46 | |
but you don't need statement granulatity on you compiler pipeline | |||
masak | what about a BEGIN with an END in it? | ||
TimToady | closure granularity is good enough | ||
fglock | ok | 19:47 | |
TimToady | the END doesn't care | ||
still executes when the run-time is exiting | |||
masak | ah | ||
reasonable | |||
TimToady | all END/CHECK/INIT do are push a closure on a queue | ||
or whatever correct English for that is... | 19:48 | ||
well, push or unshift, depending on the order used for that kind of block... | 19:49 | ||
gaal | "append"? | ||
TimToady | either that or the caller runs in the other order. | ||
gaal | or even "put" | ||
TimToady | pend this to that list | 19:50 | |
gaal | app-END{} | ||
19:50
justatheory joined
|
|||
TimToady | perhaps just push everything and let the caller decide pop vs shift. | 19:50 | |
then the list always reflects lexical order, for which there is something to be said. | 19:51 | ||
especially if people add new blocks with weird execution orders, like dependencies that have to be calculated at run time. | 19:54 | ||
fglock | TimToady: thanks for the explanations | 19:56 | |
home & | |||
19:57
GabrielVieira2 is now known as GabrielVieira
20:02
azazello joined
|
|||
svnbot6 | r15029 | fglock++ | kp6 - updated spec; added some experiments with begin-blocks | 20:11 | |
masak | fglock++ # moving stuff forward | 20:15 | |
20:39
davidm123 joined,
davidm123 left
20:56
Aankhen`` joined
21:05
jferrero joined
21:08
bernhard joined
21:14
mdiep_ joined
21:48
diotalevi left
22:03
Limbic_Region joined
22:36
GabrielVieira2 joined
22:53
polettix joined
23:14
bonesss joined
23:18
diakopter left
23:21
hexmode joined
23:26
justatheory_ joined
23:34
mako132_ joined
23:51
xpika joined
|