Trouble translating a C++ data-structure.

Trouble translating a C++ data-structure.

[Shark8]

I found a data-structure implemented in C++, a van Emde Boas Tree, and tried to write the equivalent in Ada, both using the dump-ada-spec flag w/ manual fixups AND a from-scratch transliteration, but was unable to really do so (my C++ is really rusty).

What would be a good translation?
https://github.com/diogomg/van-emde-boas-tree

Re: Trouble translating a C++ data-structure.

[Paul Rubin]

Shark8 <onewingedshark@gmail.com> writes:
> I found a data-structure implemented in C++, a van Emde Boas Tree,
> https://github.com/diogomg/van-emde-boas-tree

That is C not C++.  You should probably just read a description of the
algorithm and code from that.  The Wikipedia article looks like a
reasonable place to start:

https://en.wikipedia.org/wiki/Van_Emde_Boas_tree

Re: Trouble translating a C++ data-structure.

[gautier_niouzes]

The Wikipedia page refers to an article ("Design and implementation of an efficient priority queue", https://link.springer.com/article/10.1007%2FBF01683268) which contains a program in Pascal. I would go this way, using p2ada.
Here is an example of an algorithm taken straight from an article (scanned!):
https://unzip-ada.sourceforge.io/za_html/zip__adb.htm#17_11

Trouble translating a C++ data-structure.

[Dan'l Miller]

shark8 wrote:
> I found a data-structure implemented in C++, a van Emde Boas Tree,
> and tried to write the equivalent in Ada, both using the dump-ada-spec
> flag w/ manual fixups AND a from-scratch transliteration, but was unable
> to really do so (my C++ is really rusty). 

Which precise areas are the biggest gaps of understanding?  As pointed out above, this is garden-variety 1970s-era structured-programming non-OO C-language memory allocation from the heap.  There exist a multitude of before & after transliterations from C data structures to Ada from which to borrow various flavors of ideas about Ada-83-era or post-Ada-95-era properness in Ada.

Depending on how rusty your C/C++ knowledge is, people who reply wouldn't want to talk condescendingly to you about this matter here which you already know when what you need is that matter over yonder.

https://stackoverflow.com/questions/20879589/what-prevents-van-emde-boas-trees-from-being-more-popular-in-real-world-applicat

One observation though inherent in this data structure independent of skills, (as mentioned in the 2nd StackOverflow answer) it seems that the vEBTs inherently have a maximum universe size built into them:  referred to as M in their Wikipedia article in a prior reply.  Is, for example, some form of maximum storage-pool size in Ada a key design feature that you are seeking?  I mention this because the C-language heap implementation tries to bury/obfuscate M as much as possible by being heap-based.  The more that your Ada design emphasizes drastically different design goals (e.g., overtly showcasing what that other design obfuscates), the more that the Ada way will naturally differ from the C-language representation at that GitHub project.

Btw, Shark8/Edward, I took a look around your Byron Ada front-end work on GitHub.  Excellent work.  Please push ahead as much as time allows.  Along the “"functional" programming in Ada” posting's threads, I posted a vision of what one aspect of a drastically-not-GNAT modern Ada compiler could look like regarding multi-stage programming and/or source-code generation via generous amounts of compile-time reflection & some sort of Ada-get-it-right/elegant/not-Boost-C++-MTP analysis/reactions thereof via some sort of compile-time imperative or functional language.  Another drastically-not-GNAT open-source Ada compiler needs some sort of special-sauce thing that it does better as its killer app to attract people in.

(For Clang & LLVM displacing GCC at Apple and at FreeBSD, its special sauce seems to be written in modern-OO C++ instead of old clunky C.  GNAT's front end already is written in something far more lucid & OOish than old clunky C, so what is Byron's special sauce instead?  Perhaps a new top-level posting on comp.lang.ada instead of here.)

Re: Trouble translating a C++ data-structure.

[Shark8]

On Friday, March 9, 2018 at 9:24:39 AM UTC-7, Dan'l Miller wrote:
> shark8 wrote:
> > I found a data-structure implemented in C++, a van Emde Boas Tree,
> > and tried to write the equivalent in Ada, both using the dump-ada-spec
> > flag w/ manual fixups AND a from-scratch transliteration, but was unable
> > to really do so (my C++ is really rusty). 
> 
> Which precise areas are the biggest gaps of understanding?  As pointed out above, this is garden-variety 1970s-era structured-programming non-OO C-language memory allocation from the heap.  There exist a multitude of before & after transliterations from C data structures to Ada from which to borrow various flavors of ideas about Ada-83-era or post-Ada-95-era properness in Ada.

Essentially in translating the pointer-manipulations to proper subprograms with the proper parameter-modes. (ie using procedures where applicable, and using IN OUT instead of pointers.) -- As I said I did both a by-hand and using the spec-dump flag... I'm unsatisfied with the results, and think I might be missing things due to the rusty C.

> 
> Depending on how rusty your C/C++ knowledge is, people who reply wouldn't want to talk condescendingly to you about this matter here which you already know when what you need is that matter over yonder.

It's been about 10 years since I last touched C or C++... most of which was in school, and I was *NOT* a fan of either then (it's *always* seemed really dumb to me to use tools that are so error-prone when such errors are avoidable/detectable).

> 
> https://stackoverflow.com/questions/20879589/what-prevents-van-emde-boas-trees-from-being-more-popular-in-real-world-applicat
> 
> One observation though inherent in this data structure independent of skills, (as mentioned in the 2nd StackOverflow answer) it seems that the vEBTs inherently have a maximum universe size built into them:  referred to as M in their Wikipedia article in a prior reply.  Is, for example, some form of maximum storage-pool size in Ada a key design feature that you are seeking?

Tangentially.
I'm looking into some storage-pool ideas as it occurred to me that an access-type can be regarded as a mapping. Example:

Package EX is
   -- Access to Character.
   Type ACCESS_ID is private;
   Type POOL is private 
   
   Function  Deref( Item : ACCESS_ID; Memory : POOL ) return Character;
   Procedure Alloc( Item : Character; Memory : in out POOL; Result : out ACCESS_ID);

   NULL_VALUE : Constant ACCESS_ID;
Private
   Type ACCESS_ID is range 0..4;
   NULL_VALUE : Constant ACCESS_ID := ACCESS_ID'First;
   Subtype VALID_ID is ACCESS_ID range ACCESS_ID'Succ(NULL_VALUE)..ACCESS_ID'Last;

   -- Statically allocated chunk-o-memory.
   Type POOL is record
      Next : ACCESS_ID:= NULL_VALUE;
      Data : Array(VALID_ID) of Character;
   end record;
   
   Function Deref( Item : ACCESS_ID; Memory : POOL ) return Character is
    ( Memory.Data(Item) );
   Procedure Alloc( Item : Character; Memory : in out POOL; Result : out ACCESS_ID) is
   Begin
    Result := ACCESS_ID'Succ(Memory.Next);
    Memory.Next:= Result;
    Memory.Data(Result):= Item;
   Exception
    When Constraint_Error => Raise Storage_Error;
   End Alloc;
End EX;


(eg New String'("Steve") yields ACCESS_ID'( 128 ), and such.) This is of course covered in Ada's Storage_Pools package, but leaves the implementation up to the programmer. (A mark-and-release storage pool is one of the basic examples of using storage-pools I've found... 

So, I'd kind of like to be able to use a VEB for at least the tracking a set of used access-values + [quickly] getting the next unused item; a Trie can [possibly] replace the static-array in the above example perhaps enabling a more compact memory footprint. 

There's a lot of otherwise unnecessary restrictions due to the investigation for this being used in a DSA application. -- The main 'distributed' part of which is/will-be the DB [a distributed B-Tree].

> I mention this because the C-language heap implementation tries to bury/obfuscate M as much as possible by being heap-based.  The more that your Ada design emphasizes drastically different design goals (e.g., overtly showcasing what that other design obfuscates), the more that the Ada way will naturally differ from the C-language representation at that GitHub project.

This is true.

> 
> Btw, Shark8/Edward, I took a look around your Byron Ada front-end work on GitHub.  Excellent work.  Please push ahead as much as time allows.

Thank you; I'm going to put some more time into it after getting this DSA-MUMPS interpreter into a proof-of concept state. (I'm in contact with someone on the MUMPS standard-board, and likely going to be introduced to the rest of the board later this month... there's a chance, slim albeit, that this could be the new reference implementation -- which could help Ada: MUMPS is used in medical-records [the VA's entire system is MUMPS] and having an implementation in Ada would allow for some good interop, thus expanding the "where's it used" category.)

Right now I've isolated the parser -- https://github.com/OneWingedShark/Pratt_Parse -- and am testbedding on that to debug the implementation. (There's an error in precedence that I'd not been able to crack.)

>  Along the “"functional" programming in Ada” posting's threads, I posted a vision of what one aspect of a drastically-not-GNAT modern Ada compiler could look like regarding multi-stage programming and/or source-code generation via generous amounts of compile-time reflection & some sort of Ada-get-it-right/elegant/not-Boost-C++-MTP analysis/reactions thereof via some sort of compile-time imperative or functional language.  Another drastically-not-GNAT open-source Ada compiler needs some sort of special-sauce thing that it does better as its killer app to attract people in.

One thing I'd *REALLY* like to do is have the IR for my compiler be amiable to DB-storage; this would allow for the creation of a online-library/analog of CPAN... but instead of storing things as text-/source-files (or zipped-text, rather) and a index-file we could do it entirely in the DB. -- Moreover, we could have the system automatically take care of versioning (ie getting the correct library version needed).

(See: https://github.com/mosteo/alire/issues/1 )

> 
> (For Clang & LLVM displacing GCC at Apple and at FreeBSD, its special sauce seems to be written in modern-OO C++ instead of old clunky C.  GNAT's front end already is written in something far more lucid & OOish than old clunky C, so what is Byron's special sauce instead?  Perhaps a new top-level posting on comp.lang.ada instead of here.)

What do you mean by "top level posting"?

Well, I'm aiming for it to be not only HIGHLY portable, but extremely modular/maintainable... I'm going about that in the construction by having two main constructs a "translation"* and a "transformation"** and everything in the compiler being one of these -- thus a Phase is nothing more than a Translation. (eg "Parser( Input : Lexemes ) return IR", "Lexer( Source : Text ) return Lexemes" and "Reader( Input : File ) return Text" could be combined as "Frontend(Input : File) return IR is (Parser(Lexer(Reader(Input))))" while Lexer could itself be decomposed into various passes resulting in the proper stream of lexemes.)

Yeah, it's a very simple decomposition, but things like semantic-analysis could be done as a collection of simple transformation-functions and validators, perhaps exactly mirroring the LRM. (I haven't gotten into the semantic analysis, but this idea appeals to me in that it can allow things do be decomposed and maintained easily.)


*  Translation: F(Input : T1) return T2;
** Transformation: P(Data : in out T) OR F(Data : T) return T

Re: Trouble translating a C++ data-structure.

[Bojan Bozovic]

Shark8, look into Cormen/Leiserson/Rivest/Stein Introduction to Algorithms 3rd edition, there is reduced space van Emde Boas tree described, instead of using original research paper from seventies. I can't offer more help as I am a beginner.


https://www.amazon.com/Introduction-Algorithms-3rd-MIT-Press/dp/0262033844

Little googling will make you find it for free, though from illegal piracy sites.

Re: Trouble translating a C++ data-structure.

[Bojan Bozovic]

On Saturday, March 10, 2018 at 4:02:19 AM UTC+1, Bojan Bozovic wrote:
> Shark8, look into Cormen/Leiserson/Rivest/Stein Introduction to Algorithms 3rd edition, there is reduced space van Emde Boas tree described, instead of using original research paper from seventies. I can't offer more help as I am a beginner.
> 
> 
> https://www.amazon.com/Introduction-Algorithms-3rd-MIT-Press/dp/0262033844
> 
> Little googling will make you find it for free, though from illegal piracy sites.

Here it is, Google Books result on RS-vEB trees from Introduction to Algorithms 3rd edition.

https://books.google.rs/books?id=aefUBQAAQBAJ&pg=PA557&lpg=PA558&dq=RS-vEB+tree&source=bl&ots=dN4nTzZQ9W&sig=Hg0H8iUgbd4jSKpBG4nozGccrT8&hl=sr-Latn&sa=X&ved=0ahUKEwjZtdbX4-HZAhUIiCwKHSdZCqIQ6AEIMjAB#v=onepage&q=RS-vEB%20tree&f=false

Re: Trouble translating a C++ data-structure.

[Shark8]

On Saturday, March 10, 2018 at 5:45:10 AM UTC-7, Bojan Bozovic wrote:
> On Saturday, March 10, 2018 at 4:02:19 AM UTC+1, Bojan Bozovic wrote:
> > Shark8, look into Cormen/Leiserson/Rivest/Stein Introduction to Algorithms 3rd edition, there is reduced space van Emde Boas tree described, instead of using original research paper from seventies. I can't offer more help as I am a beginner.
> > 
> > 
> > https://www.amazon.com/Introduction-Algorithms-3rd-MIT-Press/dp/0262033844
> > 
> > Little googling will make you find it for free, though from illegal piracy sites.
> 
> Here it is, Google Books result on RS-vEB trees from Introduction to Algorithms 3rd edition.
> 
> https://books.google.rs/books?id=aefUBQAAQBAJ&pg=PA557&lpg=PA558&dq=RS-vEB+tree&source=bl&ots=dN4nTzZQ9W&sig=Hg0H8iUgbd4jSKpBG4nozGccrT8&hl=sr-Latn&sa=X&ved=0ahUKEwjZtdbX4-HZAhUIiCwKHSdZCqIQ6AEIMjAB#v=onepage&q=RS-vEB%20tree&f=false

Awesome; thank you for the links.

Re: Trouble translating a C++ data-structure.

[Dan'l Miller]

shark8 wrote:
> What do you mean by "top level posting"? 

New posting to comp.lang.ada, not a reply.

> Well, I'm aiming for it to be not only HIGHLY portable, but extremely modular/maintainable.

Which portions of GNAT are not “HIGHLY portable” for example?

On an entirely different topic in the 2nd half of the sentence above, the ultimate in “extreme modular”ity would be to remove all control-flow/looping/branching constructs from the core language, ‘reducing’ them to ‘mere’ libraries, as Alphard was pursuing in the 1970s.  Something similar could be done throughout other constructs in Ada, such as the specs, so that the core language is an extremely small language and Ada-as-we-know-it, Ada+Spark-as-we-know-it, Ada+ASIS-as-we-know-it, Ada+newFangledInnovations-yet-to-be-imagined, and so forth are •libraries•—not of subroutines & parameterized-types/generics, but of Ada-Reference-Manual semantics & syntax and so forth, much as Alphard at Carnegie Mellon University was envisioning back in the 1970s:  basically to back-apply more-modern concepts:  aspect-oriented programming (AOP) weavers on steroids.  Or in other words, what if the Ada Reference Manual was no longer English prose, but rather executable Alphard-esque code.  What if a stage of multi-stage programming was to compile the app's chosen weaving of Ada83 or Ada95 or Ada2012 or Ada+Spark or Ada+ASIS or Ada+somethingEvenMoreWow?  (Mary Shaw had a breakthrough in the making, but never finished it during the late 1970s, apparently because Greed/Red/Ada sucked all the air out of the room, leaving little budget/time/research-grants for Alphard.)  Now that truly would be the breakthrough for compiler front-ends that LLVM has been for compiler back-ends.  That would put Ada back in the driver's seat as the premier processor-native-machine-code compiled language, leap-frogging & eclipsing Clang as the perceived most-modern truly state-of-the-art among all the (open-source) compiler front-ends.  Plus, such multistage-programming modularity in the compiler front-end would unleash an explosion of new language evolution/extension in Ada (just when many people outside the Ada community think Ada is getting old & grey-haired needing to go to bed early each evening due to being out of energy each day).  It might even usher in an era of fervor for Ada unseen since the DoD chose Green over Red.

Or did you have something else in mind as “extreme modular”ity of an Ada front-end?

Re: Trouble translating a C++ data-structure.

[Randy Brukardt]

"Shark8" <onewingedshark@gmail.com> wrote in message 
news:7a285484-20b5-475e-b252-113b8a803785@googlegroups.com...
...
> Yeah, it's a very simple decomposition, but things like semantic-analysis
> could be done as a collection of simple transformation-functions and 
> validators,
> perhaps exactly mirroring the LRM. (I haven't gotten into the semantic 
> analysis,
> but this idea appeals to me in that it can allow things do be decomposed 
> and
> maintained easily.)

Sounds reasonable, but I have to think every compiler starts out with a 
grand vision of some sort. And then the real world intrudes and some part of 
that has to be given up in order for the result to be practical (for 
instance, Ada requires lengthy lookahead in some cases, so you'll probably 
find that you will want to cheat a bit and gather some information early to 
feed into later transformations). In our case, we also had to fit the result 
on very small machines, so keeping the program completely in memory was 
impractical (and thus we don't use trees for most of the compilation outside 
of expressions). Etc.

                                      Randy.

Re: Trouble translating a C++ data-structure.

[Mehdi Saada]

Could you try and explain for lowly laymen, what aspects weavers are ?
I suspect also that between the cathedral and bazaar models of software development, you prefer the bazaar. Right ?
I have nothing against more freedom to experiment, but without the prevalence of a small committee of sages and experts, the only thing freedom in decision making (liberalism ?) would convey, is CHAOS and Ada's demise. Plus, by definition I can't imagine the bazaar model for a mission-critical language.

Re: Trouble translating a C++ data-structure.

[Shark8]

On Monday, March 12, 2018 at 1:49:51 PM UTC-6, Mehdi Saada wrote:
> Could you try and explain for lowly laymen, what aspects weavers are?

I would like to know for-sure as well; my intuitive guess is something rather analogous to what EBNF is to syntax for semantics -- or, if you will, the executor/interpreter of subsequent stages of a multistage-grammar. 

See: https://en.wikipedia.org/wiki/Van_Wijngaarden_grammar and https://en.wikipedia.org/wiki/Attribute_grammar

> I suspect also that between the cathedral and bazaar models of software development, you prefer the bazaar. Right ?

I'm much more in the Cathedral camp; to the extent that I believe that the [TTBOMK] R-1000 was the closest to an ideal IDE that "the industry" has seen. See: http://www.somethinkodd.com/oddthinking/2006/01/07/introducing-the-rational-1000/

IMO it's just shameful that Ada doesn't have a standardized*, public, DB-based analog to CPAN.

* For some value of 'standard'; I'm not saying it should be part of the ARM/ISO standard, but certainly something that's open, "referencable" and usable.

Re: Trouble translating a C++ data-structure.

[Paul Rubin]

Mehdi Saada <00120260a@gmail.com> writes:
> Could you try and explain for lowly laymen, what aspects weavers are ?

It's a horrendous thing from the Enterprise Java world.  See:

https://en.wikipedia.org/wiki/Aspect-oriented_programming

> I suspect also that between the cathedral and bazaar models of
> software development, you prefer the bazaar. Right ?

From what I can tell, AOP is cathedral in the extreme.

Re: Trouble translating a C++ data-structure.

[Dan'l Miller]

This Wikipedia article on aspect weavers is more lucid than the AOP article.  AOP's aspect weavers excessively emphasize a SQL database-esque join, as if that is the only game in town.  Alphard at CMU preceding the SEI did not approach the cross-cutting problem-space that way.  Alphard approached the topic far less like AOP and far more like multi-stage programming, which itself is an extrapolation of compiler technology beyond the typical 4:  source-code begets in-memory intermediate representation (e.g., AST) begets virtual processor's register-set & instructions begets mapping virtual processor to a particular physical processor's register-set & instructions.  Multi-stage programming (and Alphard) inject at least one more ‘begets’ generated source code and/or at least one more ‘begets’ transformations in intermediate representation.  Perhaps the former there and certainly the latter can perform what AOP does with aspect weaving but without emphasizing the SQL-database-esque joins.

> Mehdi Saada wrote:
> > I suspect also that between the cathedral and bazaar models of 
> > software development, you prefer the bazaar. Right ? 

As a software architect much of my professional career, I am cathedral in the extreme.

Paul Rubin wrote:
> From what I can tell, AOP is cathedral in the extreme. 

AOP is database-cathedral applied to imperative programming languages.  Imagine something like 3rd-normal form for source code.  Hence, AOP contorts the topic excessively, and perhaps too limiting.

Read all of Mary Shaw's work on Alphard from the 1970s.  It approaches the problem-space that AOP tries to solve from an entirely different perspective (which the INRIA OCaml community also pursue differently decades later):  little languages.  Alphard envisioned the big monolithic PL/I, Ada (then Green), C++ (not yet extant then), and so forth as a community of little languages.  When viewing it all that way, getting the community of little languages to conform to the specification of a big monolithic language strongly resembles the problem-space that AOP is (botching) aspect weavers to do, especially regarding cross-cutting concerns.

https://en.wikipedia.org/wiki/Aspect_weaver

Re: Trouble translating a C++ data-structure.

[Paul Rubin]

"Dan'l Miller" <optikos@verizon.net> writes:
> This Wikipedia article on aspect weavers is more lucid than the AOP
> article.

Nice, I hadn't looked at the aspect weaver article before.  Yes it's
much more readable than the AOP article.

Do you actually use AOP?  Does Ada have it?  It comes across to me as a
glorified version of monkey patching (like in Ruby), but I haven't tried
it.  The wiki article also explicitly cites "advice", an Interlisp
feature that always seemed chaotic to me even as a Lisp aficionado,
and Lisp is as bazaar as it gets :).

OTOH I've seen claims that Haskell's monadic bind operation is something
like aspect weaving.  I can see some similarity but I don't have a sense
of how deep it is.

> Read all of Mary Shaw's work on Alphard from the 1970s.  It approaches
> the problem-space that AOP tries to solve from an entirely different
> perspective (which the INRIA OCaml community also pursue differently
> decades later): little languages.

Do you have a URL?  The Wikipedia article about Alphard isn't very
informative.  I don't see how the "little language" approach handles the
issue of cross-cutting that AOP purports to solve.

Thanks!

Re: Trouble translating a C++ data-structure.

[Dan'l Miller]

> Dan'l Miller wrote:
> > Read all of Mary Shaw's work on Alphard from the 1970s.  It approaches 
> > the problem-space that AOP tries to solve from an entirely different 
> > perspective (which the INRIA OCaml community also pursue differently 
> > decades later): little languages. 
Paul Rubin wrote:
> Do you have a URL?  The Wikipedia article about Alphard isn't very 
> informative.  I don't see how the "little language" approach handles the 
> issue of cross-cutting that AOP purports to solve. 

  Well, you asking for a URL to something nearly prehistoric in the Internet age.  But you are in luck, Google has scanned the best 37-year-old book on Alphard:

https://books.google.com/books?id=tvXSBwAAQBAJ&printsec=frontcover&dq=mary+shaw+alphard++form+and+content&hl=en&sa=X&ved=0ahUKEwi74eHouOrZAhVRt1MKHSZHAz4Q6AEIKTAA#v=onepage&q=mary%20shaw%20alphard%20%20form%20and%20content&f=false

I would recommend Parts V, VI, VII, VIII, IX, and X and the intervening Interludes.  The book is largely a compilation of the vision of Jon Bentley (Programming Pearls), William Wulf (BLISS; C.mmp MIMD), and Mary Shaw (CMU SEI).  Keep in mind, you will not see AOP jargon & solution-space in this far-earlier work.  To see it, requires a clever reading.

Re: Trouble translating a C++ data-structure.

[Dan'l Miller]

In Alphard (of which there were several different variants described, so the set-union thereof), everything is a form.  Here, form is not really a type (although when forms in Alphard are utilized to declare datatypes, forms sure look like parameterized/template/generic types).  Here, form is not really an Algol68 mode.  Here, form is really neither an OO object nor a class thereof.  Here, form is best though of is its ‘shape’ sense, as in lifeform or to form soft clay on a potter's wheel.  Everything is a form.  Integer is a form.  Each statement is a form.  If a programmer (or language-committee designer or compiler implementer) doesn't like a looping construct, the new looping construct can be •inherited• from the old one and then modified.  Same with integer forms, much the same as Ada's rich subtyping.  (I strongly suspect that Ichbiah lifted Ada's subtyping from Alphard's type-centric forms.)

Associated with each form can be, optionally, a generator and rewrite rules.  A generator can be thought of as a resumptive stateful function that can return/push a different value of a sequence multiple times from a single (initial-)invocation (which has its stack frames locked until the generator is terminated), but in Alphard it is better thought of as a compile-time-only pure-mathematical-definition, rather than a multiply-returning subroutine invoked & executed at runtime.  Hence, looping-construct forms (e.g., Alphard's for-loop form) use the counter generator, where the counter generator is inherited from integer along with its addition & subtraction operators.  Rewriting rules adapt Alphard's pure-mathematics notation into notations specified by a programming-language's syntax.  Examples given are:
1) Alphard itself lacks a dot notation to access fields of a record, as in myRecord.myField.  Instead, Alphard itself uses pure-mathematics function notation of myField(myRecord).  But rewrite rules transliterate between the 2 notations interchangeably.
2) Alphard itself lacks infix notation for operators (and postfix for that matter).  Instead, Alphard itself uses pure-mathematics function notation in its naturally prefix form plus(addend,addend).  But rewrite rules transliterate between the 2 notations interchangeably.

There exists an academic paper from the 1970s that shows a variant of Alphard that has syntax for declaring a form with a generator and with rewrite rules.  The example given is to emulate the syntax & semantics of various looping constructs in then-popular programming languages—PL/I, Fortran, and Algol68, if I recall correctly.  That paper was unfortunately omitted from the book that I linked to above.  I will need to dig through some old archive CDs to find that rarer paper.  Even so, forms, generators, and “special rewrite rules” are all described separately in the book that I linked to above.

But for those who want to cut straight to the chase scene,
a) form in Alphard is analogous to an aspect in AOP and the cross-cutting concerns thereof;
b) form+generator in Alphard is analogous to functions+sets in pure mathematics notation, which itself maps rather directly into deductive logic with processor's hardware restrictions as axiom system on which the logical deductions are founded;
c) logic deduction in Alphard is analogous to aspect weaving in AOP;
d) Alphard's late-1970s extensive work in provably-correct compilers via deductive-logic transforms is what feeds, say, an LLVM back-end (which strongly resembles what OCaml or even OCaml+Coq do in the modern era).

The name Alphard is to call to mind a multi-headed hydra via the star Alphard (Alpha Hydrae) constellation Hydra, where each form is a (co-equal-peer-)head of the hydra.  William Wulf's other project during that era (the first hypervisor, as utilized in the C.mmp MIMD confederation of PDP/11s) was also named Hydra.

If one wants to consider what a drastically-not-GNAT modular Ada compiler would look like, this would be one such re-think that had the best & brightest recognizable-brandname luminary minds of the same Ada83/Green-definition era contributing to it:  Wulf, Shaw, Liskov, Bentley, and so forth.  Alphard isn't intended to be a competitor of Ada; Alphard was obviously intended to be the design of the layers of the onion in the compiler-front-end beneath Ada, PL/I, and evermore-elaborate Fortran.

Re: Trouble translating a C++ data-structure.

[Shark8]

On Tuesday, March 13, 2018 at 1:52:21 PM UTC-6, Paul Rubin wrote:
> 
> Do you have a URL?
> 
> Thanks!

Try this; Magnet-URI for Torrent:
magnet:?xt=urn:btih:E10F82C60B3EAF8E35AB63DB980A1049E1370FF4&dn=a4ac7bc75d86875f7040794e88af1e99&tr=http%3a%2f%2flgtracker.org%2fannounce

You'll have to rename the contained file to PDF.

Re: Trouble translating a C++ data-structure.

[Bojan Bozovic]

On Wednesday, March 14, 2018 at 4:14:04 AM UTC+1, Shark8 wrote:
> On Tuesday, March 13, 2018 at 1:52:21 PM UTC-6, Paul Rubin wrote:
> > 
> > Do you have a URL?
> > 
> > Thanks!
> 
> Try this; Magnet-URI for Torrent:
> magnet:?xt=urn:btih:E10F82C60B3EAF8E35AB63DB980A1049E1370FF4&dn=a4ac7bc75d86875f7040794e88af1e99&tr=http%3a%2f%2flgtracker.org%2fannounce
> 
> You'll have to rename the contained file to PDF.

That magnet link doesn't work for me, as there are no seeds. The book can be found here http://repository.cmu.edu/isr/870/

Re: Trouble translating a C++ data-structure.

[Paul Rubin]

Bojan Bozovic <bozovic.bojan@gmail.com> writes:
> That magnet link doesn't work for me, as there are no seeds. The book
> can be found here http://repository.cmu.edu/isr/870/

Thanks!  Download is 27MB which will take a while from here, but I
started it going.  Will look at the book when I get a chance.