Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
L ldpl
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 8
    • Issues 8
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Analytics
    • Analytics
    • CI/CD
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Lartu
  • ldpl
  • Issues
  • #105

Closed
Open
Created May 22, 2019 by Lartu@lartu🐕Maintainer

Macros?

Created by: dvkt

This is probably a bad idea, but the asmjit conversation got me thinking about it a bit.

One of the most powerful features in compiled languages like C and C++ are the macros/templates. Same for Lisp.

LDPL could potentially allow users to extend the language at compile time, with no runtime performance penalty, by adding line_like()-style macros.

This would allow LDPL to remain a super simple language at its core, while letting people create higher level abstractions for use in their own programs.

Language features could be tested as macros, or packaged up and shared with other, before being added to the language. Or they could remain independent packages, allowing for a more modular design. Classic "function calls" with arguments can be faked and new syntax can be added to any program.

However, it would add a huge cognitive burden. Right now I can read any LDPL program and probably know what it does. With macros, that's not true. All sorts of other problems come with them too, not least of all the tooling difficulties.

Still, they could be fun. Here's one thought:

MACROS:
define "$num-var = $num-expr + $num-expr" as
    add $1 and $2 in $num-var
end define

define "puts $expr" as 
    display $expr crlf
end define

define data "$var is stack" as
    $var is number vector
    $var-length is number
end define

define "push $num-expr onto $num-vec" as 
    store $num-expr in $num-vec:$num-vec-length
    incr $num-vec-length
end define 

define "pop $num-vec in $num-var" as 
    if $num-vec-length is greater than 0 then 
        decr $num-vec-length
        store $num-vec:$num-var-length in $num-var
    else
        store 0 in $num-var
    end if
end define

define block "loop do" "$expr" "repeat" as 
    while 1 is equal to 1 do
        $expr
    repeat
end define

DATA:
s is stack 
n is number

PROCEDURE:
push 1 onto s
push 2 onto s
push 3 onto s
pop s in n
puts "n is " n
n = 1 + 1 
puts "1 + 1 is " n
loop do
    puts "Ctrl-C to exit"
repeat

Obviously, one could get pretty carried away. Adding new syntax (the dollar sign) is a bummer too.

But wanted to throw it out there, or at least start a discussion and see if it's worth exploring other ways of extending the language beyond just defining sub-procedures.

Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking