Re: [racket-users] [standard-fish] Update: small house facade, with attribute handling code
Thank you Hendrik. All entries are in. Give me a few days to sort through them. Stephen On Sat, 31 Aug 2019 at 17:23, Hendrik Boom wrote: > Today's version, together with a new README.md file describing my > longer-term intentions, rather than what the program dies right now. > > The code resides on a monotone repository on my server, which I hope to > figure out how to make publically accessible. > > I haven't written a formal copyrght notice; but I am hereby delaring > it's free software, and will probably be released under the GPL or MIT > licence. Advice welcome. > > Though I suspect no one much will develop anything using it, but maybe > use it as an insperation for something completely different. > > -- hendrik > > On Sat, Aug 24, 2019 at 08:27:34AM -0400, Hendrik Boom wrote: > > door.rkt draws a picture of a small house, with a door and windows. > > Different picture each time you run it. > > > > The bulk of the code is there to handle attributes (like colours and > > sizes) in an association list, so that you can establish defaults and > > the like. > > > > One thing I know is that the attribute-handling code isn't right yet, > > and follows different conventions in different parts of it. > > > > Sometimes I have multipls versions of a function that are identical > > except for using different argument conventions. > > > > It's still very much in a state of flux. > > > > Suggestions very welcome. > > > > -- hendrik > > > > -- > > You received this message because you are subscribed to the Google > Groups "Racket Users" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to racket-users+unsubscr...@googlegroups.com. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/racket-users/20190824122733.ov2gfaerxsgl5ajz%40topoi.pooq.com > . > > > #lang racket > > (require pict) > > (require racket/gui/base) > > (require racket/random) > > > > (define (show tag thing) (print (cons tag thing)) thing) > > > > ; (list 'random (random 1 10) (random 1 2) (random 1 234)) > > ; (list 'chosen (random-ref '(a b c d e f))) > > ; (list 'nope) > > ; (show 'showtest 'showdatum) > > > > > > ; Attribute management > > > > > > ; ali is an environment. It should contain all the parameters that are > neede to make a typical whatever (at the moment, the whatever is a door.) > > ; At the moment, also, it allows attributes to be defined as functions; > at lookup time the entire association list is passed to the function so > that its value can depend on other (not necessarily previous) parameters. > > > > ; This mechanism was originally introduced for flexibility, but is being > used mainly to implement the freeze operation. > > > > (define (looker name ali succeed fail) > > (letrec ( > > (lookup2 (lambda (name aa succeed fail) > > (if (eq? aa '()) > > (fail) > > (if (eq? name (caar aa)) > > (let ((value (cdar aa))) > > (if (procedure? value) > > (succeed (value ali)) > > (succeed value) > > ) > > ) > > (lookup2 name (cdr aa) succeed fail) > > ) > > ) > > ))) > > (lookup2 name ali succeed fail) > > ) > > ) > > > > (define (lookup name ali fail) > > (looker name ali (lambda (result) result) fail) > > ) > > (define (old lookup name ali fail) > > (letrec ( > > (lookup2 (lambda (name aa fail) > > (if (eq? aa '()) > > (fail) > > (if (eq? name (caar aa)) > > (let ((value (cdar aa))) > > (if (procedure? value) > > (value ali) > > value > > ) > > ) > > (lookup2 name (cdr aa) fail) > > ) > > ) > > ))) > > (lookup2 name ali fail) > > ) > > ) > > > > (define (binda name value a) (cons (cons name value) a)) > > > > (define (bind name value object) > > (lambda (a) > > (object (binda name value a)) > > ) > > ) > > > > ; Freezing is a mechanism for choosing parameters to be passed down to > more local objects, so, for example, we can set a style for all he windows > in a house, but allow each house to have its own style for windoess. This > is accomplished by having the window-style be a function instead of a > value. The freeze calls the function and rebids the name to the result of > that function. The resulting associon list is passed down to lower objects. > > > > (define (freezea name a) > > (let ((value (lookup name a (lambda () '() > > (if (eq? value '()) a (binda name value a > > > > ; Got the wrong definition for lookup. Need a way after the lookup to > base decision on its success. Returning '() in't enough. I wonder what > the right definition is. > > > > (define (freeze name f a) > > ( let (( value (lookup name a (lambda () '())) )) > > (if (eq? value '()) > > f > > (lambda (a) (f (binda
Re: [racket-users] Re: third-party package tips and developer concerns (Was: New version of file-watchers)
Simon Schlee wrote on 9/1/19 3:28 PM: Try not to make identifiers be simple generic terms, like `watch` I strongly disagree with this statement. I think what you say is valid, and I agree in some situations. However, we're talking about reusable third-party packages, which are used pretty much the same as much of the "standard library" of Racket. When I look at the Racket Reference, the standard library tends to use descriptive names, like `file-or-directory-permissions` rather than `permissions`. A third-party package analog might be `watch-file-or-directory` (or whatever the rough purpose is) rather than `watch`. The way racket does imports is one of the things I highly value because you can use modules to aggregate identifiers from different modules/packages, resolve name conflicts by renaming / or not exporting the 2 identifiers that clash. This creates a lot of freedom to create specific sets of functionality exported by one simple module. This way I can create my custom set of things which are most needed in the particular codebase. Instead of having to write 40 lines of requires like you have to in other languages. True, that kind of module coupling often happens, and a module to aggregate a class of exports used by a codebase can be very convenient. That aggregating module might also, as you said, be an opportunity to fix the problems created by having all those modules export terse generic names rather than more descriptive ones. BTW, one drawback to the exports-aggregating module for a codebase comes when any of the aggregated modules changes (or the exports change, depending on how simple the compiler's sense of dependencies and changes). In a large system, for an aggregating module used widely, this can cause needing to recompile much of the codebase (which can be costly, in the size of system in which I think one would consider making an aggregating module like that). Imagine the perhaps not-unusual situation of changing a module actually only used by 10% or 1% of the modules that import the aggregating module. Coincidentally, the largest Racket system I worked on had a couple such aggregating modules, which initially made sense, until they were covering way too much stuff that got changed way too frequently, and it made the code base way more cumbersome to work with than just having the appropriate `require`s would be. (Auto-updating the `require`s would've been nice, though.) One of them actually made a lot of sense initially -- it was a logical whole that was unlikely to change -- until that thing got more things added to it, and until we needed to actively work on that thing while testing it integrated with the system (unit tests aren't always sufficient, or aren't always the most expedient). Finding things in the documentation is a whole other technical issue. I agree that could be improved. One bit of obvious low-hanging fruit (with IDE integration) is having the context of your current #lang and requires as factors in search hit rankings. (I'm not criticizing the current documentation search; it works surprisingly well for offline search, and with not that much resources, and was very clever in how it was implemented. I think it might've been by Eli Barzilay.) In the interim, a boost comes from descriptive names (which also happens to be idiomatic Racket, and idiomatic Racket). That boost might be worse-is-better, but it works. https://en.wikipedia.org/wiki/Worse_is_better Also, I don't think Web searches, such as of forum posts/messages, articles, code repos, etc., are sensitive to ad hoc import renaming. So you might get better global search hits for "racket file-or-directory-permissions" than "racket file permissions". * Racket2 aside, since you might be looking for terseness in some regard... One of the higher-level (but not top-level) requirements for Racket2 might concern terseness. Not just in naming, but in other things as well (e.g., does a mutating or definition form also produce a value, so that it can be embedded in, say, the condition of a loop; and perhaps somehow easing the burden of expressing big imports sets). Base Scheme is one of the less-terse of languages I know, and that took a little getting used to, though eventually I decided it resulted in a good balance of overall readability (and I could layer over the base when that helped). But maybe Racket2 decides to go more terse in the base, which might be reasonable. In any case, that's a bit of language design space choices, which, in the context of Racket, I think should be traced back to top-level requirements (e.g., why is the language being made at all, for whom, for what purposes, and why that), and influence much of the other requirements below it. (I'm saying "requirements" lately because it's a software engineering framework that should help us be clear about things we haven't yet been, though I initiall
Re: [racket-users] Re: third-party package tips and developer concerns (Was: New version of file-watchers)
> > Try not to make identifiers be simple generic terms, like `watch` > I strongly disagree with this statement. Rackets require possibilities are highly flexible so if you want more specific names use prefix-in and prefix the module name or whatever you like. The way racket does imports is one of the things I highly value because you can use modules to aggregate identifiers from different modules/packages, resolve name conflicts by renaming / or not exporting the 2 identifiers that clash. This creates a lot of freedom to create specific sets of functionality exported by one simple module. This way I can create my custom set of things which are most needed in the particular codebase. Instead of having to write 40 lines of requires like you have to in other languages. Adding prefixes to imports is easy, having to create a prefix-remove that can be used in require to cut away prematurely added prefixes would annoy me. Finding things in the documentation is a whole other technical issue. If you find the documentation search features lacking for your search needs, we should figure out how the search could be improved, instead of making the code unnecessary verbose. You already could use "watch M:" to only find identifiers exported by modules that use that module path. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/ebdb13a3-13ab-465f-a115-9681c76b1dfd%40googlegroups.com.
