~arivigo/scalc-devel

4 2

Proposal to add command parameters

Details
Message ID
<CC3P19NWYDY2.2ZIZGIMELBQP@shire>
DKIM signature
pass
Download raw message
I think it would be nice to add parameters to commands to allow some
additional functionality. For example, :d could have a parameter for how
many elements to drop, the WIP :s command could be used to limit how
many elements are printed, and (maybe) the :swp command could allow
specifying two indices to swap. These would be optional and have
(the currennt) functionalities as defaults.

The alternative is a more complex command framework that allows
repeating commands many times, but that adds complexity for what I think
is unnecessary extensibility.

Let me know what you think.
Details
Message ID
<20210615102233.kfpl45wpruzj7e57@arch>
In-Reply-To
<CC3P19NWYDY2.2ZIZGIMELBQP@shire> (view parent)
DKIM signature
pass
Download raw message
Hi!

> I think it would be nice to add parameters to commands to allow some
> additional functionality. For example, :d could have a parameter for how
> many elements to drop, the WIP :s command could be used to limit how
> many elements are printed, and (maybe) the :swp command could allow
> specifying two indices to swap. These would be optional and have
> (the currennt) functionalities as defaults.

I definitely would consider this a goal for 1.x. This would make scalc
very Forth-like and I love that idea. Moreover, if we could combine
commands in one single expression, to do stuff... wow, that would be
awesome... almost driving scalc to DSL-territory (not sure if I'd like
to see this becoming a proper programming language... tbh, it's 
something I'm constantly thinking about this project).

I think the command (and also ops) implementation could benefit from 
an idea like this. What would the roadmap look like?

> The alternative is a more complex command framework that allows
> repeating commands many times, but that adds complexity for what I think
> is unnecessary extensibility.
>
> Let me know what you think.

Actually, I think your proposal makes that extensibility VERY nice.
Much nicer than what it looks like right now. I'm quite excited about
what could come from this!

Cheers!

-- 
Ariadna Vigo
Web: <https://ariadnavigo.xyz>
PGP: 0xA3B1324836A669BD
Details
Message ID
<CC48W65UODVC.3ECNI50HBW1KF@shire>
In-Reply-To
<20210615102233.kfpl45wpruzj7e57@arch> (view parent)
DKIM signature
pass
Download raw message
On Tue Jun 15, 2021 at 6:22 AM EDT, Ariadna Vigo wrote:
> I definitely would consider this a goal for 1.x. This would make scalc
> very Forth-like and I love that idea. Moreover, if we could combine
> commands in one single expression, to do stuff... wow, that would be
> awesome... almost driving scalc to DSL-territory (not sure if I'd like
> to see this becoming a proper programming language... tbh, it's 
> something I'm constantly thinking about this project).

Ah, I figured we were trying to avoid this but if that's the direction
we're headed it's certainly interesting!

> I think the command (and also ops) implementation could benefit from 
> an idea like this. What would the roadmap look like?

I think getting syntax down is probably an important step to figuring
out a roadmap. Without knowing much about how languages like Forth
handle this, it seems like having two modes of operation would make
sense. You could have the existing operations mode and then the : prefix
switches to a command mode. This mode could then provide the following:

:4d

Drop 4 times

:2swp(3,4)d

Does (swap index 3/4 then drop) twice

:4d sav(A)

Stringing commands together

---

I'm not sure about the implications of this on the stack-based approach
(like should the command line *also* be a stack where the last part
executes first) or anything else, so feel free to provide your
suggestions for the grammar.

> -- 
> Ariadna Vigo
> Web: <https://ariadnavigo.xyz>
> PGP: 0xA3B1324836A669BD

Thanks,
Steven
Details
Message ID
<20210616210945.4qiu7fus2nkosnxy@arch>
In-Reply-To
<CC48W65UODVC.3ECNI50HBW1KF@shire> (view parent)
DKIM signature
pass
Download raw message
> I think getting syntax down is probably an important step to figuring
> out a roadmap. Without knowing much about how languages like Forth
> handle this, it seems like having two modes of operation would make
> sense. You could have the existing operations mode and then the : prefix
> switches to a command mode. This mode could then provide the following:
> 
> :4d
> 
> Drop 4 times
> 
> :2swp(3,4)d
> 
> Does (swap index 3/4 then drop) twice
> 
> :4d sav(A)
> 
> Stringing commands together

I like the feel of this. How hard could a parser be for this? Maybe 
introducing spaces could make this easier? For example:

	> :4 d sav(A)

 
> I'm not sure about the implications of this on the stack-based approach
> (like should the command line *also* be a stack where the last part
> executes first) or anything else, so feel free to provide your
> suggestions for the grammar.

I feel making command "mode" (:) be a stack-based command could have
the potential benefit of reusing the same code used for evaluating math
expressions, but then is this what we want? (this would be a potential
stack-based version of the above, where modifiers go before the 
modified command, but arguments go before...
	
	> :4 d A sav

But then we run into this for the ':2swp(3,4)d' example above. This is
ambiguous, does 2 modify the swapping+drop or just the drop?

	>: 2 3 4 swp d

Maybe "pure stack" might get us into trouble.

I'll think throughoutly about this issue in the course of the following
weeks. I do think this should be a goal for 1.x, though.

-- 
Ariadna Vigo
Web: <https://ariadnavigo.xyz>
PGP: 0xA3B1324836A669BD
Details
Message ID
<CC5Y5ZKOGR3H.A3BL42YVRBGY@shire>
In-Reply-To
<20210616210945.4qiu7fus2nkosnxy@arch> (view parent)
DKIM signature
pass
Download raw message
On Wed Jun 16, 2021 at 5:11 PM EDT, Ariadna Vigo wrote:
> I like the feel of this. How hard could a parser be for this?

Well I've never written one, sooooo.... guess we'll both find out!

> Maybe introducing spaces could make this easier? For example:

Not including spaces was actually intentional, as you noted:

> But then we run into this for the ':2swp(3,4)d' example above. This is
> ambiguous, does 2 modify the swapping+drop or just the drop?

Not using spaces everywhere makes the difference clear, I think:

The original ([swap and drop] twice):

:2swp(3,4)d

Or ([swap] twice, then drop):

:2swp(3,4) d

If you always include spaces, the difference in meaning has to be
expressed with new notation (like extra parentheses) or forcing
repetition numbers, making the original:

:2 swp(3,4) d

And the alternative is:

:2 swp(3,4) 1 d

But then a simple :d turns into :1 d which feels extra. Of course you
could handle this as a special case, but that becomes even more
confusing perhaps. As you noted, if you make the command arguments stack
based this makes separating the two even harder, but see my comments
below on that.

> I feel making command "mode" (:) be a stack-based command could have
> the potential benefit of reusing the same code used for evaluating math
> expressions, but then is this what we want? (this would be a potential
> stack-based version of the above, where modifiers go before the 
> modified command, but arguments go before...

Hmm, yeah I don't think it would be particularly intuitive (certainly
not from a programming language perspective). I also haven't looked at
the existing code so not really sure on that front.
>
> I'll think throughoutly about this issue in the course of the following
> weeks. I do think this should be a goal for 1.x, though.

Yep, I think this certainly requires some thinking.

> -- 
> Ariadna Vigo
> Web: <https://ariadnavigo.xyz>
> PGP: 0xA3B1324836A669BD

Thanks,
Steven
Reply to thread Export thread (mbox)