(Lấy cảm hứng từ nhận xét này về một câu hỏi cũ.)
Lý lịch
Một quine lỗi (còn được gọi là "Kimian quine") là một chương trình, khi được biên dịch hoặc chạy, sẽ khiến trình biên dịch / trình thông dịch / thời gian chạy in một thông báo lỗi có văn bản giống hệt với chương trình và không có gì khác. Đối với mục đích của thử thách này, chúng tôi đang xác định rộng rãi "lỗi", bao gồm cả các cảnh báo.
Bài tập
Trong thử thách này, chúng tôi đang tìm kiếm một Quine đó là cũng một Quine lỗi. Khi được thực thi, chương trình phải in mã nguồn của chính nó một cách bình thường (nghĩa là không phải là thông báo lỗi / cảnh báo); đây phải là một quine thích hợp (nghĩa là một phần của chương trình phải mã hóa một phần khác của đầu ra). Ngoài ra, việc biên dịch và thực thi chương trình cũng phải khiến mã nguồn của chương trình - và không có gì khác - được in dưới dạng thông báo lỗi hoặc cảnh báo khi triển khai. (Lưu ý rằng điều này có nghĩa là bạn sẽ không thể sử dụng các lỗi thời gian biên dịch, trong các ngôn ngữ mà các chương trình đó ngăn chương trình thực thi bình thường.) Vì vậy, nói cách khác, mã nguồn của chương trình sẽ được in hai lần, mỗi lần qua mỗi phương thức.
Làm rõ
- Trong hầu hết các trường hợp, rõ ràng đây không phải là thông báo lỗi / cảnh báo; chúng tôi không phân biệt giữa hai ở đây. Trong các trường hợp không rõ ràng, hãy xác định một thông báo lỗi / cảnh báo là bất kỳ văn bản nào được tạo ra bởi việc triển khai: 1. do hậu quả của việc gì đó ngoài việc thực hiện lệnh (hoặc bất cứ điều gì tương đương gần nhất với ngôn ngữ); hoặc 2. đó không phải là một phần của đầu vào cho lệnh đã tạo ra nó làm đầu ra.
- Phần lỗi / cảnh báo của quine không cần phải là một quine thích hợp (mặc dù trong hầu hết các trường hợp, đó sẽ là tình cờ, vì hầu hết các thông báo lỗi và cảnh báo đều chứa một lượng đáng kể văn bản cố định).
- Chương trình có thể chấp nhận để đưa ra nhiều lỗi / cảnh báo, tạo thành nguồn của chương trình khi được nối với nhau. Không thể chấp nhận các lỗi / cảnh báo đầu ra không xuất hiện trong nguồn.
- Không giống như trong nhiều thử thách, các công tắc được cung cấp cho trình biên dịch và tên tệp chương trình, có khả năng có liên quan cao trong thử thách này. Cho rằng thách thức có thể không thể xảy ra nếu không, tôi sẵn sàng linh hoạt ở đây, mặc dù nếu bạn thực hiện việc triển khai theo cách khác thường, hãy nhớ rằng các quy tắc PPCG tính phí phạt byte khi làm như vậy (bằng số lượng ký tự bổ sung mà bạn cần thêm vào dòng lệnh theo cách "bình thường" ngắn nhất để chạy chương trình), và do đó bạn sẽ cần chỉ định kích thước của hình phạt trong bài đăng của mình. (Ví dụ: nếu trình thông dịch bạn đang sử dụng đọc chương trình từ một tệp và không có hạn chế cụ thể nào đối với tên tệp, thì cách thông thường ngắn nhất để chạy chương trình sẽ là từ một tệp có tên tệp 1 ký tự;
- Phiên bản trình biên dịch / trình thông dịch bạn sử dụng cũng có thể có liên quan, vì vậy là một phần trong bài gửi của bạn, vui lòng nêu một trình biên dịch hoặc trình thông dịch cụ thể mà chương trình của bạn hoạt động và phiên bản nào là bắt buộc. (Ví dụ: một bài nộp C có thể ghi "C (gcc 6.2.0)" trong tiêu đề.)
- Lưu ý rằng nhiệm vụ này có thể không thực hiện được trong tất cả các ngôn ngữ. Trong các ngôn ngữ, ngôn ngữ dễ nhất có thể là tìm lỗi hoặc thông báo cảnh báo để có thể tùy chỉnh một số tập hợp con của văn bản (thông qua thay đổi tên của nội dung được trích dẫn trong tin nhắn; tên tệp là một lựa chọn phổ biến ở đây, nhưng không phải là người duy nhất). Tôi sẽ đặc biệt ấn tượng (và ngạc nhiên) nếu ai đó tìm ra cách để làm điều này chỉ bằng các thông báo lỗi và cảnh báo có văn bản được sửa.
Điều kiện chiến thắng
Đây là một thử thách golf-code , vì vậy một mục được coi là tốt hơn nếu nó có số byte nhỏ hơn. Như vậy, một khi bạn đã làm cho chương trình của mình hoạt động hoàn toàn, bạn muốn tối ưu hóa nó để giảm số lượng byte càng nhiều càng tốt. (Tuy nhiên, đừng nản lòng nếu đã có một mục ngắn hơn, đặc biệt là nếu nó bằng một ngôn ngữ khác; điều chúng tôi thực sự tìm kiếm ở đây là rút ngắn một thuật toán hoặc ý tưởng cụ thể đằng sau một chương trình càng nhiều càng tốt, nhưng nhìn thấy nhiều các giải pháp trong các ngôn ngữ khác nhau hoặc dựa trên các nguyên tắc khác nhau luôn luôn có giá trị.)