Stats

  • Locked Locked
  • Replies 7
  • Subscribers 143
  • Views 21003
  • Members are here 0
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Nested foreach loop

T Opperman

In an attemt to make parametric simulation scripts a bit more readable, I wrote a macro that allows foreach loops to be nested. I have not tested it fully, but I would like the readers' input on my code. The code generates a string containing the foreach loop, before evaluating it. It feels a bit clumsy, but I was unable to think of an simpler way to do this. Any suggestions? 

TOForeachNestFunc=lambda( (Symbols Lists Commands)
let(((DeclareLoopVars nil) (DeclareLoopHead "") (DeclareLoopBody "") (DeclareLoopTail "")
	(MainLoop "foreach( (") (LetStringHead "let((") Result )
;We'll need to create a loop that declares the expanded sweep lists,
;before creating a main loop that runs through all the expanded sweep lists and
;executes the commands.

	foreach((List Symbol) Lists Symbols
	 DeclareLoopVars=cons(sprintf(nil "%sS" Symbol) DeclareLoopVars)
	 DeclareLoopBody=strcat(DeclareLoopBody sprintf(nil "%sS=cons(%s %sS) " Symbol Symbol Symbol))
	 DeclareLoopHead=strcat(DeclareLoopHead sprintf(nil "foreach(%s '%L " Symbol List ))
	 DeclareLoopTail=strcat(DeclareLoopTail ")")
	 MainLoop = strcat(MainLoop Symbol " ")
	)
	MainLoop = strcat(MainLoop ") ")

	foreach(Var reverse(DeclareLoopVars)
		LetStringHead=strcat(LetStringHead "(" Var " nil) ")
		MainLoop = strcat(MainLoop Var " ")
		)
	LetStringHead=strcat( LetStringHead ")")
	MainLoop = strcat(MainLoop "\n" Commands "\n) ")
	Result=strcat(LetStringHead "\n" DeclareLoopHead "\n" DeclareLoopBody "\n" DeclareLoopTail "\n" MainLoop "\n" ")")
	)
)



defmacro(TOForeachNest (Symbols Lists @rest Commands)
;Executes a nested foreach loop
;Symbols: A list of variables that are used in the commands.
;List:A list of lists that contain the values to be swept
;Example: 
;	TempL= '(-40.0 27.0 85.0)
;	VSupplyL= '(3.2 3.3 3.4)
;
;	TOForeachNest('(Temp VSupply) list(VSupplyL TempL)
;	printf("Temperature: %e, Supply Voltage: %e", Temp VSupply)
;	)
;expands to:
;	foreach(Temp TempL
;		foreach(VSupply VSupplyL
;			printf("Temperature: %e, Supply Voltage: %e\n", Temp VSupply)
;)
;)

	let((CommandString)
	CommandString=sprintf(nil "%L" ,Commands)
		CommandString=substring(CommandString 2 strlen(CommandString)-2)
		`let((Result)
			Result=funcall(,TOForeachNestFunc ,Symbols ,Lists ,CommandString)
			evalstring(Result)
		)
	)
)
Parents

  • Tjaart,

    Macros are a bit of an art - there's an increasing number of them covered in Articles (formerly known as Solutions) on Cadence Online Support, and also in (say) the SKILL for the skilled blog on the Cadence web site - but I agree, having more examples in the SKILL User Guide would be a good idea.

    That said, I tend to advise against creating too many macros. As Peter Norvig writes in Paradigms of Artificial Intelligence [Case Studies in Common Lisp]:

    "The first step in writing a macro is to recognize that every time you write one, you are defining a new language that is just like Lisp except for your new macro. The programmer who thinks that way will rightfuly be extremely frugal in defining macros. (Besides, when someone asks, "What did you get done today?" ti sounds more impressive to say "I defined a new language and wrote a compiler for it" than to say "I just hacked up a couple of macros.") Introducing a macro puts much more memory strain on the reader of your program than does introducing a function, variable, or data type, and so it should not be taken lightly. Introduce macros only when there is a clear need, and when the macro fits in well with your existing system. As C.A.R. Hoare put it, "One thing the language designer should not do is include untried ideas of his own."

    Regards,

    Andrew.

Reply

  • Tjaart,

    Macros are a bit of an art - there's an increasing number of them covered in Articles (formerly known as Solutions) on Cadence Online Support, and also in (say) the SKILL for the skilled blog on the Cadence web site - but I agree, having more examples in the SKILL User Guide would be a good idea.

    That said, I tend to advise against creating too many macros. As Peter Norvig writes in Paradigms of Artificial Intelligence [Case Studies in Common Lisp]:

    "The first step in writing a macro is to recognize that every time you write one, you are defining a new language that is just like Lisp except for your new macro. The programmer who thinks that way will rightfuly be extremely frugal in defining macros. (Besides, when someone asks, "What did you get done today?" ti sounds more impressive to say "I defined a new language and wrote a compiler for it" than to say "I just hacked up a couple of macros.") Introducing a macro puts much more memory strain on the reader of your program than does introducing a function, variable, or data type, and so it should not be taken lightly. Introduce macros only when there is a clear need, and when the macro fits in well with your existing system. As C.A.R. Hoare put it, "One thing the language designer should not do is include untried ideas of his own."

    Regards,

    Andrew.

Children
No Data

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.