freenode/lisp - IRC Chatlog
Search
15:48:41
phoe
theoretically all macroexpansions are human-readable, even in case of LOOP or TRIVIA/OPTIMA patternmatching stuff.
15:55:02
nowhere_man
White_Flame: the goal is to provide a framework for formats like file archives, images, XML documents, with compactness and decentralization
15:55:38
nowhere_man
the decentralization part needs some semantics that do beyong just binary sexpr
15:56:53
White_Flame
phoe: right, same thing. The _use_ of data formats means they're no longer effectively human friendly anymore
16:04:02
White_Flame
nowhere_man: effectively, would you say that it basically allows you to build an ASN-style packed binary format with a format declaration specifier included?
16:20:07
nowhere_man
and if you know a BULK image vocabulary and you parse a BULK stream that is such an image with a metadata vocabulary in it that you don't know, you'll still get the image
16:30:13
dlowe
it seems like the primary innovation here is the namespace with a guid. Is that reasonable?
16:30:55
dlowe
from my experience with protobufs, there are rather huge wins involved if you have a partially-parseable format that is uniformly used everywhere
16:33:09
White_Flame
nothing happens to the lexical binding, you mean. Certainly something can happen to the toplevel binding ;)
16:34:04
White_Flame
if BLAH is declared special via defvar or whatever, then the LET is a dynamic binding
16:34:30
White_Flame
but if it's only ever been setf'd and not declared special, then we would get this split situation
16:35:58
oleo
say i want to ensure a global variable retains it's original value outside of some some other program unbinding it
16:36:24
White_Flame
first google hit for me: https://groups.google.com/forum/#!topic/comp.lang.lisp/WtsTkRdqOWg
16:36:51
oleo
global-variable here -> subscope-where-it-gets-unbound-> reswitch to the surrounding env
16:37:27
White_Flame
or (let ((*global-var* *global-var*)) ...) if you want to pass through the existing value
16:37:57
White_Flame
I do a lot of this sort of thing in thread pooling. Load up a bunch of dynamic bindings like that for the current context, and let some job rip
16:38:21
oleo
i looked at the code today and was wondering why output-translations were deleted for it
16:39:58
oleo
that means while maxima gets built my output-translations are gone, that's fine so far
16:41:06
oleo
but i'm loading an asdf system which calls the maxima compilation, and after maxima compiles it looses cause the output-translations are gone
16:56:23
oleo
having saved the output-translations to *init-hooks* wouldn't work either in that case i think
16:58:27
oleo
that stuff was thought for pure maxima toplevel compilation, not some environment around it
17:11:11
jmercouris
Hey everyone, I made some really simple survey software in Lisp if anyone is interested in using it /building off of it: https://github.com/atlas-engineer/survey
17:11:41
jmercouris
it is pretty cool because you can make http requests with XML bodies to the service to dynamically create surveys
17:18:46
jmercouris
White_Flame: I'm toying with the idea of expanding this into a platform like DISQUS where it is open source, and you can run your own service, or you can use mine
17:19:24
jmercouris
White_Flame: anyways, this software was actually developed to answer the question that we talked about earlier, is there a demand for a service to group the packages/ship them cheaper
17:21:23
jmercouris
having said all of this, making it work with sexpr wouldn't be a huge leap in logic, the xml is already transformed via s-xml:parse-xml-string
17:24:08
jmercouris
anyways, not a super huge priority right now, for now I just plan to use the tool
18:00:58
aeth
White_Flame: I've brought this up in the past, but I don't like any current JSON library that I'm aware of
18:08:30
aeth
I guess JSON and YAML support are probably on the weaker side for Lisp compared to comparable languages because with a lot of the use cases people just use s-expressions as data
18:19:19
aeth
White_Flame: You can solve that by not allowing bare lists. When decoding, simply tag it with an extra cons like e.g. [] => '(json-array)
18:19:34
flip214
I'd like to have a set of functions give the caller notice of some conditions, and thought I'd just (THROW :no-filter-found nil) and CATCH that (as NIL already means "no data").
18:19:40
aeth
And require the same thing when encoding because otherwise you can't disambiguate between lists-as-sequences and lists-as-alists/plists
18:19:43
White_Flame
right, and that goes down the territory of "seem to be designed to make lisp <-> json hard" ;)
18:21:32
White_Flame
CATCH will act like a PROGN on normal return, and return the respective THROWn value otherwise
18:21:57
flip214
I'd have to (BLOCK nil (CATCH :no-filter-found (return (some-function))) (code-for-no-filter))
18:22:12
aeth
(list 1 2 3) => error; (list 'json-array 1 2 3) => [1, 2, 3]; (list 'plist :foo 42) => {"foo" : 42} or {"FOO" : 42} depending on settings and/or print-case. Default for symbols to JSON strings probably should be to :upcase into CL and :downcase into JSON strings, although obviously that won't work for arbitrary JSON, where case sensitivity might matter.
18:23:00
flip214
White_Flame: so I'd still have to bind the result and check that against EQuality of some keywords?
18:23:55
aeth
White_Flame: But lisp <-> json can't be perfect because you'd have to decide on the default for json -> lisp. I'd choose json array to Lisp vector (not list!) and json object to hash table (not plist or alist!) as the default, personally. Closest semantic match. But json objects are also equally valid as plists, alists, structs, and CLOS objects and json arrays could also be lists.
18:24:33
flip214
White_Flame: that means that I have to pass :no-filter-found at least three times - in the THROW, in the CATCH, and in a CASE clause. that doesn't feel so nice.
18:24:52
White_Flame
aeth: yeah, I know. I've dealt with a lot of that. I was just reinforcing that anything you come up with equals your assessment of "seems to be designed to make lisp <-> json hard"
18:25:37
flip214
White_Flame: currently the "main" return value is a list of records - or NIL for "no records".
18:27:30
flip214
from the inner function - yes. the outer one needs to catch that [sic ;] and replace with another data set.
18:27:43
aeth
White_Flame: I guess the solution is probably more JSON (no comments!) as metadata that could be used to override (library or program) default choices and allow for a round trip even when e.g. a struct and a CLOS object are both serialized.
18:28:02
flip214
well, currently I'm just _directly_ returning :no-filter-found - and check for that, so the keywords is only used two times.
18:28:20
White_Flame
or the inner function should just return the replacement set instead of a tag indicating the replacement set should be used
18:28:55
flip214
White_Flame: the thing is, there is not _one_ inner function - it's a set of methods, and I don't want each to have to know the default.
18:29:24
flip214
perhaps that would be better still - either return data, or (values NIL :no-filter-found) etc.
18:30:57
White_Flame
the value is only special if it's intermixed with other things. If you have a set-aside value slot for it, it need only be boolean
18:31:33
flip214
so right now I could simply pass :no-filter-found and treat that as a generalized boolean.
18:33:04
flip214
as I said, THROWing a special CONDITION seemed like an appropriate use -- I don't use them that often ;)
18:35:35
eschulte_
is there an easy way to search quicklisp for all packages which use a particular package?
18:35:37
flip214
well, it's a nonlocal transfer of the control flow - I put that in the same box as conditions.
18:38:25
eschulte_
I'd like to supply a system name and get back a list of every system in quicklisp which :depends-on that system. Just first-level (non-transitive) dependencies would be fine.
19:25:26
oleo
(defparameter *x* 0) (let ((*x* 1)) (sb-thread:join-thread (sb-thread:make-thread (lambda () (let ((*x* *x*)) *x*))))) -> 0
19:25:36
oleo
(defparameter *x* 0) (let ((*x* 1)) (sb-thread:join-thread (sb-thread:make-thread (lambda () (let ((*x* 1)) *x*))))) -> 1
19:32:23
oleo
(let ((*x* 1)) (sb-thread:join-thread (sb-thread:make-thread (lambda () (let ((*x* *x*)) (setf *x* "abc")))))) -> "abc"
19:33:29
oleo
so read the global value eventually, if you don't bind it, but write only to your own version
19:38:20
oleo
(let ((*x* 1)) (sb-thread:join-thread (sb-thread:make-thread (lambda () (setf *x* "abc")))) -> "abc"
19:42:51
mfiano
Considering threads are not part of the standard, it is undefined behavior whether they will be thread-local or not.
19:48:14
aeth
You'd not only need to pay for it, you'd first have to convince the majority of the community decision makers that it's necessary. The easiest way would probably be to hire as many as possible.
19:48:43
aeth
You could probably get away with just getting the developers of SBCL, CCL, and ECL on board.
19:50:32
aeth
oleo: How many of the people involved in the CL spec were employed by companies that used CL commercially? How many such companies exist today?
19:56:46
aeth
The main thing that would have to be worked on in a spec would probably be the type system.
19:57:41
aeth
One simple example: make SBCL's gradual-typing-via-declare the standard, expected behavior. It's already assumed in a bunch of places. No need for syntax changes. Macros can create more convenient syntax.
20:02:30
aeth
all of the people involved in CL implementations go to #anti-standards-committee where they plot about ways to prevent CL's standard from getting an update
20:03:01
White_Flame
there's CL2.1. all it takes for there to be a standard is for somebody to write it up, and others to use it
20:03:33
White_Flame
so obviously it's best when there's concensus, like the lisp industry getting together to create Common Lisp
20:04:02
aeth
White_Flame: All it takes for there to be a standard is SBCL, CCL, and ECL agreeing on something.
20:04:59
White_Flame
yep, and in many ways that's how CL formed in the first place: consolidating existing "ad hoc" features that were popular
20:05:00
jackdaniel
to agree and to have time to implement agreed *thingey* are two different things
20:05:29
jmercouris
I think what would be best would be an extension of the language in the form of macros
20:05:45
MichaelRaskin
Well, there is a reserve of implemented things where agreeing on naming is almost equal to implementing
20:06:04
jackdaniel
things which doesn't require implementation support (as in: writing macros) would be hard to justify as part of the standard
20:06:42
jackdaniel
consolidating some features is another story: i.e agree on common interface to semaphores, or threads (in fact: agree on something what portability layers try to unify)
20:07:06
White_Flame
I often liken this part to C (at least pre modern updates), where the language is small, but the industry has standardized on popular libraries
20:07:59
aeth
One easy thing to do in an upcoming spec would be to bump the minimums. Some docstrings are probably non-portable because array-total-size-limit (the maximum size of an array, including a string) has a minimum at 1024
20:08:31
aeth
Probably the way to do it would be to define minimums for 32-bit implementations and minimums for 64-bit implementations, and a way to detect which minimum the implementation is following.
20:09:16
White_Flame
one would think that a way to detect the limits would be... array-total-size-limit
20:09:40
aeth
A harder, but related, thing would be to *lower* a minimum. short-float cannot be IEEE half-precision floating point. The minimum precision is too high (13 instead of 11).
20:11:24
aeth
long float is probably still too uncommon to specify concretely. Do people want it to be quad float? 80-bit extended-precision? arbitrary precision?
20:12:29
aeth
(I'm sure some people's code would break if SBCL added a long-float because pi is long-float, not double-float!)
20:15:50
White_Flame
it would be nice to compile all the complaints people have about the current lisp spec
20:18:12
aeth
Characters (we can be more specific these days), paths (same thing), type system, more sequences (extensible sequences?), threads, maybe networking, possibly typed arrays/hash-tables/lists/etc. (lists are the only trivial one to implement yourself, but even then only your code would know your way)
20:20:07
aeth
Oh, and various functional programming things that you could technically do by writing a language in Lisp that compiles to Lisp and isn't compatible with anything anyone else uses either.
20:21:13
aeth
Lisp isn't particularly FP by today's standards even though it was by the standards of 25+ years ago.
20:25:04
jackdaniel
you miss the point, but I'm too busy with talking on #lisp-secret-room to explain myself :p time for sleep, good night
20:26:28
aeth
Considering a new standard would be a once-every-30-year event, I don't think deprecation would mean much
20:27:04
aeth
Can't remove anything, not even the currently-deprecated stuff, since people used them assuming they wouldn't be removed
20:27:50
aeth
I've only seen prog in ancient lisp code but someone probably generates it with a macro somewhere in Quicklisp instead of using tagbody for some reason.
20:32:19
aeth
White_Flame: symbol-plist is in the book. http://www.gigamonkeys.com/book/beyond-lists-other-uses-for-cons-cells.html
20:33:01
aeth
mfiano: definitely unicode because there isn't even (afaik) a major unicode portability library
20:34:41
mfiano
PLN is the big one in my opinion. As the CL ecosystem grows, and in certain cases where it makes sense to have short package names/nicknames, transitive dependencies colliding out of a user's control except only their choice of direct dependencies is a huge problem.
20:37:51
aeth
Oh, forcing specific optimizations would be nice. (declare (optimize (tco t))) and if the compiler recognizes tco it's enabled.
20:38:39
White_Flame
yeah, I've fiddled with SBCL internals to enable it while debug & safety are high, so the stack doesn't blow during testing
20:39:16
mfiano
defpackage-plus has in my opinion a very bad hack to support package-local nicknames in a way that gracefully falls back to global nicknames if an implementation doesn't support it. This is very wrong. At best, which an implementation supports them, you have non-portable code. At worst, you silently have global nicknames. It's not a "pure" solution.
20:42:08
aeth
Oh, I almost forgot. The next CL standard should sneak in a full implementation of Prolog as well. Put it in an appendix as a mandatory thing. Or maybe a long footnote.
20:42:23
mfiano
I consider that worse than just using global nicknames, because you don't know how it will behave from a user standpoint.
20:43:22
aeth
nirved: I'm trying to specifically talk about things where a layer wouldn't be too useful.
20:43:46
aeth
You can implement anything in any turing complete language, but not necessarily efficiently.
20:46:57
aeth
yes, the Prolog was a joke, but actually apparently there are some things an implementation must do in order to coexist with Prolog. iirc dmiles was talking about that a while ago
20:47:33
aeth
the latter would be more of an idea to specify as an extension or something, not actually all of Prolog
20:48:29
aeth
Perhaps the future of a CL environment is as a runtime for many languages. Then there'd be lots of interesting things that could be added.
20:48:34
nirved
if necessary CL can spit out machine code as well, and with CL writing a compiler is relatively easy
20:51:09
White_Flame
nirved: that would be more in the realm of creating a new language separate from CL, not necessarily modifying/extending CL itself
20:51:35
White_Flame
as at that level, you're working with individual implementation specifics, not anything CL-specified
20:52:12
aeth
But there are already lots of constructs in CL that don't really make sense to directly use, like tagbody
20:52:43
White_Flame
and if CL wants to be a modern runtime, it really needs feedback-based recompilation in my opinion
20:53:28
aeth
You might be able to get enough meaningful feedback in a DSL to recompile those DSL functions at runtime, if that's what you mean.
20:55:41
White_Flame
right, that sort of architecture would allow making the base langauge more generic, while still finding location-specific speed decisions
20:56:24
aeth
not sure how you'd do this without first (1) making the MOP standard and then (2) also making what you're talking about standard
20:58:33
aeth
It would be nice if something like specialization-store wasn't necessary for when you wanted generics for e.g. (simple-array single-float (3))s
21:00:18
White_Flame
recompile your code to inline the type decisions that actually occurred the most
21:01:32
White_Flame
for instance, (mapc (lambda (x) ...) list) is unrolled in SBCL to a plain loop, instead of literally calling that function every iteration
21:02:00
White_Flame
but (mapc #'some-other-function list) couldn't be inlined, because that function might be redefined, or be passed in as a variable, or whatever
21:02:19
White_Flame
in theory, if the code notices that the same function is always given to that mapc, it could be recompiled to a loop with that function inlined
21:03:41
White_Flame
the functionality should be maintained throughout its optimization; only the speed should be affected
21:04:37
White_Flame
also, if the invariant that was optimized is violate (ie, you pass in a different function than what was inlined) then it either undoes that optimization or run a separate fallback "slow path" for the more generic case
21:05:38
White_Flame
you can see how it would increase the speed of math operations, and do things like flip from baked-in fixnum to bignum processing automagically
21:06:23
White_Flame
I'm not a fan of Java, and only somewhat of JavaScript, but man I respect the tech they've put in those VMs
21:38:41
comborico1611
Why is "form" also used, and not just "expression". "Expression" does predate "form", correct?
21:41:43
White_Flame
it doesn't evaluate (car foo) first as an expression, it dispatches on the form (car ???)
21:42:11
White_Flame
if foo was (1 . 2), then evaluating the experession would yield (setf 1 3) which doesn't make sense
23:17:13
edgar-rft
comborico1611, the best explanation of Lisp forms vs. s-expressions I found so far is <https://stackoverflow.com/questions/2877371/definition-of-lisp-form>
23:18:07
edgar-rft
In short, Lisp forms can also be self-evaluating atoms like numbers, strings, arrays, etc.