Nice mixed pre/infix concept #1
Comments
|
I'm not sure to understand. But using ( ) instead of { } could lead to confusion between the regular use of ( ) in lisp/scheme and the new use. Why { } is explained in SRFI-105 in the section Design Rationale : https://srfi.schemers.org/srfi-105/srfi-105.html About := instead of <- , i used := before <- and decided to choose <- which is already used also historically in APL language, which i never learned but i learned PASCAL and it used :=. Note that in scheme unfortunately i need 2 operators <- for set! and <+ for 'define' which add a variable in the environment.Instead Python use only =. If used again := ,then i should also perheaps use something like :+ to define a variable. In fact many possibilities are already provided in Scheme+ : <- and <+ but also ← and ⥆ (which are hard to generate on keyboard, for the history IBM had a special keyboard for APL programmers) , and -> and +> ,etc , so i think i can add again back the := operator for assignment, i will try to remember to do it in a next release. |
|
Thanks for your thoughts and explanation of your thought process.
Funny you mentioned APL as I’m old enough to have used it and many others, but prefer scheme for generalized interactive computing, and do like your proposed scheme+ although we may disagree about a few relatively minor issues.
Best wishes.
… On Apr 1, 2024, at 7:12 PM, Damien MATTEI ***@***.***> wrote:
I'm not sure to understand. But using ( ) instead of { } could lead to confusion between the regular use of ( ) in lisp/scheme and the new use. Why { } is explained in SRFI-105 in the section Design Rationale : https://srfi.schemers.org/srfi-105/srfi-105.html
About := instead of <- , i used := before <- and decided to choose <- which is already used also historically in APL language, which i never learned but i learned PASCAL and it used :=.
Note that in scheme unfortunately i need 2 operators <- for set! and <+ for 'define' which add a variable in the environment.Instead Python use only =. If used again := ,then i should also perheaps use something like :+ to define a variable.
In fact many possibilities are already provided in Scheme+ : <- and <+ but also ← and ⥆ (which are hard to generate on keyboard, for the history IBM had a special keyboard for APL programmers) , and -> and +> ,etc , so i think i can add again back the := operator for assignment, i will try to remember to do it in a next release.
—
Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOQAXGW4I7IVDG3E73AHTBDY3HSXFAVCNFSM6AAAAABFR6KNPOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMZQG43DONJRGA>.
You are receiving this because you authored the thread.
|
|
For what it's worth regarding “{}”, as the only valid scheme expressions are those which begin with a function or macro name, any beginning with something other can be then easily alternatively considered to be an infix or possibly post-fix expression, without having to introduce a new expression delimiter such as {expression} it seems to me.
I.e. what else could (a < b) likely intuitively mean if a was not defined as a function?
while it’s true one could (define (a …) …) but so could one (define (+ …) …) which would similarly corrupt the default presumption that (+ …) specified arithmetic addition.
Again, not a big deal, I just personally find {} visually noisy and not strictly unnecessary, but understand others preferences may differ; that’s what’s fun about being a language designer, you can choose to define things as they suite you.
… On Apr 1, 2024, at 7:12 PM, Damien MATTEI ***@***.***> wrote:
I'm not sure to understand. But using ( ) instead of { } could lead to confusion between the regular use of ( ) in lisp/scheme and the new use. Why { } is explained in SRFI-105 in the section Design Rationale : https://srfi.schemers.org/srfi-105/srfi-105.html
About := instead of <- , i used := before <- and decided to choose <- which is already used also historically in APL language, which i never learned but i learned PASCAL and it used :=.
Note that in scheme unfortunately i need 2 operators <- for set! and <+ for 'define' which add a variable in the environment.Instead Python use only =. If used again := ,then i should also perheaps use something like :+ to define a variable.
In fact many possibilities are already provided in Scheme+ : <- and <+ but also ← and ⥆ (which are hard to generate on keyboard, for the history IBM had a special keyboard for APL programmers) , and -> and +> ,etc , so i think i can add again back the := operator for assignment, i will try to remember to do it in a next release.
—
Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOQAXGW4I7IVDG3E73AHTBDY3HSXFAVCNFSM6AAAAABFR6KNPOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMZQG43DONJRGA>.
You are receiving this because you authored the thread.
|
|
I released a new sub-version with the := operator again. I understand your ideas. I suppose it could be done, it seems to have been studied in discussions in the SRFI 105 , see part : "Why not autodetect infix?". It would require to know/detect the type of expressions. It would be a totally different implementation with no use of the already implemented SRFI 105. |
|
Hi Damien,
For what it's worth, please consider that attempting to modify the syntax of control-flow expressions such as (if <cond> <then> <else>) => (if <cond> then <then> else <else>) may be counter productive; as for me the only thing attractive about being able to optionally express an expression in infix form is that it reflects a typical arithmetic expression syntax i.e. (a + b) vs (+ a b); however altering the syntax of a conditional expression such as (if <cond> <else> <then>) buys me nothing as its both more wordy and fundamentally alters the root syntax of the language unless possibly the intent is to treat then and else as equivalent to begin; and thereby:
(if <cond> (then …) (else ….)) :: (if <cond> (begin …) (begin …))
which makes it a bit more expressive (especially if (then …) and (else …) blocks are checked for being properly ordered in sequence following an (if …) i.e.:
(if (a < b) a) VALID
(if (a < b) a b) VALID
(if (a < b) a (else …)) VALID
(if (a < b) (then …) b) VALID
(if (a < b) (then …)) VALID
(if (a < b) (then …) (else ….) VALID
(if (a < b) (else …) ERROR
(if (a < b) (then …) (then ..) ERROR
etc.
and thereby:
(if (< a b)
(begin (set! a (+ a b)) (* a b))
(begin (set! b (- a b)) (/ a b)))
may be alternatively written as:
(if (a < b)
(then (a := (a + b)) (a * b))
(else (b := (a - b)) (a / b)))
… On Apr 3, 2024, at 6:55 PM, Damien MATTEI ***@***.***> wrote:
Closed #1 <#1> as completed.
—
Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOQAXGQ47TNESTKDD36AMLLY3SCGPAVCNFSM6AAAAABFR6KNPOVHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJSGM2DSMZSGU4TGNY>.
You are receiving this because you authored the thread.
|
|
Hi Damien, (with a few typo’s corrected)
For what it's worth, please consider that attempting to modify the syntax of control-flow expressions such as (if <cond> <then> <else>) => (if <cond> then <then> else <else>) may be counter productive; as for me the only thing attractive about being able to optionally express an expression in infix form is that it reflects a typical arithmetic expression syntax i.e. (a + b) vs (+ a b); however altering the syntax of a conditional expression such as (if <cond> <else> <then>) buys me nothing as its both more wordy and fundamentally alters the root syntax of the language unless possibly the intent is to treat then and else as equivalent to begin; and thereby:
(if <cond> (then …) (else ….)) :: (if <cond> (begin …) (begin …))
which makes it a bit more expressive (especially if (then …) and (else …) blocks are checked for being properly ordered in sequence following an (if …) i.e.:
(if (a < b) a) VALID
(if (a < b) a b) VALID
(if (a < b) a (else …)) VALID
(if (a < b) (then …) b) VALID
(if (a < b) (then …)) VALID
(if (a < b) (then …) (else ….)) VALID
(if (a < b) (else …)) ERROR
(if (a < b) (then …) (then ..)) ERROR
etc.
and thereby:
(if (< a b)
(begin (set! a (+ a b)) (* a b))
(begin (set! b (- a b)) (/ a b)))
may be alternatively written as:
(if (a < b)
(then (a := (a + b)) (a * b))
(else (b := (a - b)) (a / b)))
… On Apr 3, 2024, at 6:55 PM, Damien MATTEI ***@***.***> wrote:
Closed #1 <#1> as completed.
—
Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOQAXGQ47TNESTKDD36AMLLY3SCGPAVCNFSM6AAAAABFR6KNPOVHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJSGM2DSMZSGU4TGNY>.
You are receiving this because you authored the thread.
|
|
hello, About if then else , it is a minor feature, i added it at a point when the project is finish (?) .It could be good for many things: As you say it to improve the code reading:
And it is implemented in a way it is 100% compatible with the classic scheme 'if' here examples i commented in source code: you can read the code yourself here if you want: so it is fool proof again a lot of errors. I admit that i try to implement it with macros but was too complex so i put it directly in the reader. anyway normal (if test then-expression else-expression ) still works. note that: if (a < b) (else …)) ERROR is not an error:
it simply return nothing as there is no expression. |
|
The choices are entirely yours.
I understand your position with respect to () vs {}; however in my mere opinion (if <cond> else <else> then <then>) is a mistake; as it introduces a keyword expression separator which is entirely foreign to lisp-like languages, but as noted earlier, the choice is yours to make; presuming you mean to enable a sequence of expressions between then, else, and a terminating ).
(if {a < b}
then {a := {a + b}} {a * b}
else {b := {a - b}} {a / b})
vs. hypothetically using {} for infix
(if {a < b}
(then {a := {a + b}} {a * b})
(else {b := {a - b}} {a / b})))
or eliminating {} and treating then & else as begin:
(if (a < b)
(then (a := (a + b)) (a * b))
(else (b := (a - b)) (a / b))))
I simply personally simply prefer the later, others milage may vary.
Best regards.
… On Apr 6, 2024, at 3:17 PM, Damien MATTEI ***@***.***> wrote:
hello,
about (a + b) vs {a + b}, i admit it could be done but my work was based on SRFI 105 that already did the job. And my compilation and lexical parsing course are far away behind me in the past. After that, using only ( ) add a functionality more to the ( ) making code less readable with complex expressions.
About if then else , it is a minor feature, i added it at a point when the project is finish (?) .It could be good for many things: As you say it to improve the code reading:
impropve code reading
be used as begin, like (then ...) (else ...) instead of (begin ...) which are macro i used in the past
And it is implemented in a way it is 100% compatible with the classic scheme 'if'
here examples i commented in source code:
;; > (if #f else 3)
;; 3
;; > (if #t else 3)
;; > (if #t 2 else 3)
;; 2
;; > (if #t then 2 else 3)
;; 2
;; > (if #f then 2 else 3)
;; 3
;; > (if #f then 1 2 else 3 4)
;; 4
;; > (if #t then 1 2 else 3 4)
;; 2
;; > (if #t 1 2 3)
;; 3
;; > (if #t then 1 2 else 3 4 then 5)
;; . . SRFI-105.rkt:181:17: if: then after else near : '(then 5)
;; > (if #t then 1 2 else 3 4 else 5)
;; . . SRFI-105.rkt:181:17: if: 2 else inside near: '(else 5)
;; > (if #t else 1 2 then 3 4)
;; . . SRFI-105.rkt:181:17: if: then after else near : '(then 3 4)
;; > (if #t then 1 2 then 3 4)
;; . . SRFI-105.rkt:181:17: if: 2 then inside near: '(then 3 4)
you can read the code yourself here if you want:
https://github.com/damien-mattei/Scheme-PLUS-for-Racket/blob/main/src/SRFI-105.scm#L122
so it is fool proof again a lot of errors.
I admit that i try to implement it with macros but was too complex so i put it directly in the reader.
anyway normal (if test then-expression else-expression ) still works.
note that:
if (a < b) (else …)) ERROR
is not an error:
(if {2 < 3} else "no error")
it simply return nothing as there is no expression.
—
Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOQAXGUF3RDNYQE7A3YCJILY4BC25AVCNFSM6AAAAABFR6KNPOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBRGE3TCMZWHE>.
You are receiving this because you authored the thread.
|
|
(sorry, fixed formatting and removed a bit too many )’s below)
The choices are entirely yours.
I understand your position with respect to () vs {}; however in my mere opinion (if <cond> else <else> then <then>) is a mistake; as it introduces a keyword expression separator which is entirely foreign to lisp-like languages, but as noted earlier, the choice is yours to make; presuming you mean to enable a sequence of expressions between then, else, and a terminating ).
(if {a < b}
then {a := {a + b}} {a * b}
else {b := {a - b}} {a / b})
vs. hypothetically using {} for infix
(if {a < b}
(then {a := {a + b}} {a * b})
(else {b := {a - b}} {a / b}))
or eliminating {} and treating then & else as begin:
(if (a < b)
(then (a := (a + b)) (a * b))
(else (b := (a - b)) (a / b)))
I simply personally simply prefer the later, others milage may vary.
Best regards.
… On Apr 6, 2024, at 3:17 PM, Damien MATTEI ***@***.***> wrote:
hello,
about (a + b) vs {a + b}, i admit it could be done but my work was based on SRFI 105 that already did the job. And my compilation and lexical parsing course are far away behind me in the past. After that, using only ( ) add a functionality more to the ( ) making code less readable with complex expressions.
About if then else , it is a minor feature, i added it at a point when the project is finish (?) .It could be good for many things: As you say it to improve the code reading:
impropve code reading
be used as begin, like (then ...) (else ...) instead of (begin ...) which are macro i used in the past
And it is implemented in a way it is 100% compatible with the classic scheme 'if'
here examples i commented in source code:
;; > (if #f else 3)
;; 3
;; > (if #t else 3)
;; > (if #t 2 else 3)
;; 2
;; > (if #t then 2 else 3)
;; 2
;; > (if #f then 2 else 3)
;; 3
;; > (if #f then 1 2 else 3 4)
;; 4
;; > (if #t then 1 2 else 3 4)
;; 2
;; > (if #t 1 2 3)
;; 3
;; > (if #t then 1 2 else 3 4 then 5)
;; . . SRFI-105.rkt:181:17: if: then after else near : '(then 5)
;; > (if #t then 1 2 else 3 4 else 5)
;; . . SRFI-105.rkt:181:17: if: 2 else inside near: '(else 5)
;; > (if #t else 1 2 then 3 4)
;; . . SRFI-105.rkt:181:17: if: then after else near : '(then 3 4)
;; > (if #t then 1 2 then 3 4)
;; . . SRFI-105.rkt:181:17: if: 2 then inside near: '(then 3 4)
you can read the code yourself here if you want:
https://github.com/damien-mattei/Scheme-PLUS-for-Racket/blob/main/src/SRFI-105.scm#L122
so it is fool proof again a lot of errors.
I admit that i try to implement it with macros but was too complex so i put it directly in the reader.
anyway normal (if test then-expression else-expression ) still works.
note that:
if (a < b) (else …)) ERROR
is not an error:
(if {2 < 3} else "no error")
it simply return nothing as there is no expression.
—
Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOQAXGUF3RDNYQE7A3YCJILY4BC25AVCNFSM6AAAAABFR6KNPOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBRGE3TCMZWHE>.
You are receiving this because you authored the thread.
|
|
strange... i was just thinking to explain better about 'separator which is entirely foreign to lisp-like languages' and i wanted to point that the 'cond' of scheme introduce already an 'else' but this is an exception, i can remember that LISP instead use a #t at the end of a 'cond' instead of 'else'. LISP is more pure than Scheme about that. In fact i do not see what problem is with having some reserved words such as 'then' 'else' 'until' but perheaps it has something to do with lambda calculus? about this syntax: (if (a < b) this is the way works my Scheme+ because it implement operator precedence you can write directly this: (if {a < b} here is a real test in Scheme+ for Racket: Welcome to DrRacket, version 8.12 [cs].
(define-syntax else-block
0.564516129032258 |
|
actually else in cond is not really an exception, it’s a keyword prefix for a default terminating expression which behave like begin.
(define a #f)
(cond (a ’true)
(else (set! a #t) ‘false))
… ‘false
On Apr 6, 2024, at 4:06 PM, Damien MATTEI ***@***.***> wrote:
strange... i was just thinking to explain better about 'separator which is entirely foreign to lisp-like languages' and i wanted to point that the 'cond' of scheme introduce already an 'else' but this is an exception, i can remember that LISP instead use a #t at the end of a 'cond' instead of 'else'. LISP is more pure than Scheme about that. In fact i do not see what problem is with having some reserved words such as 'then' 'else' 'until' but perheaps it has something to do with lambda calculus?
about this syntax:
(if (a < b)
(then (a := (a + b)) (a * b))
(else (b := (a - b)) (a / b))))
it is true that it would be a pretty language.I like it too, just id did not know how to implement it.
note that it can even be simplified by removing unecessary parenthesis:
(if (a < b)
(then (a := a + b) (a * b))
(else (b := a - b) (a / b))))
this is the way works my Scheme+ because it implement operator precedence you can write directly this:
(if {a < b}
(then {a := a + b} {a * b})
(else {b := a - b} {a / b}))
here is a real test in Scheme+ for Racket:
note that you can use 'then' in scheme but not 'else' as it is already used in 'cond' , in the past i used then-block else-block:
https://github.com/damien-mattei/library-FunctProg/blob/master/if-then-else.scm#L19
Welcome to DrRacket, version 8.12 [cs].
Language: reader "SRFI-105.rkt", with debugging; memory limit: 8192 MB.
(define-syntax then-block
(syntax-rules ()
((_ ev) ev)
((_ ev ...) (begin ev ...))))
(define-syntax else-block
(syntax-rules ()
((_ ev) ev)
((_ ev ...) (begin ev ...))))
(define a 3.5)
(define b -2.7)
(if {a < b}
(then-block {a := a + b} {a * b})
(else-block {b := a - b} {a / b}))
0.564516129032258
—
Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOQAXGS4IGMFJ6C2JAA7JSDY4BIU3AVCNFSM6AAAAABFR6KNPOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBRGE4DCOBRGU>.
You are receiving this because you authored the thread.
|
|
Damien,
If you have an interest in attempting to forgo using SRFI-105 as the basis of your Scheme+, and instead attempt to “auto-detect” infix expressions beginning with something other than a valid prefix-function assuming the use of pre-determined infix operators such as ::, :=, <, >, =, <=, >=, !=, +, -, *, /, etc.; I’d try asking Matthew Flatt or others on the Racket-Lang team for guidance; as I’m sure one of them could point you in the right direction, as I don’t believe it should be too hard to assume that any expression which begins with an object which is not defined as a function may be a valid infix expressions without having to use {} delimiters.
… On Apr 6, 2024, at 4:17 PM, Paul Schlie ***@***.***> wrote:
actually else in cond is not really an exception, it’s a keyword prefix for a default terminating expression which behave like begin.
(define a #f)
(cond (a ’true)
(else (set! a #t) ‘false))
> ‘false
> On Apr 6, 2024, at 4:06 PM, Damien MATTEI ***@***.***> wrote:
>
>
> strange... i was just thinking to explain better about 'separator which is entirely foreign to lisp-like languages' and i wanted to point that the 'cond' of scheme introduce already an 'else' but this is an exception, i can remember that LISP instead use a #t at the end of a 'cond' instead of 'else'. LISP is more pure than Scheme about that. In fact i do not see what problem is with having some reserved words such as 'then' 'else' 'until' but perheaps it has something to do with lambda calculus?
>
> about this syntax:
> (if (a < b)
> (then (a := (a + b)) (a * b))
> (else (b := (a - b)) (a / b))))
> it is true that it would be a pretty language.I like it too, just id did not know how to implement it.
> note that it can even be simplified by removing unecessary parenthesis:
>
> (if (a < b)
> (then (a := a + b) (a * b))
> (else (b := a - b) (a / b))))
>
> this is the way works my Scheme+ because it implement operator precedence you can write directly this:
>
> (if {a < b}
> (then {a := a + b} {a * b})
> (else {b := a - b} {a / b}))
>
> here is a real test in Scheme+ for Racket:
> note that you can use 'then' in scheme but not 'else' as it is already used in 'cond' , in the past i used then-block else-block:
> https://github.com/damien-mattei/library-FunctProg/blob/master/if-then-else.scm#L19
>
> Welcome to DrRacket, version 8.12 [cs].
> Language: reader "SRFI-105.rkt", with debugging; memory limit: 8192 MB.
>
> (define-syntax then-block
> (syntax-rules ()
> ((_ ev) ev)
> ((_ ev ...) (begin ev ...))))
>
> (define-syntax else-block
> (syntax-rules ()
> ((_ ev) ev)
> ((_ ev ...) (begin ev ...))))
>
> (define a 3.5)
> (define b -2.7)
> (if {a < b}
> (then-block {a := a + b} {a * b})
> (else-block {b := a - b} {a / b}))
>
> 0.564516129032258
>
> —
> Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOQAXGS4IGMFJ6C2JAA7JSDY4BIU3AVCNFSM6AAAAABFR6KNPOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBRGE4DCOBRGU>.
> You are receiving this because you authored the thread.
>
|
|
yes i have done it. Note that Scheme+ not only does infix but also indexes vectors,strings,arrays,etc with [ ] . All those features requires to work the parser, perheaps not only use macro. |
|
Good. Who knows, having the Racket team think about how to enable alternative syntaxes to be supported in combination with traditional Scheme where not in conflict, may actually help them accomplish one of their stated goals to create a language/tool to help facilitate the creation of application specific languages.
… On Apr 8, 2024, at 6:47 PM, Damien MATTEI ***@***.***> wrote:
yes i have done it. Note that Scheme+ not only does infix but also indexes vectors,strings,arrays,etc with [ ] . All those features requires to work the parser, perheaps not only use macro.
—
Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOQAXGUHWGJ4VZLX7SJS6RTY4MM7JAVCNFSM6AAAAABFR6KNPOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBTG43DENZRGI>.
You are receiving this because you authored the thread.
|
|
about application specific language: "Racket is not Scheme" is not really true, it is scheme compatible but it is used to construct language too, but i have poor knowledge about the racket's feature about creating language. I know they implements for example Algol 60 so i suppose they can implements any language perheaps. note that evaluating (a * b + c) require to know the type of a to detect it is not a procedure but a number or matrix etc... so this could be done by different ways: But detecting at runtime can not be done at the parser stage, the modification are deep in the scheme implementation to make them. for memory there would be 3 sort of evaluation in such a new scheme: |
|
my suspicion is that auto-detected-infix (i.e. use of “()” vs :”{}” to work, some restrictions will be necessary, such as all scheme functions and objects may need to be defined prior to their first use so it can be determined whether an expression begins with a valid scheme function, or the first operand of an infix operator, or something like that; but again someone like Matthew who knows racket inside out will be able to assess what’s reasonably possible, or not. Best of luck, as I do believe there are benefits to being able to mix traditional scheme expressions in combination with expressions using an algebraic syntax
… On Apr 9, 2024, at 5:51 AM, Damien MATTEI ***@***.***> wrote:
about application specific language: "Racket is not Scheme" is not really true, it is scheme compatible but it is used to construct language too, but i have poor knowledge about the racket's feature about creating language. I know they implements for example Algol 60 so i suppose they can implements any language perheaps.
note that evaluating (a * b + c) require to know the type of a to detect it is not a procedure but a number or matrix etc... so this could be done by different ways:
-type declaration , example in Typed Racket but not Scheme
-type inference, example in Haskell, but very hard, i do not know a scheme implementation making this
-runtime, the way scheme works
But detecting at runtime can not be done at the parser stage, the modification are deep in the scheme implementation to make them.
Scheme implementation are generally based on lambda calculus which is a sort of limited rewrite rules system and there is no type consideration in it.
for memory there would be 3 sort of evaluation in such a new scheme:
(procedure arg1 arg2 ....)
(special-form-macro arg1 arg2 ....)
(arg1 operator arg2 .....)
—
Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOQAXGRQYYGMHZFVXZDES6DY4O2YPAVCNFSM6AAAAABFR6KNPOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBUGYYDENJTGM>.
You are receiving this because you authored the thread.
|
|
but if you have so much idea about the infix notation for scheme with ( ) why do not talking yourself with the Racket team? |
|
I would like to see you be successful in refining Scheme+, but candidly my interest is only casual and I have no interest in participating in its development as I’m already over obligated with other commitments.
… On Apr 9, 2024, at 3:16 PM, Damien MATTEI ***@***.***> wrote:
but if you have so much idea about the infix notation for scheme with ( ) why do not talking yourself with the Racket team?
—
Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOQAXGQGLFQ3JYWMIYQIUFTY4Q5B7AVCNFSM6AAAAABFR6KNPOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBVHEYDAMZXGQ>.
You are receiving this because you authored the thread.
|
|
advice is to use #%app to implement what you are talking. |
|
i just commited a version that do it.... {(a * x) + y + (d * x) / (add1 (x ** 2))} {(ksx / (sqrt 2)) * (x + y)} (define (σ z̃) (define z 3 * 5 + 2) (define a 2 * (cos (2 * pi * p / q)) ) |
|
Very nice, congratulations. (I am a bit uncertain about "(define z 3 * 5 + 2)” etc. as it feels "(define z {3 * 5 + 2})" would be more consistent, as the infix expression sequence is not delimited by your curly braces although within the context of a prefixed-expression, and not sure what you meant by "(define (σ z̃)” ?
The curly braces still bug me however.
I can’t help but wondering if they are necessary, as it would seem that an expression (delimited by parens) parsed after initial macro expansion could be simply considered prefixed if its first term is a defined syntactic-keyword/function, or otherwise simply parsed as an infixed expression (i.e. prefix is assumed, unless the first term can't be validly interpreted as such)?
… On Nov 28, 2024, at 5:31 PM, Damien MATTEI ***@***.***> wrote:
i just commited a version that do it....
{(a * x) + y + (d * x) / (add1 (x ** 2))}
{(ksx / (sqrt 2)) * (x + y)}
(define (σ z̃)
{1 / (1 + (exp (- z̃)))}
(define z 3 * 5 + 2)
(define a 2 * (cos (2 * pi * p / q)) )
—
Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOQAXGUQZ3AII7AG57WVLAT2C6KV5AVCNFSM6AAAAABSV6GYP6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMBWHAYTKMZVGQ>.
You are receiving this because you authored the thread.
|
|
thank you. for your last point it is not so easy, first i de not use only a macro there is: using just ( ) could be done in Racket specifically but not compatible with Scheme there is not a way to test in scheme if an object is a procedure. (map - ns) is it infix? or prefix? will fail : ( this will works: {ns := (list 1 2 3 4)} because op- hide the - operator, so the expression is considered prefix, not infix but your are right, with a modified parser we can only use parenthesis, i have all the code and stuff to do it now, that could be interesting ...... |
|
seems almost done, will check tomorrow more examples:
(define-infix (foo) (3 * 5 + 2)) #
foo #
(foo) #
(define-infix (foo) (3 * 5 + 2) (2 - 3)) #
(foo) #
(define-infix (foo) (if (2 > 3) "never" "right")) #
(foo) # still working prefix:
(define-infix (foo) (if (> 2 3) "never" "right")) #
(foo) define-infix should be renamed define , like both syntax are accepted.... |
|
note: this even not require parser! simply macros as you mentioned it month ago, i was too obsessed by SRFI 105... but SRFI 105 is still usefull for indexing arrays [ ] will check tomorrow for infix again, but if it works, it was just changing one or 2 lines in the code here: just have to add thank you for insisting so much , it was worth it. |
|
or possibly similarly define a syntax-rule “:"
such that “(: <some-infix-expression) using your $nfx$ and assuming all procedure calls remain “(<proc> <args)”, then ...
(define x (: 3 + 6 / 3 * (radom 3)))
or
(define (x b) (: 3 + b / 3 * (random)))
… On Nov 30, 2024, at 7:06 PM, Damien MATTEI ***@***.***> wrote:
seems almost done, will check tomorrow more examples:
(define-infix (foo) (3 * 5 + 2))
(define-infix (foo) (3 * 5 + 2))
#
foo
foo
#procedure:foo
#
(foo)
(foo)
17
#
(define-infix (foo) (3 * 5 + 2) (2 - 3))
(define-infix (foo) (3 * 5 + 2) (2 - 3))
#
(foo)
(foo)
-1
#
(define-infix (foo) (if (2 > 3) "never" "right"))
(define-infix (foo) (if (2 > 3) "never" "right"))
#
(foo)
(foo)
"right"
#
—
Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOQAXGVTJ3YO6B6U3XEMOZT2DJHGRAVCNFSM6AAAAABSV6GYP6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMBZGQ4DGNZQG4>.
You are receiving this because you authored the thread.
|
|
or …
(if (: a < b) c (: a := a + b / 3))
absent the ability to differentiate the type of the first term in an expression to classify an expression encapsulated by parens as being prefix vs infix; to my tired (being older than not) eyes, the use of a colon visually accentuates the beginning of an infix-expression better than surrounding it with curry braces and seems more consistent with the syntax of the language in general (but I understand that’s subjective).
… On Nov 30, 2024, at 9:37 PM, Paul Schlie ***@***.***> wrote:
or possibly similarly define a syntax-rule “:"
such that “(: <some-infix-expression) using your $nfx$ and assuming all procedure calls remain “(<proc> <args)”, then ...
(define x (: 3 + 6 / 3 * (radom 3)))
or
(define (x b) (: 3 + b / 3 * (random 3)))
> On Nov 30, 2024, at 7:06 PM, Damien MATTEI ***@***.***> wrote:
>
>
> seems almost done, will check tomorrow more examples:
>
> (define-infix (foo) (3 * 5 + 2))
>
> (define-infix (foo) (3 * 5 + 2))
>
> #
>
> foo
>
> foo
> #procedure:foo
>
> #
>
> (foo)
>
> (foo)
> 17
>
> #
>
> (define-infix (foo) (3 * 5 + 2) (2 - 3))
>
> (define-infix (foo) (3 * 5 + 2) (2 - 3))
>
> #
>
> (foo)
>
> (foo)
> -1
>
> #
>
> (define-infix (foo) (if (2 > 3) "never" "right"))
>
> (define-infix (foo) (if (2 > 3) "never" "right"))
>
> #
>
> (foo)
>
> (foo)
> "right"
>
> #
>
> —
> Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOQAXGVTJ3YO6B6U3XEMOZT2DJHGRAVCNFSM6AAAAABSV6GYP6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMBZGQ4DGNZQG4>.
> You are receiving this because you authored the thread.
>
|
|
the only other thing I’d tend to (personally) favor is expanding within the context of an (if <exp> <then-exp> <else-exp>) the optional use of (then <expression-sequence>) and (else <expression-sequence>), as oppose to (begin <expression-sequence>) to improve the clarity of the intent of the expression …
(if (: a = b) (+ a b) (begin (set! a b) (+ a b))
(if (= a b) (+ a b) (else (set! a b) (+ a b)))
(if (: a = b) (then (+ a b)) (else (: a := b) (+ a b)))
and recognizing the following as a syntax error:
(if (= a b) (else …)) ; missing <then> term
(if (= a b) (else …) …) ; missing <then> term, and unexpected <terms> following <else>
(if (= a b) (+ a b) (then …)) ; duplicate <then> term
or something like that.
Good luck with your experiment, syntax/semantic preference tend to be subject to the eye of the beholder.
… On Dec 1, 2024, at 9:27 AM, Paul Schlie ***@***.***> wrote:
or …
(if (: a < b) c (: a := a + b / 3))
absent the ability to differentiate the type of the first term in an expression to classify an expression encapsulated by parens as being prefix vs infix; to my tired (being older than not) eyes, the use of a colon visually accentuates the beginning of an infix-expression better than surrounding it with curry braces and seems more consistent with the syntax of the language in general (but I understand that’s subjective).
> On Nov 30, 2024, at 9:37 PM, Paul Schlie ***@***.***> wrote:
>
> or possibly similarly define a syntax-rule “:"
>
> such that “(: <some-infix-expression) using your $nfx$ and assuming all procedure calls remain “(<proc> <args)”, then ...
>
> (define x (: 3 + 6 / 3 * (radom 3)))
> or
> (define (x b) (: 3 + b / 3 * (random 3)))
>
>
>
>> On Nov 30, 2024, at 7:06 PM, Damien MATTEI ***@***.***> wrote:
>>
>>
>> seems almost done, will check tomorrow more examples:
>>
>> (define-infix (foo) (3 * 5 + 2))
>>
>> (define-infix (foo) (3 * 5 + 2))
>>
>> #
>>
>> foo
>>
>> foo
>> #procedure:foo
>>
>> #
>>
>> (foo)
>>
>> (foo)
>> 17
>>
>> #
>>
>> (define-infix (foo) (3 * 5 + 2) (2 - 3))
>>
>> (define-infix (foo) (3 * 5 + 2) (2 - 3))
>>
>> #
>>
>> (foo)
>>
>> (foo)
>> -1
>>
>> #
>>
>> (define-infix (foo) (if (2 > 3) "never" "right"))
>>
>> (define-infix (foo) (if (2 > 3) "never" "right"))
>>
>> #
>>
>> (foo)
>>
>> (foo)
>> "right"
>>
>> #
>>
>> —
>> Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOQAXGVTJ3YO6B6U3XEMOZT2DJHGRAVCNFSM6AAAAABSV6GYP6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMBZGQ4DGNZQG4>.
>> You are receiving this because you authored the thread.
>>
>
|
i want a mathematical syntax, having a (: before infix is not mathematical |
|
this is subjective, of course ,i can think of the possibility to provide many solutions if they are not confictual in the implementation, already i think that : is the same as another think i must have a coherent system, currently if define-infix a procedure if there is inner define they will be forced define-infix ,that a problem i must solve. A possibility would be for coder to use define and inner define-infix when needed but the inner block will not be infix so , unless i use some portion with { var := infix expression} ,already for this reason it is interesting to have curly bracketts . Ok it works, but the simpliest it will be the more elegant it would be. About if then else i already have in scheme+ $> that is begin (it is short and cause less indentation, $+> is a (let () that allow define inside, due to limitation in some scheme implementation. |
|
my thought is basically that the native scheme prefix syntax should be considered the default, with infix being the explicit exception for the context of the terms within the then current expression, but not subexpressions which again defaults to pre-fix; i.e. (using your {} notation to indicate the beginning of an infix expression)
(define (f a b) {a := a / (random 10)}) ; where (random 10) is presumed to be a prefixed subexpression as it does not begin with { or (: which would be required to indicate the beginning of a infix subexpression.
likely because I personally prefer using a consistent prefix notion by default with the exception of when algebraic notation feels more natural, as is typically the case in comparison and arithmetic expressions like ...
(if {a < b} (then {a := b / (random 10)}) (else 0))
or if preferred …
(if {a < b} {a := b / (random 10)} 0)
… On Dec 1, 2024, at 3:41 PM, Damien MATTEI ***@***.***> wrote:
this is subjective, of course ,i can think of the possibility to provide many solutions if they are not confictual in the implementation, already i think that : is the same as $nfx$ that i can export to user toplevel.
another think i must have a coherent system, currently if define-infix a procedure if there is inner define they will be forced define-infix ,that a problem i must solve. A possibility would be for coder to use define and inner define-infix when needed but the inner block will not be infix so , unless i use some portion with { var := infix expression} ,already for this reason it is interesting to have curly bracketts . Ok it works, but the simpliest it will be the more elegant it would be. About if then else i already have in scheme+ $> that is begin (it is short and cause less indentation, $+> is a (let () that allow define inside, due to limitation in some scheme implementation.
—
Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOQAXGSMHUECO2JS6WBSUYT2DNYAFAVCNFSM6AAAAABSV6GYP6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMJQGI2DGMBSGY>.
You are receiving this because you authored the thread.
|
|
(with typo fixed to express what was intended, sorry …)
my thought is basically that the native scheme prefix syntax should be considered the default, with infix being the explicit exception for the context of the terms within the then current expression, but not subexpressions which again defaults to pre-fix; i.e. (using your {} notation to indicate the beginning of an infix expression)
(define (f a b) {a := a / (random 10)} {a * b}) ; where (random 10) is presumed to be a prefixed subexpression as it does not begin with { or (: which would be required to indicate the beginning of a infix subexpression.
likely because I personally prefer using a consistent prefix notion by default with the exception of when algebraic notation feels more natural, as is typically the case in comparison and arithmetic expressions like ...
(if {a < b} (then {a := b / (random 10)}) (else 0))
or if preferred …
(if {a < b} {a := b / (random 10)} 0)
In summary I tend to really only be interested in the use of infix for simple distinct algebraic expressions, but not otherwise; in large part because I don’t like using expression separators like “;” to separate distinct infix expressions.
(but that may be just me)
… On Dec 1, 2024, at 3:41 PM, Damien MATTEI ***@***.***> wrote:
this is subjective, of course ,i can think of the possibility to provide many solutions if they are not confictual in the implementation, already i think that : is the same as $nfx$ that i can export to user toplevel.
another think i must have a coherent system, currently if define-infix a procedure if there is inner define they will be forced define-infix ,that a problem i must solve. A possibility would be for coder to use define and inner define-infix when needed but the inner block will not be infix so , unless i use some portion with { var := infix expression} ,already for this reason it is interesting to have curly bracketts . Ok it works, but the simpliest it will be the more elegant it would be. About if then else i already have in scheme+ $> that is begin (it is short and cause less indentation, $+> is a (let () that allow define inside, due to limitation in some scheme implementation.
—
Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOQAXGSMHUECO2JS6WBSUYT2DNYAFAVCNFSM6AAAAABSV6GYP6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMJQGI2DGMBSGY>.
You are receiving this because you authored the thread.
|
|
i agree with you, i expect a 100% backward compatibility or almost, we can not change the habit of users, having something we do not really when we can use infix or prefix would be bad. Note that all this is possible with syntax transformers, not the way macro used to works with define-macro but with define-syntax and R6RS,R7RS. When i started the project i did not knew that so i was sticked to SRFI 105 and parser. Things has evolves since. the notation should be able to write: (if (a < b) {a := b / (random 10)} 0) the crucial part being here (map - ....) being not infix but prefix. As the macros are basically recursive in a define-infix it will modify all the define arguments considering them infix, that i must change by detecting inner define in define-infix. I have to perform tests about all that, because the system is becaming more and more complex, syntax transforming is done only one time ,so there is by chance no time penality in a looping program or recalling the same definitions. But the more the system is complex ,this could lead to bugs. Also i have 'def' that act as python allowing 'return' , i would have again a 'def' and a 'def-infix' , even if the 2 form are proposed, the best programming style would be to use the infix ones and only when necessary use inner define prefix ,they are very rare ,all that is just to do (map - ns) and sort of things that are 1% of programming but we can not leave that wrong or impossible.... note : it is hard to write code, but you can re-edit your own message by clkiking at right on ... edit |
|
I don’t understand the problem, if prefix is assumed by default, and infix is only assumed for a top-level terms of an expression enclosed in curly-brackets where in-turn embedded terms which are sub-expressions are again assumed to be prefix unless enclosed by curly-braces, then the following and the like are unambiguously equivalent (please note I’m not assuming infix procedures have any implied precedence, application order has to be explicitly defined by syntactic nesting hierarchy) ...
(let ((a 1) (b 2))
(if {a < b} {a := b / {a + b}} 0)
(define ns (list 1 2 3))
(define result (map - (cons a ns)))
result)
=> ‘(-2/3 -1 -2 -3)
(let ((a 1) (b 2))
(if {a < b} {a := b / (+ a b)} 0)
(define ns (list 1 2 3))
(define result (map - (cons a ns)))
result)
=> ‘(-2/3 -1 -2 -3)
(let ((a 1) (b 2))
(if (< a b) (set! a (/ b (+ a b))) 0)
(define ns (list 1 2 3))
(define result (map - (cons a ns)))
result)
=> ‘(-2/3 -1 -2 -3)
i.e. (or something like it)
<expression> :: [<literal>|<symbol>|<prefix-expression>|<infix-expression>]
<prefix-expression> :: (<procedure> [<arg>]*)
<infix-expression> :: {<arg> [<procedure> [<arg>]]
<arg> :: <expression>
… On Dec 2, 2024, at 5:20 AM, Damien MATTEI ***@***.***> wrote:
i agree with you, i expect a 100% backward compatibility or almost, we can not change the habit of users, having something we do not really when we can use infix or prefix would be bad.
It must be proposed a syntax where 'define' is always the way it used to works with prefix. For 'define-infix' i have the idea to detect nested 'define' and escape from infix mode to fallback to prefix one. This should be faisable.
Note that all this is possible with syntax transformers, not the way macro used to works with define-macro but with define-syntax and R6RS,R7RS. When i started the project i did not knew that so i was sticked to SRFI 105 and parser. Things has evolves since.
the notation should be able to write: (if (a < b) {a := b / (random 10)} 0)
in a 'define-infix' but if inside there is an inner definition with 'define' , one should be able to write
(if (a < b) {a := b / (random 10)} 0)
(define ns (list 1 2 3))
(define result (map - (cons a ns)))
result)```
the crucial part being here (map - ....) being not infix but prefix.
As the macros are basically recursive in a define-infix it will modify all the define arguments considering them infix, that i must change by detecting inner define in define-infix.
I have to perform tests about all that, because the system is becaming more and more complex, syntax transforming is done only one time ,so there is by chance no time penality in a looping program or recalling the same definitions.
But the more the system is complex ,this could lead to bugs.
Also i have 'def' that act as python allowing 'return' , i would have again a 'def' and a 'def-infix' , even if the 2 form are proposed, the best programming style would be to use the infix ones and only when necessary use inner define prefix ,they are very rare ,all that is just to do (map - ns) and sort of things that are 1% of programming but we can not leave that wrong or impossible....
—
Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOQAXGTS56Q6Q6D5ZNB34L32DQX7PAVCNFSM6AAAAABSV6GYP6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMJRGEZDMMRSGI>.
You are receiving this because you authored the thread.
|
|
(with correction below which explicitly denotes all infix sub-expressions properly, which I suspect you may not like as it’s more verbose, being why you may prefer infix expressions with implied precedences) ...
I don’t understand the problem, if prefix is assumed by default, and infix is only assumed for a top-level terms of an expression enclosed in curly-brackets where in-turn embedded terms which are sub-expressions are again assumed to be prefix unless enclosed by curly-braces, then the following and the like are unambiguously equivalent (please note I’m not assuming infix procedures have any implied precedence, application order has to be explicitly defined by syntactic nesting hierarchy) ...
(let ((a 1) (b 2))
(if {a < b} {a := {b / {a + b}}} 0)
(define ns (list 1 2 3))
(define result (map - (cons a ns)))
result)
=> ‘(-2/3 -1 -2 -3)
(let ((a 1) (b 2))
(if {a < b} {a := {b / (+ a b)}} 0)
(define ns (list 1 2 3))
(define result (map - (cons a ns)))
result)
=> ‘(-2/3 -1 -2 -3)
(let ((a 1) (b 2))
(if (< a b) (set! a (/ b (+ a b))) 0)
(define ns (list 1 2 3))
(define result (map - (cons a ns)))
result)
=> ‘(-2/3 -1 -2 -3)
i.e. (or something like it)
<expression> :: [<literal>|<symbol>|<prefix-expression>|<infix-expression>]
<prefix-expression> :: (<procedure> [<arg>]*)
<infix-expression> :: {<arg> [<procedure> [<arg>]]
<arg> :: <expression>
… On Dec 2, 2024, at 5:20 AM, Damien MATTEI ***@***.***> wrote:
i agree with you, i expect a 100% backward compatibility or almost, we can not change the habit of users, having something we do not really when we can use infix or prefix would be bad.
It must be proposed a syntax where 'define' is always the way it used to works with prefix. For 'define-infix' i have the idea to detect nested 'define' and escape from infix mode to fallback to prefix one. This should be faisable.
Note that all this is possible with syntax transformers, not the way macro used to works with define-macro but with define-syntax and R6RS,R7RS. When i started the project i did not knew that so i was sticked to SRFI 105 and parser. Things has evolves since.
the notation should be able to write: (if (a < b) {a := b / (random 10)} 0)
in a 'define-infix' but if inside there is an inner definition with 'define' , one should be able to write
(if (a < b) {a := b / (random 10)} 0)
(define ns (list 1 2 3))
(define result (map - (cons a ns)))
result)```
the crucial part being here (map - ....) being not infix but prefix.
As the macros are basically recursive in a define-infix it will modify all the define arguments considering them infix, that i must change by detecting inner define in define-infix.
I have to perform tests about all that, because the system is becaming more and more complex, syntax transforming is done only one time ,so there is by chance no time penality in a looping program or recalling the same definitions.
But the more the system is complex ,this could lead to bugs.
Also i have 'def' that act as python allowing 'return' , i would have again a 'def' and a 'def-infix' , even if the 2 form are proposed, the best programming style would be to use the infix ones and only when necessary use inner define prefix ,they are very rare ,all that is just to do (map - ns) and sort of things that are 1% of programming but we can not leave that wrong or impossible....
—
Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOQAXGTS56Q6Q6D5ZNB34L32DQX7PAVCNFSM6AAAAABSV6GYP6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMJRGEZDMMRSGI>.
You are receiving this because you authored the thread.
|
|
yes my presentation is not good. historically there is: |
|
it is done (but not commited) , just a few lines to add at the good place: this allow define to be the usual way, the rest infix. But it is an endless story , toplevel statements not in a define should be parsed to , this will be done by a modified (module ... macro . not yet all tested but it shapes well. |
However I can't help but wonder if using a different syntactic brace "{}" to explicitly designate an intended pre/in/post-fix expression is truly required or even preferred, vs. identifying such an expressions from its context, i.e. possibly like:
<expression-type> ::
<literal-type>|<object-type>
(<function-type> <expression-type>*)
(<prefix-operator-type> <expression-type>)
(<expression-type> <infix-operator-type> <expression-type>)
(<expression-type> <postfix-operator-type>)
where an <object-type> or <function-type> must be defined via (def ...),
but whose value be modified via an assignment using (set! <object> <value>) or (<object> := <value>)
(Where it's assumed some sort of type analysis/conversion is performed with some order of precedence to enable a logical pairing between the <???-operator-type> and its operand(s) <expression-type>)
And for what it's worth, I'd tend to prefer use of a historical assignment operator such as ":=" in lieu of "<-".
Yielding something like:
(if (x<3) (x:=2*x^3) (set! x (x/2)))
The text was updated successfully, but these errors were encountered: