beneroth changed the topic of #picolisp to: PicoLisp language | The scalpel of software development | Channel Log: https://libera.irclog.whitequark.org/picolisp | Check www.picolisp.com for more information
alexshendi has quit [Read error: Connection reset by peer]
alexshendi has joined #picolisp
pablo_escoberg has quit [Ping timeout: 246 seconds]
pablo_escoberg has joined #picolisp
<pablo_escoberg> OK, so, for when you guys get back.  Here's what I realized:  First of all, it makes sense to make this functionality require the `send` method since it's pretty much always going to be for dynamic dispatch.  Second, since it looks like I'm the only one that's going to be using it, there is no need to actually redefine `send`.  Rather, I
<pablo_escoberg> created a function called `disp` (for "dispatch") which, along with a trivial use case, is here:  http://pb1n.de/?1301b6
<pablo_escoberg> 1 last thing:  You guys are thinking "illegal methods".  I am thinking "default methods".
pablo_escoberg has quit [Quit: Client closed]
<aw-> pablo_escoberg: to be honest, even after 8 years of picolisp, i still don't use the object oriented features / classes etc
<aw-> it's not really "necessary"
<aw-> i personally consider that an "advanced" topic of PicoLisp, you can do very well without ever needing it
<aw-> and if you really absolutely have a use-case for it, and you haven't mastered lisp/picolisp yet, then perhaps you're just waving around a hammer thinking everything is a nail ;)
seninha has quit [Quit: Leaving]
<aw-> btw pablo_escoberg, method_missing in Ruby is a kludge because the language itself is not as powerful as Lisp, that's why it's needed
<aw-> your Active Record proves it, take something like: User.find_all_languagues_and_sort_by_date('R', 2000) # which doesn't exist, method_missing might handle that by splitting it and creating an SQL query like "SELECT * FROM langs WHERE name CONTAINS 'R' AND creation_date > 2019 ORDER BY creation_date ASC;" ... in PicoLisp you could have a simple (de User @ (cond ((= "Ruby" (next)) (query-1 (next))) ((= "Rust" (next)) (query-2 (next))) (
<aw-> (query-generic (args)))
<aw-> probably my example doesn't work, but this is possible
<aw-> you don't "need" to define EVERY possible function and SQL query, and you can totally have "default" handlers for use-cases that weren't previously defined, and handle them the same way you would have in Ruby's "method_missing"
<aw-> this is a super basic default "feature" of PicoLisp, no "method_missing" kludge required
<aw-> you should look into the 'T catch-all condition available in many functions such as (cond) and (case)
<aw-> and this works because you don't NEED to define functions for everything in Lisp, as you've likely read before: code is data.
<aw-> and for the record, 'method_missing' is absolutely unecessary in Ruby as well, if you use Ruby's functional programming "features": blocks, procs, lambdas.. they let very closely write code and handle data the "same" way Lisp does..
<aw-> but then, if you're using Ruby to write Lisp... hahaha
pablo_escoberg has joined #picolisp
<abu[7]> pablo_escoberg, your pastebin above calls 'try' and if NIL it handles the missing. Perhaps it got lost but I recommended 'method' instead yesterdat
<pablo_escoberg> aw- it's all unnecessary.  It's a matter of convenience and clean code. So, for example, you can definitely get by without `caddr` and friends, but they're nice to have.  They eliminate little chunks of code, and I really appreciate niceties like that in Pil (and in Ruby).  I'm just trying to add more of the same.
<abu[7]> (if (method 'foo> Obj) (@ args) (missing ...
<abu[7]> 'try' has the disadvantage that a successful call needs to always return non-NIL
<pablo_escoberg> good point.
<pablo_escoberg> I guess I should use `can` or similar
<abu[7]> I don't understand your plans, but 'can' ij expensive
<abu[7]> It searches all *classes*, nothing to do with the current *object*
<pablo_escoberg> hell, maybe I'll ditch the object thing as aw- recommends.  It really may be easier to just encapsulate things in namespaces.  Might end up with cleaner syntax, too.
<abu[7]> ok
<pablo_escoberg> Also, aw- I always preferred `Sequel` over Active Record and was trying to build something similar.  Might not end up being the right way to go.
alexshendi has quit [Quit: -a- Connection Timed Out]
alexshendi has joined #picolisp
alexshe26 has joined #picolisp
alexshendi has quit [Read error: Connection reset by peer]
<aw-> never heard of Sequel, but why don't you just use Ruby instead of trying to make PicoLisp do what Ruby does?
<aw-> i don't understand what you're looking for
<aw-> if you have a problem to solve, use the best tool that you're either already skilled with, or learn to use a new tool properly the way it's mean to be used
<aw-> not to say that PicoLisp can't be used the way you want, but you seem to look for complexity where it shouldn't exist
<pablo_escoberg> Glad you brought this up.  I was just about to write up a quick document to explain all that.  I will now do that and paste in here when done.  Shouldn't take terribly long...
<abu[7]> Cool, let's see
<pablo_escoberg> Actually taking a little longer than I thought, and will be a little longer than I'd hoped :(.  But I'll take the time to make it as short as possible.
<abu[7]> Most important point to explain: Which problem exactly does it solve?
<pablo_escoberg> Will bear that in mind.  But also feel I should explain additional stuff.
<abu[7]> great
<aw-> well usually before writing software, it's a good idea to have a basic design on paper, doesn't take long, maybe a paragraph or something to flesh out the problem and the end-goal.
<aw-> so it's a good exercise for you to write it out
<aw-> then it'll be so much easier to actually create the software you _need_
<pablo_escoberg> cool.
<aw-> and the best part with PicoLisp is it's easy to iterate on your solution
<aw-> and once you become familiar enough with the language, it'll also be easy to iterate on the problem ;)
<tankf33der> morning all
<abu[7]> Hi tankf33der!
<tankf33der> 20:41 <abu[7]> tankf33der: (symbols 'pico 'simul) is not rigxt
<tankf33der> you had opposite opinion 3 weeks ago about the same line :/
<tankf33der> pico has 99.99% of symbols in it, should be first, as i understand it
<abu[7]> You said this before
<abu[7]> I don't think I ever said this
<abu[7]> If you put simul *behind* picolisp, all local symbols are hidden. Makes no sense to use a namespace then
alexshe26 has quit [Quit: -a- Connection Timed Out]
alexshendi has joined #picolisp
<abu[7]> Can you find this discussion 3 weeks ago in the irc log?
alexshendi has quit [Read error: Connection reset by peer]
<tankf33der> 11:21 <abu[7]> The right symbols call is (symbols 'simul 'pico)
<tankf33der> you are right, i was wrong
alexshendi has joined #picolisp
pablo_escoberg has quit [Ping timeout: 246 seconds]
pablo_escoberg has joined #picolisp
<pablo_escoberg> OK, so I've obviously been communicating very poorly very with the community and I may have even ruffled some feathers.  My apologies.  So here's what I'm trying to do and why I'm trying to do it:
<pablo_escoberg> When I was arrested in 2012 (Cannabis and psychedellics; nothing violent or untoward), I was putting the finishing touches on a framework (ruby backend; JS frontend) named Marley,  Much as picolisp is the distillation of @abu's coding experience in the form of code, this was mine.  I could pretty much write a DB frontend while talking to the
<pablo_escoberg> domain expert.  No specs needed.  I'll explain the mechanics below.
<pablo_escoberg> By the time I got out of prison, Ruby had moved from 1.8 to 3.1 (I think) and was a completely different beast.  Looks like you need docker to run the thing now.  And in fact, everything is containerized, systemd-ized and way over compli
<pablo_escoberg> cated.  The only tools left in my toolkit that I still love are vim and sqlite.
<pablo_escoberg> Thankfully, I had the resources to live comfortably without working, so I just sat around and yelled at clouds for a while.  But it was boring, and there are always lots of cool projects to do, and I love coding.
<pablo_escoberg> But my primary platform was no longer enticing.  I looked around and played with a variety of platforms and I'm not really sure how I found Pil (probably HN), but there it was (is).
<pablo_escoberg> No dockerized bullshit.  Everything in one small, fast package.  Nothing opaqe.  Really elegant.  Great integrations.  Some downside, but they seem manageable.
<pablo_escoberg> But I'd gotten used to doing things a certain way, and it's clearly not the way this community does things.  It goes like this:
<pablo_escoberg> - All URL's human readable and with a format like /Entity/Key/SubEntity/Key (so Order/14333/Item/6) or Entity/search?name=bob .
<pablo_escoberg> - Each request authenticated and autorized.  Yes it's computationally expensive, but compute isn't that expensive.  And this completely eliminates all need for state, which is huge.
<pablo_escoberg> - Each request has a single purpose:  Read/Create/Update/Delete and this is reflected in the http verb.  No it's not a perfect mapping, but it can easily be forced into one if one isn't pedantic about it.
<pablo_escoberg> - Urls correspond to Entity classes, which almost always correspond to database tables (can also be views or completely virtual entities).
<pablo_escoberg> - All Entity classes within a given namespace are exposed to URL's by default, subject to authorization (see above).
<pablo_escoberg> - Everything had sane, overrideable defaults.
<pablo_escoberg> Basically, coding an application came down to DDL plus some edge case handling.  The frontend was generic JS using a microframework called Prevel which I contributed to.  It acceepted JSON with some display hints and displayed it, along with updateable in place forms, autocomplete fields, etc.
<pablo_escoberg> So that's what I'm trying to recreate here:  A framework that boils coding down to good DDL plus some edge case handling and display hints.
<pablo_escoberg> I hope I can do this in picolisp, but if it's really not the Pil way, maybe I'm better off checking out Racket again.
<aw-> pablo_escoberg: i mentioned before, ruby was my stepping stone towards picolisp
<aw-> so yeah a lot of crap happened in the ruby world between 1.9 and 3.x.. i stopped playing with it around 2.2 after yet another forced update with major breaking changes
<pablo_escoberg> I missed all that, along with the systemd wars, and a great many other disasters that made prison riots look like fun :-/.
<aw-> good for you hahaha
<aw-> i ignored it
<pablo_escoberg> good for you! :D
<aw-> ok so to get your project
<pablo_escoberg> but yeah, that's what I'm trying to build
<aw-> you're trying to make like a 'Rails' framework?
<pablo_escoberg> NO!
<aw-> or just the scaffolding part of Rails?
<pablo_escoberg> I loathe rails.  It's a train wreck on rails :).
<pablo_escoberg> And the scaffolding is the worst part.
<pablo_escoberg> There is (was) a great ORM name `Sequel`.  Very extensible.
<aw-> but what you describe seems like scaffolding, which is really just CRUD on top of a DB layer
<pablo_escoberg> ok, terminology.  I think of scaffolding as generated boilerplate.
<pablo_escoberg> so in that case, yes, very different scaffolding.  dramatically simpler.
<pablo_escoberg> no controllers
<aw-> rails scaffolding was for creating a quick CRUD UI on top of a DB
<pablo_escoberg> no routes.  just active record patterns exposed as URL's.
<aw-> wait
<aw-> i might be mixing up terminology too
<aw-> one sec i need to search ;)
<pablo_escoberg> you may have the terminology right.  I'm not very confident about it.
<pablo_escoberg> But as long as we're on the same page about what I'm trying to accomplish, it's not an issue.
<aw-> yeah i think i have an idea
<pablo_escoberg> great!
<aw-> you're not looking to make an MVC framework
<pablo_escoberg> Without the V and the C :D
<pablo_escoberg> the M handles the C, and the V is generic.
<pablo_escoberg> or nearly generic
<aw-> just something that can manage a DB's contents without knowing in advance what the schema resembles?
<pablo_escoberg> that;s the ORM part.  So the DDL gets to define the application to a very large extent.
<pablo_escoberg> My test applications had more DDL code than Ruby code.
<pablo_escoberg> which was the entire point.  DDL and done.
<aw-> what is DDL?
<pablo_escoberg> Data Definition Language.  The `Create Table` part of SQL.
<aw-> i see
<aw-> well.. that seems like a lot of work, i'm not sure what is the use-case for such a thing though
<pablo_escoberg> it was a lot of thought work, very little code.  And the use case is rapid application development.
<pablo_escoberg> and not just prototyping.
<pablo_escoberg> Dev looked like this:  create the tables and you have an application in which anybody could read or create anything and update or delete anything they created.
<pablo_escoberg> then you could override all of that.
<pablo_escoberg> and it had all the rails niceties: `date_created` and other autopopulated fields.
<aw-> i see
<aw-> sounds dangerous
<aw-> hahahaha
<pablo_escoberg> column/row level security.
<pablo_escoberg> but yes, everything powerful is also dangerous.
<pablo_escoberg> Pil is no exception...
<aw-> pil is just a pile of unbound rope
<pablo_escoberg> which is really dangerous
<aw-> ok so i'm thinking about your project, and it seems like this could actually be extremely simple to write
<pablo_escoberg> so my question is, am I barking up the wrong tree here?
<pablo_escoberg> It should be extremely simple, yes
<aw-> no, i mean, flexibility is the main selling point of any Lisp
<pablo_escoberg> less than 500 lines of Ruby, but I did have Rack to work with.
<aw-> but you have to throw away your knowledge of Ruby
<pablo_escoberg> yeah, I'm getting that feeling.
<aw-> i can give you one heads-up though, the PicoLisp main webserver (http.l) is unsuitable for the dynamic routes you want to support
<aw-> it's not designed to handle requests that way
<pablo_escoberg> I know.  that's why I wrote a CGI driver
<pablo_escoberg> I'll probably need to convert to FCGI at some point, but don't want to optimize prematurely ;)
<aw-> good! that's a good start
<pablo_escoberg> yeah, that was STUPID easy.
<aw-> so if you have like.. Nginx handling the routing, and then sending the request to picolisp's http.l in a format it can handle, then you're halfway there
<pablo_escoberg> I'm getting the requests in a format I can handle.
<aw-> you mentioned one thing as well: /Entity/Key/SubEntity/Key
<pablo_escoberg> yes, I really like that, along with the verbs.
<aw-> shouldn't it be /Key1/Value1/Key2/Value2 ?
<pablo_escoberg> well, the idea is you're making a request of a particular active entity, and you want to know which entity that is first.
<aw-> your approach is doing like a tree with only 1 branch at each level
<pablo_escoberg> the URL structure can be significantly more complicated
<pablo_escoberg> I just gave 2 simple examples.
<aw-> ok ok so that's what might trip you up, you should have a very strictly defined URL structure
<pablo_escoberg> for KV pairs it would be the standard html way at the end of the query string.
<pablo_escoberg> it is very strictly defined.
<aw-> almost like a schema for the URLs, that way you can reliably construct them and process them even if the data is different
<pablo_escoberg> haven't written a formal spec, but I know what it is.  The are a few schemas
<pablo_escoberg> yes, exactly.
<aw-> hmmm.. html way such as ?key=value ?
<pablo_escoberg> yes
<pablo_escoberg> so everything has an overridable default
<aw-> ok so /Entity/Key/SubEntity/Key?key1=value1&key2=value2 ?
<pablo_escoberg> by default, an entity is accessed as Entity/ID
<pablo_escoberg> but you can make it Entity/Name by default instead, for example.
<pablo_escoberg> Or, if you need to Entity?date=20230728
<aw-> now this is starting to look like the PicoLisp DB/GUI
<pablo_escoberg> not really.
<pablo_escoberg> so human readable URLs
<pablo_escoberg> no sessious/state
<pablo_escoberg> works primarily as an API, with client display as almost an afterthought.
<pablo_escoberg> At the risk of pissing EVERYBODY off, significantly simpler, if a tad less powerful.
<aw-> yeah..
<aw-> so then what's the purpose?
<pablo_escoberg> rapid application development
<aw-> just an abstraction layer that is less powerful?
<pablo_escoberg> slightly less powerful, much cleaner and simpler.
<aw-> that's the biggest problem with abstractions, as they grow in simplicity, they decrease in usefulness
<pablo_escoberg> there are several sweetspots, and which one you choose is a matter of preference.
<aw-> or as they grow in complexity, new abstractions are created on top
<aw-> then we end up with things like Docker
<aw-> *facepalm*
<pablo_escoberg> That happens, sure.  But again, there are sweet spots, and we each have to choose ours.
<aw-> ok
<aw-> i have an idea for you
<aw-> how about, instead of starting from the top: "I want a framework with pretty URLs and DB abstraction etc etc", you could start from the bottom: "I want to abstract a DB. Then I want to abstract queries. Then I want generic functions for calling them. Then I want a loadable module/library... etc"
<aw-> and build UP until you have the whole framework thing
<pablo_escoberg> that's what I've been doing.
<aw-> the difference here is to just start with one thing and build up from there, you dont need to talk about URLs until you have the rest of the stuff _done_ and working well
<aw-> it'll confuse us a lot less too :0
<pablo_escoberg> I guess you are not on Matrix, but abu[7] built the bottom layer of the C API for a Sqlite driver.
<pablo_escoberg> So I have that, and the CGI.  Now I'm building on those.
<pablo_escoberg> my first instinct was to build an object layer, but if that's not the way, I'll go with namespaces or symbols or something else.
<pablo_escoberg> But I am very much building upward.
pablo_escoberg has quit [Quit: Client closed]
pablo_escoberg has joined #picolisp
<pablo_escoberg> OK, I think I figured this out (medium confidence):  The pil object system, while powerful, is not built for this kind of thing.  The mechanism to use here is symbol properties.  There will be a main symbol whose property names correspond to table names and whose property values contain data about the table and any overrides for default
<pablo_escoberg> behaviors.  Thanks again for all the help and advice.
<pablo_escoberg> And I hope you don't all think I'm nuts :).
<abu[7]> What limitation of the pil object system do you mean?
<pablo_escoberg> well, it wasn't built for that kind of thing.  So no method_missing for example.  But I think I can do it all very cleanly without the object system.
pablo_escoberg has quit [Client Quit]
<abu[7]> As I said, call 'method' to find a missing method. What's wrong with this?
<abu[7]> I still believe the miising method concept is wrong. There may be the wrong method with the same name, or it expects different arguments etc.
pablo_escoberg has joined #picolisp
<abu[7]> I answered, see log
<abu[7]> 'send' or 'try' do nothing more internally than calling 'method' and invoking the returned function
<pablo_escoberg> yup, saw the answer.  You may be right.  method_missing may not be a great idea, but regardless, given the state of things, I think I'm better off with symbol properties .
<abu[7]> I think also that OOP is not the right way for many problems, just wanted to know what limitation you see in Pil OOP
<pablo_escoberg> ah, gotcha.  This will work out nicely.  There may be no objects involved at all.  When it comes down to it, both are just kv pairs with different syntax.
<beneroth> aw-, so many perfect quotes from you in this thread <3
<beneroth> abu[7], don't worry. You don't understands pablos goal and he misunderstands a lot in pil, that's why it doesn't make sense to you.
<beneroth> pablo_escoberg, I think I now get your goal.
<pablo_escoberg> glad to hear it!
<beneroth> you could easily do it in picolisp by just using (put) and (get) and not even the +Entity framework
<pablo_escoberg> yes, that is the current plan, as I obviously didn't make clear above :).
<beneroth> the whole point of the +Entity stuff is to do some additional database chore work, like indexing. but you could start simpler and just save whatever you want in external symbols
<pablo_escoberg> I had never planned to use +Entity.  The plan was to use a different set of objects.
<pablo_escoberg> but yeah, any kv store will do, and I can even switch to cons pairs if need be.
<beneroth> question is.. do you even want a schema? I mean "multiple records following some strict rules". it gives advantages. but you can also have every record be completely independent (that's commonly called a "document database", there are many in NoSQl-land).
<beneroth> other question
<beneroth> pablo_escoberg, do you want to build an application or an application framework?
<beneroth> doing multiple things at the same time usually fails.
<pablo_escoberg> well, I'm building up.  So application framework first, then many applications.
<pablo_escoberg> however, when building a framework, it helps to have a test application being built at the same time.
<beneroth> but a universal application framework will need a lot more than what you require for your specific application
<pablo_escoberg> not in my experience.
<pablo_escoberg> and yes, I've been working with set schema databases for over 30 years and I'm just too used to thinking of data that way switch paradigms.
<pablo_escoberg> Maybe not, maybe I will get used to the database.
<pablo_escoberg> But I still want the clean urls, the statelessness, etc.
<pablo_escoberg> Now that I think of it, urls do map better to hierarchical structures than flat tables.  But the great thing about building in layers is that I can build the REST layer for sqlite, and then build a interface to pilDB if I decide to that route.  Others might find that handy for writing stateless API's.
<aw-> i've already built a stateless REST API over sqlite in picolisp, and it's open source
<pablo_escoberg> ISTR you sending a link to a sqlite driver.
<pablo_escoberg> But I'd love to have a look at what you've written.
<aw-> so the API is here: https://github.com/on-prem/jidoteki-admin-api/tree/master/api/v1 .. the API endpoints are like: /admin/backup /admin/logs etc.. they are defined in a file 'core/allowed.l'
<aw-> it's not updated/maintained anymore, and was for a specific use-case
<aw-> but you're free to pull parts of it and use it as you wish
<pablo_escoberg> Thanks!  I'll have a look and see what I can grab.
<aw-> the license is MPL-2.0 but i can change it to MIT license if you want, it's old unused anymore so it doesn't matter to me
<pablo_escoberg> cool.  looks like you wrote a whole web server.
<pablo_escoberg> Thanks, but I'll use an external server.  No need to reinvent all the wheels :D
<aw-> i did but not in this repo, it's in a private repo
<pablo_escoberg> cool.  fun project I'm sure.
<aw-> i think when it's in production and sold to customers, it's not a project anymore ;)
<pablo_escoberg> depends.  If it's a framework you use over and over, you maintain it.
<aw-> yes true
<aw-> in any case, picolisp is awesome for buildings things really quickly
<aw-> after i built this initial API, it was so easy to add new endpoints and functionality
<aw-> without changing the "core"
<pablo_escoberg> that's why I'm here.
<pablo_escoberg> Pil is well on it's way to being my third tool, and my secret weapon.
<aw-> oh it's definitely a secret weapon when you look at how long it takes people to get "seemingly simple" programs out the door
<aw-> in languages like Rust or Java..
<pablo_escoberg> Rust happened while I was away so I know nothing about it, but yes, Java is a dumpster fire onboard a train wreck.  That's what kept me away from Clojure, which I otherwise really like.
<pablo_escoberg> and Ruby used to be a not-so-secret weapon as well.  Now, not so much...
<aw-> yes Java is also what keeps me away from Clojure
<aw-> i don't care how "good" it is, Java is a deal breaker
<pablo_escoberg> I'll be stuck with it when it's time to develop on Android, sadly.  Really not looking forward to that.
<aw-> not necessarily
<aw-> picolisp is available on android
<aw-> through PilBox.apk - install it, run pil, move-on
<beneroth> haha aw- I get you about java. Good friend of me uses clojure, loves it. It runs on JVM but there the connection to java largely ends.
<beneroth> but I don't get the FP hang up on "immutability". Yes it makes sense in some cases and especially when multihreading. But I don't think it makes sense everywhere, and I find a good programmer should be able to judge when which tactic is more appropriate.
<aw-> it's useful for writing code that requires 100% test coverage
<aw-> if you know that each function _always_ outputs the same result given the same input, then writing tests for those is a piece of cake
<aw-> i'm all for that, but i know it's not necessarily practical/possible when dealing with network data or user input
<aw-> and it can be time-consuming to write code with 100% test coverage (I do it for libraries though, because you typically want libraries to be deterministic)
<beneroth> well test coverage is nice but the correlation to correct software can be low
<beneroth> agreed with the library. a library should be encapsulated
<aw-> if the tests are wrong sure
<beneroth> people often forget that testing should also test that wrong inputs give the expected errors
<beneroth> testing the negative cases, not just the positive ones
<aw-> but that's a bad example because it's so small
<aw-> sorry i gotta run
<aw-> ttyl
<beneroth> nice
<beneroth> have a good time!
<beneroth> gotta go soon too
pablo_escoberg has quit [Ping timeout: 246 seconds]
alexshe20 has joined #picolisp
alexshendi has quit [Read error: Connection reset by peer]
seninha has joined #picolisp
skyjuice has quit [Remote host closed the connection]
tankf33der[m] has quit [Remote host closed the connection]
tankf33der[m] has joined #picolisp
skyjuice has joined #picolisp
alexshendi has joined #picolisp
alexshendi has quit [Read error: Connection reset by peer]
alexshendi has joined #picolisp
alexshendi has quit [Read error: Connection reset by peer]
alexshendi has joined #picolisp
alexshe20 has quit [Ping timeout: 260 seconds]
alexshendi has quit [Read error: Connection reset by peer]
alexshendi has joined #picolisp
pablo_escoberg has joined #picolisp
alexshe96 has joined #picolisp
alexshendi has quit [Ping timeout: 245 seconds]
alexshe96 has quit [Read error: Connection reset by peer]
alexshendi has joined #picolisp
seninha has quit [Ping timeout: 246 seconds]
pablo_escoberg has quit [Quit: Client closed]
pablo_escoberg has joined #picolisp
alexshe84 has joined #picolisp
alexshendi has quit [Read error: Connection reset by peer]
pablo_escoberg has quit [Quit: Client closed]
alexshe84 has quit [Read error: Connection reset by peer]
alexshendi has joined #picolisp
pablo_escoberg has joined #picolisp
<pablo_escoberg> Quick question about naming conventions:  I have a namespace I want to call `rest` but can't for obvious reasons.  Is it considered acceptable to call it `Rest` or should I call is e.g. `rst` instead?
<pablo_escoberg> it*
<abu[7]> Good question. A namespace is also just a global symbol, so lower-case is recommended (or *Rest, but this is rather a global variable)
<pablo_escoberg> ok, I think I'll go with `rst` in this case.  Representational State Transfer, after all.
<abu[7]> Yeah, sounds good
<abu[7]> I see no other solution
<abu[7]> 'rest' is better not redefined ;)
<pablo_escoberg> all the builtins, really.
<abu[7]> yes
<abu[7]> If one is absolutely sure some esotheric function will never be used in that app, one could do it, but it is bad style and confusing
<pablo_escoberg> yeah, but why risk it?  My worry is always that I will clobber some future function.
<abu[7]> Right, this is also a risk
<abu[7]> One more reason not to put too many nifty utils into the core system ;)
pablo_escoberg has quit [Quit: Client closed]
pablo_escoberg has joined #picolisp
<pablo_escoberg> yes.  namespace management becomes an issue.
<pablo_escoberg> But in my defense, I use `sc` about as often as `cadr` and `cddr` and less often than e.g. `caddr` and such.
<abu[7]> ok
<abu[7]> I think I don't need the 'chop' usually
<abu[7]> Then (split (foo) " ") is not worth abstracting
<abu[7]> You can usually design the input in such a way that you already have lists of chars
<pablo_escoberg> so far, I'm finding that's true about 2/3 of the time.  The rest of the time I use `sc` , which is still quite often.
<beneroth> why do you read the input as symbol/string and not as chopped list?
<beneroth> where is you input coming from? cli? reading text/json?
<abu[7]> Mostly 'line' and 'till'
<pablo_escoberg> For me, right now, it's mostly parsing web server output, so it all comes to me as strings from the environment vars and stdin.
<abu[7]> And stdin you can read with 'char', 'line', 'till' etc.
<pablo_escoberg> right, but the env vars are all strings.
<abu[7]> e.g.@lib/http.l reads all that way
<abu[7]> never long transient names
<abu[7]> ok, yes
<pablo_escoberg> makes sense.
seninha has joined #picolisp
pablo_escoberg has quit [Quit: Client closed]
alexshe51 has joined #picolisp
alexshe51 has quit [Read error: Connection reset by peer]
alexshendi has quit [Read error: Connection reset by peer]
alexshendi has joined #picolisp
skyjuice has quit [Ping timeout: 245 seconds]
tankf33der[m] has quit [Ping timeout: 245 seconds]