I'm working on modernizing Rosetta Code's infrastructure. Starting with communications. Please accept this time-limited open invite to RC's Slack.. --Michael Mol (talk) 20:59, 30 May 2020 (UTC)

User talk:GordonCharlton

From Rosetta Code

Quackery[edit]

I'm a huge concatenative language nerd and Quackery is the most unique take on one I've seen in a long time. Ancillary stacks are a real neat abstraction. They pretty much stand in for locals, globals, dynamic scoping, and well, ancillary stacks. And probably even structs with just a few more words. The metaflow operators are like nothing I've ever seen before. The most unique thing about the language in my view is how nests do themselves by default, and a lot of words look at them from ahead instead of behind. I guess that's where the Lisp influence seeps through.

I'm impressed that you released an entire book alongside the language. I read it from cover to cover and thoroughly enjoyed it. I hope you don't mind if I take a stab at some of the tasks here on Rosetta Code in Quackery from time to time! :) Feel free to point out anything silly I do on my talk page.

As an aside, I got it running on Windows no problem. --Chunes (talk) 12:15, 24 January 2021 (UTC)


Wow! That's the nicest thing anyone has said to me in a long while. If we ever meet IRL I may have to hug you. Yes, please do some tasks in Quackery. I'd love to see how someone else codes in the language.
Perhaps you could help me out - at the moment I'm replying to you by editing the page and typing the "Gordon Charlton ... ... date and time" at the end by hand. I guess there must be a better way?
PS. Thank you for creating a "tasks not implemented" for Quackery. I couldn't figure out how to do that. :-)
--GordonCharlton (talk) 16:01, 24 January 2021 (UTC)


When you edit a talk page, there should be some buttons at the upper left of the form where you type text. One of these is a button to insert your signature. You can also type --~~~~ but I can never remember it. --Chunes (talk) 00:00, 25 January 2021 (UTC)
Found it. Cheers. :-) --GordonCharlton (talk) 00:17, 25 January 2021 (UTC)
Just noticed your contributions to the Quackery corpus. :-) Nothing silly there! I like your poke and find approach to the pangrams task. That's something I really wouldn't of thought of but now I can see a similar approach applying to other things. --GordonCharlton (talk) 12:06, 26 January 2021 (UTC)
Thanks! I'm used to having Factor's set operations at my fingertips, so I had to get slightly more creative. :) On my latest submission (ISBN13 Check Digit), I experimented with a nest indentation style that is easier for me to understand. If you prefer there to be a specific style to Quackery, I can continue writing it more like you do, though.
Speaking of style, the way you write code is how I always would have preferred to write Factor, with the 3 aligned columns for code, names, and stack comments. But it wasn't the 'official' way to write Factor, so I never did that. I'm happy there is someone else out there who prefers this way.
Which reminds me, I have a question for you about stack comments. Words like witheach have a stack comment like ( a --> ) or ( [ --> ). This makes sense strictly from the stack standpoint, but as a word contract I find it doesn't give me the picture I'm looking for to understand the word, since there is no indication of the nest it expects following the word. Is this something that could be resolved with a stack comment notation, like ( [ . [] --> )? Just spitballing here; the . indicates the word position, while the [] indicates a nest following the word. No wrong answer either way; I understand wanting to keep it simple. --Chunes (talk) 12:39, 26 January 2021 (UTC)
I almost included set operations in Quackery, but I decided to let users roll their own in the end. I mostly only put in things that I needed for the REPL - which is why bigrat.qky is an add-on. I really wanted rational arithmetic, but it's more than bare-bones Quackery, so it got shifted into its own file at an early stage.
I would have done sets with bitwise operations. i.e.
  Quackery [ 0 ]          is empty.set           (   --> set    )
 
[ 26 bit 1 - ] constant is set.of.letters ( --> set )
 
[ char A - bit ] is letter->set.element ( c --> setnum )
and so on. Something along those lines.
After the "fun" of coding Quackery in a language where formatting is part of the syntax I would never seek to impose a style on any part of Quackery. Develop your own in-house rules that you are comfortable with. Mine are based solely on making the source-code look super-consistent and fit nicely on a sheet of A4 with 12pt inconsolata for the book. Now they're a habit I feel no need to get out of. Good point about words that use ]'[ though.
GordonCharlton (talk) 15:14, 26 January 2021 (UTC)
_____


I looked at ISBN13 Check Digit. I see the Factor influence in filter.

Um, does ' [ [ 1 ] [ 2 ] [ ] [ 3 ] [ 4 ] ] filter [ [] != ] do what you expect? How about:
[ [] swap ]'[ swap
witheach [
dup nested
unrot over do
iff [ dip join ]
else nip
] drop ] is filter ( [ --> [ )
--GordonCharlton (talk) 04:11, 27 January 2021 (UTC)
Good catch! I've made a note to myself to test nests carefully in words that accept general input. I was wanting to check out how easy it would be to introduce a functional feeling to the language and it turns out: quite easy! Also, if you ever feel like adding a solution to a task I've already done, please feel free. Rosetta Code encourages that sort of thing as long as the approach is sufficiently different. --Chunes (talk) 05:28, 27 January 2021 (UTC)
That's a catch I've caught so many times it's become part of my work-flow. Step 1, get it working for simple nests, Step 2, generalise it to nested nests by figuring out where to insert the nested.

Eventually I want to build a little library of the more useful combinators, but, lacking the background in functional programming (my LISP experience was mostly about consing up lists, and mapcar was rather exotic) I figured that I'd get some Quackery experience under my belt before addressing that. filter and reduce are obvious candidates, but beyond that the list of combinators that Factor offers is quite bewildering to me.

Indeed. I had noticed that Python users get the functional approach, the iterative approach, the recursive approach, dynamic programming, object oriented, Python 2, Python 3, ... (and then a scrap of Quackery just below it like an impertinent footnote at the end of a long chapter. Which amuses me. I have been tempted to add "Using Quackery" to the end of the the list of Python approaches. (import quackery; print(quackery.quackery('$ "Hello World"')) (or something like that.) LOL.) At the moment my distant mountain is Ideal Minimum Penetration (fnarr), but if I see an opportunity to add a very different approach to a task I'll certainly add it.
--GordonCharlton (talk) 11:54, 27 January 2021 (UTC)
25%, huh? That's pretty doable. Another 30 submissions or so and you'll be halfway there. At least as far as non-draft tasks. As for the combinators, yeah, Factor is probably about 50% combinators, lol. I really love that way of programming, though. I find it extremely flexible because you can tweak them as needed with partial application. But I like the library approach you've taken with Quackery. It's great to stick everything but the kitchen sink in a language, but there's something alluring about staring at a single page of words and having almost nothing feel out of reach. --Chunes (talk) 13:54, 27 January 2021 (UTC)
You wrote: "And probably even structs with just a few more words."
Were you thinking of something like this as a starting point? zen objects --GordonCharlton (talk) 19:49, 5 February 2021 (UTC)
I was thinking along the lines of objects that support multiple fields accessible by name. --Chunes (talk) 00:38, 9 February 2021 (UTC)
Yeah, at the moment they're accessible by number. Numbers could be named. I'll be developing this one slowly as I come across tasks that benefit from it. What's puzzling me at the moment is the best way to dig down into fields in nests within nests. --GordonCharlton (talk) 12:07, 9 February 2021 (UTC)
Example of addressing fields by number --GordonCharlton (talk) 16:55, 9 February 2021 (UTC)
Here you go. Compound data type#Quackery Thank you for suggesting structs. :-) --GordonCharlton (talk) 22:31, 19 February 2021 (UTC)

vmax[edit]

Hi, Gordon. I recently found myself reaching for a vmax that wasn't there when writing a solution for http://rosettacode.org/wiki/Price_fraction#Quackery. I think it might be a nice addition to a future edition of bigrat.qky. :)

This was my first time really working with bigrats and I found it pretty interesting. Having instant access to numerator and denominator lets you tweak your calculations in ways that aren't readily apparent when working with a single value. But, of course, you need to tread especially lightly on the data stack. --Chunes (talk) 20:19, 9 March 2021 (UTC)

Hi, Chunes. Yeah, vmax would be a reasonable addition. OTOH, it's easy enough to code up just when required, and there are a whole lot of other words of similar complexity that would be handy. Feature creep vs. bare essentials.
Rationals are definitely an edge case. On the one hand, as you note, instant access to the num and den is convenient. The counter-argument is that rationals are undeniably composite, and having a single nest to represent them would ease the stack pressure. I pondered it a fair bit, and to be honest it could have gone either way. The answer - for me - was that switching between two numbers and a single nest is fairly easy - either with 2 pack and unpack or, less cleanly but more efficiently with join and do. The question is, should every bignum word have to unpack its arguments at the start and pack them at the end, or is it preferable to let the programmer put in that additional code just when circumstances suggest it? ... If you would have preferred the former choice, you can put in a little preamble to your code along the lines of
  [ dip do do v+ join ] is [v+] ( [ [ --> [ )  ( .. and similar for all the other bigrat words ... ) 
whereas if I had gone the other route, wrapping [v+] with join dip join [v+] do would be an option, but wouldn't that just feel like so much busywork?
In related news, I'm currently adding a new operator - python to allow you to to exec() a string of python script from within Quackery. The code to do that is trivial, but I'm spending so time giving it a workout before I document and release it. Mostly the workout consists of porting in turtle graphics from Python, and ... of course ... I'm using rationals to specify distances and angles. So I'm also experiencing the stack pressure. But... so far ... haven't felt the need to pack rationals onto nests. Anyway, a bit more testing and then I'll add it to The Book.