Is it possible to replace keywords such as "writeLn" with "writeLine" or "say" or whatever?
How about operators such as ":=" being replaced with "becomes" or "isNow"?
I'm looking to create a domain specific language within standard FreePascal code (rather than modifying the FreePascal compiler).
I'm not 100% certain of the terminology, so I don't know what to search for in the documentation.
Is it possible to replace keywords such as "writeLn" with "writeLine" or "say" or whatever?
How about operators such as ":=" being replaced with "becomes" or "isNow"?
WriteLn is not a keyword, it's an intrinsic, a compiler provided function. That means, no, you can't replace it with something else without modifying the compiler (*).Yes that is perfectly possible to some extend and just like Sarah wrote it does have its limitations. Just for fun:
Would creating a procedure or function called "writeLine" that contained "writeLn" work?
Don't follow that approach. Define the DSL syntax and behaviour you want, then learn how to parse and compile/interpret it.
I don't know of any Pascal compilers that can target multiple retro machines,
... one of whom put together a new compiler which targets retro platforms – and it goes by the name Turbo Rascal.Source: https://hackaday.com/2021/11/30/turbo-rascal-is-the-retro-pascal-compiler-we-always-wanted/ (https://hackaday.com/2021/11/30/turbo-rascal-is-the-retro-pascal-compiler-we-always-wanted/)
The list of supported platforms is extensive, with Turbo Rascal able to compile highly-optimized binaries for the C64, Amiga 500, BBC Micro, IBM PC, Atari ST, Game Boy, Amstrad, NES, ZX Spectrum, and more.
(Turbo Rascal SE, TRSE) is a complete suite (IDE, compiler, programming language, image sprite level resource editor) intended for developing games/demos for 8 / 16-bit line of computers, with a focus on the MOS 6502, the Motorola 68000, the (GB)Z80 and the X86. TRSE currently supports application development for the C64, C128, VIC-20, PLUS4, NES, Gameboy, PET, ZX Spectrum, TIKI 100, Amstrad CPC 464, Atari 2600, 8086AT, Amiga 500, Atari 800, BBC Micro, Mega65, MSX, Apple II and the Atari ST 520.Source: https://retrogamecoders.com/introduction-to-trse-programming/
A slightly easier option would be to modify an existing language and compiler. That would also require modifying/creating a transpiler targetting C though.
Unless I'm missing something, there are only two retro machines supported: ZX Spectrum and MSX.
z88dk (https://z88dk.org/site/) can compile C code for over a hundred Z80 machines (https://github.com/z88dk/z88dk/wiki/Platform).
I'm not personally interested in compiling for all those platforms, but the ones I am interested in are in that list.
How about TurboRascal?I bookmarked that some time ago, but it isn't yet complete enough for my needs.
Then FPC wouldn't be a help for you anyway, cause FPC does not transpile to C. And changing what language FPC supports wouldn't change what targets it supports.None of the third party Pascal to C translators will work with FreePascal?
You could just as well port FPC for those platforms. After all I've done the same for MSX...Do you mean create a cross-compiler that runs on modern machines and compiles for the retro machines, or create a native FPC compiler for each retro machine?
C might be an inefficient option, but AFAIK the only other simple option is to use whatever version of BASIC is available on each target platform. I would imagine that a C compiler aimed at small devices is going to be reasonably efficient in comparison.
I do know that I want to avoid anything with a C-style syntax, as all those curly braces would sap my will to live before I was halfway done. I'd almost rather work with assembly language.
Why, and do you mean speed-efficient or space-efficient?It has supposedly been written with small devices in mind, so should be optimised for such.
And I suggest giving some thought to Alan Kay's comment on Meta-2.I'm afraid you've lost me there.
It should be more efficient in terms of memory and speed, as BASIC was usually interpreted and memory resident on 8-bit machines.
QuoteAnd I suggest giving some thought to Alan Kay's comment on Meta-2.I'm afraid you've lost me there.
META II is the first documented version of a metacompiler, as it compiles to machine code for one of the earliest instances of a virtual machine.
The paper itself is a wonderful gem which includes a number of excellent examples, including the bootstrapping of Meta II in itself (all this was done on an 8K (six bit byte) 1401!)."—Alan Kay
I do know that I want to avoid anything with a C-style syntax, as all those curly braces would sap my will to live before I was halfway done.Use Racket https://www.racket-lang.org/ (https://www.racket-lang.org/), it avoids the C-style syntax and you don't need to worry about all those curly braces ;D
Then FPC wouldn't be a help for you anyway, cause FPC does not transpile to C. And changing what language FPC supports wouldn't change what targets it supports.None of the third party Pascal to C translators will work with FreePascal?
QuoteYou could just as well port FPC for those platforms. After all I've done the same for MSX...Do you mean create a cross-compiler that runs on modern machines and compiles for the retro machines, or create a native FPC compiler for each retro machine?
Either way, it sounds like it would be complicated.
I did notice that there's a Z80 cross-compiler already in the dev branch, but again I haven't looked into that option as I'm not sure FreePascal meets my other needs.
I haven't learned anything about assembly language, but wouldn't object to learning enough about each Z80 system to create new targets based on the existing ones.
Some of the targets I would like to support are quite obscure, but I should be able to find the necessary info.
Some of the targets I would like to support are quite obscure, but I should be able to find the necessary info.
Would PascalScript be an option if I wanted to be able to test programs without compiling?
I haven't learned anything about assembly language, but wouldn't object to learning enough about each Z80 system to create new targets based on the existing ones.
Some of the targets I would like to support are quite obscure, but I should be able to find the necessary info.
If you can't find the info you're screwed in every case. In FPC terms, the compiler generated Z80 code and you might need to adapt the RTL slightly for different targets. However I suggest you examine what early versions of Turbo Pascal did to customise themselves, even if in general they only targeted different variants of CP/M.
FPC's RTL is already well abstracted so that platform specific code can be easily inserted. It might be a bit more heavy weight than what TP did in a more direct way (after all we want to keep this maintainable), but so far it worked great. :)
Okay, a lot of assumptions are being made here, probably because I didn't think it would be helpful to go into a lot of detail about what I have researched so far.
My end goal is to create a system that runs on modern hardware that can produce text-based programs that run on modern and retro hardware.
I want to find the simplest, easiest and least time-consuming route to do that, as I want to live long enough to be able to use that system myself and make it available for others to use.
*snip*
My end goal is to create a system that runs on modern hardware that can produce text-based programs that run on modern and retro hardware. ...
The main target audience for this system would be those who own retro 8-bit home computers or use emulators for them (possibly because they no longer own such machines).
Interpreters were common for these devices and compilers were much less so. Including one with the front end of the system seems natural, especially if the process for translating and compiling the code has several stages.
BASIC would have been the most commonly used language on these retro machines, as it was inluded with most of them. Pascal and C compilers were available, but much less widely used.
HiSoft sold versions of BASIC, Pascal and C, for example.
If you owned a Z80 machine with a disk drive (rare in the UK), you could use more languages via CP/M. I'm reasonably sure that this was how Turbo Pascal was made available for 8-bit micros.
The upshot of this is, that more users would know BASIC than any other language, so the system should use something similar. Pascal would be close enough for those used to structured BASIC.
Languages with a C-style syntax would be harder to adjust to. I know it caused me issues when I tried learning it.
And for similar reasons that makes using a PC-hosted cross-compiler unrealistic, /unless/ you produced an entire product range of physical and emulated micros with some sort of "tube" arrangement to the host for program downloadI was hoping that anyone with the desire to target retro machines would either own one or find suitable emulators for themselves.
My suspicion is that it's easier to write a Pascal compiler than a BASIC oneI actually bought two books on writing an interpreter in Object Pascal and am waiting for the third to be published before diving in. The created language is a variation of BASIC.
However, you need to consider two things: (a) do you need the level of immediacy that only BASIC really gives you and (b) if you decide to use Pascal are you prepared to stick to the language handled by the early versions (short strings, no try-finally construct, no exceptions, no objects and so on).I think the desire for immediacy would be sated by any interpreter. Python is a popular mainstream example.
Oh, and I knew Hisoft and Dave Nutkins fairly well, as well as some of the people who wrote stuff for them.Are you still in contact with them? I've used the contact form on their site a couple of times asking about legally obtaining HiSoft Pascal for 8-bit machines and haven't had a response.
But Structured BASIC is much younger than the 8-bit micros you're talking about: it's a 16-bit thing (QB4?).By "structured BASIC" I meant ANSI Full BASIC or BBC BASIC that allowed for a more modular construction via procedures and provided more looping options. They were available somewhere around the late 80s. IS-BASIC on the Z80-based Enterprise 64 (released in 1985) was a variation of ANSI Full BASIC.
There is very little difference between Pascal and C: both are direct descendants of ALGOL-60. I'd suggest that the problem you had with C was the number of idioms you were forced to learn- iterating a string using a pointer etc.- that were quite simply hidden in Pascal.Having to use braces was off-putting, but dealing more directly with memory allocation was also a factor, yes.
I'd suggest focussing not on what language you want, but on the degree of immediacy: what sort of IDE, and what sort of debugger. Compared with those, writing a compiler will be trivial.Having a quick way to test code would be a high priority. Maybe that could be made available via a compile and run option on the host machine as the programs shouldn't become too large.
QuoteOh, and I knew Hisoft and Dave Nutkins fairly well, as well as some of the people who wrote stuff for them.Are you still in contact with them? I've used the contact form on their site a couple of times asking about legally obtaining HiSoft Pascal for 8-bit machines and haven't had a response.
I haven't thought about the IDE too deeply, as I was hoping to allow almost any existing tool to be used. I shall have to reconsider that if I want an integrated interpreter rather than a command line one.
The debugger I haven't considered at all, mostly because of not knowing the direction I will be taking. If I modify or reuse an existing system, it will likely already have one available.
What you are talking about is 2. And especially: video, keyboard (, mouse) and storage. Mostly, this is a list of pointers and constants, with some very basic functions. Like, where does the screenbuffer start, how many rows and columns, how do I print a char at that location. Like, an old BIOS. Compiled, it will fit a few KB of code.
What you are talking about is 2. And especially: video, keyboard (, mouse) and storage. Mostly, this is a list of pointers and constants, with some very basic functions. Like, where does the screenbuffer start, how many rows and columns, how do I print a char at that location. Like, an old BIOS. Compiled, it will fit a few KB of code.
/If/ the target has a screenbuffer. That was the difference between the MS-DOS and PC-DOS variants of early TP: the PC-DOS one had a memory mapped display (and was what matured into later versions) while the CP/M and MS-DOS ones assumed ASCII+escapes.
Then there was a small number of code generators and RTLs, and a small number of OSes.
MarkMLl
@Wysardry:Ideally, I'd like to reuse whatever is already available, to reduce the amount of time and effort it would take, plus a certain number of people would already know the original tools/language/system.
When you talk about "a compiler", you're actually talking about three separate things:
Like other companies of the era, I suspect that the original entity no longer exists (i.e. there might be a successor, but they have no interest in the original business and no longer represent the same software authors etc.).I rechecked the HiSoft About Us (https://www.hisoft.co.uk/about%20hisoft/) page and it seems David Link still works there, but Dave Nutkins is barely mentioned.
That's where you need to start. Writing a compiler is by now well-understood, but a half-decent IDE and debugger is still an art.I think I'll start testing similar software to see what works and what doesn't.
Frankly, I think that in effect you're out to reinvent Turbo Pascal or something of that era, and that you'll find it extremely difficult to fit it onto an 8-bit system without writing large parts in carefully-tuned assembler.I'm hoping to avoid creating tools that run on the 8-bit targets. I would much rather reuse what already works, by producing source code to feed into existing 8-bit compilers.
If that was my project, I would go a slightly different path. Write a p-code compiler and interpreter.I had considered this idea, but discounted it due to the lack of memory on the 8-bit systems.
Going back to your original idea of just renaming WriteLn() to MyWriteLn(), I think that compared to any other idea it would be more realistic and feasible to just create a single INC file with all your macro renaming aliases that you would just have to include into all your units...Yes, storing macros in include files is similar to what I had in mind. I also envisioned creating a library of different files containing functions that could optionally be added if needed.
If that was my project, I would go a slightly different path. Write a p-code compiler and interpreter.I had considered this idea, but discounted it due to the lack of memory on the 8-bit systems.
Interpreters and virtual machines often waste a lot of memory, as they have to contain code for every supported function even if the program it is currently running does not use them all.
... the GPLv2 license by itself is not compatible with GPLv3 ...Source: https://en.wikipedia.org/wiki/License_compatibility#Copyleft_licenses_and_GPL
I don't have any intention to merge code.
Are you aware that almost every mentioned 8-bit system has built in BASIC interpreter as a proof that your claims are wrong? Only essentials are embedded, the rest is provided through external units/ libraries.If that was my project, I would go a slightly different path. Write a p-code compiler and interpreter.I had considered this idea, but discounted it due to the lack of memory on the 8-bit systems.
Interpreters and virtual machines often waste a lot of memory, as they have to contain code for every supported function even if the program it is currently running does not use them all.
Although many of the 8-bit home computers had a Z80 processor, not all of them did, so FreePascal alone (with its current targets) would not be enough.I've already said what would be enough:
You could start immediately writing apps for already supported FPC targets, and later implement missing targets for FPC.If that step is too much for you, then you should not waste time on this direction...
In that case what's the point? You seem to be aiming at a cross-compiled solution with no common download mechanism.The point would be to provide multiple translation and cross compilation options, depending on what target platforms the end user is targetting. There is no existing direct route for all platforms.
You started the thread asking about a DSL, but what you're now talking about isn't. You're now talking about multiple layers of code translation, but don't appreciate that with every hop you will introduce inefficiency and miss optimisation possibilities.The tools I suggested were for a proof of concept, so that I could learn what would work and what wouldn't.
start off with FPC or e.g. Turbo-Rascal (don't expect to be able to use both) and after identifying what desirable targets they don't support learn enough to help the project team add the desired functionality.It's entirely possible that I might do that in the future, especially if my tests go badly.
In any event, you've got a big job on your hands and the first thing you have to do is have a robust description of what /exactly/ you're trying to do: for your own benefit as much as anybody else.What I'm trying to do is create (or reuse) tools to allow text-based programs to be written in a domain specific language and/or library on modern platforms and then compile or cross compile them for as many platforms as practical. Testing should be possible on the modern platforms before cross compilation is attempted to simplify the workflow.
Are you aware that almost every mentioned 8-bit system has built in BASIC interpreter as a proof that your claims are wrong? Only essentials are embedded, the rest is provided through external units/ libraries.Are you aware that many of the 64Kb machine had less than 40Kb available to write programs in? Much of the unavailable space was used by the BASIC interpreter (although some was taken by the BIOS of the day).
I've already said what would be enough:I've already said that I'd be willing to learn enough to add new Z80 targets as I've been told it's relatively simple due to the work already done by others.QuoteYou could start immediately writing apps for already supported FPC targets, and later implement missing targets for FPC.If that step is too much for you, then you should not waste time on this direction...
It's a little early to be thinking about how everything would be made available for download.
Are you aware that many of the 64Kb machine had less than 40Kb available to write programs in? Much of the unavailable space was used by the BASIC interpreter (although some was taken by the BIOS of the day).
It's a little early to be thinking about how everything would be made available for download.
I meant download from the development host to the target. You need to be considering that sort of thing early- very early- since accessibility of debugging symbols etc. is an important issue.
*snip*
IMHO is the trickiest part of the whole venture. All of the vintage home computers I've had (Apple ][, Oric Atmos, SinclairQL) used some sort of tape cartridges/cassettes or (luxury) floppies with a specific format. Not even a serial port (except for QL).That is one of the possible workflows, yes. Apart from the magical aspect that is.
@Wysardry
If I'm getting you right, the idea is to use BASIC as a primary language, then transpile it to Pascal, use FPC as a cross-compiler to the specific targets (mostly 8-bit vintage CPUs), eventually debug the product in some emulators, and then somehow "magically" send them to the actual items for execution. Correct me if I'm wrong on this.
The main BASIC virtue isn't the simplicity of the language, but convenience of use - its interactivity and simultaneous execution, see DTSS (https://en.wikipedia.org/wiki/Dartmouth_Time_Sharing_System). Your workflow is about to nullify those advantages.On a modern machine you do lose the immediate feedback you would get from a retro machine when entering code a line at a time, but you gain a better editing environment.
Most if not all of those micros have BASIC included into ROM. Despite it is mostly a toy implementation, it gives the ability to write short programs without the need to load additional executables from the external storage. You don't waste precious RAM, time or effort. In your workflow, again, it requires some sort of downloading and the binary will reside into RAM together with the RTL.The BASIC interpreter would only be used on modern platforms with memory and storage space to spare.
Each micro has its own ways to work with the display/keyboard, character codes are weird, sometimes with inverse/blinking bits in them. Any idea how to match, i.e. how to display the same letters for all micros? Graphics mode?I would hope the differences would be handled by the final compiler, if it includes configuration settings for multiple platforms. Graphics would not be an issue as the system is only intended to be used to create text-based programs.
Have you considered/investigated the FORTH system?I have absolutely no experience with FORTH and the only thing I know about it is it was included with the Jupiter Ace, which I have never seen a physical example of.
There are existing tools that allow suitable files to be converted into an audio format. Some retro compilers include the option as standard.
For example, the ZX Basic Compiler (https://www.boriel.com/pages/the-zx-basic-compiler.html) can create files in .bin and .tzx format for use with emulators and in .mp3 and .wav format to use with digital recorders or record to tape.
Some emulators also include an audio export option, and there are third party tools which do the same.
I doubt these options exist for every retro platform, but they do for most of the popular ones.
I have absolutely no experience with FORTH and the only thing I know about it is it was included with the Jupiter Ace, which I have never seen a physical example of.
In the eighties ZX81 had 8Kb ROM and 1Kb RAM, and it had built in BASIC editor (which takes most space and not needed by you) and interpreter. Screen handling, cassete and cartridge handling and lots of other things also took ROM space but let's be gentle and not count them. ZX Spectrum had 16Kb ROM and 16Kb RAM. I remember that in my early ATMEL AVR days I have even seen a magazine publishing full sources of pascal interpreter for a microcontroller with 1Kb RAM and 8Kb flash. That is way below your available resources so implementation possibility is not in question. Did you look at p-machine implementations at all? P6 is fresh, but first few were built in the seventies when resources were even more limited, so I do not see a problem comming from that side.Are you aware that almost every mentioned 8-bit system has built in BASIC interpreter as a proof that your claims are wrong? Only essentials are embedded, the rest is provided through external units/ libraries.Are you aware that many of the 64Kb machine had less than 40Kb available to write programs in? Much of the unavailable space was used by the BASIC interpreter (although some was taken by the BIOS of the day).
Did you look at p-machine implementations at all? P6 is fresh, but first few were built in the seventies when resources were even more limited, so I do not see a problem comming from that side.
I think it's worth noting that chips which are currently considered to be "absolutely miniscule" like the ESP8266 hence barely supportable by Pascal are, in fact, substantially larger than most 1980s home computers.
I wouldn't consider the ESP8266 even close as “miniscule”. It's simply an embedded platform just like the Pi Pico which Pascal can run very well on. More miniscule are the AVRs, especially the TinyAVRs and even there you can use Pascal ;)
Did you look at p-machine implementations at all? P6 is fresh, but first few were built in the seventies when resources were even more limited, so I do not see a problem comming from that side.
Did you look at p-machine implementations at all? P6 is fresh, but first few were built in the seventies when resources were even more limited, so I do not see a problem comming from that side.
Which P6 ?
https://github.com/samiam95124/Pascal-P6 Last commit 4-5 years ago....
http://wirth-dijkstra-langs.org/ Hasn't processed FPC compatibility contributions sent 3 (4?) years ago.
Both seem to be quite stale.
In that case get off your backside and at least read about how it worked. That sort of ignorance is out of place for somebody trying to do what you are.There are plenty of other rabbit holes for me to dive down that would be a more direct route to where I want to end up.
But I'm troubled that the use of a multi-layered cross-development platform with diminished immediacy on the target makes this a non-starter: there just isn't enough there to make it attractive to the average retro user who only cares about the computer and software he remembers from his teens. Are you /really/ serious about dedicating a big chunk of your life to doing this?This project wouldn't really be aimed at someone who wants to use a particular computer from their youth, as they can just use BASIC on a physical machine or in an emulator.
Did you look at p-machine implementations at all? P6 is fresh, but first few were built in the seventies when resources were even more limited, so I do not see a problem comming from that side.I actually bought a used book on creating text adventures in UCSD Pascal a couple of years back.
TBH, I think that OP would do far better throwing his enthusiasm behind either FPC or Turbo Rascal, or identifying some comparable project with a common frontend language and multiple backends.I will definitely be considering adding extra Z80 targets to FPC if it becomes part of the toolchain.
If I had £1 for every suggestion I've seen over the years that a single under-resourced developer of limited experience could rewrite everything from scratch in a finite time, or that "it must be easy" to integrate a few dozen tools from competing suppliers to produce a result that would have well-heeled customers beating a path to his door, I'd be much richer than I am now.I do know that it will be far from easy. I've been searching for potential solutions on and off for about two years now, trying to find compatible pieces of the puzzle.
*snip*It was about how someone approached the particular problem with its own DSL. Not for the language itself. BTW BASIC was created in a similar way.
Most likely, Forth is one of the many languages I have discounted because they either don't run on the machines I would be targetting or the syntax looks too different to BASIC or Pascal.
*snip*I can hardly imagine anyone doing it except out of nostalgic reasons.
This project wouldn't really be aimed at someone who wants to use a particular computer from their youth, as they can just use BASIC on a physical machine or in an emulator.
This would be for someone who likes or uses more than one machine and wants to produce software for all of them plus modern machines, using one set of code.And who would want to do that? Where is the point?
*snip*
There are plenty of other rabbit holes for me to dive down that would be a more direct route to where I want to end up.
Most likely...
I actually bought a used book on creating text adventures in UCSD Pascal a couple of years back.
I haven't seen any implementations for 8-bit home computers though, so I haven't explored it too thoroughly.
I will definitely be considering adding extra Z80 targets to FPC if it becomes part of the toolchain.
Turbo Rascal would be somewhat of a non-starter because AFAIK it has a small team who likely have their own workflow and wouldn't want a beginner who hates C messing with their existing code.
I do know that it will be far from easy. I've been searching for potential solutions on and off for about two years now, trying to find compatible pieces of the puzzle.
Did you look at p-machine implementations at all? P6 is fresh, but first few were built in the seventies when resources were even more limited, so I do not see a problem comming from that side.
Which P6 ?
https://github.com/samiam95124/Pascal-P6 Last commit 4-5 years ago....
http://wirth-dijkstra-langs.org/ Hasn't processed FPC compatibility contributions sent 3 (4?) years ago.
Both seem to be quite stale.
I wouldn't consider the ESP8266 even close as “miniscule”. It's simply an embedded platform just like the Pi Pico which Pascal can run very well on. More miniscule are the AVRs, especially the TinyAVRs and even there you can use Pascal ;)
I'd hardly call the Pico tiny, with 100s of Kb RAM and provision for several Mb Flash. And whenever one maxes-out an AVR one can simply move to the next one along the product range.
Turbo Rascal would be somewhat of a non-starter because AFAIK it has a small team who likely have their own workflow and wouldn't want a beginner who hates C messing with their existing code.
Turbo Rascal would be somewhat of a non-starter because AFAIK it has a small team who likely have their own workflow and wouldn't want a beginner who hates C messing with their existing code.
You are aware that FPC also has a relatively small circle of really active core developers? Also with our own workflow... However we are definitely open for merge requests as long as they adhere to a few things (e.g. not changing coding style or providing features that we don't consider in the spirit of Pascal).
Turbo Rascal would be somewhat of a non-starter because AFAIK it has a small team who likely have their own workflow and wouldn't want a beginner who hates C messing with their existing code.
You are aware that FPC also has a relatively small circle of really active core developers? Also with our own workflow... However we are definitely open for merge requests as long as they adhere to a few things (e.g. not changing coding style or providing features that we don't consider in the spirit of Pascal).
I must say that looking superficially at the example screenshots e.g. https://lemonspawn.com/wp-content/uploads/2020/08/trse_background.png I'm a little troubled at the extent to which the Turbo Rascal developers have departed from the standard Pascal syntax. For example, they've reverted to Wirth's original /* */ for comments and they're declaring arrays like.
It might well be that their requirements were very similar to OP's and that they settled on something "Pascal-like" because it's usable rather than out of affection for the language and its traditions, but there's a risk that at some point in the future somebody will start arguing that FPC ought to have a TurboRascal mode.
There is already software available that allows people to create code on a modern machine that will run on modern machines and multiple retro platforms, so there must be at least some demand for it.I see. My suggestion is that post relates to https://forum.lazarus.freepascal.org/index.php/topic,55335.msg411593.html#msg411593
CROSS LIB (https://github.com/Fabrizio-Caruso/CROSS-LIB) is an example of a game framework for vintage systems that can also be used for modern systems via GCC.
Lantern (http://textadventure.net/) is a similar system for creating text adventures.
Several programming languages with multiple targets have already been mentioned in this thread.
There'd probably be a Oxygene mode before that... ::)
The important point about Forth is not the (pretty bad) language syntax, but the execution model.At this point, I don't know what languages, tools, execution model etc. I will be using. Until I do, thorough research on any topic is likely to eat up too much time for no real benefit.
... but the important thing is /how/ it worked.Again, at this point that may or may not be relevant.
And you reckon FPC is any different? And you really think you're going to get anywhere if "I hate C" is your overriding criterion?As I would mainly be attempting this project for my own satisfaction, I won't be getting paid for it and there may only be a handful of other people that ever use it, I feel perfectly justified in rejecting any language or tool for any reason I wish.
And I've been doing the same for about 45 years. Need I say more?As it's unlikely I have 45 years left in me, telling me (and anyone else reading this) which parts were a waste of time would be useful. :)
You are aware that FPC also has a relatively small circle of really active core developers? Also with our own workflow... However we are definitely open for merge requests as long as they adhere to a few things (e.g. not changing coding style or providing features that we don't consider in the spirit of Pascal).I may be wrong, but I get the impression that adding new Z80 targets to FreePascal would be simpler and involve creating less C code than doing the same with TurboRascal.
And it is also about text adventure games, right?It was originally related to creating text adventures and that is still the main focus, yes. However, I have realised that it wouldn't take much more effort to allow other text-based programs to be created with the same system.
About CROSS LIB - it is a collection of gcc cross compilers and a multi-target library. That is how I would go, but I'm not an opposer of the C language.CROSS LIB is more complex than I need, as it supports the use of graphics.
About Lantern - it is a GUI of a game builder, it has a script language with {}, not clear to me how the images were built, it is not open-sourced.There is some code available here (https://github.com/evancwright?tab=repositories) if you're interested.
If the aim is towards the text adventure games, there is no need for a full programming language. Such games can be completely data driven, i.e. you need the specific game data plus a static interpretative part.There are already several systems that take that approach. I'm looking to create something more flexible.
You can write a decent GUI editor (like Lantern) in Lazarus and then assemble a BASIC code with both data and the (game) interpreter. You can use only the common intersection of the available BASIC dialects: namely READ/DATA/RESTORE/PRINT/FOR/NEXT/IF/GOTO. You can even embed the 'scripts' directly into BASIC code - just put line numbers and substitute the 'variables' with a corresponding two-letter names.I was considering a similar system some time ago.
That way you can have your beloved BASIC at your disposal and you can use what is given (in ROM) not to waste more RAM for a runtime.Although I would like to support the use of existing BASIC interpreters on retro targets if possible, I also want users to have other options.
QuoteAnd I've been doing the same for about 45 years. Need I say more?As it's unlikely I have 45 years left in me, telling me (and anyone else reading this) which parts were a waste of time would be useful. :)
I finally used Postscript Viewer (https://postscript-viewer.software.informer.com/) from Software Informer if anyone else using Windows 10 has this problem. It converts to a .pdf file and then opens in your default PDF viewer (possibly Microsoft Edge).
There'd probably be a Oxygene mode before that... ::)
I've never looked at in an any detail. Are you suggesting that Turbo Rascal might actually be an Oxygene rather than a Turbo Pascal derivative?
@PascalDragon: I've seen suggestion that RD isn't as good as some other approaches at error reporting and recovery. Do you have any comment?
Since classical Pascal (etc.) didn't support multiple compilation units, my preferred Pascal-like language would have separate interface and implementation files (like the TopSpeed compilers). In part this is because of the way that copyright etc. laws are moving, but also because it would be desirable to be able to lock-down at the OS level files containing definitions or complex hacks (e.g. the sort of thing that a systems programmer needs to do to get reference counting to work reliably).
I'm running out of steam. Hopefully that's given you something to think about, and plenty for Sven to complain about :-)
There are certain places where our error reporting could be better though whether they're due to the recursive descent parser or not I can't say right now. And recovery needs to be taken into account at each location and so depending on the error it's a bit hit and miss. Don't know whether a non-RD parser would really fare better there however...
what do you mean with “lock-down at the OS level”?
Too busy to really read and digest all that and thus I only picked out the cherries. :P
There are certain places where our error reporting could be better though whether they're due to the recursive descent parser or not I can't say right now. And recovery needs to be taken into account at each location and so depending on the error it's a bit hit and miss. Don't know whether a non-RD parser would really fare better there however...
Thanks for that and please note that I definitely wasn't complaining. Noting that I'm only repeating suggestions I've read, my /suspicion/ is that it relates to a compiler's ability to report more than the first syntax error it encounters.
Quotewhat do you mean with “lock-down at the OS level”?
Set a file read-only to less-privileged users.
And what would be the advantage here to only set the implementation to read-only, but not the interface as well?
why not simply provide it binary only?
QuoteAnd what would be the advantage here to only set the implementation to read-only, but not the interface as well?
I was assuming they were: I /did/ say "lock-down at the OS level files containing definitions or complex hacks".
Quotewhy not simply provide it binary only?
Depends on how the separate compilation works... /if/ it's done at all. Noting that my comments are in the general case rather than pertaining to any particular Pascal compiler or derivative, I suspect that never carrying around baggage relating to exception handling etc. implies that separate compilation would be to the AST level with actual code generation only after all calls into or out of a block had been resolved.
And then why the separation if both are locked down anyway?
What has how the separate compilation is done to do with whether or not you'd provide a binary only module?
So far, the language syntax seems more like a mix of BASIC and Pascal. Maybe that will change in version 2, which is described in book 3 (not yet published).
I haven't reached the point where he explains the REPL in detail, but the source code for all three books is available in his Rhodus Interpreter Repositories (https://github.com/ObjectPascalInterpreter) if you're curious.
I haven't reached the point where he explains the REPL in detail, but the source code for all three books is available in his Rhodus Interpreter Repositories (https://github.com/ObjectPascalInterpreter) if you're curious.And what REPL has to do in you multi-target bulder idea?
*snip*