News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu
avatar_m_dr_m

Basic On Mushroom

Started by m_dr_m, 17:17, 26 March 24

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

m_dr_m

I'm tempted to work on an improved native Basic (*)
Goals are similar to: smalltalk port
  • Easier prototyping
  • Write fast tools fastly

Three axes:
  • New functionalities (E.g. named functions / sub-routines with local variables).
  • Faster interpreter / compilation (just in time and/or ahead of time)
  • IDE (reuse Orgams goodies like go-to-definition, go-to-next-occurrence etc. Plus step by step debugging).
 
Now, the most important, choosing the name of the project!

  • ACID: Amstrad CPC Intelligent Development
  • ACID: Accelerated Creation Integrating DMT
  • BASLEV: Basic levitation (ref to Maglev, fastest train on earth).
  • BOM: Basic On Mushrooms, "Good" in portuguese
  • BRASIC

(*) For now I would be only interested in a collaborative effort.

GUNHED

Nice idea. Maybe it could help to define commands of that new language first.  :)
http://futureos.de --> Get the revolutionary FutureOS (Update: 2023.11.30)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> Get the RSX-ROM for LambdaSpeak :-) (Updated: 2021.12.26)

HAL6128

Yeah, I like the idea and a similar approach as in Orgams only with Basic (an advanced compiler)
BOM sounds good in two ways.
...proudly supported Schnapps Demo, Pentomino and NQ-Music-Disc with GFX

dodogildo

BOM sounds great!
M'enfin!

m_dr_m

Quote from: GUNHED on 23:43, 26 March 24Nice idea. Maybe it could help to define commands of that new language first.  :)
I am not sure about that: wouldn't be a brand new language, just incremental changes.
The most important step in my book would be to be able to define multi-lines function. Each variable used in the scope of the function shall be local.

If there are commands you'd like to see, please go ahead!

 

Sykobee (Briggsy)

Do you mean something like this?

First line could be DEFFN repstr$(IN a%, IN b$, OUT result$) if you like this type of structure.

DEFFN repstr$(a%, b$)
  result$=""
  FOR (j% = 1 TO a%)
    results$ = result$ + b$;
  NEXT j%
  RETURN result$
ENDDEF

and steal DEFPROC from BBC BASIC?

m_dr_m

Exactly! With optional ENDDEF (indentation is clearer, cf haskell or python)
I like the idea of reusing DEFFN (must check if the semantic is the same: are the global a% and b$ altered?)
I don't know what DEFPROC brings to the table!

Your example makes me think: 
  • Generators (cf yield in python) would be great
  • The type shouldn't part of the variable (no sigil for Cyril)

Targhan

What about something like LUA on CPC?  It is simple, and can be added "modules" for more features, which could be added later.
Targhan/Arkos

Arkos Tracker 2.0.1 now released! - Follow the news on Twitter!
Disark - A cross-platform Z80 disassembler/source converter
FDC Tool 1.1 - Read Amsdos files without the system

Imperial Mahjong
Orion Prime

eto

Would an adaption of MMBasic make sense? It's designed for microcontrollers with limited RAM. Not sure if it's possible to adapt it for an 8bit processor though. 


GUNHED

Well, the above code example already show what I personally dislike regarding programming languages: Lots of needless brackets all over!  :-\

Madrams idea is great: The simplicity of BASIC, brackets reserved for math. And some additional (missing) functions / features.

It could help to start with few commands first, then more commands can be added. Also imho the language could be made in a way to be able to run under different CPC-OS from the beginning. This means: Separate two parts: The language itself - and the part to connect to the underlying OS. Imagine a language which can be used under native Firmware, CP/M, SymbOS and FutureOS.  :o

Regarding mathematics, especially for SQR and SIN/COS/TAN there are quick routines for the Z80 - way quicker compared to the usual BASIC dialects.  :)
http://futureos.de --> Get the revolutionary FutureOS (Update: 2023.11.30)
http://futureos.cpc-live.com/files/LambdaSpeak_RSX_by_TFM.zip --> Get the RSX-ROM for LambdaSpeak :-) (Updated: 2021.12.26)

m_dr_m

#10
Quote from: Targhan on 23:50, 27 March 24What about something like LUA on CPC?  It is simple, and can be added "modules" for more features, which could be added later.
Sounds like a great idea!
It has a lot of warts compare to e.g. Nim, but it might be small enough.
I might try to port the VM, following @PulkoMandy's steps. As GUNHED suggests, with careful separation of system part, to target:
  • CP/M? (to benefit a larger community, and CP/M on CPC has become sexy again)
  • SymbOs directly? (for less memory constraints?)

Quote from: eto on Yesterday at 08:40Would an adaption of MMBasic make sense? It's designed for microcontrollers with limited RAM. Not sure if it's possible to adapt it for an 8bit processor though.
The site states: "In its minimal version MMBasic typically compiles to about 94K of flash". Ouch!
It can be good for inspiration, but if I were to port a language, I would prefer start from wren.

@GUNHED. You should try lisp.

Syntax is usually passionately debated, while being the less important aspect, as long as:
  • it is consistent
  • easy stuff is easy to write and hard stuff is possible to write
Parenthesis are already used for function calls. It makes no sense discriminating user functions from built-in functions, especially if you want to promote functions as first class citizen (ability to store, pass and return functions) and allow generic programming.

m_dr_m

Regarding Lua, I forgot I did some preliminary experiments. Maybe I should post the results somewhere more visible?

The conclusions were: 
  • wren seems to have a smaller footprint (while being a more attractyves language)
  • it wasn't viable!

But those tests were done with LLVM_Z80, and since then SDCC has improved and generates better code (e.g. calls via register instead of stack handled via IX).

PulkoMandy

Did you get somewhere with Wren? If I understand correctly, the data format is "evrything is a 64-bit floating point value", with normally unused bits in NaN values to represent non-floating point things.

But I didn't look to see if the languga could be separated from this implementation, and be implemented in a maybe more compact way.

m_dr_m

No I didn't try anything. Yep 64 bits would be overkill!

Powered by SMFPacks Menu Editor Mod