<pjb>
minion: memo for trocado: (let ((string "WXYZ")) (loop for i below (1- (length string)) for a = (aref string i) for b = (aref string (1+ i)) collect (list a b))) #| --> ((#\W #\X) (#\X #\Y) (#\Y #\Z)) |#
<minion>
Remembered. I'll tell trocado when he/she/it next speaks.
_whitelogger has joined #lisp
notzmv has joined #lisp
moldybits has joined #lisp
stux|RC-only has joined #lisp
noobineer has quit [Quit: Leaving]
atgreen has quit [Remote host closed the connection]
atgreen has joined #lisp
_whitelogger has joined #lisp
dddddd has quit [Remote host closed the connection]
atgreen has quit [Ping timeout: 264 seconds]
Lycurgus has joined #lisp
techquila has quit [Remote host closed the connection]
techquila has joined #lisp
techquila has quit [Remote host closed the connection]
techquila has joined #lisp
jason_m has quit [Ping timeout: 252 seconds]
karlosz has joined #lisp
_whitelogger has joined #lisp
noobineer has joined #lisp
varjag has joined #lisp
varjag has quit [Ping timeout: 250 seconds]
noobineer has quit [Read error: Connection reset by peer]
<beach>
Good morning everyone!
stux|RC-only has quit [Ping timeout: 268 seconds]
<LdBeth>
morning
patlv has quit [Quit: patlv]
<rumbler31>
morning
<rumbler31>
I'm trying to work through adding an optional field to a format string, s.t. if say a predicate is supplied and is true, an additional field will be output
<rumbler31>
for example, (format t "case ~a: ~a ~a" count dat1 dat2) outputs case 1: a b
<rumbler31>
but say instead I want to add debug output in this line by supplying a predicate, it is not quite clear to me how to say this in one control string
<rumbler31>
(format t "case ~a ~:[~;~a~] ~a ~a" num pred-p debug-data dat1 dat2)
<rumbler31>
such that if pred-p is true then the clause will consume debug-data, and if it is not true it will refrain
<rumbler31>
er, skip it
stux|RC-only has joined #lisp
<Bike>
you want ~@[, i think.
<Bike>
no wait if it's just a predicate you want to consume it either way
<rumbler31>
exactly
<Bike>
so your problem is you want to consume debug-data even if pred-p is false, right?
<rumbler31>
yes
<rumbler31>
effectively throwing it away, is there
<Bike>
i think putting a ~* in the false branch will work
<Bike>
~* ignores the next argument
<rumbler31>
that sounds like exactly what I need
<Bike>
i've never done this, though
<Bike>
seems to work though
<Bike>
if you need to ignore more arguments you can do ~3* to ignore 3, and such
Lycurgus has quit [Quit: Exeunt]
<rumbler31>
oh wild
<rumbler31>
yes that does fit the bill
<rumbler31>
its easy to miss a construct with all those ~ in the docs
<Bike>
yea. well, it's in the control flow section with ~[.
<rumbler31>
I must be missing it
<rumbler31>
nm
<rumbler31>
i see
stux|RC-only has quit [Ping timeout: 250 seconds]
noobineer has joined #lisp
<rumbler31>
anyone doing the google codejam and is there a channel for it?
Bike has quit [Quit: Lost terminal]
_whitelogger has joined #lisp
smokeink has joined #lisp
asarch has joined #lisp
<asarch>
Thank you for the package nicknames aeth
<asarch>
Thank you very much :-)
sauvin has joined #lisp
noobineer has quit [Read error: Connection reset by peer]
noobineer has joined #lisp
noobineer has quit [Read error: Connection reset by peer]
noobineer has joined #lisp
noobineer has quit [Read error: Connection reset by peer]
<beach>
Is it possible for an implementation to have fewer types as its complex parts than RATIONAL plus all its float types?
shifty has joined #lisp
vlatkoB has joined #lisp
techquila has quit [Remote host closed the connection]
techquila has joined #lisp
techquila has quit [Remote host closed the connection]
<beach>
Maybe I should ask my question in a different way. Given an implementation with its subset of float representations, what are the possible return values of UPGRADED-COMPLEX-PART-TYPE?
techquila has joined #lisp
noobineer has quit [Read error: Connection reset by peer]
<beach>
Related question: When I ask SBCL to evaluate (UPGRADED-COMPLEX-PART-TYPE 'FLOAT), it returns FLOAT. I can't see how that answer fits the specification of UPGRADED-COMPLEX-PART-TYPE.
<beach>
Same question for (UPGRADED-COMPLEX-PART-TYPE 'RATIO) => RATIO.
rippa has joined #lisp
<stylewarning>
beach: to me it makes sense: FLOAT is the most specialized type that can hold each of that type. It can’t be a subtype of FLOAT certainly
<stylewarning>
beach: it could potentially be a broader, like REAL, if the implementation really doesn’t have a specialized complex type
<stylewarning>
It could also give you SINGLE-FLOAT, if the only float subtype is that (and all others are type equivalent), and if it actually has a special representation of SINGLE-FLOAT
<stylewarning>
It definitely seems odd for an implementation to give back FLOAT and not REAL though. Why have specialized complex numbers for the union of different float types? /me shrugs
<beach>
Yeah, those are the kinds of questions I ask myself.
<beach>
I need to contemplate your explanation.
smokeink has quit [Ping timeout: 268 seconds]
keep_learning_M has quit [Ping timeout: 258 seconds]
<stylewarning>
beach: careful reading of the pages on COMPLEX seem to imply that there can exist numbers like #C(1.0s0 1.0d0), which again is odd
<beach>
Oh?
<nirved>
FLOAT looks better to me, REAL includes RATIONAL as well; a complex with FLOAT subtype cannot have RATIONAL subtype
<nirved>
"The real part and imaginary part are either both rational or both of the same float type."
angavrilov has joined #lisp
<beach>
Right.
<nirved>
1s0 and 1d0 are different float types
<beach>
Yes, I agree.
<stylewarning>
I disagree. They are both of type FLOAT, and both meet in the type lattice of UCPT
<beach>
Hmm.
<stylewarning>
The spec says “Two disjoint types can be upgraded into the same thing.” on the page about COMPLEX (the function)
<jackdaniel>
beach: right now I'm working on that, so I may chip in with some
<jackdaniel>
right now ECL has only one complex type, which is a structure having realpart and imagpart
<jackdaniel>
so it is just (complex real)
<jackdaniel>
after adding a separate specialized type for complex float there will be (complex rational) and (complex *-float)
<beach>
OK.
<jackdaniel>
upgraded-complex-part-type is used to indicate the most specialized implementation for a particular typespec
<jackdaniel>
so for (single-float 0.0 15.23) previously it was just real, and now it will be single-float
<jackdaniel>
stylewarning: according to 2.3.2.3 it can't be that #c(1.0s0 1.0d0) doesn't upgrade to #c(1.0d0 1.0d0)
<stylewarning>
Let me look
<jackdaniel>
"either both are rationals, or both are of the *same* float subtype."
<stylewarning>
Ah, that’s pretty clear
<stylewarning>
Why that’s buried on a page about syntax is unclear
<jackdaniel>
agreed
<jackdaniel>
that said I'm glad I first did a pass through spec
<nirved>
maybe they missed "sub" in the other page
<jackdaniel>
whole contagion rule is very useful and clear btw
<jackdaniel>
it simplifies the implementation of numeric tower greatly
<beach>
OK, so a complex with two different float types for the real part and the imaginary part can not exist.
<stylewarning>
Correct according to that syntax page
<beach>
And there can be no object for which (type-of <object>) returns FLOAT, right?
asarch has quit [Quit: Leaving]
<nirved>
"two different float types" reads to me as "two different float subtypes", otherwise it makes no sense
<beach>
Right.
<jackdaniel>
beach: I can imagine implementation, where there is only one float representation
<jackdaniel>
i.e short-float and single-float are same thing on ECL
<beach>
Of course.
<beach>
But then it is single-float.
<jackdaniel>
hm, probably so; returning single-float is certainly not wrong in such occasion
<beach>
That's certainly true. But I am also guessing that it is incorrect to have the two types float and single-float be the same type in such an implementation.
<stylewarning>
Here’s a brain teaser: suppose for all float subtypes, the UCPT is that float subtype. That means every instance of FLOAT has a specialized complex representation. Since the standard forbids mixed floats, then (COMPLEX FLOAT) == the union of (COMPLEX f) for all f subtype FLOAT. If an implementation does *not* have a special representation for (COMPLEX FLOAT), is it required that (UCPT FLOAT) returns FLOAT since (COMPLEX
<stylewarning>
REAL) would be the *incorrect* representation?
shifty has quit [Ping timeout: 240 seconds]
<jackdaniel>
beach: I'm not sure if I understand correctly, but if I do, then that's not right. short-float may be the same type as single float
<jackdaniel>
"There can be fewer than four internal representations for floats" in clhs about floats
<beach>
jackdaniel: Yes, yes. Let me say it differently.
<beach>
jackdaniel: I am guessing that (subtypep 'float 'single-float) can never return true in any implementation.
<beach>
stylewarning: Again, I would have to think about that.
<jackdaniel>
stylewarning: imo that's correct, virtually it has special representation for float(s), it's just there are no instances of "abstract"float
ricekrispie2 has joined #lisp
<jackdaniel>
beach: that may be right, I don't know
<stylewarning>
I thought FLOAT can be type= to SINGLE-FLOAT
ricekrispie has quit [Ping timeout: 268 seconds]
<beach>
stylewarning: I am thinking not.
<jackdaniel>
that's the part I do not know. if it can, then (subtypep 'float 'single-float) could return T. other possibility is that concreete float representations /must/ be subtype of float, even if there is only one such representation
<jackdaniel>
and looking at the clhs page I think that beach is right
<beach>
stylewarning: I also don't understand what you mean by "since (COMPLEX REAL) would be the *incorrect* representation".
<stylewarning>
beach: (COMPLEX REAL) internally is probably like a cons cell: two pointers
<jackdaniel>
(complex rational) would be incorrect representation. but that is also true, that for *every* float specialized representatino would would be not a generic one
<jackdaniel>
so saying (complex real) will be incorrect, because for every possible instance of float it will be (complex *-float)
<jackdaniel>
so it should return (complex float) not (complex real)
<beach>
What should return (complex float)?
<jackdaniel>
(upgraded-complex-part-type 'float)
<stylewarning>
(UCPT 'FLOAT) => FLOAT
<beach>
That would definitely be wrong.
<jackdaniel>
(given all floats have a specialized representation)
<jackdaniel>
bleh, not (complex float) but float
<jackdaniel>
sorry
<beach>
stylewarning: I am asking specifically about the word "incorrect representation", or at least "representation". Where is that mentioned on any of those pages in the Common Lisp HyperSpec?
<stylewarning>
beach: UCPT says “the most specific representation” or thereabouts in CLHS
<beach>
OK.
<stylewarning>
“upgraded-complex-part-type returns the part type of the most specialized complex number representation that can hold parts of type typespec.”
smokeink has joined #lisp
<beach>
But since no object can have (type-of <object>) => float, how can a specialized complex be represented like that?
<jackdaniel>
every object which type is float has a specialized representation
<beach>
Yes "*a* specialized representation".
<jackdaniel>
by means of subtype of course, because there are no instances of float
<beach>
*sigh*
<beach>
I am not getting any wiser here. There must be something wrong with me today.
<jackdaniel>
my understanding is that upgraded-complex-part-type is a mean to provide insight about internal complex representation of the implementation. if any float will be represented by special means then returning REAL here would be useless
<beach>
Let me ask this. Is it possible in any implementation that there could be a complex type that can hold parts of type FLOAT, but not of type rational?
<jackdaniel>
subtype of comples yes, complex itself ineed can always hold parts of type real
<beach>
I am not asking about subtypes.
<beach>
I am asking about that precise type.
<jackdaniel>
I've answered your question (and more), I'm sure you knew answer to your question
<beach>
No, I am totally confused still.
<beach>
Sorry if that is not obvious.
<stylewarning>
The spec seems to demand the existence of elements with type (COMPLEX RATIONAL)
<jackdaniel>
(ucpt 'float) returning real is imho not incorrect even if all floats have specialized representation, but it is not incorrect to return 'float either (and the latter is definetely more practical)
<stylewarning>
that’s not what you were asking though I guess
<beach>
In other words, can there be a "most specialized complex number representation" that can hold parts of type float, but not parts of type rational?
<beach>
What would such a representation look like?
<stylewarning>
I claim yes. And I think I can prove it mathematically?
<beach>
How would you represent such a thing in your implementation?
<jackdaniel>
union { float _Complex, double _Complex, long double _Complex }
<jackdaniel>
C-ishy speaking
<jackdaniel>
fun fact, all lisp types in ECL are represented as a union in this spirit and cl_object is just a pointer to it
<jackdaniel>
I'll read the later discussion with interest, but I need to attend Saturday errands, see you later \o
<stylewarning>
beach: the spec says: “Every element of this type is a complex whose real part and imaginary part are each of type (upgraded-complex-part-type typespec). This type encompasses those complexes that can result by giving numbers of type typespec to complex.”
<beach>
stylewarning: As far as I can tell, the only possibility is to represent it with two full pointers to the parts. And if so, that same representation can also hold rationals.
<stylewarning>
This means that we must be able to “give” numbers of type FLOAT to the function COMPLEX. We indeed can do this
<beach>
We can not give numbers such that (type-of <that-number>) is FLOAT.
<jackdaniel>
but for every number which (typep <that-number> 'float) complex representation could be a specialized representation (i.e not two pointers)
<stylewarning>
I don’t agree with that interpretation beach: in this case I think it must satisfy TYPEP
<stylewarning>
If I “give a function an argument of type X”, it is sensible for me to call TYPEP or CHECK-TYPE to verify that claim, *not* that it is TYPE-OF equivalent
<beach>
I am giving up for the time being, since I am not improving my understanding. Thanks to all of you for trying.
<stylewarning>
beach: Can you answer this? If you say a function accepts an argument of type S, what is the correct interpretation of that? Forget about all this complex mumbo jumbo.
<nirved>
complex have parts which are of type real. Type real can be either float or rational. Both parts are either float or rational. When rational imaginary part cannot be 0. When float both parts are the same float (sub)type.
<beach>
stylewarning: Sure, that means any object such that (typep <object> 'S) returns true.
<beach>
But that doesn't help my understanding.
<stylewarning>
beach: Okay, the next step is this. From CLHS on the COMPLEX system class page, there is this very key passage:
<stylewarning>
"(complex type-specifier) refers to all complexes that can result from giving numbers of type type-specifier to the function complex, plus all other complexes of the same specialized representation."
<stylewarning>
In other words, we shall understand the *type* (COMPLEX S) as the possible return values of providing objects of type S (in the sense you just described) to the function COMPLEX.
<stylewarning>
If S = FLOAT, then providing objects of type S to #'COMPLEX means we provide any actual objects of type SHORT-FLOAT, ..., LONG-FLOAT. Since we have stipulated that each of these has a special representation, i.e. that (U-C-P-T <float subtype>) == <float subtype>, then we can deduce that the return type of #'COMPLEX is (OR (COMPLEX SHORT-FLOAT) ... (COMPLEX LONG-FLOAT)).
refpga has joined #lisp
<stylewarning>
Which means that, from the CLHS passage, the *meaning* of (COMPLEX FLOAT) should be equivalent to (OR (COMPLEX SHORT-FLOAT) ... (COMPLEX LONG-FLOAT))
dddddd has joined #lisp
ggole has joined #lisp
shka_ has joined #lisp
dale has quit [Quit: dale]
<beach>
I think you meant "we shall understand the *type* (COMPLEX S) as the TYPE OF the possible return values of providing objects of type S to the function COMPLEX.
<beach>
And yes, I agree with that.
<stylewarning>
beach: yes, that clarification is right
<beach>
And I agree with your interpretation of (COMPLEX FLOAT).
<stylewarning>
beach: There is one line in CLHS that I personally find ambiguous. As written, it states a vacuous truth. The line is this:
<stylewarning>
"Every element of this type [(COMPLEX typespec)] is a complex whose real part and imaginary part are each of type (upgraded-complex-part-type typespec)." ; [...] is my clarification
varjag has joined #lisp
<beach>
I see your point.
<beach>
But perhaps the key to my understanding is an interpretation of that phrase that is not a vacuous truth.
<beach>
I think I will go do something else for a while and come back to this later.
rumbler31 has quit [Remote host closed the connection]
<stylewarning>
(:
orivej has joined #lisp
varjag has quit [Ping timeout: 258 seconds]
lumm has joined #lisp
nowhereman has joined #lisp
random-nick has joined #lisp
Zaab1t has joined #lisp
techquila has quit [Remote host closed the connection]
techquila has joined #lisp
techquila has quit [Remote host closed the connection]
techquila has joined #lisp
Arcaelyx has quit [Ping timeout: 268 seconds]
<MichaelRaskin>
beach: reading the Trucler specification, I am not sure I understand the basic model of the world it aims to provide. What is the proper way to ask: here, direct mail, issues?
atgreen has joined #lisp
wigust- has quit [Read error: Connection reset by peer]
<beach>
Here is fine.
<beach>
Or #sicl.
wigust has joined #lisp
wxie has joined #lisp
<MichaelRaskin>
Hm, good question whether my questions are more about generic case or about SICL case.
<beach>
It may be that the documentation does not reflect the separation that we settled upon.
<MichaelRaskin>
Might be.
<beach>
Let me check...
<beach>
Right, 4.2 does not belong there.
<MichaelRaskin>
How many sides are supposed to be there in the general case? Client code (agnostic-lizard would be that, I guess), language processor (this is the implementation, right?), is that all? I see _some_ text about expectations to reuse parts of the generic reference implementation and customise others per Lisp implementation
shka_ has quit [Quit: Konversation terminated!]
<beach>
"sides"?
<beach>
agnostic lizard is a language processor.
<beach>
The client is the implementation.
<MichaelRaskin>
OK, client being the implementation — provider of the interface — did throw me off the track a bit
<beach>
I may have abused the term "client" in some cases.
<beach>
Actually, client is more general than the implementation.
<MichaelRaskin>
In the sense that it can also be implementation-specific support code loaded as a library?
beach has quit [Disconnected by services]
beach has joined #lisp
<beach>
Sorry, computer crashed. I am back now.
<makomo>
crashed as in rebooted? that was quick
<makomo>
MichaelRaskin: what's this .xltx extension for your slides. at first i thought it was an excel file lol :)
<beach>
Crashed as in froze. Reboot is fast, because I have SSDs for the system.
<makomo>
(cdr-walkability)
<beach>
MichaelRaskin: The client is just anything you pass to those generic functions.
<MichaelRaskin>
I prefer to keep track whether the files are LaTeX or XeLaTeX when I am not actively exchanging versions/co-editing with anyone
<beach>
So the implementation typically provides methods according to its representation.
<beach>
But the language processor can subclass the client and override those methods, or extend them.
nowhereman has quit [Ping timeout: 268 seconds]
<makomo>
MichaelRaskin: oh i see
<beach>
MichaelRaskin: 4.3 should also be moved.
<MichaelRaskin>
When you say that an implementation might provide a client implementation with augmentation interface restricted to high-level part, does that mean that portable language processors should avoid using the low-level augmentation interface unless it is required?
<beach>
That's correct.
<beach>
The low-level augmentation functions may not work for most implementations.
<beach>
They are used for implementations that choose to use the reference representation of environments.
<beach>
A new implementation might do that, say SICL.
<MichaelRaskin>
Indeed
<MichaelRaskin>
Right, moving 4.2 will probably make it more obvious
<beach>
Yeah, and 4.3 too I think.
smokeink has quit [Remote host closed the connection]
<MichaelRaskin>
Probably so.
smokeink has joined #lisp
libertyprime has joined #lisp
nowhereman has joined #lisp
<MichaelRaskin>
And about environments — Trucler reference implementation says it provides lexical but not global environments; what is the difference, provided that suporting non-Trucler-based Lisp implementation lexical environments requires implementing support for the implementation-specific lexenvs, too?
shifty has joined #lisp
<beach>
Give me a second to think about that. I was away for a minute.
<beach>
There are things that local environments are never involved in...
<beach>
For example, information about classes and type definitions.
<beach>
And things like upgraded element types of arrays and complex numbers.
<beach>
So the idea is to provide a single function GLOBAL-ENVIRONMENT that returns a representation of the global environment.
<beach>
And to have a second protocol that provides those parts.
<beach>
I am currently working on such a protocol.
<beach>
It would provide functions for querying the global environment for any information that a language processor might need.
<beach>
And, yes, a typical implementation such as SBCL, would use its own lexical environment representation and provide methods on the Trucler generic functions to manipulate those.
<MichaelRaskin>
And the expected behaviour of language processor is to query a lexical environment for an entry, then look at (a/the) global environment?
<MichaelRaskin>
(In case of no-…-description condition)
<MichaelRaskin>
Also, does Trucler have a specific opinion on whether no-variable-description is a serious condition?
karlosz has quit [Quit: karlosz]
powerbit has joined #lisp
aindilis has joined #lisp
<beach>
I think the language processor would always have an ENVIRONMENT parameter for all its processing functions.
<beach>
So it just calls TRUCLER:GLOBAL-ENVIRONMENT on that object.
<beach>
I haven't really thought about the conditions.
<MichaelRaskin>
global-environment is not defined in the spec yet, right?
<beach>
I imagine the language processor would handle them and signal its own.
<beach>
That's probably true.
<beach>
It is in the reference implementation.
<MichaelRaskin>
Global environment is expected to support the environment query protocol of Trucler, right?
<beach>
Yes. Plus more.
<beach>
The implementation would supply a standard object for its global environment.
<beach>
So that it can be dispatched on.
<beach>
Even though a typical implementation does not have first-class global environments.
mindthelion has joined #lisp
techquila has quit [Remote host closed the connection]
mindthelion has quit [Read error: Connection reset by peer]
techquila has joined #lisp
techquila has quit [Remote host closed the connection]
techquila has joined #lisp
JohnMS_WORK has joined #lisp
varjag has joined #lisp
wxie has quit [Ping timeout: 240 seconds]
<MichaelRaskin>
I think it might be useful to either specify a serious condition or non-serious condition and nil return value, probably based on the current state of the reference implementation. (Just to prevent minor API misunderstanding leading to code that works on some implementations but not all of them)
<beach>
Sounds good.
makomo has quit [Quit: WeeChat 2.2]
<MichaelRaskin>
Should I open Github issues about anything from this discussion? I can also open pull request for specification, but I expect to fail to fit the style so they will get rewritten anyway.
<beach>
Issues would be helpful.
<MichaelRaskin>
One with bullet points or multiple?
<beach>
Multiple, if you have the energy. Otherwise, whatever you can stand. :)
nowhereman has quit [Ping timeout: 252 seconds]
aindilis has quit [Ping timeout: 268 seconds]
dddddd has quit [Remote host closed the connection]
SaganMan has joined #lisp
SaganMan has quit [Ping timeout: 250 seconds]
shifty has quit [Ping timeout: 264 seconds]
varjag has quit [Remote host closed the connection]
varjag has joined #lisp
igemnace has quit [Quit: WeeChat 2.4]
aindilis has joined #lisp
hugotty has left #lisp ["ERC (IRC client for Emacs 26.1)"]
varjag has quit [Ping timeout: 252 seconds]
SaganMan has joined #lisp
<MichaelRaskin>
Hm. So, global-environment is supposed to support the same functions for variable lookup. Is it supposed to support global-environment accessor? Should it return the same environment or nil?
<MichaelRaskin>
(Or alternatively should there be a predicate for checking if an environment is global? Should global environments inherit from some specified class?)
SaganMan has quit [Ping timeout: 250 seconds]
techquila has quit [Remote host closed the connection]
aindilis has quit [Remote host closed the connection]
<MichaelRaskin>
I wonder if making Trucler protocol implementable on top of other Common Lisp implementations without large internal changes requires more support for dynamic-extent environments. Apparently, the SBCL implementation as merge has not reached the environment augmentation stage yet.
aindilis has joined #lisp
libertyprime has quit [Ping timeout: 264 seconds]
hugotty has joined #lisp
ravenousmoose has joined #lisp
<beach>
Sorry, was away for lunch.
rumbler31 has joined #lisp
<beach>
I think GLOBAL-ENVIRONMENT, when applied to a global environment, should return the environment passed to it as an argument.
<MichaelRaskin>
Fair enough.
<MichaelRaskin>
(and easy to check)
<beach>
Yes, the implementation must supply methods on the Trucler query functions, specialized to the global environment class of the implementation.
<beach>
There is no need for a root class for global environments.
<beach>
I suggest you ask heisig about other implementations. I know very little about how they do things.
rumbler31 has quit [Ping timeout: 252 seconds]
<MichaelRaskin>
Well, ny question is more about the portable part of the protocol requiring less above the standard.
<MichaelRaskin>
I now have a feeling that which parts of environment are actually dynamic extent might be also version-dependent…
<beach>
I am not sure what you mean. Are you saying that you want the lexical environments to be allocated on the stack?
<MichaelRaskin>
I want the protocol to be friendly to implementations that include references to stack-allocated objects into an environment
<beach>
I don't see anything that would prevent that.
<MichaelRaskin>
Hm, maybe saying that «like environment» includes having the same extent would be enough. Hopefully
<beach>
I still don't understand. A typical implementation would just use its own lexical environments.
<MichaelRaskin>
In some cases «new» is expected to mean that destructive operations or extent limitations of the «old» do not affect the «new»
<beach>
Now I am completely lost.
<beach>
Every Trucler augmentation function returns a fresh environment.
<MichaelRaskin>
Well, if I augment an environment and obtain a «new» one, am I allowed to put it in a global variable and keep it there for a long time?
<MichaelRaskin>
(and expect operations on it to work correctly after the dynamic extent has long expired etc.)
<beach>
That is up to you. If the implementation lets you do it, sure.
Josh_2 has quit [Remote host closed the connection]
<MichaelRaskin>
Exactly — it is up to implementation, not up to me.
Josh_2 has joined #lisp
<beach>
Certainly, the reference implementation would allow it.
xkapastel has joined #lisp
<MichaelRaskin>
As I have no intention to hide, I want to use (a subset of) specification before using the reference implementation.
<beach>
Of course. If you use the reference implementation, you are basically limited to SICL, and maybe Clasp.
Ukari has quit [Remote host closed the connection]
Ukari has joined #lisp
<MichaelRaskin>
Well, I also have an option of inheriting metaenv in Agnostic-Lizard from Trucler's reference implementation of lexical environment.
hugotty has quit [Quit: ZNC 1.6.5+deb1+deb9u1 - http://znc.in]
<beach>
I guess so. But then you get into that tricky situation where the host macroexpand-1 does not recognize the Trucler reference environments.
hugotty has joined #lisp
<MichaelRaskin>
I am already in that situation now anyway!
<beach>
Ah, OK.
<beach>
I am not sure why you need to make that decision though.
<beach>
Wouldn't you just use whatever each implementation provides?
<MichaelRaskin>
Then I need to maintain implementation-specific (and quickly bitrotting) code for doing something with these environments.
<beach>
Are you saying the Trucler protocol is not enough for what you want to do with a code walker?
<beach>
That would indicate a failure of the protocol.
<MichaelRaskin>
On implementation supporting Trucler, it should be enough.
<MichaelRaskin>
For using Trucler as internal representation while running on a non-supporting implementation, I would need to extend it a bit
<beach>
Then it would appear to me that it would be best to add support for the other implementations to Trucler.
<MichaelRaskin>
And observe it code-rotting there?
<beach>
Because then it can be used by Cleavir and other language processors as well.
<beach>
So, I take it the representation of lexical environments is not stable in most implementations?
<MichaelRaskin>
Not over medium term
<beach>
But yes, it would be preferable to have the bitrot in Trucler, rather than in multiple places.
<MichaelRaskin>
Well, for that we need some kind of a credible signal that Trucler is always the least bitrotted version
<beach>
I need to go take my bread out of the oven. I'll be back.
<MichaelRaskin>
And keeping track of
atgreen has quit [Ping timeout: 240 seconds]
<MichaelRaskin>
the versions of a supported implementation even if all the versions were supported at some point might be separately annoying
Achylles has joined #lisp
ravenousmoose has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
scymtym has joined #lisp
* beach
is back.
<beach>
I think version problem is alleviated by the existence of the CLIENT parameter. Minor differences in versions could be handled by specializing to a subclass of some root class for the implementation.
<MichaelRaskin>
It allows to ship support for all the versions, but choice is going to be annoying anyway
<vms14>
This is the largest code I've made with common lisp and it just uses format xD
<vms14>
I try to create a program which renders html with json-ld for cooking recipes
<vms14>
I need to make a recursive function to write nested json objects but I have no idea how I should do it
mhd2018 has quit [Ping timeout: 246 seconds]
<Grue`>
I didn't know you could format directly into a string, what a strange feature
xkapastel has quit [Quit: Connection closed for inactivity]
<vms14>
Grue`: you can
<vms14>
but it needs to be an adjustable array with fill pointer
<vms14>
(defparameter *json* (make-array 0 :adjustable t :fill-pointer t :element-type 'character ))
<vms14>
btw I guess I solved the problem of nested json objects
<vms14>
(defun nest-json (n v &optional ( tab 6 ))
<vms14>
(format nil "{~%~vt\"~a\":\"~a\"}" tab n v))
<vms14>
then I should just put that function as the value parameter of the json function
<vms14>
(json "object" (nest-json "oh" "meh"))
<vms14>
format is a very nice function
<vms14>
and lisp a very funny language <3
<vms14>
I've made this program because I want to get used to lisp, and the best way is coding
<vms14>
it made me appreciate the format function
<vms14>
I have a group project in a webdev course and they chose make a cooking recipes web page, so it's a nice option for learn json-ld and microdata
<vms14>
and also lisp <3
xkapastel has joined #lisp
<vms14>
the function does not work
moei has joined #lisp
montezad has joined #lisp
Zaab1t has quit [Ping timeout: 264 seconds]
rumbler31 has quit [Remote host closed the connection]
varjag has quit [Quit: ERC (IRC client for Emacs 26.1)]
kenu has joined #lisp
<kenu>
is there an easy way to check if list is an plist?
<Bike>
you could check that it has an even length
<aeth>
kenu: Usually you want to do it at the same time as the iteration because it's expensive to go through the list twice.
<aeth>
kenu: What are you trying to do with the plist?
<kenu>
aeth: I just need to keep some property values
rumbler31 has joined #lisp
<aeth>
kenu: If you're parsing them, you can parse them with destructuring-bind as if it was a key lambda list, and destructuring-bind should verify that it's well-formed (key and value, with even length). e.g. (destructuring-bind (&key foo bar baz) `(:foo 42 :bar 43 :baz 44) (values foo bar baz))
<kenu>
Bike: not very reliable I would say
<Bike>
why not
<kenu>
Bike: '(1 2) is that plist? no.
<Bike>
it could be, with 1 as a key
<Bike>
not that that's usual
<Bike>
if you want to restrict it to keywords as keys you can test that with a loop
keep_learning_M has joined #lisp
<aeth>
plist is a messy concept
<aeth>
Usually I only deal with plists with keyword keys
<kenu>
I've got a nested list with plist leaf nodes
<kenu>
(defun ble (elems)
<kenu>
(if (plistp elem)
<kenu>
(do-something-with plist)
<kenu>
(mapcar #'(lambda elem
<kenu>
(ble elem)))
<kenu>
elems))
<aeth>
alexandria has a doplist
<Bike>
you might want to consider using objects or having some other kind of more obvious indicator.
<kenu>
I simply need to check if a given list is a plist and act accordingly
jruchti has quit [Quit: jruchti]
<Bike>
yeah but what we're trying to get across here is that plist-ness is not something obvious.
<Bike>
it's not really suitable as a type.
<aeth>
In addition to alexandria:doplist, you can also loop :by #'cddr but if you do that you can't use LOOP's destructuring because it won't check if it's well formed, you have to just say ":for sublist :on forms :by #'cddr" and then use destructuring bind like (destructuring-bind (key value &rest) sublist (declare (ignore rest)) ...)
<aeth>
s/&rest/&rest rest/
gxt has joined #lisp
<aeth>
Ime, plists are best suited for macros
<aeth>
You can use the macro to transform them into a more useful representation, either by generating that constructor or even by creating it in the macro and giving the object a make-load-form method so it can be loaded.
<aeth>
If you're doing destructuring-bind outside of a macro, that could be a hint that there's a structure for your data there that you could use instead of lists
nowhereman has joined #lisp
_whitelogger has joined #lisp
random-nick has quit [Read error: Connection reset by peer]
Oladon has quit [Quit: Leaving.]
rumbler31 has quit [Remote host closed the connection]
<slyrus_>
it seems there are a number of libraries that let one define SQL tables associated with CLOS classes. Are there any libraries for going the other way, that is defining CLOS classes from (existing) SQL tables?
jruchti has joined #lisp
igemnace has joined #lisp
cantstanya has quit [Ping timeout: 256 seconds]
keep_learning_M has quit [Quit: This computer has gone to sleep]
<vms14>
slyrus_: maybe not, but lisp lets you create your own with less effort than most of languages
<vms14>
if you're not so experienced sure you're even able to make something that works with lisp
cantstanya has joined #lisp
ldb has joined #lisp
<ldb>
sup
elem6 has quit [Remote host closed the connection]
akoana has joined #lisp
smokeink has quit [Remote host closed the connection]
smokeink has joined #lisp
smokeink has quit [Remote host closed the connection]
keep_learning_M has joined #lisp
pmai has joined #lisp
xkapastel has quit [Quit: Connection closed for inactivity]