<neuro_sys>
veltas: Thanks, I had that in mind, but didn't get around to reading about it yet.
<neuro_sys>
Now I'll check that. Thanks for pointing it out.
<neuro_sys>
AoC is pretty trivial so far indeed, but it gets progressively difficult.
<neuro_sys>
It's not entirely clear to me why (the docs or the standard doen't mention usage) the structure field is used like 0 field-name.
<neuro_sys>
Ah it is clear now, nevermind. :) An offset is always used with a base address, that's why.
<neuro_sys>
xb
<neuro_sys>
^ typo
<siraben>
veltas: hah, for day 3 I saw someone post a one-line awk solution
<siraben>
i'd be happy if finally finished AoC this year
<siraben>
neuro_sys: nice, using named parameters makes it clearer
boru` has joined #forth
boru has quit [Disconnected by services]
boru` is now known as boru
nmz has joined #forth
nmz has quit [Quit: EXIT]
nmz has joined #forth
dave0 has joined #forth
<crc>
I don't
<crc>
I don't expect to finish aoc, I'll likely run out of time as the challenges get longer
Gromboli_ has quit [Read error: Connection reset by peer]
gravicappa has joined #forth
sts-q has quit [Ping timeout: 260 seconds]
sts-q has joined #forth
dave0 has quit [Read error: Connection reset by peer]
dave0 has joined #forth
<siraben>
i wonder how the Forthers fared with day 4
<siraben>
I used parser combinators, other people used regexes
xek_ has joined #forth
<veltas>
I don't bother with AoC, this year I plan on doing some in Forth
<veltas>
Regex's are overrated imo
<veltas>
Last night I was writing 2's solution, trying to do it a bit more 'idiomatically' for neuro_sys, will look at it again at lunch probably
<veltas>
As an exercise and in case it's helpful
<veltas>
Well 2 part 1 anyway
<neuro_sys>
It would be helpful veltas.
<veltas>
I think your code is good, but it's definitely not very "forthy", and so the example might help you
<veltas>
I don't think there is anything objectively wrong with yours
<veltas>
When I put mine in here hopefully some older forthers will flame it and make it even better
<neuro_sys>
siraben: I would imagin that custom parsers were quite common.
<veltas>
I think I strongly dislike 'declarative' code features that hide weeds and complexities that reappear elsewhere
<neuro_sys>
I would be curious to know about the more common styles.
<veltas>
I'm no authority but I will give it a shot
<neuro_sys>
crc's retro forth style is very appealing and something I'd like to get into eventually, but I need to study some more functional programming.
<neuro_sys>
OTOH, I'm curious about the olden times Forth style too
<veltas>
crc's retro is not functional imo, I think it's just factored and higher level than what most forths provide
<veltas>
I think if you want you should just try using it and crc might help, or someone else might help, if things go wrong
* veltas
back to work
<neuro_sys>
I might be mixing up terminology, but I'm mostly referring to "combinatory logic", curries and such. Not sure specifically FP (which I'm familiar with the basics, and write such code at work).
<veltas>
Just my opinion that a language is not 'functional' just because it has lots of functions
hosewiejacke has joined #forth
<neuro_sys>
My understanding of the basic requirement is that functions are lambda functions (no free variables) and avoiding mutable state.
X-Scale has quit [Ping timeout: 260 seconds]
X-Scale` has joined #forth
<proteusguy>
neuro_sys, that's close enough to be practical for most all discussions.
<siraben>
Yeah crc's code is not functional but procedural.
<veltas>
neuro_sys: I haven't done day 4 yet, but looking at the big OR expression... you could represent each field as a flag
<veltas>
Then check that the result is equal to $FE or $FF (or you know, whatever the result will be with/without the country ID)
<veltas>
c-alpha? isn't used so I can delete that
<veltas>
I think I was using that and then factored it out
<neuro_sys>
The way I wrote so far is just applying c-like language style into Forth I think, and the two things that were problematic are: short-circuit evaluation, and early return/exits.
<neuro_sys>
So perhaps I may stop solving AoC further, and study some more classic Forth code instead (or I'll just keep going, let's see).
<veltas>
You should try writing the first aoc again and see how much you can factor it
<veltas>
And then post it here and we'll see what we can do to take it further
<neuro_sys>
I need write first AoC again indeed, I haven't put it on the github.
<veltas>
I wrote very similar code using locals etc to get c-like code at first, and I think like that it's just C but worse
<veltas>
It's when you take off the training wheels and try and write it more classically that you start to appreciate the elegance of forth, if there is such a thing
<veltas>
The last line I wrote when working on the program was the valid-entry? definition, and I love how simple it turned out at the end
<veltas>
It's just : valid-entry? read-rule remaining-pad ccount rot rot within ;
<veltas>
Like "get the rule, then count how many of the rule's character is in remaining pad space, and check it's within the rule's range"
<veltas>
It reminds me of the examples in Starting Forth near the beginning, like : WASHER WASH SPIN RINSE SPIN ;
<veltas>
But yes, try without locals, and try writing mostly one-line definitions and see what you get
<neuro_sys>
I'll practice that.
<neuro_sys>
crc: Just checked your solution for day 4, looks very good. Very concise and compact.
<neuro_sys>
I see that you use ' to represent strings, but what if they contain whitespace?
<crc>
Yes, underscores are converted to spaces by default
<crc>
not generally. strings at interpret time are allocated from a rotating pool, and memory at `here` can be reclaimed with a little trick
<crc>
(e.g., as a lot of things allocate space at `here`, if you don't need to keep them after execution is done, you could wrap the code in a `&Heap [ ... ] v:preserve`, which restores `Heap` (the `here` pointer) after the quote finishes running
<neuro_sys>
That sounds quite interesting
<crc>
full garbage collection is difficult to get working reliably (I explored this in a couple of other languages I've implemented, but haven't missed it enough to go through the trouble of adding to retro)
<neuro_sys>
If I understand correctly `here` points to Dictionary in Forth, and ALLOCATE uses a separate storage than the dictionary data space. Is it similar in Forth? In that case does Retro allocate only in Dictionary and/or on the heap via ALLOCATE?
<neuro_sys>
s/similar in Forth/similar in Retro/
<crc>
I have no heap, just what forth calls the dictionary
<veltas>
That's interesting! I assumed retro uses heap a lot!
<crc>
memory is a fixed pool, allocated at startup and initialized to zero
<veltas>
Just from looking at the code it seemed like that, puts retro in a new light the next time I read it
<neuro_sys>
So far I only used ALLOCATE for reserving space in Forth, and I'm not yet quite sure about how the Dictionary can be utilized for temporary data storage.
<neuro_sys>
I've seen in Retro (and other Forth code) HERE being used in conjuction with CREATE, or right after word definition.
<crc>
you just need to be careful. if you allocate space at here, then define something you want to keep, you can't reclaim the space. but if you reset the pointers first, it's fine.
<MrMobius>
crc, the only way i have been able to figure out garbage collection is tokenizing words then marking all data with a type to figure out which ones are pointers
<Zarutian_HTC>
hmm... I have written an object system with gc in Forth. I wonder if a colon def of a word could just be all references. Hmm
<Zarutian_HTC>
MrMobious: not heard of two section object struct implementation then?
<MrMobius>
I havent. tell me
<Zarutian_HTC>
basically each obj is a header (sizes and gc colour), references section, and data section
<Zarutian_HTC>
(also in header is a bit to tell if this is a broken heart (moved obj) or not)
<veltas>
Can you have an owner of a broken heart
<Zarutian_HTC>
I am mainly using this object system for graphics stuff. Each obj has an xt of its invocation handler. When invoked the handler sees a pointer to the object on TOS
<Zarutian_HTC>
veltas: not sure what you mean. It is basically a record that points to where the object has moved to
* inode
counts the yes references
<Zarutian_HTC>
the gc is a modified variant of two space copying collector, only there is just one circular space
<Zarutian_HTC>
easy because all pointer calculations is done via ptr+ word
<Zarutian_HTC>
to diffrientate between old objects and moved ones, I use gc colour bit. The current gc colour flips at each gc run.
<Zarutian_HTC>
I have even sketched out a way to do 'ref gone linear' detection and notification but that is more complex than I am currently using this for
<Zarutian_HTC>
but using this for Forth words? well that might be tricky
xek_ has quit [Ping timeout: 256 seconds]
<neuro_sys>
veltas: I looked at your code, it's a very good example of the classic style I'd like to learn more.