A C-based alternative for compiling ZIL? I don't believe there's one that works. The two options for compiling ZIL code are to run ZILF on a modern system or to run ZILCH on a PDP-10 emulator.
The good news is you don't need to install any C# development tools if you use the prepackaged binaries, since they're standalone executables.
Right - that's because ZIL was more or less a _superset_ of MDL.
ZILCH (Infocom's compiler) provided all the functions of MDL, _plus_ a bunch of new ones that manipulated data structures which were then used to generate assembly code for the Z-machine.
One of those new functions, ROUTINE, accepted code written in a domain-specific language resembling a stripped-down MDL, which was then translated into Z-machine instructions. But that domain-specific language isn't synonymous with ZIL: other functions that were inarguably part of ZIL, like OBJECT and SYNTAX, are not part of that domain-specific language.
IMO, the only reasonable definition of ZIL is "the language accepted by a ZIL compiler", which (depending on whether you look at ZILCH or ZILF) is either a superset of MDL or an overlapping set.
Author of ZILF here. I wouldn't say that ZIL "does not have support for custom macros", because ZIL never existed in a form independent of MDL. There's no such thing as "MDL macros that were not available in ZIL", because there was never a version of ZIL that didn't have macros.
I'd worry that the doctor might recommend dangerous and ineffective treatments, that the police officers would arrest me on false pretenses, and that the cleaner would steal my belongings and poison my groceries. So, yeah, I'd fire the cleaner, switch doctors, etc.
But... would I let myself attend an industry conference that's also being attended by someone who voted for a politician whose opinions or policies are hostile to me?
Yes. Of course.
I'd also attend a conference that's being attended by someone who thinks I'm going to hell when I die. I'd even attend a conference where one of the speakers thinks that. Because I don't have to trust conference attendees or speakers with my life or health; I don't have to interact with them at all, and if I do, it'll be in a busy public place; and if they were the kind of person to go into a blind rage when they meet someone like me in public, they probably would've done it already and gotten caught.
There's a very wide range of sleazy but not illegal behavior as well as hard to prove illegal acts which also might affect the equation.
For a conference organizer, the primary question is how to make it a positive experience for as many visitors as possible, and that's the criteria they will use when determining who gets to visit.
If allowing a particular person to visit means several others will refrain from visiting, is it then a good idea to permit that? That's a value judgement for the organizers to make.
And if you think they made the wrong decision, feel free to tell them so or even to boycott it yourself, giving them a reason to consider other potential solutions.
>If allowing a particular person to visit means several others will refrain from visiting, is it then a good idea to permit that? That's a value judgement for the organizers to make.
That's part of it, but it's also a value judgment for everyone else to make.
In many cases, the rest of us in society care enough about how those decisions are made that we've passed laws prohibiting businesses from rejecting customers for certain reasons.
For example, if your market research shows that allowing Jews into your event results in lower overall attendance, because too many of the other potential attendees are anti-Semites who refuse to go to an event that allows Jews, you still don't get to ban them. We've established that making those opportunities equally available to all religions, ethnicities, genders, races, etc. is more important than maximizing profit. Even when that discrimination isn't illegal, it's often frowned upon by the culture.
And one reason for that is that we distinguish between the business deciding you can't visit them, and you deciding you can't visit them. We expect businesses to be inclusive, even if that means more people choose to exclude themselves -- because this way, the people who are excluded at least get a choice.
>And if you think they made the wrong decision, feel free to tell them so or even to boycott it yourself, giving them a reason to consider other potential solutions.
I've got no reason to attend a Kubernetes conference anyway, but I have the same interest as any other member of society in ensuring that people get treated fairly.
We also purposefully do not extend that protection to literally everything distinct about a person. Even stuff like California's laws only protect employees from their employers when engaging in political action.
There's no universal legal protection against an entity responding to another person's general beliefs, if that entity consider those to be harmful.
We do not want to obstruct society from holding people accountable for harmful behavior.
Yes, goog-anon is doing candidates -- and the lawyers in Wilberg v. Google -- a huge favor by admitting on the record that there's explicit racial bias in their hiring process.
The men interviewed for the paper disagreed that discrimination, social barriers, stereotypes, or other forms of injustice play a role. ("I don’t feel that there is any injustice… men who want to teach, are able to. It’s not like we’re being held down.")
It also points out that a greater number of men than women choose to go into primary education during college, which is the opposite of what we'd expect if they were being driven out by professors and peers.
> If you're self-taught you have to be willing to learn things you find completely uninteresting (or boring, hard, whatever) if you want to be as well-rounded as a CS graduate.
Not necessarily, you could also just find all that CS stuff interesting.
>Quasiquotation pretty much doesn't need to exist because of the ! sequence "operator" for splicing lists into lists and forms.
Hmm... I guess I don't know everything quasiquoting is used for in Lisp, but in MDL and ZIL, segments don't really solve the problem that quasiquoting does when it comes to writing macros.
That is, I usually want to use macros to generate code according to a template:
<PRSI? ,FOO>
should become
<==? ,PRSI ,FOO>
The way to write that macro is to call FORM to build the form:
<DEFMAC PRSI? (X)
<FORM ==? ',PRSI .X>>
But if it's a complex block of code, and the blanks I want to fill in are deeply nested, the template quickly becomes unreadable, because every structure turns into a form, and every form turns into a call to FORM.
Yeah, it does not completely replace quasiquotation, but in my experience the main things quasiquotation solves are (1) not having to write quote marks in front of every symbol and (2) not having to append lists yourself. MDL handles the first by making atoms self-evaluating (though the flip side is that you have to use , and . everywhere), and the second is handled by sequences. I agree that something like quasiquotation would make FORM construction in macros nicer to look at, though it is pretty nice that sequences work everywhere and not just inside quasiquotations.
As an example, consider the following possible implementation of PROG1 in terms of LET's implicit PROGN. They both evaluate a sequence of forms in order, but the first returns the value of the first form, and PROGN the last:
I chose this example to demonstrate how sequences alleviate the pain of splicing things into the middle of things.
Backtick is not used in MDL, right? And you're somewhat free to extend the MDL used in Zilf, right? You could get the best of both worlds by adding either a PREFORM type or an REBUILD form. For example:
`< ... > or `< ... `> -> #PREFORM ( ... )
or
`struct -> <REBUILD struct>
The semantics would be that a PREFORM would be evaluated like a LIST, but then it would CHTYPE to FORM. Or, a REBUILD is an FSUBR that expects a structure, and it maps EVAL over the elements of that structure.
It doesn't run on any available MDL implementation, because it's actually for MIM, an even more obscure and undocumented extension of MDL. ZILF implements some parts of MIM, but doesn't implement READ-TABLEs at all, and the format of the table implied by that code is different from what's documented for MDL.
