3 ms·

- The plan was originally to design a syntax for a simple scripting language; but the more I designed it, the more I saw the ability to just bring in the rest o

by asvln 5y ago

- The plan was originally to design a syntax for a simple scripting language; but the more I designed it, the more I saw the ability to just bring in the rest of the language. To represent all of Rust with only only a small set of ASCII characters, while keeping visual noise to a minimum, and still representing what the code was supposed to do was quite a riddle. I enjoy riddles. - Changing lifetimes was due to the fact that ` does not conflict with any other part of Rust, I felt the concept of lifetimes deserved its own symbol, and it is much more readable when used as a prefix/suffix on a set of letters. - The // characters stand out in a group of letters and numbers moreso than ||. In this manner, I can add highlight/significance to closure calls which can be deeply nested in function calls which are mainly chars [a-Z]. Also if you imagine you are in a circle: things loop in a straight line ||, but // would be take you on a diverging path. - "analogous" "strictly transitive (by analogy) but you using it intransitively (as it were)" This is very much intentional. Nouns do not exist in the real world, everything is verbing all the time. Languages have failings, they depend on the users of the language to use/redefine it as they see applicable. The initial goal was to design an 'analogical' language. Or in other words: a language in which it's symbolic representation would correlate to the concepts being implemented. The first commit of the repo exemplifies this more. - The macros can be translated directly into Rust, the first example is valid. Indentation would be substituted for a { on the macro call and the end of indentation would signify the }. As far as I know, leading and trailing whitespace is not a concern with Rust's macro system. a) Making its own macro system would be futile considering most expressions haven't changed. It just requires more cognitive overhead to remember the ),; where applicable, but at least you only have to think about that stuff in macro calls. b) If someone had to fallback to Rust when wanting to use this syntax, then the whole thing would be pointless and I would lament my time spent designing it to not learning how to bake crumb cake. c) Now that's a lot of syntax trees...

chrismorgan 5y ago
I think you’re missing the complexity of macros: they’re not just Rust or not-Rust, they can mix and match, including using Rust-like syntax. Take this macro stub for example (implemented as a procedural macro, if you want to make it harder): macro_rules! alpha { ( $(<$($beta:ident),* $(,)?>)? for $gamma:ty; $(#[$delta:meta])* struct $epsilon:ident default $zeta:expr; ## $eta:tt // And I’m not telling you how I’m using this one $theta:item ) => { … }; } I can’t see any way to make this work with Analog syntax in such places as $gamma, $zeta and $theta (and who knows about some of the others like $eta?). I’ve made this a fairly extreme example, but simpler examples that are still problematic are widespread.
- asvln 5y ago
  I think you misunderstood, or I am misunderstanding what you are trying to communicate. There would be no attempt to change any syntax within macro calls. All token trees fed into any macro would be fed directly with the exception of the implied braces when indenting the call.
  - chrismorgan 5y ago
    In your println! example, you’ve written Analog syntax, but it must be being translated into Rust syntax for the macro to consume. How are you going to decide what to translate and what not to? Perhaps I might put it this way instead: can you write out for me what an invocation of that alpha macro (which is defined in Rust code) from Analog might look like?
    - asvln 5y ago
      You are absolutely correct, apologies I just saw it now. It was a remnant that got left over. I now see the issue this raises and have discovered a solution through a macro!! call.

by asvln 5y ago

chrismorgan 5y ago

I think you’re missing the complexity of macros: they’re not just Rust or not-Rust, they can mix and match, including using Rust-like syntax. Take this macro stub for example (implemented as a procedural macro, if you want to make it harder): macro_rules! alpha { ( $(<$($beta:ident),* $(,)?>)? for $gamma:ty; $(#[$delta:meta])* struct $epsilon:ident default $zeta:expr; ## $eta:tt // And I’m not telling you how I’m using this one $theta:item ) => { … }; } I can’t see any way to make this work with Analog syntax in such places as $gamma, $zeta and $theta (and who knows about some of the others like $eta?). I’ve made this a fairly extreme example, but simpler examples that are still problematic are widespread.

asvln 5y ago
I think you misunderstood, or I am misunderstanding what you are trying to communicate. There would be no attempt to change any syntax within macro calls. All token trees fed into any macro would be fed directly with the exception of the implied braces when indenting the call.
- chrismorgan 5y ago
  In your println! example, you’ve written Analog syntax, but it must be being translated into Rust syntax for the macro to consume. How are you going to decide what to translate and what not to? Perhaps I might put it this way instead: can you write out for me what an invocation of that alpha macro (which is defined in Rust code) from Analog might look like?
  - asvln 5y ago
    You are absolutely correct, apologies I just saw it now. It was a remnant that got left over. I now see the issue this raises and have discovered a solution through a macro!! call.