[M3devel] source paths to generics?

[Rodney M. Bates]

On 06/29/2016 11:49 PM, Jay K wrote:
> I guess neither of us looked outside of m3front.
> The code runs. Not clear if the strings can get output.
> Maybe from asserts or Compiler.ThisFile in a generic?
> I"ll try some more.
>

I started looking in all of m3-sys, since the different compiler
packages there are linked together into cm3.  Later, I
looked in the entire cm3 repo and didn't see anything.
In any case, since it's part of the compiler, it really would be
strange to call it from outside m3-sys.

But if it is executing, we must have missed something.  How did you
find it executing?  In a debugger?  Can you do a backtrace?

> jair:m3core jay$ grep -i parseimp ../../m3-sys/cm3/src/Builder.m3
>      ids := M3Front.ParseImports (source, s.m3env);
>
>
>   - Jay
>
>
> ----------------------------------------
>> Date: Wed, 29 Jun 2016 19:34:13 -0500
>> From: rodney_bates at lcwb.coop
>> To: m3devel at elegosoft.com
>> Subject: Re: [M3devel] source paths to generics?
>>
>> Hmm. I poked around a bit, and it looks like there is some cruft here,
>> left over from something.
>>
>> The only call I can find on M3Header.Parse is M3Front.m3:37. This is
>> in M3Front.ParseImports. I can find no calls on that at all. (There
>> are other procedures by this name.)
>>
>> Also, it appears M3Header.ParseImports actually collects the exports, the imports,
>> the generic actuals.
>>
>> As for the concocted (by M3Header) name of the form <instantiation> => <generic>,
>> this looks to be used only to initialize the scanner's file number while scanning
>> up through the formals of the generic, but that is not used.
>>
>> On 06/29/2016 11:34 AM, Jay K wrote:
>>> There is similar code in Module.m3 and that is the code producing
>>> the data "I don't like".
>>>
>>> M3Header isn't dead but I haven't seen it run yet.
>>>
>>> I changed them from "=>" to "1=>" and "2=>" and looked
>>> where those occur in the output .s files under -keep.
>>>
>>> This is kinda something I wish were easier, like more strings
>>> need to be longer for easier finding w/o ambiguity (the flip
>>> side of my context arguments!)
>>>
>>> As things stand, I can't check that in.
>>> I suppose maybe with a CG.comment but nevermind.
>>>
>>> - Jay
>>>
>>>
>>>
>>> ----------------------------------------
>>>> From: jay.krell at cornell.edu
>>>> To: m3devel at elegosoft.com
>>>> Subject: RE: [M3devel] source paths to generics?
>>>> Date: Wed, 29 Jun 2016 15:22:14 +0000
>>>>
>>>> mfront/src/misc/M3Header.m3 has this:
>>>>
>>>>
>>>> (* build a synthetic file name & start reading *)
>>>> filename := old_filename & " => " & filename;
>>>> Scanner.Push (filename, s.generic, is_main := Scanner.in_main);
>>>>
>>>>
>>>> and instantiated generics aren't what I thought.
>>>> I thought the build system or compiler did a textual
>>>> substitution of the generic parameters into the entire implementation,
>>>> and saved that to the file system,
>>>> and had the assert/debug paths point to it.
>>>>
>>>> So could step through what looks exactly like an .m3 file.
>>>>
>>>> But it doesn't. The instantiated file is a little stub, like:
>>>>
>>>> jair:libm3 jay$ more I386_DARWIN/TextAtomTbl.m3
>>>> (*generated by m3build*)
>>>>
>>>> MODULE TextAtomTbl = Table (Text, Atom) END TextAtomTbl.
>>>>
>>>>
>>>> so I have one or two proposals.
>>>>
>>>> 1) old_filename above contains the target, it looks like:
>>>>
>>>> "../I386_DARWIN/TextAtomTbl.m3 => ../src/table/Table.mg"
>>>> or
>>>> "../I386_DARWIN/TextAtomTbl.m3 => ../src/table"
>>>>
>>>> These both occur.
>>>> I'm not sure what the second is, seems like a mistake.
>>>>
>>>> I suggest the first string in both pairs be changed to be the leaf element, like:
>>>>
>>>> "TextAtomTbl.m3 => ../src/table/Table.mg"
>>>> or
>>>> "TextAtomTbl.m3 => ../src/table"
>>>>
>>>> and maybe the second string in both cases should be as it is in the second pair.
>>>>
>>>> 2) Possibly it should reall just be:
>>>> ../src/table/Table.mg
>>>>
>>>> and developer can step through that, knowing that it is a somewhat abstracted
>>>> form of what is running
>>>>
>>>> I'm willing to do this under like:
>>>>
>>>> CONST TemporaryForTargetConvergence = TRUE
>>>>
>>>> or
>>>> VAR TemporaryForTargetConvergence: BOOLEAN;
>>>>
>>>> and a command line switch, but I suspect it isn't really useful to anyone asis,
>>>> so might as well remove target unconditionally.
>>>>
>>>>
>>>> ?
>>>>
>>>> - Jay
>>>>
>>>>
>>>>
>>>> ----------------------------------------
>>>>> From: jay.krell at cornell.edu
>>>>> To: m3devel at elegosoft.com
>>>>> Date: Wed, 29 Jun 2016 09:44:51 +0000
>>>>> Subject: [M3devel] source paths to generics?
>>>>>
>>>>> I haven't fully verified this, but it appears for example if I debug a generic, or fail an assert in a generic,
>>>>> the source file I am told about is the instantiated i3/m3 file.
>>>>>
>>>>> This isn't particularly useful for the programmer or convenient for the compiler, right?
>>>>>
>>>>> The programmer would rather see the .ig/.mg files, and this is easy to provide in the compiler?
>>>>> I guess it is slightly easier in the compiler, but easy to do better?
>>>>>
>>>>> I should look into make it so?
>>>>>
>>>>> My real agenda is I want to see:
>>>>> ../src/foo.mg
>>>>>
>>>>> instead of
>>>>> I386_DARWIN/foo.m3
>>>>>
>>>>> I don't want the target variation, but other points seem true also, right?
>>>>>
>>>>> Right? The line numbers match between them, and the generic syntax is so close to "normal" that a programmer not used to it won't be confused, right?
>>>>>
>>>>> I'll try to poke around more.
>>>>>
>>>>> - Jay
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> M3devel mailing list
>>>>> M3devel at elegosoft.com
>>>>> https://m3lists.elegosoft.com/mailman/listinfo/m3devel
>>>>
>>>
>>> _______________________________________________
>>> M3devel mailing list
>>> M3devel at elegosoft.com
>>> https://m3lists.elegosoft.com/mailman/listinfo/m3devel
>>>
>>
>> --
>> Rodney Bates
>> rodney.m.bates at acm.org
>> _______________________________________________
>> M3devel mailing list
>> M3devel at elegosoft.com
>> https://m3lists.elegosoft.com/mailman/listinfo/m3devel
>   		 	   		
> _______________________________________________
> M3devel mailing list
> M3devel at elegosoft.com
> https://m3lists.elegosoft.com/mailman/listinfo/m3devel
>

-- 
Rodney Bates
rodney.m.bates at acm.org